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_configa 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é?

— lonix
source

Tant que ce ne sont pas de vrais comptes d'utilisateurs, ou qu'ils n'ont pas besoin de leur mot de passe pour y sudoaccéder (soit parce qu'ils n'ont pas du tout d'autorisations sudo, soit en ayant l'autorisation sudo avec NOPASSWD), la réponse que vous avez sélectionnée devrait être appropriée. J'ai soumis une modification à cette réponse pour inclure la préoccupation sudo, mais j'ai pensé que je vous l'appellerais ici en attendant.

— Doktor J

Réponses:

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

vous êtes sûr qu'un utilisateur (en tant que personne) n'aura pas plusieurs comptes d'utilisateurs et qu'il doit basculer entre ceux d'une session SSH (enfin, il peut également ouvrir plusieurs sessions SSH si le besoin s'en fait sentir)

ils n'auront jamais besoin d'un accès "physique" (via clavier + moniteur ou via console distante pour une VM) au serveur

aucun utilisateur n'a sudoaccès par mot de passe (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 à la machine virtuelle via la console distante vmware, les autres se connectent uniquement via SSH avec l'authentification pubkey).

— M. Shunz
source

J'ajouterais également "vous savez que les utilisateurs n'auront jamais à accéder au système à partir de systèmes distants dépourvus de leur clé SSH privée". Et "Vous êtes prêt à traiter avec des utilisateurs qui se retrouvent dans une situation à laquelle vous n'avez pas pensé."

— Andrew Henle

La première condition est que l'OMI n'est pas nécessaire. Vos utilisateurs doivent créer eux-mêmes leurs clés. Vous autorisez simplement leurs clés publiques telles qu'elles vous les donnent. S'ils perdent une clé, ils n'en généreront qu'une autre et vous remplacerez l'ancienne sur le serveur.

— Christophe Drevet-Droguet

@AndrewHenle C'est un bon point, cependant si sshd a PasswordAuthentication noalors c'est un problème différent (l'utilisateur ne pourrait pas se connecter de toute façon).

— lonix

"Jamais" est si long. L'administrateur peut facilement rajouter l'authentification par mot de passe, si besoin est.

— hyde

Eh bien, la question concerne clairement les comptes qui ne se connectent certainement pas (et ne devraient probablement pas) se connecter, comme les comptes système utilisés par des services spécifiques ou des utilisateurs sftp uniquement. La question indique également que les utilisateurs n'ont pas de shell de connexion. Pour ces types d'utilisateurs, je pense qu'il est conseillé de désactiver explicitement la connexion via mot de passe.

— Christian Gawron

Cette question mentionnée à l'origine passwd --delete <username> n'est pas sûre : avec cela, le champ de mot de passe crypté /etc/shadowsera complètement vide.

username::...

Si vous avez configuré votre sshdpour refuser l'authentification par mot de passe, alors c'est sûr avec SSH ... Mais si tout autre service 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! Tu ne veux pas ça.

adduser --disabled-passwdproduira une /etc/shadowentrée où le champ de mot de passe crypté est juste un astérisque, c.-à-d.

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-loginalors le champ ne contiendra 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 -la le même effet en préfixant le hachage de mot de passe existant avec un point d'exclamation, ce qui rend encore une fois l'authentification par mot de passe impossible à utiliser.

Mais voici un piège pour les imprudents: en 2008, la version de la passwdcommande qui vient de l'ancien shadowpaquet a été changée pour redéfinir passwd -lde "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 les sujets qui ne adduser(8)sont apparemment pas encore conscients de cette distinction.

La partie qui désactive le compte pour toutes les méthodes d'authentification est effectivement mise en valeur d' une date d'expiration de 1 pour le compte: usermod --expiredate 1 <username>. Avant l'année 2008, passwd -lcela provient du shadowkit source utilisé pour ce faire en plus de préfixer le mot de passe avec un point d'exclamation - mais ne fait plus cela.

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 aux versions précédentes de passwd et à d'autres implémentations. Ferme: # 492307

L'historique des bogues pour le bogue 492307 et le bogue 389183 de Debian peut être utile pour comprendre la réflexion derrière cela.

— telcoM
source

Merci pour l'avertissement ... Je vais modifier la question pour que personne ne fasse cette erreur!

— lonix

Votre avertissement s'applique-t-il également au cas où j'utilise adduser --disabled-passwd- donc si un autre service permet l'authentification par mot de passe, l'utilisateur peut se connecter sans mot de passe?

— lonix

Non, adduser --disabled-passwordspécifiquement, il est impossible de réussir l'authentification par mot de passe pour ce compte.

— telcoM

Parce que la suppression du mot de passe semble si innocente mais si dangereuse, je suggère de changer le paragraphe à ce sujet avec le paragraphe sur l'utilisation *, c'est donc la première chose que les gens lisent.

— Captain Man

Wow, c'est une mauvaise surprise qui attend de se produire ... et comme d'habitude, il y a apparemment un problème de compatibilité à blâmer. Il est apparu dans passwdle code source en 2008. Ne l'aimez-vous pas quand quelque chose que vous avez appris et sur lequel vous vous êtes fondé s'est avéré ne plus l'être?

— telcoM