Pourquoi l'authentification par mot de passe SSH constitue-t-elle un risque pour la sécurité?

68

La plupart des guides pour la configuration OpenSSH conseillent de désactiver l'authentification par mot de passe en faveur de l'authentification par clé. Mais à mon avis, l’authentification par mot de passe présente un avantage considérable: la possibilité de se connecter de manière absolue n’importe où sans clé. S'il est toujours utilisé avec un mot de passe fort, cela ne devrait pas poser de risque de sécurité. Ou devrait-il?

— Septagram
source

2

Les mots de passe sont une authentification à un facteur qui peut être reniflée, devinée et rejouée. Les clés sont (éventuellement) à deux facteurs. Pouvoir se connecter de n'importe où avec un seul facteur est inacceptable sur certains systèmes.

— Alex Holst

25

Il y a des avantages et des inconvénients pour l'authentification pw ou basée sur une clé.

Dans certains cas, par exemple, l'authentification par clé est moins sécurisée que l'authentification par mot de passe. Dans d'autres cas, il est moins sécurisé sur la base de son logiciel. Dans certains cas, l'un est plus pratique, dans d'autres, moins.

Tout se résume à ceci: lorsque vous effectuez une authentification basée sur une clé, vous devez sécuriser votre clé avec une phrase secrète. Sauf si ssh-agent est en cours d'exécution (ssh-agent vous évite de saisir votre phrase secrète à chaque fois), vous n'avez rien gagné en termes de commodité. La sécurité est discutable: le vecteur d’attaque est maintenant passé du serveur à VOUS, à votre compte ou à votre machine personnelle, (...) - ceux-ci peuvent être plus ou moins faciles à détruire.

Pensez en dehors de la boîte lorsque vous décidez cela. Que vous gagniez ou perdiez en termes de sécurité dépend du reste de votre environnement et d'autres mesures.

edit: Oh, viens de voir que vous parlez d'un serveur domestique. J'étais dans la même situation, "mot de passe" ou "clé USB avec la clé" toujours avec moi? Je suis allé pour l'ancien mais ai changé le port d'écoute SSH en quelque chose de différent de 22. Cela arrête tous ces enfoirés de script lamentables brute forçant des plages de réseau entières.

— romain
source

Changer le port SSH de 22 peut ne pas être une bonne idée dans de nombreux cas. adayinthelifeof.nl/2012/03/12/...

— Tymek

75

L'utilisation des clés ssh présente une caractéristique unique par rapport à la connexion par mot de passe: vous pouvez spécifier les commandes autorisées. Cela peut être fait en modifiant le ~/.ssh/authorized_keysfichier sur le serveur.

Par exemple,

command="/usr/local/bin/your_backup_script.sh", ssh-rsa auiosfSAFfAFDFJL1234214DFAfDFa...

n'autoriserait que la commande `/usr/local/bin/your_backup_script.sh" avec cette clé particulière.

Vous pouvez également spécifier les hôtes autorisés pour la clé:

from="yourclient,yourotherclient", ssh-rsa auiosfSAFfAFDFJL1234214DFAfDFa...

Ou combinez les deux:

from="yourbackupserver", command="/usr/local/bin/your_backup_script.sh", ssh-rsa auiosfSAFfAFDFJL1234214DFAfDFa...

Avec les clés, vous pouvez également accorder un accès temporaire à un utilisateur (un consultant, par exemple) à un serveur sans révéler le mot de passe de ce compte particulier. Une fois que le consultant a terminé son travail, la clé temporaire peut être supprimée.

— Janne Pikkarainen
source

Conseil très très utile.

— Sachin Divekar

3

De plus, utiliser Keys, c'est comme avoir un long mot de passe de 2000 caractères (techniquement, c'est encore plus fort) par rapport à ce que vous pouvez

— saisir

3

Deux astuces très utiles sur l’authentification SSH, mais qui ne répondent vraiment pas à la question pour moi ...

— MikeMurko

Si vous souhaitez forcer un utilisateur authentifié par mot de passe à exécuter une commande spécifique, modifiez son shell de connexion. En outre, "accorder un accès temporaire sans révéler le mot de passe" est une très mauvaise idée. Il existe des centaines de façons différentes de conserver l'accès pour plus tard.

— b0fh

Le dernier paragraphe à lui seul répond à la question IMO - les clés permettent une révocation granulaire, alors qu'avec les mots de passe, vous devez informer tout le monde que vous le modifiez.

— Riking

48

Vous pouvez obtenir le meilleur des deux mondes en autorisant uniquement l'authentification par mot de passe à partir de votre réseau. Ajoutez ce qui suit à la fin de votre sshd_config:

PasswordAuthentication no
Match Address 10.0.0.0/8,172.16.0.0/12,192.168.0.0/16
    PasswordAuthentication yes

— MikeyB
source

7

Vous avez partiellement répondu à votre question: plus l'attaquant peut se connecter, plus il a de possibilités pour pénétrer sur votre serveur en armant brutalement (considérez les attaques DDoS).

Comparez également la longueur de votre mot de passe avec la taille de la clé (généralement des milliers de bits).

— Martin Vejmelka
source

4

Une entropie de 96 bits signifie un mot de passe de 80 caractères, s'il est écrit en anglais; 15 caractères s'il s'agit d'un charabia aléatoire du jeu de caractères imprimables. Etes-vous bien sûr que vos mots de passe SSH sont aussi longs / forts?

— MadHatter

3

Si vous avez plusieurs mots de passe avec une entropie de 96 bits qui ne seront pas vulnérables aux attaques du dictionnaire, vous devrez probablement utiliser un logiciel de gestion de mot de passe de toute façon, de sorte que vous perdez effectivement l'élément accessible partout de l'utilisation de mots de passe. .

— Nick Downton

5

@SachinDivekar, c'est 96 bits d'entropie uniquement si vous utilisez des mots de passe aléatoires de l'ensemble [a-zA-Z], pas s'il s'agit de mots anglais.

— Jaap Eldering

16

@ NickDownton - Vous pouvez avoir un bon mot de passe long sans avoir recours au logiciel du clavier. Quelque chose comme mywifesnameisangelaandshehasanicebuttinvunlable aux attaques par dictionnaire, est très fort, et très simple à retenir, mais impossible à deviner. Et cela vient avec le bonus si points brownie si jamais vous avez besoin de donner votre mot de passe à votre femme.

— Mark Henderson

7

Désolé, Mark, mais c'est faux. La phrase secrète que vous donnez contient 37 caractères et donc environ 44 bits d'entropie, ce qui est plus faible que 7 caractères imprimables au hasard et éminemment attaquables. Lisez l'article de Wikipedia sur le travail de Claude Shannon pour plus de détails, mais le résultat est que l'anglais écrit est très prévisible - par exemple, après "mywifesname", le mot "is" est presque garanti. Pour les mots de passe forts impliquant des mots, quatre mots choisis au hasard dans un dictionnaire vous donneront environ 10 ** 23 possibilités, soit environ 77 bits d'entropie; toujours pas génial, mais pas mal.

— MadHatter

7

Lorsque vous vous connectez avec un mot de passe, vous transmettez votre mot de passe au serveur. Cela signifie que l'opérateur du serveur peut modifier le SSHD pour accéder à votre mot de passe. Avec l'authentification par clé publique, ils ne peuvent pas obtenir votre clé privée, car seule votre clé publique est attribuée au serveur.

— Ramon
source

2

Ceci est particulièrement pertinent lorsque vous vous connectez au mauvais serveur en raison d'une faute de frappe. Par exemple, à un moment donné, .cg était un caractère générique pointant sur une seule machine avec ssh activé. Chaque fois que vous saisiriez le type .cg pour le fichier .ch, vous vous connecteriez à cette boîte de

— dialogue

@ b0fh en effet. Autant que je sache, c'est la seule vulnérabilité réelle introduite par l'utilisation de mots de passe avec ssh. Si quelqu'un possède déjà le serveur auquel vous vous connectez ou peut usurper les adresses IP auxquelles vous vous connectez (MITM), vous avez déjà perdu.

— plaques

6

Les clés ssh empêchent les attaques de type homme du milieu contre votre mot de passe.

Lorsque vous essayez de vous connecter avec une clé, le serveur crée un défi basé sur votre clé publique et l'envoie à votre client. qui le déchiffrera et construira une réponse appropriée à envoyer.

Votre clé privée n'est jamais envoyée au serveur et toute personne qui écoute est incapable de faire autre chose que d'intercepter cette session.

avec un mot de passe, ils auraient vos informations d'identification.

Ma solution est d’avoir une clé SSH portable dans des formats appropriés sur une partition chiffrée sur une clé USB. cela me permet de:
retirer facilement cette clé en cas de perte.
restreindre quels serveurs il me permet d'accéder à
et toujours le transporter

Bien que l’installation du logiciel de montage pose un problème (TrueCrypt)

— Tacticus
source

1

C'est faux. Dès que vous connaissez la clé publique du serveur (ce que vous faites si vous l'avez ajoutée à votre cache et que vous n'avez pas reçu MITM lors de la première connexion), vous êtes immunisé contre les attaques MITM. L'authentification par clé / mot de passe n'a rien à voir avec cela. Le mot de passe n'est jamais envoyé en clair sur le réseau, une connexion sécurisée à l'authentification au niveau de l'ordinateur (quelle est votre / ma clé publique) est toujours configurée avant l'authentification au niveau de l'utilisateur (quel est votre mot de passe / prouvez-moi que cette clé publique est la vôtre) .

— Thomas

3

Thomas, en réalité, beaucoup de gens ignorent l'avertissement concernant un changement d'empreinte digitale. L’autorisation Pubkey garantit la protection de MITM même si la clé privée du serveur est compromise ou si un type humain «oui» distraitement: l’attaquant doit choisir entre ne pas voir le trafic et envoyer une clé publique qui ne se connectera pas. gagner.

— Score_Under

5

Et pour le répondeur: vous n'avez pas besoin d'utiliser TrueCrypt, les clés privées openssh sont fournies avec leur propre cryptage facultatif basé sur un mot de passe.

— Score_Under

5

C'est un compromis, comme le dit @MartinVejmelka.

La raison pour laquelle vous utilisez une clé basée sur l'authentification est que la clé est si loin au-dessus de la force brute actuelle ou future qui vous oblige à venir de votre propre PC ou d'avoir la clé sur une clé USB ou similaire.

Un mot de passe a les problèmes suivants:

Si c'est court, ça peut être forcé
Si c'est long c'est facilement oublié
Il pourrait être surfé à l'épaule

Une clé est un ordre de grandeur plus long et ne s'affiche à aucun moment, ce qui évite ces trois problèmes.

— Rory Alsop
source

mais l'utilisation d'un fichier de clé ajoute le problème de la perte du stylo lecteur ou de l'espace de stockage utilisé.

— João Portela

1

à ce stade, la clé perdue peut être supprimée et une nouvelle clé ajoutée. Avec les mots de passe (en particulier les mots de passe partagés), cela peut être une douleur MAJEURE et implique beaucoup de gémissements.

— SplinterReality

Un de mes mots de passe (récemment retraités): 08Forging2?seminal*^Rajas-(Posed/|. C'est généré aléatoirement mais je n'ai aucun mal à m'en souvenir. Et bonne chance pour surfer sur les épaules ou le forcer.

— fin

1

@finnw Correct Agrafe de batterie de cheval :-) security.stackexchange.com/q/6095/485

— Rory Alsop

2

Bons points mentionnés ici déjà.

Ce que je considère comme le plus gros risque, étant donné que vous vous êtes occupé des bases avec un mot de passe fort, est que de nombreux ordinateurs ont des enregistreurs de frappe installés sans que l'utilisateur ne s'en rende compte. Il y a même des gens qui créent des sites entiers avec des utilitaires utiles contenant des chevaux de Troie, afin que cela puisse arriver aux meilleurs d'entre nous. Un enregistreur de frappe enverra par exemple les informations de connexion par courrier électronique à un pirate informatique qui pourrait alors accéder facilement au serveur.

Norton m'a récemment mis en garde de télécharger le programme d'installation de Zombee Mod (et non le fichier jar, l'installateur) pour avoir ajouté le vol au fichier jar Minecraft. J'ai examiné les détails et Norton a répertorié de nombreux utilitaires sur ce site, marqués comme contenant un cheval de Troie. Je ne sais pas si cela est correct ou non, mais c'était assez spécifique avec les noms de fichiers. C'est également un fait connu que les chevaux de Troie sont placés dans (certains) warez avant d'être distribués.

— Tedd Hansen
source

2

L'un des avantages potentiels de SSH par rapport aux mots de passe est que, si vous ne spécifiez pas de phrase de passe SSH, vous ne devez plus jamais taper de mot de passe ... votre ordinateur est intrinsèquement approuvé sur le serveur car il possède la clé. Cela dit, j’utilise généralement toujours un mot de passe composé SSH, de sorte que j’écarte cet avantage.

Je trouve que la meilleure réponse pour laquelle les guides de l'utilisateur recommandent souvent SSH au-dessus de l'authentification par mot de passe provient du manuel Ubuntu pour SSHOpenSSHKeys. Je cite,

Si vous ne le jugez pas important, essayez de consigner toutes les tentatives de connexion malveillantes de la semaine suivante. Mon ordinateur - un ordinateur de bureau parfaitement ordinaire - a eu plus de 4 000 tentatives de deviner mon mot de passe et près de 2 500 tentatives d'intrusion au cours de la seule semaine écoulée. Combien de milliers de suppositions aléatoires pensez-vous qu'il faudra avant qu'un attaquant découvre votre mot de passe?

Essentiellement, si vous avez un mot de passe très solide, avec des signes de ponctuation, des majuscules et des minuscules et des chiffres, l'authentification par mot de passe sera probablement satisfaisante. De même, si vous envisagez de surveiller vos journaux et que vous ne procédez de toute façon pas à des tâches "super sécurisées" sur le réseau, utilisez un serveur domestique. Alors, bien sûr, un mot de passe fonctionne bien.

— MikeMurko
source

1

La méthode d'authentification par mot de passe n'est vraiment pas sécurisée (à mon humble avis). Avec ce mécanisme, le mot de passe sera transmis au serveur sshd (comme @ramon l’a déjà dit). Cela signifie que certaines personnes pourraient modifier le serveur sshd pour récupérer le mot de passe. Avec une attaque Man-In-The-Middle, cela est très facile à réaliser au sein d'un réseau local.

Vous pouvez simplement corriger le serveur sshd en installant ce correctif ( https://github.com/jtesta/ssh-mitm ). Utilisez arpspoofet iptablespour placer votre serveur corrigé entre le client et le serveur sshd authentique.

Veuillez désactiver le mot de passe d'authentification: ouvrez le fichier de configuration /etc/ssh/ssh_configet ajoutez la ligne PasswordAuthentication no.

— Pioz
source

Le client SSH ne vérifie-t-il pas l'empreinte RSA du serveur? Après avoir au moins une fois envoyé ce serveur à un serveur particulier, les empreintes digitales sont mémorisées. Par conséquent, en cas d'attaques éventuelles par MITM, SSH afficherait un avertissement, n'est-ce pas?

— Septagramme

1

Ouais. L'avertissement apparaît, mais 99% du temps, cela est dû à la réinstallation du système d'exploitation, à la modification de la configuration, etc., la plupart des utilisateurs l'ignoreront et continueront.

— Pioz

@Seagramme De nombreux fournisseurs de comptes shell ne sont pas habitués à publier l'empreinte actuelle de la clé de serveur actuelle pour les nouveaux abonnés, pour la migration des comptes d'utilisateurs vers de nouveaux serveurs, etc.

— Damian Yerrick

-2

Vous pouvez contourner le avec l' -o StrictHostKeyChecking=nooption. Ceci est très utile lorsque vous utilisez ssh dans un script shell.

ssh -o StrictHostKeyChecking=no -o ConnectTimeout=10 -o PasswordAuthentication=no -o ConnectionAttempts=5 xxUser@xxxHost

— arganzheng
source