J'ai une configuration de serveur 12.10 sur une machine virtuelle avec son réseau défini sur ponté (sera essentiellement considéré comme un ordinateur connecté à mon commutateur).
J'ai installé opensshd via apt-get
et j'ai pu me connecter au serveur à l'aide de PuTTY avec mon nom d'utilisateur et mon mot de passe.
Je me suis ensuite efforcé de le faire utiliser une authentification par clé publique/privée. J'ai fait ce qui suit:
/etc/ssh/myusername/authorized_keys
(j'utilise des répertoires de départ chiffrés).Configurez sshd_config
comme ceci:
PubkeyAuthentication yes
AuthorizedKeysFile /etc/ssh/%u/authorized_keys
StrictModes no
PasswordAuthentication no
UsePAM yes
Lorsque je me connecte à l'aide de PuTTY ou de WinSCP, un message d'erreur indiquant Aucune méthode d'authentification prise en charge disponible (clé publique envoyée par le serveur) s'affiche.
Si j'exécute sshd
en mode débogage, je vois:
PAM: initializing for "username"
PAM: setting PAM_RHOST to "192.168.1.7"
PAM: setting PAM_TTY to "ssh"
userauth-request for user username service ssh-connection method publickey [preauth]
attempt 1 failures 0 [preauth]
test whether pkalg/pkblob are acceptable [preauth[
Checking blacklist file /usr/share/ssh/blacklist.RSA-1023
Checking blacklist file /etc/ssh/blacklist.RSA-1023
temporarily_use_uid: 1000/1000 (e=0/0)
trying public key file /etc/ssh/username/authorized_keys
fd4 clearing O_NONBLOCK
restore_uid: 0/0
Failed publickey for username from 192.168.1.7 port 14343 ssh2
Received disconnect from 192.168.1.7: 14: No supported authentication methods available [preauth]
do_cleanup [preauth]
monitor_read_log: child log fd closed
do_cleanup
PAM: cleanup
Pourquoi cela se produit-il et comment puis-je résoudre ce problème?
Problème résolu:
On dirait qu'il y a eu un problème avec mon fichier de clé publique. PuttyGen créera un fichier de clé publique qui ressemble à ceci:
---- BEGIN SSH2 PUBLIC KEY ----
Comment: "rsa-key-20121022"
AAAAB3NzaC1yc2EAAAABJQAAAIEAhGF6GIuMY8FJ1+CNApnSY1N2YSlkYz72Yvwu
a6N1nFpBklz1+dsIMg4rcTLcF34M/tW5Yz+NUDAw2AEbxQ32FPgw7sAOIXktkYOH
tr7mmimiTjkoSCrJh1kqalPSpi8rglT/Bp67Ql2SZwvUFfMzHISryR0EZC4rXP/u
vObrJe8=
---- END SSH2 PUBLIC KEY ----
Cependant, cela ne fonctionnera pas, vous devez donc ouvrir la clé dans PuttyGen, puis la copier à partir de là (la clé sera alors au bon format et sur une ligne):
ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAIEAhGF6GIuMY8FJ1+CNApnSY1N2YSlkYz72Yvwua6N1nFpBklz1+dsIMg4rcTLcF34M/tW5Yz+NUDAw2AEbxQ32FPgw7sAOIXktkYOHtr7mmimiTjkoSCrJh1kqalPSpi8rglT/Bp67Ql2SZwvUFfMzHISryR0EZC4rXP/uvObrJe8= rsa-key-20121022
Collez ceci dans authorized_keys
alors cela devrait fonctionner.
/etc/ssh/sshd_config
.PasswordAuthentication
et ChallengeResponseAuthentication
par yes
.3a. Redémarrez ssh /etc/init.d/ssh restart
.
OU
3b. mieux vous utilisez service sshd restart
J'espère que cela pourrait aider quelqu'un d'autre avec les maux de tête que j'avais. F21 a raison de dire que vous devez copier la clé hors de la fenêtre de PuTTYGen au lieu de sauvegarder le fichier, mais après la copie, la façon dont vous la collez peut avoir un impact significatif sur le fonctionnement de votre clé. Certains éditeurs modifieront le texte au fur et à mesure que vous collerez ou feront quelque chose avec des nouvelles lignes ou quelque chose qui rend le fichier authorised_keys invalide.
Ce que j'ai trouvé être le moins susceptible de casser est de faire écho à la chaîne complète et de rediriger la sortie vers le fichier. En cliquant avec le bouton droit de la souris dans PuTTY pour coller la chaîne de clé dans la ligne de commande, cela fonctionne comme suit (avec l'exemple donné ci-dessus):
echo [right-click-to-paste-here] > /etc/ssh/username/authorized_keys
Vous allez vous retrouver avec ceci:
echo ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAIEAhGF6GIuMY8FJ1+CNApnSY1N2YSlkYz72Yvwua6N1nFpBklz1+dsIMg4rcTLcF34M/tW5Yz+NUDAw2AEbxQ32FPgw7sAOIXktkYOHtr7mmimiTjkoSCrJh1kqalPSpi8rglT/Bp67Ql2SZwvUFfMzHISryR0EZC4rXP/uvObrJe8= rsa-key-20121022 > /etc/ssh/username/authorized_keys
Un autre avantage de cette méthode est que vous pouvez ajouter plusieurs clés de cette manière en utilisant >> pour ajouter au lieu de> pour remplacer, par exemple:
echo ssh-rsa AAAAB3<...snip...>rJe8= rsa-key-20121022 >> /etc/ssh/username
J'espère que ça aide quelqu'un.
Nous utilisions déjà le bon type de clé (ppk au lieu de pem).
Dans notre cas, il s’agissait d’un problème d’autorisations de fichier pour allowed_keys sur le dossier de l’utilisateur du serveur. Ce doit être -rw-r - r-- ... C'était -rw-rw-r--
sSH est très pointilleux sur les permanentes de fichiers.
Dans mon cas, la raison en était que le fichier de clé privée (.ppk) avait été supprimé dans l'agent d'authentification PuTTY, à savoir Pageant. Je viens juste de le mettre à jour à nouveau sur Pageant et la connexion a parfaitement fonctionné par la suite.
Résolu: