SSH a échoué l'authentification par clé publique

16

J'ai un serveur et je veux pouvoir me connecter avec deux utilisateurs différents. J'ai configuré l'authentification par clé publique pour le premier utilisateur, et cela fonctionne très bien, cependant, je ne peux pas me connecter avec le deuxième utilisateur. La différence entre le authorized_keysfichier est que le deuxième utilisateur a deux clés (les deux échouent lors de l'authentification). Le répertoire .ssh et le fichier de clés autorisées disposent de 755 autorisations. Le client ssh envoie la clé avec laquelle je veux m'authentifier. Quel pourrait être le problème?

ssh

— laci37
source

Veuillez montrer les commandes pour les deux utilisateurs et les différentes clés pour le deuxième utilisateur que vous utilisez pour accéder au serveur par ssh.

— lord.garbage

Heureux ce qui précède a fonctionné dans votre cas. En plus de simplement réinitialiser le mot de passe. Je vous conseille également de jeter un coup d'œil si vous avez verrouillé le compte de manière transparente. pam_tally2 --user userb --reset Cela réinitialisera les décomptes échoués sur le compte et vous permettra de vous connecter.

— Tman

18

Tout d'abord, le répertoire .ssh doit avoir 700 autorisations et le fichier authorized_keys doit avoir 600.

chmod 700 .ssh
chmod 600 .ssh/authorized_keys

Dans le cas où vous avez créé les fichiers avec say root pour userB, faites également:

chown -R userb:userb .ssh

Si le problème persiste, postez la sortie de votre fichier journal ssh dans votre question et je mettrai à jour ma réponse.

Pour Debian:

less /var/log/auth

Pour Redhat:

less /var/log/secure

— devnull
source

chown -R userb:userb .sshremplacer userbpar votre utilisateur actuel. je l'ai fait chown -R userb:userb .ssh/authorized_keys au cas où aussi. Réponse vraiment utile !!

— IvRRimUm

5

J'ai trouvé ce message dans /var/log/auth.log:

Oct 22 13:27:58 hagyma sshd[27420]: User userb not allowed because account is locked

J'ai défini un mot de passe pour userb avec sudo passwd userbet il a déverrouillé le compte.

— laci37
source

c'était la solution pour un utilisateur de sauvegarde créé en tant que compte système

— Stuart Cardall

..et maintenant vous avez deux problèmes. espérons que le mot de passe est sécurisé.

— tedder42

3

Pour moi, sshdc'était ignorer ~/.ssh/authorized_keysparce que la /homepartition était montée d'une manière inhabituelle. J'ai tout essayé, j'ai défini les bonnes autorisations et cela n'a fonctionné qu'après une modification dans sshd_config:

StrictModes no

— idragosalex
source

Cela fonctionnait pour moi sur CentOS 7. La connexion root avec la clé publique fonctionnait, mais pas pour les utilisateurs sur / home

— itsafire