Je plussoie et j'en rajoute. Les seuls cas que j'ai croisé où un mot de passe semblait mieux, il s'est avéré ensuite que ce "mieux" était uniquement lié à mon incompétence ; quand on apprend à se servir des clés, c'est mille fois plus sécurisé et puissant, et cela ne complexifie même pas vraiment la tâche (passée la phase d'apprentissage). Une bonne politique sur les mots de passe demande de toute façon aussi un sacré apprentissage ; typiquement sur l'accès ssh, tu peux bien mettre un mot de passe de 25 caractères, mais si tu ne fais que ça, tu garde un risque assez élevé de te faire trouer le serveur. Et comme derrière, l'utilisateur par défaut est probablement "root", ça sera tout de suite du vrai dégât (vu comme les bots tentent de rentrer en utilisant "root" comme utilisateur, il doit y avoir une raison statistique). Après, si quelqu'un as des exemples concrets où le mot de passe est plus pertinent, je suis ouverte à revoir ma copie... Mais il me faudra des cas concrets où une clé ssh n'aurais pas été pertinente.
On peut aussi faire des bêtises avec des clés (être sur une distribution où les options par défaut sont faibles, la générer sans mot de passe, stocker la clé privée de façon non sécurisée, etc) mais comme cela demande de comprendre un peu ce qu'on fait, il y a plus de chance de faire "suffisamment bien".
Tiens d'ailleurs autre point de sécurité par défaut : interdire formellement la connexion ssh via l'utilisateur root... Oui oui, si on a une connexion par clé, fail2ban, etc, la connexion via root n'est pas tant un souci, mais c'est quand même augmenter un peu les risques, pour un confort mineur. Et la combo des config par défaut root+connexion par mot de passe, c'est juste terrible.
Tout ce qui va à l'encontre des pratiques statistiques améliore les chances de résister aux crackbots de base et des script-kiddies, qui représentent la majorité des attaques. Donc au moins pousser l'utilisateur à se choisir un nom d'utilisateur et un mot de passe associé pour accéder au sésame "sudo" (ce qui est le cas sur pas mal de distributions de bureau), puis interdire "root" à se connecter en ssh, c'est déjà pas mal.
[^] # Re: Paramètres par défaut des distributions
Posté par Zatalyz (site web personnel) . En réponse au journal ssh : et si nous sensibilisions par un label, ou autre impératif?. Évalué à 3.
Je plussoie et j'en rajoute. Les seuls cas que j'ai croisé où un mot de passe semblait mieux, il s'est avéré ensuite que ce "mieux" était uniquement lié à mon incompétence ; quand on apprend à se servir des clés, c'est mille fois plus sécurisé et puissant, et cela ne complexifie même pas vraiment la tâche (passée la phase d'apprentissage). Une bonne politique sur les mots de passe demande de toute façon aussi un sacré apprentissage ; typiquement sur l'accès ssh, tu peux bien mettre un mot de passe de 25 caractères, mais si tu ne fais que ça, tu garde un risque assez élevé de te faire trouer le serveur. Et comme derrière, l'utilisateur par défaut est probablement "root", ça sera tout de suite du vrai dégât (vu comme les bots tentent de rentrer en utilisant "root" comme utilisateur, il doit y avoir une raison statistique). Après, si quelqu'un as des exemples concrets où le mot de passe est plus pertinent, je suis ouverte à revoir ma copie... Mais il me faudra des cas concrets où une clé ssh n'aurais pas été pertinente.
On peut aussi faire des bêtises avec des clés (être sur une distribution où les options par défaut sont faibles, la générer sans mot de passe, stocker la clé privée de façon non sécurisée, etc) mais comme cela demande de comprendre un peu ce qu'on fait, il y a plus de chance de faire "suffisamment bien".
Tiens d'ailleurs autre point de sécurité par défaut : interdire formellement la connexion ssh via l'utilisateur root... Oui oui, si on a une connexion par clé, fail2ban, etc, la connexion via root n'est pas tant un souci, mais c'est quand même augmenter un peu les risques, pour un confort mineur. Et la combo des config par défaut root+connexion par mot de passe, c'est juste terrible.
Tout ce qui va à l'encontre des pratiques statistiques améliore les chances de résister aux crackbots de base et des script-kiddies, qui représentent la majorité des attaques. Donc au moins pousser l'utilisateur à se choisir un nom d'utilisateur et un mot de passe associé pour accéder au sésame "sudo" (ce qui est le cas sur pas mal de distributions de bureau), puis interdire "root" à se connecter en ssh, c'est déjà pas mal.