Génère clé SSH

Version imprimable

21/10/2008, 15h55
Noizet

Génère clé SSH

Bonjour,

J'ai génère une paire de clé afin de ne plus devoir rentrer le mot de passe à chaque fois que je me connecte sur le serveur.

J'ai suivie l'exemple montré sur : http://lipforge.ens-lyon.fr/www/weba...e/cle-ssh.html

Le problème est que le serveur me met l'erreur suivant que je veux me connecter pour la première fois :the authenticity of host 'monServeur.ch' can't be established. RSA key fingerprint is.....

Et ensuite, il me redemande à chaque fois le password, qqun aurait une idée de la source du problème ?

merci de votre aide!
21/10/2008, 16h11
dtrosset

Bonjour,

Alors l'erreur "the authenticity of host 'monServeur.ch' can't be established." je ne vois pas trop.

Par contre, il faut aussi bien mettre les bonnes permissions aux repertoires et fichiers afin que le login soit automatique : ~/.ssh doit être drwx------ et ~/.ssh/authorized_keys doit être -rw-------.

Didier
21/10/2008, 16h21
Noizet

Ils ont ces droits, mais ça ne fonctionne toujours pas :-(
21/10/2008, 16h46
jmelyn

Bonjour,

C'est un peu compliqué à tout expliquer comme ça. En gros, l'authentification SSH se fait en deux étapes: D'abord il faut que la machine cliente soit reconnue et ensuite que l'utilisateur soit reconnu.

Pour la première étape, il est nécessaire de prendre la clé de la machine cliente et de la donner au serveur. Il y a 3 types de clés: RSA1, RSA et DSA. À voir le message, il faut prendre la clé publique RSA: /etc/ssh/ssh_host_rsa_key.pub et la mettre à la fin du fichier /etc/ssh/ssh_known_hosts du serveur.

Pour la seconde étape, il faut faire la même chose mais avec la clé publique de l'utilisateur: clé sur la machine cliente: ~/.ssh/id_rsa.pub si on prend la clé RSA et la copier dans le répertoire utilisateur (ça peut être un utilisateur différent) de la machine serveur: ~/.ssh/authorized_keys.

Si ça ne marche toujours pas, il faudra vérifier les configs du client et du serveur...

PS: le répertoire ~/.ssh doit avoir les droits: rwx------ et le bon owner: l'utilisateur. Par contre, authorized_keys comme toutes les clés publiques peuvent être lisibles par tous. Ce sont les clés privées (sans le .pub) qui doivent être rwx------.
21/10/2008, 17h52
mess-mate

Jmelyn a très bien expliqué le fonctionnement.
Mais j'ajouterai:
- il faut toujours donner le mot de passe, allons c'est une connexion sécurisée.
- la première fois que tu te connecte il y a en effet un message venant de ta machine qui t'avertis et demande si tu veux continuer; tu répond tout simplement oui ou yes.

Regarde maintenant dans ta ./ssh, tu y trouve:know_hosts et tes cléfs *rsa et *rsa.pub.

Tu as peut-être déjà fait des manips qu'il ne fallait pas. Le plus simple dans ton cas est de supprimer toutes les lignes se trouvant dans ta ./ss/know_hosts.

Tu te reconnecte maintenant à ton autre machine et tu répond oui et ensuite tu entre ton mot de passe lorsqu'il te le demandera.

Si ça marche pas c'est tu as fait trop de choses qu'il ne fallait pas.
Seul moyen rapide dans ce cas est de déinstaller et purger openssh et réinstaller openssh. Il te demandera ce qu'il faut et tu répond oui.
N'oublis pas non plus de supprimer ta ./ssh avant la réinstall.
Voilà
21/10/2008, 19h07
jmelyn

@ mess-mate:

- il faut toujours donner le mot de passe, allons c'est une connexion sécurisée.

Heureusement que non! SSH peut fonctionner avec mot de passe ou clés, c'est dans la config que l'on décide (/etc/ssh/ssh_config et /etc/ssh/sshd_config). Comme exemple personnel au boulot, lorsque je suis connecté avec mon user sur une machine, je peux me connecter sur n'importe quelle autre machine comme user root sans mot de passe :D.

- la première fois que tu te connecte il y a en effet un message venant de ta machine qui t'avertis et demande si tu veux continuer; tu répond tout simplement oui ou yes.

C'est pareil: heureusement que non! Ce cas survient si le fichier /etc/ssh/ssh_known_hosts n'est pas à jour.

Enfin, il est possible de regénérer les clés de façon propre (man ssh-keygen). C'est faisable, j'ai régulièrement testé pour le partage de clés.
21/10/2008, 19h26
Noizet

Merci de vos réponses !
Alors, j'ai utilisé ssh-keygen pour générer mes clés et j'ai également répondu yes au message qui apparait quand je me connecte la première fois! Mais ça ne fonctionne toujours pas, je dois quand même à chaque fois remettre le mot de passe.

Pour refaire fonctionner, je dois déinstaller et purger openssh sur le serveur ou la machine locale ? Que veux-tu dire par purger ?

Encore une question, mes clés sur la machine local sont enregistré dans le dossier admin (dossier choisi par ssh-keygen) est-ce que c'est normal ou est-ce que je dois les mettre dans un dossier particulier
21/10/2008, 19h58
jmelyn

Comme cela a été écrit, les clés user doivent être dans le répertoire ~/.ssh. Si c'est une clé RSA (créée par la commande: ssh-keygen -t rsa), les deux fichiers doivent s'appeler id_rsa et id_rsa.pub. Si les fichiers ne sont pas bien placés, ça ne marchera pas! Et pareil du côté serveur: faire clé_client.pub >> ~/.ssh/authorized_keys, en supposant que cle_client est la clé publique générée sur le client puis transférée sur le serveur.

Pour voir le problème lors de la connexion ssh, tu peux faire: ssh -vvv serveur. Et tu postes la sortie ici.
21/10/2008, 21h26
mess-mate

Citation:

Envoyé par jmelyn

@ mess-mate:

- il faut toujours donner le mot de passe, allons c'est une connexion sécurisée.

Heureusement que non! SSH peut fonctionner avec mot de passe ou clés, c'est dans la config que l'on décide (/etc/ssh/ssh_config et /etc/ssh/sshd_config). Comme exemple personnel au boulot, lorsque je suis connecté avec mon user sur une machine, je peux me connecter sur n'importe quelle autre machine comme user root sans mot de passe :D.

Se connecter en tant que root ???
Se serait pas chez moi en tout cas.
Bonjour la sécurité !!

On se logge en tant que user et si on a les droits sur cette machine en tant que root, ensuite on fait un 'su' et on est parti en tant que root.
:mrgreen:
Pour les clefs:
comme déjà dit et jemelyn il y a 2 clefs générés lors de l'installation de openssh, la privé et la pub.
Maintenant, quand on se logge à une machine distante une clef ( je l'appelle comme ça) est généré également lorsque tu l'as autorisé. Cette dernière se trouve dans ./ssh/know_hosts. Le mot le dit par lui-même, host connu.

Il faudra donc de cette façon toujours donner son mot de passe vu que tu y a un compte.
Maintenant ceux qui ne veulent pas c'est leur/votre affaire.
22/10/2008, 00h22
jmelyn

Se connecter en tant que root ???
Se serait pas chez moi en tout cas.
Bonjour la sécurité !!

Ma clé publique RSA se trouve sur toutes les machines (plus de 400) dans le répertoire /root/.ssh/authorized_keys. De ce côté-là, aucun problème de sécurité. Ma clé privée se trouve sur un serveur AFS dont la sécurité est gérée par Kerberos 5. De ce côté-là, pas de problème non plus. Il reste que je ne dois pas rester logué lorsque je quitte un ordi. C'est ce que je fais. Donc niveau sécurité, y'a pas de blème. De ma console, il me suffit de taper "ssh root@machine" pour me retrouver une fraction de seconde plus tard root sur ladite machine. Comme c'est une grosse partie de mon travail, ça m'évite de taper le mot de passe root toutes les minutes. Cool...

Pour ce qui est des clés ordi, je ne me fie pas à ce qu'il y a dans ~/.ssh/known_hosts: En fait, je vire régulierement ce fichier. Par contre, c'est dans /etc/ssh/ssh_known_hosts que je tiens à jour la liste des clés ordi. Pourquoi? Parce que de cette manière, tous les utilisateurs profiteront des clés; autrement dit, plus personne n'aura de problème chaque fois qu'on ré-installe une machine (il faut alors lancer la commande ssh-keygen -R machine pour supprimer la clé périmée, puis taper 'yes' au premier ssh). Et surtout certains programmes utilisent directement ssh mais ne sont pas capables de lire la question et de répondre. Faut que ça marche du premier coup!
22/10/2008, 10h05
mess-mate

On a des divergences de vue là.
Je maintiens ce que j'ai dit et à chacun ses opinions.
On oublie très souvent ce qui se ballade sur le fil.
Mais j'ai l'impression qu'on dépasse un peu le cadre de cette discussion = la question de Noizet à laquelle tu as répondu et où j'ai fait une mise en garde.
22/10/2008, 11h33
jmelyn

C'est vrai que ça dépasse le sujet initial. Mais lorsque les arguments sont clairs et que cela permet d'apporter des lumières aux autres lecteurs, inutile de se priver, n'est-ce pas?

En ce qui concerne les arguments pour les clés SSH, voici ce que je peux dire:
* La clé publique ne risque pas grand-chose puisqu'elle est publique.
* La clé privée est particulièrement sensible et ne doit jamais être divulguée. Si la home-dir est sur NFS (sauf NFSv4), la sécurité n'est pas assurée. Kerberos, qui permet d'authentifier de manière sure les utilisateurs, est utilisé dans NFSv4 et AFS. Si la home-dir est locale, il faut voir qui sont les admins (qui a le mot de passe root, qui est sudoer). L'accès à la home-dir peut aussi se faire directement, à midi ou la nuit si l'utilisateur ne se délogue pas!
* Il vaut mieux utiliser la version 2 de SSH, qui est normalement plus sure. À régler dans /etc/ssh/ssh_config (réglage du client), le serveur étant capable de répondre aux deux protocoles.
* Il n'y a aucun problème si le réseau est non sûr (typiquement Internet): par SSH tout est crypté, mot de passe compris. Par exemple, si je copie un fichier mp3 ou avi par SCP (basé sur SSH), impossible de savoir ce qui est transféré en écoutant le réseau.

Finalement je maintiens, en argumentant, que l'utilisation de clés pour SSH est sure, même pour root. En évitant les quelques pièges décrits ci-dessus.
22/10/2008, 16h23
mess-mate

Bon, je vais terminer la discussion avec ceci:
http://www.linux.com/feature/61061
A lire d'urgence.
27/10/2008, 15h25
Noizet

Hello,
Merci de vos réponses, mais je dois toujours entré le mot de passe et je ne comprend pas ce que je fais de faux !

Certaine chose on changé, je ne peux plus rien mettre sur le serveur (clé)

On m'a donné trois clés publiques (ssh_host_rsa_key , ssh_host_key, ssh_host_dsa_key)

Voilà ce que j'ai fait en essayant de suivre vos conseils :roll:

1° J'ai mis la clé ssh_host_dsa_key dans le dossier home/.ssh (machine locale) et je l'ai renommé en authorized_keys.pub

2° J'ai mis la clé ssh_host_rsa_key dans le dossier home/.ssh (machine locale) et je l'ai renommé en known_hosts

3° Je me suis connecter depuis la console en mode ssh sur le serveur, il m'a mis un message, j'ai mis yes et j'ai entré le mot de passe.

Voilà, et depuis, je dois toujours rentré le mot de passe :?

Est-ce que vous pouvez m'expliquer ce que je fais de faux !

Merci beaucoup !
27/10/2008, 17h33
jmelyn
Bonjour,

Si tu as lu ce qu'il y a d'écrit dans ce fil, tu n'as pas dû comprendre grand-chose. Si tu veux comprendre, relis et demande si ça coince.

Tu parles de trois fichiers que l'on t'a passés. J'espère que ce sont bien les clés publiques. Pour vérifier, tape les commandes grep PRIVATE ssh_host_key, puis grep PRIVATE ssh_host_rsa_key, et enfin grep PRIVATE ssh_host_dsa_key. Normalement, ça ne devrait rien sortir.

Tu remarqueras que ces trois fichiers (ssh_host_key, ssh_host_rsa_key, ssh_host_dsa_key) comportent le mot host. Ce sont trois clés ordi qui t'éviteront de répondre à la question:
The authenticity of host 'XXXXX (123.456.789.012)' can't be established.
RSA key fingerprint is ..........
Are you sure you want to continue connecting (yes/no)?
Il faut que tu mettes ces trois clés dans le fichier ~/.ssh/known_hosts de la machine cliente. Pour ce faire, tape les commandes (depuis la machine cliente):
Code:

1 2 3 cat ssh_host_key > ~/.ssh/known_hosts cat ssh_host_rsa_key >> ~/.ssh/known_hosts cat ssh_host_dsa_key >> ~/.ssh/known_hosts
Maintenant, il faut transmettre ta clé publique d'utilisateur au serveur. Je ne sais pas comment tu peux la tranmettre (e-mail, répertoire commun, NFS ou autre), à toi de voir. Le ou les fichiers que tu dois transmettre se trouvent sur la machine cliente dans ton répertoire ~/.ssh: Tous ceux qui se terminent par ".pub" doivent être copiés vers le serveur. Si tu ne trouves aucun fichier ".pub" dis-le, il y a une manip supplémentaire à faire. Il peut y avoir 3 fichiers max: identity.pub, id_rsa.pub, id_dsa.pub. Une fois ces trois fichiers copiés, tu te connectes sur le serveur avec le bon user et tu ajoutes les trois fichiers à ~/.ssh/authorized_keys. Voici comment faire:
Code:

1 2 3 cat identity.pub > ~/.ssh/authorized_keys cat id_rsa.pub >> ~/.ssh/authorized_keys cat id_dsa.pub >> ~/.ssh/authorized_keys
J'espère que tu liras correctement ce post pour faire les manips.
27/10/2008, 20h14
Noizet

Merci de ta réponse, désolé je n'ai jamais utiliser ssh auparavant ! :(

Je n'ai aucun .pub dans le fichier .ssh, quelle est la manipulation à faire ?

Je sais comment générer la clé dsa et rsa, mais pas la dernière

.ssh n'est pas un fichier mais un sous-répertoire de ~ (c'est-à-dire $HOME). Pour créer les clés, il faut le faire avec la commande ssh-keygen:
Code:

1 2 3 4 5 6 7 8 9 ssh-keygen -t rsa1 Generating public/private rsa1 key pair. Enter file in which to save the key (/home/user/.ssh/identity): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in identity. Your public key has been saved in identity.pub. The key fingerprint is: xx:yy:.... user@machine.domaine
Il suffit de juste taper "Enter" aux trois questions. Idem pour les autres clés: ssh-keygen -t rsa et ssh-keygen -t dsa. Maintenant, il devrait y avoir six fichiers supplémentaires dans le répertoire .ssh.

28/10/2008, 10h21
Noizet

Rebonjour,

J'ai suivi à la lettre les manips que tu as décrites.

- J'ai mis les trois clés publiques du serveur dans le fichier ~/.ssh/known_hosts de la machine locale
- J'ai générer les clés identity, rsa et dsa, j'ai mis les publiques sur le serveur (~/.ssh/autorized_keys)

Ca ne fonctionne toujours pas. Pourtant, il me semble que les sous-répertoires .ssh sont à la bonne place, car quand j'exectue la commande ~/.ssh, il arrive directement dans .ssh
28/10/2008, 11h11
jmelyn

Bon, cela devient clair et précis, les actions que tu as effectuées vont dans le bon sens. Il reste encore des points flous comme les users et home-dirs des comptes sur les machines cliente et serveur: Est-ce le même compte? Est-ce un home-dir commun?

Il faudra s'attaquer aux configurations des machines cliente et serveur. Mais pour l'instant, afin d'affiner le diagnostic, il faudrait lancer la commande suivante:

Code:

[user_client@machine_cliente] ~ $ ssh -vvv user_server@machine_serveur

La partie en gras est le prompt (donc pas à taper) pour indiquer où tu es et avec quel user. La sortie sera assez verbeuse, mais il faudrait tout mettre ici, entre balises [ CODE ] et [ /CODE ].

Edit: Il faudra être plus précis dans les constatations. "Ça ne fonctionne pas" n'est pas suffisant, les détails sont les bienvenus. De plus, j'imagine que tu parles de la commande ssh-keygen, pas ~/.ssh.
28/10/2008, 12h06
Noizet

Alors, ce qui fonctionne pas, c'est que je dois remettre le mot de passe à chaque fois que je me connecte.

la comande ssh-keygen, fonctionne sans problème!

Non ce n'est pas les même users entre la machine cliente et le serveur.

Par contre, comment je fais pour copier ce qu'il m'a écrit dans le dos ? Je ne peux pas sélectionner..
28/10/2008, 12h20
jmelyn

C'est étrange, dans la console où je tape la commande je peux sélectionner le texte. Sinon, il faut tout écrire dans un fichier puis faire le copier-coller après coup. Voici comment faire:

Code:

ssh -vvv user_server@machine_serveur &> ssh.out

Tu attends quelques secondes puis tu tapes Ctrl + D pour la déconnexion. Un fichier ssh.out de quelques Ko devrait apparaître dans le répertoire courant. Tout est dedans.

Voilà ce que ça me sors :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
C:\Documents and Settings\Administrateur>ssh -vvv user@monServeur.ch
OpenSSH_4.3p2, OpenSSL 0.9.8b 04 May 2006
debug2: ssh_connect: needpriv 0
debug1: Connecting to monServueur port 22.
debug1: Connection established.
debug1: identity file /cygdrive/c/Documents and Settings/Administrateur/.ssh/ide
ntity type 0
debug3: Not a RSA1 key file /cygdrive/c/Documents and Settings/Administrateur/.s
sh/id_rsa.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: missing keytype
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug2: key_type_from_name: unknown key type '-----END'
debug3: key_read: missing keytype
debug1: identity file /cygdrive/c/Documents and Settings/Administrateur/.ssh/id_
rsa type 1
debug3: Not a RSA1 key file /cygdrive/c/Documents and Settings/Administrateur/.s
sh/id_dsa.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: missing keytype
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug2: key_type_from_name: unknown key type '-----END'
debug3: key_read: missing keytype
debug1: identity file /cygdrive/c/Documents and Settings/Administrateur/.ssh/id_
dsa type 2
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3
debug1: match: OpenSSH_4.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.3
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-gro
up14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour1
28,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-c
tr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour1
28,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-c
tr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@open
ssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@open
ssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-gro
up14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour1
28,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-c
tr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour1
28,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-c
tr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@open
ssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@open
ssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_init: found hmac-md5
debug1: kex: server->client aes128-cbc hmac-md5 none
debug2: mac_init: found hmac-md5
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug2: dh_gen_key: priv key bits set: 138/256
debug2: bits set: 500/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug3: check_host_in_hostfile: filename /cygdrive/c/Documents and Settings/Admi
nistrateur/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 1
debug3: check_host_in_hostfile: filename /cygdrive/c/Documents and Settings/Admi
nistrateur/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 1
debug1: Host 'monServeur' is known and matches the RSA host key.
debug1: Found key in /cygdrive/c/Documents and Settings/Administrateur/.ssh/know
n_hosts:1
debug2: bits set: 487/1024
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /cygdrive/c/Documents and Settings/Administrateur/.ssh/id_rsa (0x10
02ade8)
debug2: key: /cygdrive/c/Documents and Settings/Administrateur/.ssh/id_dsa (0x10
02ae00)
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug3: start over, passed a different list publickey,gssapi-with-mic,password
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering public key: /cygdrive/c/Documents and Settings/Administrateur/.
ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Offering public key: /cygdrive/c/Documents and Settings/Administrateur/.
ssh/id_dsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
user@monServeur's password:
debug3: packet_send2: adding 48 (len 61 padlen 19 extra_pad 64)
debug2: we sent a password packet, wait for reply
debug1: Authentication succeeded (password).
debug2: fd 5 setting O_NONBLOCK
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug1: Entering interactive session.
debug2: callback start
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 0
debug3: tty_make_modes: ospeed 38400
debug3: tty_make_modes: ispeed 38400
debug3: tty_make_modes: 1 3
debug3: tty_make_modes: 2 28
debug3: tty_make_modes: 3 8
debug3: tty_make_modes: 4 21
debug3: tty_make_modes: 5 4
debug3: tty_make_modes: 6 0
debug3: tty_make_modes: 7 0
debug3: tty_make_modes: 8 17
debug3: tty_make_modes: 9 19
debug3: tty_make_modes: 10 26
debug3: tty_make_modes: 12 18
debug3: tty_make_modes: 13 23
debug3: tty_make_modes: 14 22
debug3: tty_make_modes: 18 15
debug3: tty_make_modes: 30 0
debug3: tty_make_modes: 31 0
debug3: tty_make_modes: 32 0
debug3: tty_make_modes: 33 0
debug3: tty_make_modes: 34 0
debug3: tty_make_modes: 35 0
debug3: tty_make_modes: 36 1
debug3: tty_make_modes: 37 0
debug3: tty_make_modes: 38 1
debug3: tty_make_modes: 39 0
debug3: tty_make_modes: 40 0
debug3: tty_make_modes: 41 0
debug3: tty_make_modes: 50 1
debug3: tty_make_modes: 51 1
debug3: tty_make_modes: 53 1
debug3: tty_make_modes: 54 0
debug3: tty_make_modes: 55 0
debug3: tty_make_modes: 56 0
debug3: tty_make_modes: 57 0
debug3: tty_make_modes: 58 0
debug3: tty_make_modes: 59 1
debug3: tty_make_modes: 60 0
debug3: tty_make_modes: 61 0
debug3: tty_make_modes: 70 1
debug3: tty_make_modes: 71 0
debug3: tty_make_modes: 72 1
debug3: tty_make_modes: 73 0
debug3: tty_make_modes: 74 0
debug3: tty_make_modes: 75 0
debug3: tty_make_modes: 90 1
debug3: tty_make_modes: 91 1
debug3: tty_make_modes: 92 0
debug3: tty_make_modes: 93 0
debug2: channel 0: request shell confirm 0
debug2: fd 3 setting TCP_NODELAY
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel 0: rcvd adjust 131072
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug2: channel 0: rcvd eof
debug2: channel 0: output open -> drain
debug2: channel 0: obuf empty
debug2: channel 0: close_write
debug2: channel 0: output drain -> closed
debug2: channel 0: rcvd close
debug2: channel 0: close_read
debug2: channel 0: input open -> closed
debug3: channel 0: will not send data after close
debug2: channel 0: almost dead
debug2: channel 0: gc: notify user
debug2: channel 0: gc: user detached
debug2: channel 0: send close
debug2: channel 0: is dead
debug2: channel 0: garbage collecting
debug1: channel 0: free: client-session, nchannels 1
debug3: channel 0: status: The following connections are open:
  #0 client-session (t4 r0 i3/0 o3/0 fd -1/-1 cfd -1)
 
debug3: channel 0: close_fds r -1 w -1 e 6 c -1
debug3: fd 1 is not O_NONBLOCK
Connection to monServeur closed.
debug1: Transferred: stdin 0, stdout 0, stderr 38 bytes in 237.3 seconds
debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.2
debug1: Exit status 127
 
C:\Documents and Settings\Administrateur>

J'ai l'impression qu'il y a un problème avec ta clé RSA1.
Premièrement, vérifie les fichiers ~/.ssh/identity et ~/.ssh/identity.pub.
Code:

1 2 3 4 5 6 ~/.ssh/identity: SSH PRIVATE KEY FILE FORMAT 1.1 �+s��U �I�6t�KZ�\$��:1=ټ~y��u0�ho��%�q`�Rd�... ~/.ssh/identity.pub: 2048 35 2388025230002275464220709516997...
Si les fichiers n'ont pas cette structure, c'est qu'ils ont été mal générés. Le cas échéant, il faut les supprimer tout simplement parce que non utilisés: protocole version 1 alors que l'authentification est faite en version 2. Toujours dans ce cas, il faudrait également vérifier les deux autres clés.
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 ~/.ssh/id_rsa: -----BEGIN RSA PRIVATE KEY----- MIIEoQIBAAKCAQEA64Ld0Ic0GrGy/GLEx+7SgZF... ~/.ssh/id_rsa.pub: ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA64Ld... ~/.ssh/id_dsa: -----BEGIN DSA PRIVATE KEY----- MIIBugIBAAKBgQCDlgiBtFYTWdUUkeOOAntJH6WZ... ~/.ssh/id_dsa.pub: ssh-dss AAAAB3NzaC1kc3MAAACBAIOWCIG0VhNZ1RSR444...
Par contre, la reconnaissance de la clé ordi fonctionne correctement grâce à la clé RSA (donc les RSA1 et DSA sont inutiles).

Enfin, je crois qu'il y a un problème durant l'authentification par clé (RSA puis DSA): le serveur ne répond pas. Peut-être un réglage à modifier.
Deuxièmement, mets le fichier /etc/ssh/sshd_config ici, entre balises code.

Tous les fichiers ont la structure que tu as écrit

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
#	$OpenBSD: sshd_config,v 1.73 2005/12/06 22:38:28 reyk Exp $
 
# This is the sshd server system-wide configuration file.  See
# sshd_config(5) for more information.
 
# This sshd was compiled with PATH=/usr/local/bin:/bin:/usr/bin
 
# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented.  Uncommented options change a
# default value.
 
#Port 22
#Protocol 2,1
Protocol 2
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::
 
# HostKey for protocol version 1
#HostKey /etc/ssh/ssh_host_key
# HostKeys for protocol version 2
#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_dsa_key
 
# Lifetime and size of ephemeral version 1 server key
#KeyRegenerationInterval 1h
#ServerKeyBits 768
 
# Logging
# obsoletes QuietMode and FascistLogging
#SyslogFacility AUTH
SyslogFacility AUTHPRIV
#LogLevel INFO
 
# Authentication:
 
#LoginGraceTime 2m
#PermitRootLogin yes
#StrictModes yes
#MaxAuthTries 6
 
#RSAAuthentication yes
#PubkeyAuthentication yes
#AuthorizedKeysFile	.ssh/authorized_keys
 
# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#RhostsRSAAuthentication no
# similar for protocol version 2
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# RhostsRSAAuthentication and HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes
 
# To disable tunneled clear text passwords, change to no here!
#PasswordAuthentication yes
#PermitEmptyPasswords no
PasswordAuthentication yes
 
# Change to no to disable s/key passwords
#ChallengeResponseAuthentication yes
ChallengeResponseAuthentication no
 
# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no
 
# GSSAPI options
#GSSAPIAuthentication no
GSSAPIAuthentication yes
#GSSAPICleanupCredentials yes
GSSAPICleanupCredentials yes
 
# Set this to 'yes' to enable PAM authentication, account processing, 
# and session processing. If this is enabled, PAM authentication will 
# be allowed through the ChallengeResponseAuthentication mechanism. 
# Depending on your PAM configuration, this may bypass the setting of 
# PasswordAuthentication, PermitEmptyPasswords, and 
# "PermitRootLogin without-password". If you just want the PAM account and 
# session checks to run without PAM authentication, then enable this but set 
# ChallengeResponseAuthentication=no
#UsePAM no
UsePAM yes
 
# Accept locale-related environment variables
AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES 
AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT 
AcceptEnv LC_IDENTIFICATION LC_ALL
#AllowTcpForwarding yes
#GatewayPorts no
#X11Forwarding no
X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes
#PrintMotd yes
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no
#UsePrivilegeSeparation yes
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#ShowPatchLevel no
#UseDNS yes
#PidFile /var/run/sshd.pid
#MaxStartups 10
#PermitTunnel no
 
# no default banner path
#Banner /some/path
 
# override default of no subsystems
Subsystem	sftp	/usr/libexec/openssh/sftp-server

Bon, c'est un peu long, mais ça avance.

Le serveur ne répond qu'au protocole 2, donc tu peux virer la clé RSA1 (qui est en protocole 1); donc tu supprimes ~/.ssh/identity* sur le client, et sur le serveur la clé publique RSA1 qui se trouve dans ~/.ssh/authorized_keys (c'est la ligne où il n'y a que des chiffres).

Sinon le fichier /etc/ssh/sshd_config du serveur SSH sur la machine serveur a l'air correct. J'ai oublié de te dire d'extraire les infos pertinentes de la manière suivante:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 awk '$0 !~ /^#/ && NF > 0' /etc/ssh/sshd_config Protocol 2 SyslogFacility AUTHPRIV PasswordAuthentication yes ChallengeResponseAuthentication no GSSAPIAuthentication yes GSSAPICleanupCredentials yes UsePAM yes AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT AcceptEnv LC_IDENTIFICATION LC_ALL X11Forwarding yes Subsystem sftp /usr/libexec/openssh/sftp-server
Il me faut maintenant les infos pertinentes du client SSH sur la machine cliente. Comme tu as une machine Windows en client, je ne sais pas comment faire. Sur Linux ce serait:

Code:

awk '$0 !~ /^#/ && NF > 0' /etc/ssh/ssh_config

Enfin, vérifie les droits des répertoires et fichiers (client comme serveur):
~/.ssh: drwx------
~/.ssh/id_rsa: -rw------- (clé RSA privée)
~/.ssh/id_rsa.pub: -rw-r--r-- (clé RSA publique)
~/.ssh/id_dsa: -rw------- (clé DSA privée)
~/.ssh/id_dsa.pub: -rw-r--r-- (clé DSA publique)
~/.ssh/known_hosts: -rw-r--r-- (liste des serveurs connus, sur le client)
~/.ssh/authorized_keys: -rw-r--r-- (liste des clés publiques des clients, sur le serveur)

Ma dernière réponse était trop rapide. J'étais au travail et avais la tête ailleurs, résultat je n'ai pas bien décortiqué la sortie de la commande ssh -vvv. J'en suis désolé.
Voici ce qu'on peut y lire:
Code:

1 2 3 4 debug1: Offering public key: /cygdrive/c/Documents and Settings/Administrateur/.ssh/id_rsa debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Authentications that can continue: publickey,gssapi-with-mic,password
Je suis connecté sur les ordis du travail, et voici ce que j'obtiens:
Code:

1 2 3 4 5 debug1: Offering public key: <my_home_dir>/.ssh/id_rsa debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Server accepts key: pkalg ssh-rsa blen 277
Il est clair que le serveur chez moi accepte la requête, mais chez toi, Noizet, il la refuse. C'est donc le serveur qui est en cause. Pour obtenir plus d'indices sur le problème, il faudrait que tu arrives à lire le fichier de log du serveur ssh. Chez nous, les distros utilisées sont dérivées de RedHat et ce fichier est /var/log/secure. Il faut être root pour le lire. Exemple de connexion réussie, de <user_name> à root:
Code:

1 2 3 Oct 28 19:42:28 <server_name> sshd[6689]: Postponed publickey for root from <client_ip> port 48559 ssh2 Oct 28 19:42:28 <server_name> sshd[6688]: Accepted publickey for root from <client_ip> port 48559 ssh2 Oct 28 19:42:28 <server_name> sshd[6688]: pam_unix(sshd:session): session opened for user root by (uid=0)
On devrait lire dans les dernières lignes du fichier la raison pour laquelle ce foutu serveur SSH refuse la requête de connexion. Donne les lignes intéressantes (réfère-toi à l'heure).

29/10/2008, 09h46
Noizet

Ok, le soucis c'est que je n'ai pas les droits suffisants pour aller lire ce fichier.

Je vais regarder lundi avec la personne concerner si elle peut me sortir ce fichier et te redonne des nouvelles ;)
29/10/2008, 10h04
jmelyn

Entendu. Cependant, ce devrait être à l'admin de résoudre ce problème, et non à l'utilisateur.

Dans la situation actuelle, je pense que ce peut être une config PAM inadaptée. Dans ce cas, voir /etc/pam.d/sshd et les fichiers inclus. Je ne suis pas spécialiste de la chose, d'ailleurs ton post aurait dû passer dans le forum Linux/Sécurité plutôt que Linux/Applications/Shell. Néanmoins je suis curieux de voir comment ce problème aura été résolu alors donne des nouvelles.

Voilà les lignes que sa me met :

Code:

1
2
3
Nov  3 09:17:44 SERVER sshd[3723]: pam_unix(sshd:session): session closed for user USER
Nov  3 09:17:58 SERVER sshd[3745]: Authentication refused: bad ownership or modes for file /data/USER/.ssh/authorized_keys
Nov  3 09:17:58 SERVER sshd[3745]: Authentication refused: bad ownership or modes for file /data/USER/.ssh/authorized_keys

03/11/2008, 10h51
jmelyn

Bonjour Noizet,

Le fichier de log est très instructif, n'est-ce pas? Peux-tu mettre maintenant le résultat de la commande

Code:

ls -l /data/USER/.ssh/authorized_keys

Fais bien attention à USER: Si ce n'est pas le même, alors mets USER1 et USER2, par exemple.

Edit: Il peux y avoir plusieurs erreurs de ce côté-là, alors fais tout de suite ls -al /data/USER/.ssh
03/11/2008, 11h03
Noizet

Code:

-rwxrwxrwx USER1 UER1 1668 Oct 28 .ssh/authorized_keys

J'ai également les mêmes droits pour id_dsa, id:dsa.pub, identitiy, identity.pub, id_rsa,id_rsa.pub
03/11/2008, 11h32
jmelyn
Bon, le problème est maintenant clair. Si tu lis la man page de ssh, à la fin sont indiqués les droits que doivent avoir les fichiers:
- Les clés privées (les trois fichiers id_dsa, id_rsa et identity) doivent être privées, c'est-à-dire: -rw-------.
- Les clés publiques (les trois fichiers id_dsa.pub, id_rsa.pub, et identity.pub) peuvent être publiques: -rw-r--r--. Mais elles ont le droit de rester privées quand même.
- Le fichier des clés publiques host des ordinateurs connus (authorized_keys) peut être publique: -rw-r--r--.
- Le répertoire .ssh doit être privé: drwx------.
J'espère que tu sais modifier les droits des fichiers pour obtenir exactement ce qui est indiqué. Une fois les changements effectués, essaie à nouveau et dis-nous si ça marche.
03/11/2008, 13h16
Noizet

Alors, les fichiers sur le serveur ont ces droits, mais ça ne change rien, il me demande toujours mon mot de passe quand je me connect
03/11/2008, 14h09
jmelyn

Bon, il y a peut-être d'autres problèmes. Mais essaie d'être plus actif en n'attendant pas que quelqu'un te résolve tes problèmes. Par exemple, retourne voir ce que te dit maintenant le fichier /var/log/secure, il donnera certainement d'autres indices, maintenant que le problème des droits est résolu. Et puis relance la commande ssh avec l'option -vvv: il y a toutes les étapes survenues durant la tentative de connexion.
03/11/2008, 14h47
Noizet

Malheureusement je n'ai pas accès à ce fichier...

J'ai exécuté la commande -vvv, j'ai exactement la même chose que la dernière fois, aucune ligne n'a changé !
03/11/2008, 15h24
jmelyn

Si vraiment aucune ligne n'a changé lors de la sortie de la commande ssh -vvv, c'est que le serveur ne veut toujours pas répondre. Il faut voir pourquoi dans le fichier /var/log/secure. En attendant, tu peux aussi vérifier les droits des fichiers ssh sur le poste client. Les droits doivent être comme décrits précédemment.
04/11/2008, 10h02
Noizet

Les droits sont ok.

Est-ce que bien correcte :

- Machine cliente (.ssh): id_dsa, id_dsa.pub, id_rsa, id_rsa.pub, identity, identity.pub, known_hosts

- Serveur (.ssh): id_dsa, id_dsa.pub, id_rsa, id_rsa.pub, identity, identity.pub, authorized_keys

Est-ce correct ou j'ai omis un fichier et sa coince ici ?
04/11/2008, 10h31
jmelyn
Bonjour Noizet,

Pour cette connexion uniquement (ssh protocole 2), les fichiers indispensables dans le répertoire .ssh sont:

Client
- id_rsa: contient la clé privée de l'utilisateur; fichier utilisé durant la connexion.
- id_rsa.pub: contient la clé publique de l'utilisateur; fichier non utilisé directement chez le client.
- known_hosts: contient la clé publique de la machine serveur, et provient du fichier /etc/ssh/ssh_host_rsa_key.pub (sur le serveur); fichier utilisé durant la connexion.
Serveur
- authorized_keys: contient la clé publique de l'utilisateur sur la machine cliente, et provient du fichier ~/.ssh/id_rsa.pub (sur le machine cliente); fichier utilisé durant la connexion.
C'est tout.