Comment déverrouiller le compte pour l'autorisation ssh de clé publique, mais pas pour l'autorisation de mot de passe?

Le ssh ne me laisse pas me connecter, car le compte est verrouillé. Je veux déverrouiller l'utilisateur sur mon serveur pour l'autorisation de clé publique sur ssh, mais ne pas activer la connexion par mot de passe.

J'ai essayé:

# passwd -u username
passwd: unlocking the password would result in a passwordless account.
You should set a password with usermod -p to unlock the password of this account.

Entrées du journal d'authentification:

Mar 28 00:00:00 vm11111 sshd[11111]: User username not allowed because account is locked
Mar 28 00:00:00 vm11111 sshd[11111]: input_userauth_request: invalid user username [preauth]

Déverrouillez le compte et donnez à l'utilisateur un mot de passe complexe comme le suggère @Skaperen.

Modifiez /etc/ssh/sshd_configet assurez-vous d'avoir:

PasswordAuthentication no

Vérifiez que la ligne n'est pas commentée ( #au début) et enregistrez le fichier. Enfin, redémarrez le sshdservice.

Avant cela, assurez-vous que votre authentification par clé publique fonctionne en premier.

Si vous devez le faire pour un seul (ou un petit nombre) d'utilisateurs, laissez PasswordAuthenticationactivé et utilisez plutôt Match User:

Match User miro, alice, bob
    PasswordAuthentication no

Placer au bas du fichier car il est valide jusqu'à la prochaine Matchcommande ou EOF.

Vous pouvez également utiliser Match Group <group name>ou une négationMatch User !bloggs

Comme vous le mentionnez dans les commentaires, vous pouvez également l'inverser afin que l'authentification par mot de passe soit désactivée dans la partie principale de la configuration et utiliser des Matchinstructions pour l'activer pour quelques utilisateurs:

PasswordAuthentication no
.
.
.
Match <lame user>
    PasswordAuthentication yes

Quoi que vous fassiez, ne laissez pas le compte dans l'état laissé par passwd -u, avec un champ de mot de passe vide: qui permet les connexions sans entrer de mot de passe (sauf via SSH, car SSH refuse cela).

Modifiez le compte pour ne pas avoir de mot de passe, mais déverrouillez. Un compte n'a pas de mot de passe si le hachage de mot de passe dans la base de données de mots de passe n'est pas le hachage d'une chaîne. Traditionnellement, une chaîne d'un caractère telle que *ou !est utilisée pour cela.

Les comptes verrouillés utilisent également un marqueur spécial dans le champ de mot de passe qui empêche la chaîne d'être le hachage d'une chaîne. Le marqueur dépend du système. Sous Linux, la passwdcommande marque les mots de passe verrouillés en mettant un !au début, et OpenSSH traite le compte comme verrouillé si le champ commence par !. Les autres variantes Unix ont tendance à utiliser des mécanismes similaires mais pas identiques, alors faites attention si votre base de données de mots de passe est partagée entre un réseau hétérogène.

Sous Linux, vous pouvez désactiver l'accès par mot de passe à un compte tout en autorisant l'accès SSH (avec une autre méthode d'authentification, généralement une paire de clés) avec

usermod -p '*' username

L'utilisateur ne pourra pas redéfinir le compte pour avoir un mot de passe, car cela nécessite qu'il entre un mot de passe valide.

Si vous le souhaitez, vous pouvez configurer SSH à la place pour refuser l'authentification par mot de passe, que le compte ait ou non un mot de passe. Vous devrez toujours prendre des dispositions pour que SSH ne considère pas le compte comme verrouillé, donc par exemple sous Linux, vous devrez supprimer le !champ du mot de passe (mais ne faites pas le champ vide - définissez-le *comme expliqué ci-dessus) ). Pour désactiver l'authentification par mot de passe pour SSH, ajoutez une PasswordAuthenticationdirective à /etc/sshd_configou /etc/ssh/sshd_config(quelle qu'elle soit sur votre système). Utilisez un Matchbloc pour que cette directive ne s'applique qu'à un utilisateur spécifique; Matchles blocs doivent apparaître

…
Match User username
    PasswordAuthentication no

Vous n'avez pas besoin d'activer ou de définir des mots de passe, et vous ne devriez vraiment pas, si vous utilisez déjà des clés fortes. Re-verrouillez simplement votre compte (sudo passwd -l nom d'utilisateur) à partir d'une session existante et corrigez votre configuration SSH.

La raison pour laquelle cela s'est produit est probablement parce que vous avez modifié l'un des paramètres par défaut du démon SSH (dans / etc / ssh / sshd_config).

Modifiez cela dans / etc / ssh / sshd_config et redémarrez SSH:

UsePAM yes

En général, sauf si vous avez une très bonne raison de désactiver PAM, je vous recommande de le garder activé; l'activation de PAM dans SSH vous permettra de toujours vous connecter, même avec un mot de passe supprimé. Quoi que vous fassiez, ne définissez pas un mot de passe vide ou similaire ... verrouiller le champ du mot de passe ne signifie pas nécessairement verrouiller tout votre compte.

Astuce rapide lorsque vous jouez avec SSH: gardez une autre session ouverte (dans une autre fenêtre) chaque fois que vous modifiez votre configuration SSH, puis testez que vous pouvez toujours vous connecter; si vous interrompez votre accès par inadvertance, utilisez votre session en cours pour y remédier.

(Avertissement: je travaille chez Userify, qui fournit un logiciel de gestion de clés SSH.)

J'ai eu ce problème sur CentOS 7. Je suis un utilisateur Linux régulier basé sur Debian, j'étais donc un poisson hors de l'eau. J'ai remarqué que dans certains serveurs, cela fonctionnait et dans un seul, cela ne fonctionnait pas. L'audit.log n'a rien dit d'utile et le secure.log n'a rien donné non plus. J'ai trouvé que la seule vraie différence était quelques différences de contexte de sécurité sur les fichiers et les répertoires entre ceux qui fonctionnaient et ceux qui ne fonctionnaient pas. Obtenez la sécurité avec

sudo ls -laZ <user-home>/.ssh

du répertoire (je suppose que beaucoup de valeurs par défaut sur sshd_config).

Vous devriez voir certains attributs ssh_home_tet user_home_t. Si ce n'est pas le cas, utilisez la chconcommande pour ajouter les attributs manquants.

Par exemple

home="$(getent passwd <user> | cut -d: -f6)"
sudo chcon -R unconfined_u:object_r:ssh_home_t:s0 "$home".ssh
sudo chcon unconfined_u:object_r:user_home_t:s0 "$home"

Dans mon cas, je soupçonne que l'utilisateur a été créé de manière non standard. Sa maison était un répertoire /var/lib.

Plus d'informations sur: https://www.linuxquestions.org/questions/linux-security-4/selinux-preventing-ssh-login-with-~-ssh-authorized_keys-4175469538/

déverrouillez le compte et changez le mot de passe en une chaîne aléatoire