Fedora-Fr

Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

authentification par clef dans ssh...

[supprimé]

salut, je viens de faire mes premiers essais sous ssh... j'ai voulu tester la connection avec le système de clef...

en procédant comme çi-après

ssh-keygen -t dsa
après introduction de la pass-phrase, j'ai fait la copie du contenu de la clef publique dans le fichier authorized-keys du repertoire /home/usrename/.ssh/ de l'ordinateur cible (comme ceux-ci n'existaient pas encore j'ai du créer le répertoire et le fichier, j'aurais du le faire avec la commande "ssh-copy-id -i ~/.ssh/id_dsa.pub login@nom_DNS_du_serveur" mais elle ne fonctionnait pas, j'ai donc fait un bete copier-coller du contenu (peut-être le problême vient-il de là...))

tout celà étant fait, je me logue en ssh comme je le fait d'habitude "ssh username@servername", mais il continue a me demander le mot de passe, ce qu'il ne devrait pas faire si j'ai bien compris le système de la connection par clef...

Une solution ?

valhalla

Salut,

La manip est bonne mais les droits sur les fichiers sont surement incorrectes. Pour que ca marche, il faut ces droits la sur tes differents fichiers dans .ssh:

-rw-r--r-- authorized_keys
-rw------- id_rsa
-rw-r--r-- id_rsa.pub
-rw-r--r-- known_hosts

Moi j'utilise rsa mais ca doit aussi marcher en dsa je suppose.

[supprimé]

merci, je vais essayer ça ce soir et je dirai quoi pour le résultat 🙂

[supprimé]

j'ai bien fait comme indiqué dans ta réponse, mais helas, pas de changement..... :-?

valhalla

Il faut bien creer la cle publique sur le pc d'ou tu veux te connecter. La cle publique contient a la fin utilisateur@machine. Tu copies directement sur le compte de celui chez qui tu veux te connecter ta clé publique (dans authorized-keys). Et donc ca marchera si tu te connectes depuis la machine ou tu as creer ta cle sur le compte de la personne qui contient ta clé publique dans authorized_keys.

Verifie bien les droits sur les fichiers des 2 cotés (du compte d'ou tu veux te connecter, et du compte ou tu veux te connecter).

benj63

Bonjour,

J'ai récemment installé Fedora 4 (2.6.11-1.1369_FC4smp) sur une machine, et je souhaiterais pouvoir m'y connecter en SSH sans mot de passe.

J'ai créé un utilisateur chef, puis :

ssh chef@machine  
(mot de passe)  
mkdir .ssh  
cd .ssh  
ssh-keygen -t rsa  
(nom du fichier) identity  
(pas de passphrase)  
cat identity.pub > authorized_keys

Modification de /etc/ssh/sshd_config en tant que root :
(je n'ai laissé ici que les lignes non commentées)

Protocol 2  
SyslogFacility AUTHPRIV  
RSAAuthentication yes  
PubkeyAuthentication yes  
AuthorizedKeysFile ~/.ssh/authorized_keys  
PasswordAuthentication yes  
ChallengeResponseAuthentication no  
GSSAPIAuthentication yes  
GSSAPICleanupCredentials yes  
UsePAM yes  
X11Forwarding yes  
X11DisplayOffset 10  
Subsystem sftp /usr/libexec/openssh/sftp-server

J'ai redémarré le serveur ssh : /etc/init.d/sshd restart

...eh bien lorsque je tape ssh chef@localhost il me demande toujours mon mot de passe !

J'ai réessayé en utilisant un fichier id_dsa, un fichier id_rsa, et en mettant toutes ces clés dans le /authorized_keys... Rien n'y fait !!!

Voici un ssh -v chef@localhost :

OpenSSH_4.0p1, OpenSSL 0.9.7f 22 Mar 2005  
debug1: Reading configuration data /etc/ssh/ssh_config  
debug1: Applying options for *  
debug1: Connecting to localhost [127.0.0.1] port 22.  
debug1: Connection established.  
debug1: identity file /home/chef/.ssh/identity type -1  
debug1: identity file /home/chef/.ssh/id_rsa type 1  
debug1: identity file /home/chef/.ssh/id_dsa type 2  
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.0  
debug1: match: OpenSSH_4.0 pat OpenSSH*  
debug1: Enabling compatibility mode for protocol 2.0  
debug1: Local version string SSH-2.0-OpenSSH_4.0  
debug1: SSH2_MSG_KEXINIT sent  
debug1: SSH2_MSG_KEXINIT received  
debug1: kex: server->client aes128-cbc hmac-md5 none  
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  
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent  
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY  
debug1: Host 'localhost' is known and matches the RSA host key.  
debug1: Found key in /home/chef/.ssh/known_hosts:1  
debug1: ssh_rsa_verify: signature correct  
debug1: SSH2_MSG_NEWKEYS sent  
debug1: expecting SSH2_MSG_NEWKEYS  
debug1: SSH2_MSG_NEWKEYS received  
debug1: SSH2_MSG_SERVICE_REQUEST sent  
debug1: SSH2_MSG_SERVICE_ACCEPT received  
debug1: Authentications that can continue: publickey,gssapi-with-mic,password  
debug1: Next authentication method: gssapi-with-mic  
debug1: Authentications that can continue: publickey,gssapi-with-mic,password  
debug1: Authentications that can continue: publickey,gssapi-with-mic,password  
debug1: Next authentication method: publickey  
debug1: Trying private key: /home/chef/.ssh/identity  
debug1: Offering public key: /home/chef/.ssh/id_rsa  
debug1: Authentications that can continue: publickey,gssapi-with-mic,password  
debug1: Offering public key: /home/chef/.ssh/id_dsa  
debug1: Authentications that can continue: publickey,gssapi-with-mic,password  
debug1: Next authentication method: password  
chef@localhost's password:

Il me demande toujours le mot de passe. J'ai réussi à faire fonctionner tout cela en tant que root (connexion sans mot de passe à root@localhost), mais pas en tant qu'utilisateur chef ou autre (j'ai même essayé de recréer l'utilisateur etc).

Concernant les droits sur les répertoires :
répertoire /home/ :

drwxr-xr-x    3 root root  4096 sep  5 09:53 home

répertoire /home/chef/ :

drwx------  14 chef chef 4096 sep  5 10:06 chef

répertoire /home/chef/.ssh/ :

drwxrwxr-x   2 chef chef 4096 sep  5 14:31 .ssh

contenu du répertoire /home/chef/.ssh/ :

-rw-rw-r--   1 chef chef 462 sep  5 14:33 authorized_keys 
-rw-------   1 chef chef 883 sep  5 14:31 identity 
-rw-r--r--   1 chef chef 231 sep  5 14:31 identity.pub 
-rw-r--r--   1 chef chef 443 sep  5 12:28 known_hosts

normalement, ce sont les droits par défaut, je n'ai rien modifié...

J'ai déjà fait cette manip 50 fois sous RedHat 9 sur d'autres postes, et elle ne m'a jamais posé de problèmes jusqu'à présent... Aurais-je oublié quelque chose cette fois-ci ? Est-ce qu'il y a des soucis avec le parefeu intégré à Fedora 4 ?

Merci par avance pour vos idées...

Anvil

Le pare-feu n'a rien a voir avec tant que tu arrives a te connecter (au niveau IP).
Personnellement y'a 3 choses qui me choquent:
1. Le repertoire .ssh avec le droit d'ecriture au groupe
2. le authorized_keys avec le droit d'ecriture au groupe
3. Jamais tu n'as dit que l'utilisateur chef etait celui qui lancait la commande ssh. Si ca n'est pas le cas je te suggere de revoir ton raisonnement et de donner la cle privee a l'utilisateur qui lance le ssh et la cle publique a chef.

Le 1. et 2. sont completement bloquant. Ca ne marchera jamais si tu laisses les permissions dans cet etat.

Apres, je desapprouve completement l'utilisation non restreinte des cles ssh sans phrase de passe comme tu donnes l'impression de faire. Je t'invite a potasser longuement la documentation du ssh-agent et a _toujours_ _tout le temps_ _constamment_ proteger tes cles privees par une phrase.

benj63

Je te remercie, je suis parvenu à mes fins en changeant les droits des fichiers.

En ce qui concerne l'utilisation de passphrase, à quel moment cela change-t'il quelque chose ? (je me permets de te demander avant de potasser la doc) La connexion en SSH sans mot de passe via des scripts automatisés sont-ils toujours possibles ? Quelle est la contrainte / sécurité qu'ajoute l'utilisation d'une passphrase ?

Merci par avance !