Je tente de me connecter en SSH avec PuTTY sur Windows à une machine Ubuntu.
J'ai créé la clé publique et la clé privée avec PuttyKeygen et ajouté la clé publique au fichier /home/[user]/.ssh/authorized_keys du serveur en tant que ligne unique, en ajoutant [user@serveur] à la fin, et en ajoutant ssh-rsa au début, ce qui donne :
ssh-rsa [clé] [utilisateur]@[serveur]Cela se trouve sur une seule ligne; le chmod de authorized_keys est de 600, le dossier ~/.ssh est de 700 sur le serveur. Tout est conforme à ce tutoriel.
Pourtant, lorsque j'essaie d'utiliser le fichier de clé privée avec PuTTY, je reçois la réponse suivante :
"Le serveur a refusé notre clé"
Voici le journal de session :
2011-10-08 23:43:58 Recherche de l'hôte "serveur"
2011-10-08 23:43:58 Connexion au port 22 de serveur
2011-10-08 23:43:58 Version du serveur : SSH-2.0-OpenSSH_5.8p1 Debian-1ubuntu3
2011-10-08 23:43:58 Nous utilisons la version : SSH-2.0-PuTTY_Release_0.60
2011-10-08 23:43:58 Utilisation du protocole SSH version 2
2011-10-08 23:43:58 Échange du groupe Diffie-Hellman
2011-10-08 23:43:58 Échange de clés Diffie-Hellman avec le hachage SHA-256
2011-10-08 23:43:59 L'empreinte de la clé d'hôte est :
2011-10-08 23:43:59 ssh-rsa 2048 be:32:9b:69:e9:fb:5d:08:71:3e:08:09:4d:b2:c8:b4
2011-10-08 23:43:59 Initialisation du chiffrement client->serveur AES-256 SDCTR
2011-10-08 23:43:59 Initialisation de l'algorithme HMAC-SHA1 client->serveur MAC
2011-10-08 23:43:59 Initialisation du chiffrement serveur->client AES-256 SDCTR
2011-10-08 23:43:59 Initialisation de l'algorithme HMAC-SHA1 serveur->client MAC
2011-10-08 23:43:59 Lecture du fichier de clé privée "C:\Users\User\.ssh\id_rsa.ppk"
2011-10-08 23:43:59 Clé publique proposée
2011-10-08 23:43:59 Le serveur a refusé la clé publiqueVoici ce que je vois dans le fichier auth.log
Oct 9 01:53:12 [serveur] sshd[1818]: Connexion fermée par [client-ip]
Oct 9 01:53:12 [serveur] sshd[1818]: Transféré : envoyé 3104 octets, reçu 2008 octets
Oct 9 01:53:12 [serveur] sshd[1818]: Fermeture de la connexion à [client-ip] sur le port 51499
Oct 9 01:53:12 [serveur] sshd[1800]: pam_unix(sshd:session): session fermée pour l'utilisateur [utilisateur]
Oct 9 01:53:15 [serveur] sshd[1786]: Connexion fermée par [client-ip]
Oct 9 01:53:15 [serveur] sshd[1786]: Transféré : envoyé 1944288 octets, reçu 9040 octets
Oct 9 01:53:15 [serveur] sshd[1786]: Fermeture de la connexion à [client-ip] sur le port 51498
Oct 9 01:53:15 [serveur] sshd[1764]: pam_unix(sshd:session): session fermée pour l'utilisateur [utilisateur]
Oct 9 01:53:20 [serveur] sshd[1933]: A réglé /proc/self/oom_score_adj à 0
Oct 9 01:53:20 [serveur] sshd[1933]: Connexion depuis [client-ip] sur le port 51501
Oct 9 01:53:20 [serveur] sshd[1933]: Échec d'authentification par clé publique pour [utilisateur] depuis [client-ip] port 51501 ssh2Voici le fichier sshd_config
# Ports, IPs et protocoles que nous écoutons
Port 22
# Utilisez ces options pour restreindre les interfaces/protocoles auxquels sshd se liera
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocole 2
# Clés hôtes pour la version du protocole 2
CléHôte /etc/ssh/ssh_host_rsa_key
CléHôte /etc/ssh/ssh_host_dsa_key
# La séparation des privilèges est activée pour des raisons de sécurité
UtilisationSéparationPrivilèges oui
# Durée de vie et taille de la clé serveur éphémère de la version 1
IntervalleRegénérationClé 3600
TailleCléServeur 768
# Journalisation
FacilitéSyslog AUTH
NiveauJournal DEBUG#INFO
# Authentification :
DélaiGrâceConnexion 120
ConnexionAutoriséeRoot non
ModesStrictes oui
AuthentificationRSA oui
AuthentificationCléPublique oui
FichierClésAutorisées /home/%u/.ssh/authorized_keys
# Ne pas lire les fichiers ~/.rhosts et ~/.shosts de l'utilisateur
IgnorerRhosts oui
# Pour que cela fonctionne, vous aurez également besoin de clés hôtes dans /etc/ssh_known_hosts
AuthentificationRhostsRSA oui#non
# de même pour la version du protocole 2
AuthentificationBaséeHôte non
# Décommentez si vous ne faites pas confiance à ~/.ssh/known_hosts pour l'authentificationRhostsRSA
#IgnorerHôtesConnusUtilisateur oui
# Pour autoriser les mots de passe vides, changer en yes (PAS RECOMMANDÉ)
AutoriserMotsDePasseVides non
# Passez à yes pour activer les mots de passe par challenge-réponse (attention aux problèmes avec
# certains modules PAM et les threads)
AuthentificationChallengeRéponse non
# Passez à no pour désactiver les mots de passe en clair tunnelisés
# AuthentificationMotDePasse no
# Options Kerberos
#AuthentificationKerberos no
#RécupérationJettonAFSKerberos no
#KerberosOuPasswdLocal yes
#NettoyageJettonKerberos yes
# Options GSSAPI
#AuthentificationGSSAPI no
#NettoyageJettonsAuthentificationGSSAPI yes
TransfertX11 oui
DécalageAffichageX11 10
AfficherMessage non
JournalDernièreConnexion oui
MaintienConnexionTCP oui
#UtilisationConnexion non
#NombreMaxDémarrages 10:30:60
#Bannière /etc/issue.net
# Autorise le client à transmettre des variables d'environnement de localisation
AccepterEnv LANG LC_*
SousSystème sftp /usr/lib/openssh/sftp-serveur
# Passez à 'yes' pour activer l'authentification PAM, le traitement du compte,
# et le traitement des sessions. Si cela est activé, l'authentification PAM sera
# autorisée via l'AuthentificationChallengeRéponse et
# AuthentificationMotDePasse. Selon votre configuration PAM,
# l'authentification PAM via AuthentificationChallengeRéponse peut contourner
# le réglage de "ConnexionAutoriséeRoot sans mot de passe".
# Si vous souhaitez simplement que les vérifications de compte et de session PAM s'exécutent sans
# l'authentification PAM, alors activez ceci mais définissez AuthentificationMotDePasse et
# AuthentificationChallengeRéponse sur 'no'.
UtilisationPAM oui
