Problème SSH via RSA

Version imprimable

Salut à tous,

J'essaye de me connecter en SSH via une authentification RSA, d'une machine de dev vers un serveur de dev, histoire de ne pas à avoir à taper le mot de passe toutes les 5 minutes.

Le problème, c'est que j'ai beau écumer les tutos sur le net, ben ça marche pas :(

Je détaille ma manip (je sais que la sécurité est pas super, mais là j'essaye de faire marcher ça sur des machines de dev, j'ai lu et je suis au courant des bonnes pratiques de l'authentification SSH/RSA) :

A noter que les utilisateurs sur les deux machines ont des noms différents

La machine de dev s'appellera "machine" et le serveur de dev s'appellera "server", les utilisateurs seront respectivement "user_machine" et "user_server". Je peux pas faire plus compréhensible :)

Code:

@machine:> ssh-keygen [no passphrase]

Note : sont générés : id_rsa.pub et id_rsa
Code:

1 2 3 4 5 6 @machine:> scp /home/user_machine/.ssh/id_rsa.pub user_server@server:/home/user_server/ @machine:> ssh server -l user_server @server:> cd /home/user_server @server:> cat id_rsa.pub >> .ssh/authorized_keys
Le sshd_config de mon serveur a cette tête là :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Port 22 Protocol 2 SyslogFacility AUTHPRIV RSAAuthentication yes PubkeyAuthentication yes AuthorizedKeysFile ~/.ssh/authorized_keys 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 LANGUAGE X11Forwarding yes Subsystem sftp /usr/libexec/openssh/sftp-server
Note : Merci de ne commenter uniquement le problème que je mentionne, je sais que cette configuration n'est pas la config idéale, c'est même la config par défaut, mais ce n'est pas mon problème actuel :)

Le ssh_config de ma machine à cette tête :
Code:

1 2 3 4 5 6 7 Host * ForwardX11 yes RSAAuthentication yes PasswordAuthentication yes IdentityFile ~/.ssh/id_rsa Port 22 Protocol 2
Les droits des fichiers authorized_keys sur le serveur de dev et id_rsa sur la machine de dev sont respectivement attribués aux utilisateurs user_server et user_machine.

J'ai redémarré les services correspondants et ... rien ne marche :)

Quand je me connecte en ssh de ma machine vers mon serveur, ce dernier n'a de cesse de me demander le mot de passe ...
Code:

1 2 @machine:>ssh server -l user_server user_server@server's password:
Si une bonne âme peut m'expliquer ce que je fais de travers j'en serai vraiment ravi, car je sèche complètement !

Merci beaucoup et bonne journée,

Cyril

14/12/2009, 10h38
becket
Tu as vérifié le log d'authentification ? Tu as vérifié que les droits jusqu'au fichier et sur le fichier ne sont pas trop permissifs ?

Une méthode plus facile pour envoyer sa clé privée est d'utiliser ssh-copy-id
Code:

1 2 ssh-copy-id -i cle_publique.pub user@machine

Salut Becket,

Merci pour l'info, je ne connaissais pas ssh-copy-id

Sinon, j'ai vérifié les permissions, effectivement, c'était pas les bonnes, mais ça ne résout pas le problème.

Mon dossier .ssh est maintenant en chmod 700 et mon authentification_keys est en chmod 600.

Je ne trouve pas le log d'authentification. J'ai vérifié /var/log, il n'y a pas de auth.log. J'ai jeté un oeil dans le fichier secure, rien de transcendant n'apparait (il me dit juste quand j'annule la demande de connection avec un ^C, quand je tape le mot de passe, etc... mais rien sur l'authentification RSA)

J'ai aussi essayé de générer ma clé avec ssh-keygen -t dsa, vu que c'est ce qu'on voit un peu partout, mais en recommençant toutes les manips, ça ne fonctionne toujours pas. La seule chose un peu intéressante que j'ai trouvé c'est en faisant ssh avec l'option verbose (-v) sur la machine de dev, là il me dit qu'il essaye bien de s'identifier avec les clés privées :
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 debug1: Reading configuration data /etc/ssh_config debug1: Connecting to machine [xx.xx.xx.xx] port 22. debug1: Connection established. debug1: identity file /Users/user_machine/.ssh/identity type -1 debug1: identity file /Users/user_machine/.ssh/id_rsa type 1 debug1: identity file /Users/user_machine/.ssh/id_dsa type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_5.2 debug1: match: OpenSSH_5.2 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_5.2 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-ctr hmac-md5 none debug1: kex: client->server aes128-ctr 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 'machine' is known and matches the RSA host key. debug1: Found key in /Users/user_machine/.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: publickey debug1: Trying private key: /Users/user_machine/.ssh/identity debug1: Offering public key: /Users/user_machine/.ssh/id_rsa debug1: Authentications that can continue: publickey,gssapi-with-mic,password debug1: Trying private key: /Users/user_machine/.ssh/id_dsa debug1: Next authentication method: password
On voit bien dans les dernières lignes qu'il essaye de fournir des clés privées / publiques. J'ai remarqué qu'elles ne portaient pas les mêmes noms, alors j'ai essayé de leur coller les noms qu'il demande, à savoir identity pour la clé privée et id_rsa pour la clé publique, cette fois la sortie diffère un peu (je ne place que les dernères lignes, les premières sont identiques)
Code:

1 2 3 4 5 6 7 8 9 debug1: Authentications that can continue: publickey,gssapi-with-mic,password debug1: Next authentication method: publickey debug1: Trying private key: /Users/user_machine/.ssh/identity debug1: read PEM private key done: type RSA debug1: Authentications that can continue: publickey,gssapi-with-mic,password debug1: Offering public key: /Users/user_machine/.ssh/id_rsa debug1: Authentications that can continue: publickey,gssapi-with-mic,password debug1: Trying private key: /Users/user_machine/.ssh/id_dsa debug1: Next authentication method: password
Il a ajouté la ligne "read PEM private key done: type RSA", mais rien ne change au résultat, il me demande toujours un mot de passe.

Savez vous ou trouver, sur le serveur de dev, un log détaillé de ces tentatives et pourquoi elles se font jeter, je tourne sous Fedora 11 ?

Avez vous une idée de ce qu'il peut se passer ?

Merci beaucoup !

Cyril

14/12/2009, 13h32
becket

Apparemment il échoue après le PEM, parce qu'après cet envoi et la vérification de la clé, tu devrais être loggué
14/12/2009, 13h48
ZeGuizmo

Et une idée de ou je pourrais trouver une trace de l'erreur sur le serveur ?

Merci,

Cyril
14/12/2009, 14h04
becket

Tu peux modifier le niveau LogLevel sur le server : DEBUG3 par exemple

Ah, j'ai du concret !!

Avec un loglevel = debug3, voici ce que je trouve dans /var/log/messages
Code:

1 2 3 4 Dec 14 15:23:18 server sshd[3682]: Server listening on 0.0.0.0 port 22. Dec 14 15:23:18 server sshd[3682]: Server listening on :: port 22. Dec 14 15:23:37 server sshd[3694]: Connection from xx.xx.xx.xx port 9561 Dec 14 15:23:40 server sshd[3694]: Failed publickey for user_server from xx.xx.xx.xx port 9561 ssh2
Donc la on voit bien qu'il se fait jeter, alors que la publickey est censée être la bonne !

D'autre part, c'est quoi cette histoire de port 9561 ?? Je suis dans deux réseaux différents, et mes deux machines sont NATées jusqu'au cou. Je n'ai aucune règle concernant le port 9561 dans le NAT (vu que je sais même pas ce que c'est que ce port....) c'est peut-être un début d'embryon de piste non ?

Merci ;)

Cyril

14/12/2009, 15h37
becket

Le port 9561, cela doit être le port ouvert sur ta machine pour connecter le port 22 sur ton serveur SSH. Pour le reste, la question étant de savoir pourquoi cette authentification via la public key échoue
14/12/2009, 16h01
ZeGuizmo

J'ai trouvé ... :ccool:

Très con, comme d'habitude.

Le fichier /etc/ssh/sshd_config mentionne une clé publique située sur ~/.ssh/authorized_keys

Mais le démon est lancé en root, donc ~/ = /root/

En changeant ~ par /home/user_server, ça marche nickel

Je me pose une question quand même, mettre un chemin en dur dans un fichier de conf, je trouve que ça craint, y'a pas moyen d'éviter ça ? Si je change d'utilisateur, ou si je veux me connecter avec un autre utilisateur, comment je fais si le chemin est en dur ?

Merci

Cyril
14/12/2009, 18h39
becket

Sur les distributions que j'ai sous la main, le paramètre est à chaque fois en commentaire