Dois-je supprimer les mots de passe des utilisateurs une fois que j'ai configuré l'authentification par clé publique pour SSH?
Il est préférable d'utiliser des clés publiques pour SSH. Alors mon sshd_config a PasswordAuthentication no.
Certains utilisateurs ne se connectent jamais, par exemple un utilisateur sftp avec Shell /usr/sbin/nologin. Ou un compte système.
Je peux donc créer un tel utilisateur sans mot de passe avec adduser gary --Shell /usr/sbin/nologin --disabled-password.
Est-ce une bonne/mauvaise idée? Y a-t-il des ramifications auxquelles je n'ai pas pensé?
Si vous avez un accès root au serveur et pouvez régénérer les clés ssh pour vos utilisateurs au cas où ils les perdraient
ET
vous êtes sûr qu'un utilisateur (en tant que personne) n'aura pas plusieurs comptes d'utilisateur et qu'il doit basculer entre ceux d'une session SSH (enfin, ils peuvent également ouvrir plusieurs sessions SSH si le besoin s'en fait sentir)
ET
ils auront jamais besoin d'un accès "physique" (via clavier + moniteur ou via console distante pour une VM) au serveur
ET
aucun utilisateur n'a accès à un mot de passe Sudo (c'est-à-dire qu'il n'a pas du tout accès Sudo, ou qu'il a accès Sudo avec NOPASSWD)
Je pense que tu vas bien.
Nous avons de nombreux serveurs au travail configurés comme ceci (seuls certains comptes ont besoin d'accéder à VM via la console distante vmware, les autres se connectent uniquement via SSH avec l'authentification pubkey).
Cette question mentionnait à l'origine passwd --delete <username> ce qui n'est pas sûr : avec cela, le champ du mot de passe crypté dans /etc/shadow Sera complètement vide .
username::...
Si vous avez configuré votre sshd pour refuser l'authentification par mot de passe, alors c'est sûr avec SSH ... Mais si le service tout autre sur votre système utilise l'authentification par mot de passe et n'est pas configuré pour rejeter les mots de passe nuls, cela permet l'accès sans mot de passe! Vous ne voulez pas cela.
adduser --disabled-passwd Produira une entrée /etc/shadow Où le champ du mot de passe chiffré n'est qu'un astérisque, c'est-à-dire.
username:*:...
Il s'agit d'un "mot de passe crypté qui ne peut jamais être entré avec succès", c'est-à-dire que le compte est valide et autorise techniquement les connexions, mais il rend impossible l'authentification par mot de passe . Donc, si vous avez d'autres services basés sur l'authentification par mot de passe sur votre serveur, cet utilisateur en est bloqué.
Seules les méthodes d'authentification qui utilisent autre chose que le mot de passe de compte standard (par exemple les clés SSH) fonctionneront pour cet utilisateur, pour tout service qui utilise les fichiers de mot de passe système dans ce système. Lorsque vous avez besoin d'un utilisateur qui peut se connecter avec des clés SSH uniquement, c'est ce que vous voulez.
Si vous devez définir un compte existant sur cet état, vous pouvez utiliser cette commande:
echo 'username:*' | chpasswd -e
Il existe une troisième valeur spéciale pour le champ de mot de passe crypté: adduser --disabled-login, Le champ ne contiendra alors qu'un seul point d'exclamation.
username:!:...
Comme l'astérisque, cela rend impossible l'authentification par mot de passe, mais il a également une signification supplémentaire: il marque le mot de passe comme "verrouillé" pour certains outils d'administration. passwd -l A sensiblement le même effet en préfixant le hachage de mot de passe existant avec un point d'exclamation, ce qui rend à nouveau l'authentification par mot de passe impossible à utiliser.
Mais voici un piège pour les imprudents: en 2008, la version de la commande passwd qui provient de l'ancienne shadow package a été changé pour redéfinir passwd -l de "verrouiller le compte" à "verrouiller le mot de passe". La raison indiquée est "pour la compatibilité avec une autre version de passwd".
Si vous (comme moi) avez appris cela il y a longtemps, cela peut être une mauvaise surprise. Cela n'aide pas non plus que adduser(8) ne soit apparemment pas encore au courant de cette distinction.
La partie qui désactive le compte pour toutes les méthodes d'authentification définit en fait une valeur de date d'expiration de 1 pour le compte: usermod --expiredate 1 <username>. Avant l'année 2008, passwd -l Qui provient du kit source shadow utilisé pour ce faire en plus de préfixant le mot de passe avec un point d'exclamation - mais ne fait plus fais ça.
Le journal des modifications du paquet Debian dit:
- debian/patches/494_passwd_lock-no_account_lock: Restaurez le comportement précédent de passwd -l (qui a changé dans # 389183): verrouillez uniquement le mot de passe de l'utilisateur, pas le compte de l'utilisateur. Documentez également explicitement les différences. Cela restaure un comportement commun avec les versions précédentes de passwd et avec d'autres implémentations. Ferme: # 492307
Les historiques de bogues pour bogue Debian 492307 et bogue 38918 peuvent être utiles pour comprendre la réflexion derrière cela.