Echec de la connexion SSH avec la clé publique

J'ai rencontré ce problème lorsque j'ai essayé de me connecter à un compte qui n'a pas de mot de passe, même si j'utilise l'authentification par paire de clés SSH et que la connexion par mot de passe est désactivée. La solution a été de définir un mot de passe en utilisant mon compte root :

passwd user1
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully

1. Lorsque vous rencontrez un problème de connexion à un serveur, il est toujours préférable d'ajouter l'option -v le drapeau, par exemple

   $ ssh -v host -l user

2. Dans les deux cas ci-dessus, la clé publique ( id_rsa.pub ) doit être ajouté au fichier " .ssh/authorized_keys " de l'utilisateur distant. Dans votre cas ci-dessus, à la fois pour root et user1. Cela peut facilement être fait via la commande ssh-copy-id commandement.

3. /var/log/secure contient des indices sur la raison pour laquelle la connexion n'a pas réussi.

4. Les permissions du répertoire doivent être 700 [rwx] (et non 600) [rw-].

J'ai rencontré un problème similaire il y a quelque temps en essayant de faire un

chmod -R 600 ~/.ssh 

Apparemment, si les permissions des fichiers sont correctes mais que celles des répertoires ne le sont pas, le même type d'erreur de permissions peut se produire.

Je pense également que vous devez renommer le fichier id_rsa.pub en authorized_keys.

Quelques notes : Puisque vous avez spécifiquement désactivé l'authentification par mot de passe, vous ne pouvez pas vous connecter avec un mot de passe. Je pense que vous devez configurer les utilisateurs autorisés d'une autre manière (Match User est probablement la meilleure façon de procéder). De plus, vous devez autoriser spécifiquement l'utilisateur root (PermitRootLogin réglé sur oui).

Il serait judicieux de nous donner un peu plus d'informations sur les paramètres dans /etc/ssh/sshd_config en particulier StrictModes ( grep StrictModes /etc/ssh/sshd_config ). StrictModes est le paramètre qui régit la sensibilité sshd réagit aux permissions des fichiers et des dossiers de chaque utilisateur. ~/.ssh y ~/.ssh/authorized_keys . Vous ne nous avez pas non plus donné le décor de AuthorizedKeysFile dans votre sshd_config . Très pertinent, si votre serveur SSH cherche le fichier ailleurs que là où vous l'avez mis.

Mais en dehors des réponses données jusqu'à présent, il peut y avoir une multitude de raisons à cela. Le problème est que, même si vous avez essayé, il n'y a pas assez d'informations pour deviner avec certitude ce qui ne va pas.

Une autre chose peut être les restrictions PAM ( UsePAM sur sshd_config ). Ubuntu l'a fait à un moment donné. Si le compte utilisateur n'avait pas de mot de passe défini (authentification par clé publique uniquement), il n'était pas autorisé à entrer.

Mais laissez-moi vous donner une méthode générique pour déboguer de tels problèmes.

Dépannage générique de sshd

Ce que je trouve généralement très utile dans de tels cas est de commencer par sshd sans le laisser se démoniser ("passer en arrière-plan et se détacher du terminal"). Souvent, les journaux ne seront pas très utiles, en particulier lorsque vous avez une erreur de configuration (ce qui n'est pas le cas le plus évident).

Vous le démarrez depuis le terminal comme ça :

# $(which sshd) -Ddp 10222

Vous obtiendrez ainsi de nombreux résultats de débogage qui n'apparaîtraient pas autrement (sans l'option -d ) ou finir dans les bûches si vous avez de la chance.

NB : le site $(which sshd) est la meilleure méthode pour satisfaire sshd l'exigence d'un chemin absolu. Sinon, vous obtiendrez l'erreur suivante : sshd re-exec requires execution with an absolute path . Le site -p 10222 fait sshd écouter sur ce port alternatif, en prenant le pas sur le fichier de configuration - ceci afin de ne pas entrer en conflit avec d'éventuelles exécutions de sshd instances. Assurez-vous de choisir un port libre ici.

Cette méthode m'a aidé à de nombreuses reprises à trouver des problèmes, qu'il s'agisse de problèmes d'authentification, de performances ou d'autres types de problèmes. Pour obtenir une sortie vraiment verbeuse à stdout utiliser $(which sshd) -Ddddp 10222 (notez l'ajout de dd pour augmenter la verbosité). Pour plus de facilité de débogage, consultez man sshd .

Du côté du client ssh peut prendre -v (jusqu'à -vvv ) pour être très explicite sur ce qu'il fait.

La ligne de journal

... ubuntu sshd[8476]: User root not allowed because account is locked

laisse entendre que c'est le problème, alors cours :

sudo passwd -u root