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 via ssh, mais je n'active pas 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.
Éditer /etc/ssh/sshd_config et 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 service sshd.
Avant cela, assurez-vous que votre authentification par clé publique fonctionne en premier.
Si vous devez effectuer cette opération pour un seul (ou un petit nombre) d'utilisateurs, laissez PasswordAuthentication activé et utilisez plutôt Match User:
Match User miro, alice, bob
PasswordAuthentication no
Placez au bas du fichier car il est valide jusqu'à la prochaine commande Match ou EOF.
Vous pouvez aussi utiliser Match Group <group name> ou une négation Match 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 les instructions Match 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é 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 commande passwd 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é, par exemple sous Linux, vous devrez supprimer le ! dans le champ du mot de passe (mais ne videz pas le champ - définissez-le sur * comme expliqué ci-dessus). Pour désactiver l'authentification par mot de passe pour SSH, ajoutez une directive PasswordAuthentication à /etc/sshd_config ou /etc/ssh/sshd_config (quel qu'il soit sur votre système). Utilisez un bloc Match pour que cette directive ne s'applique qu'à un utilisateur spécifique; Match les 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 touches fortes. Il vous suffit de re-verrouiller votre compte (Sudo passwd -l nom d'utilisateur) à partir d'une session existante et de corriger 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 votre compte entier.
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 serify , 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 quelques ssh_home_t et user_home_t les attributs. Si ce n'est pas le cas, utilisez la commande chcon 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 dans /var/lib.
Plus d'informations dans: https://www.linuxquestions.org/questions/linux-security-4/selinux-preventing-ssh-login-with-~-ssh-authorized_keys-4175469538/