Solution 1 :
Oui, vous pouvez le faire, comme vous l'avez décrit.
[email protected] ~$ ssh-add -l 4096 10:b3:fd:29:08:86:24:a6:da:0a:dd:c6:1e:b0:66:6a id_rsa (RSA) [email protected] ~$ ssh [email protected] motd message, etc. [email protected] ~$
Solution 2 :
C'est un peu un aparté, mais.....
Si vous utilisez toujours le même nom d'utilisateur pour un serveur distant, vous pouvez également trouver utile d'ajouter un hôte dans votre configuration ssh :
Host remotesystem
User baruser
De cette façon, vous n'avez pas besoin de vous rappeler de spécifier le nom d'utilisateur lors de la connexion, et vous l'excluez lorsque vous rencontrez des problèmes avec les clés à l'avenir.
Solution 3 :
Votre nom d'utilisateur local n'a pas vraiment d'importance (mis à part que la clé privée doit résider dans le répertoire personnel de votre utilisateur local). Copiez simplement la clé dans le authorized_keys de l'utilisateur distant section et cela fonctionnera.
Solution 4 :
Pour tout problème lié à ssh, la première chose à faire est d'augmenter la verbosité du client :
ssh [email protected] -vvv
Si cela ne vous donne aucune idée de ce qui ne va pas, vous devez modifier le niveau de journalisation sur le serveur et redémarrer le démon.
LogLevel DEBUG3
Vous devriez trouver la sortie de débogage dans /var/log/auth.log (ou partout où ssh est configuré pour se connecter). Une fois que vous avez trouvé le problème, n'oubliez pas de le rétablir tel que vous l'avez trouvé.
Solution 5 :
Les autorisations sur les répertoires .ssh sur les deux machines doivent être correctes. Généralement, cela signifie 700 sur le répertoire .ssh et au plus 755 sur le répertoire personnel. En plus de 600 sur tous les fichiers des répertoires .ssh.
Si l'utilisateur sur le système distant est root, assurez-vous que root peut ssh. (PermitRootLogin dans sshd_config) et que la clé publique (PubkeyAuthentication) et si nécessaire RSA (RSAAuthentication) sont activés.