Votre mot de passe SSH est-il révélé lorsque vous essayez de vous connecter au mauvais serveur?

192

Lorsque vous tentez accidentellement de vous connecter au mauvais serveur avec des informations d'identification de mot de passe, l'administrateur peut-il lire et enregistrer le mot de passe que vous avez utilisé?

ssh password

— vfclistes
source

11

L'authentification par mot de passe SSH fournit-elle le mot de passe au serveur?

— jamesdlin

41

Dans un client ssh, vous authentifiez d'abord le serveur et vous dites: "Je suis sûr que je peux dire mon mot de passe à ce serveur". La prochaine fois, portez une attention particulière au message que vous avez vu en premier: "L’authenticité de X ne peut pas être établie. L’empreinte digitale de la clé RSA est Y Êtes-vous sûr de Z? (Oui / non)" Cette question ne vous serait pas posée si vous supposiez pour répondre automatiquement oui à chaque fois.

— Kubanczyk

6

Il est possible de définir PasswordAuthentication nopar défaut dans OpenSSH, et de ne l'activer que (si / si nécessaire) pour les serveurs sécurisés. Combiné à une vérification stricte de la clé de l'hôte, cela devrait surtout vous protéger de la divulgation de votre mot de passe, à un coût raisonnable, bien entendu.

— Hobbs

6

@kubanczyk, si vous voulez utiliser SSH pour "internal-www.my-company.com" mais que vous avez tapé accidentellement "ssh www.my-company.com", cette invite ne vous protégera pas - il est probable que les deux serveurs soient sur votre liste de confiance, c’est que l’un d’eux est dirigé par vous et l’autre par un tiers.

— Mark

@ Hobbs ChallengeResponseAuthentication noaussi, je pense

— ilkkachu le

215

Mise simple: oui

Plus de détails...

Si vous vous connectez à ma machine, vous ne savez pas si j'utilise un sshserveur normal ou un serveur modifié pour écrire le mot de passe en cours de transmission.

De plus, je n'aurais pas nécessairement besoin de modifier sshd, mais je pourrais écrire un module PAM (par exemple, utiliser pam_script), auquel sera transmis votre mot de passe.

Donc oui. N'envoyez JAMAIS votre mot de passe à un serveur non fiable. Le propriétaire de la machine aurait facilement pu la configurer pour enregistrer tous les mots de passe essayés.

(En fait, cela n’est pas rare dans le monde d’infosec; configurez un serveur propriétaire pour enregistrer les mots de passe essayés)

— Stephen Harris
source

13

Correct. Par défaut, la norme sshdne consigne pas les mots de passe. (Si vous entrez votre mot de passe comme identifiant, il sera enregistré, mais c'est un autre problème). La norme sshdest un outil de sécurité, et ne consignera donc pas d'informations d'identification de ce genre :-)

— Stephen Harris

116

Encore une autre raison d'utiliser des paires de clés publique / privée ...

— gerrit

3

Je me posais des questions sur mon utilisation des mots de passe depuis un moment et je me suis récemment rendu compte que tenter de me connecter à de mauvais serveurs serait un bon moyen de révéler mon mot de passe à un administrateur de serveur malveillant.

— Vfclists

10

@vfclists vous connecter sur le mauvais serveur est également la raison exacte pour laquelle votre client sshd stocke l'empreinte digitale de chaque serveur. Lorsque vous vous connectez pour la première fois, vous acceptez cette empreinte. Plus tard, si elle ne correspond pas, vous recevez un avertissement géant auquel vous devez faire attention.

— hometoast

44

Meilleur conseil: n'utilisez jamais d'authentification par mot de passe pour ssh. Le protocole a une autorisation pubkey pour de très bonnes raisons; utilise le!

— R ..

52

Oui.

Le mot de passe est envoyé une fois la connexion cryptée établie, mais le serveur distant obtient le mot de passe en texte brut.

Si vous y tenez, la solution la plus simple et la plus simple consiste à utiliser des clés SSH.

Si vous avez des machines qui ne peuvent pas accepter les clés, une solution consiste à créer un outil qui stocke vos mots de passe en toute sécurité, puis sshpassà toujours envoyer le mot de passe correct en fonction du serveur auquel vous vous connectez.

Maintenant, la raison pour laquelle le mot de passe est envoyé en texte clair est qu’il laisse toutes les décisions de le manipuler et de le stocker à l’extérieur, et le client peut être totalement stupide. Il existe plusieurs formats de hachage de mots de passe (stockage) utilisés par les systèmes Linux et BSD au cours des dix dernières années environ ( crypt (3) ), dont aucun n’a besoin de l’assistance du client.

Bien que cela soit en partie dû à l'histoire aussi (c'est à dire que ça a toujours été comme ça). Il existe de meilleurs protocoles d'authentification challenge-response qui pourraient être utilisés même avec des mots de passe. Par exemple, SRP , qui fournit aux parties un secret partagé lors de l'authentification. Il a été implémenté pour certains serveurs SSH, mais le correctif pour OpenSSH concerne une version (très) ancienne.

— ilkkachu
source

1

Le problème avec les protocoles de challenge-response pour l'authentification par mot de passe est que certains d'entre eux nécessitent que le serveur stocke le mot de passe en texte brut. Si le protocole challenge-response permet au serveur de stocker un mot de passe haché, il nécessite probablement un algorithme de hachage très spécifique.

— kasperd

8

Les mots de passe sont généralement envoyés en "texte clair" (c'est-à-dire pas en clair, mais uniquement avec la protection fournie par le SSH | TLS | sous-jacent, quelle que soit la connexion fournie). Si un système demandait que les mots de passe soient hachés côté client et que le hachage soit envoyé, les serveurs n'auraient aucun moyen de dériver le mot de passe réel et donneraient plutôt l'accès à toute personne pouvant fournir le hachage du mot de passe , le rendant ainsi équivalent à un mot de passe. .

— Blacklight Shining

1

@BlacklightShining Les preuves de mot de passe à zéro connaissance existent, mais ne sont pas utilisées dans SSH car il n'y a aucun moyen d'utiliser la base de données de mots de passe standard pour elles et aucun intérêt réel à les utiliser plutôt qu'une authentification basée sur une clé.

— Random832

Où puis-je voir les mots de passe utilisés pour s'authentifier? Ils ne sont pas dans /var/log/auth.log, où donc?

— アレックス

OpenSSH n'enregistrera pas les mots de passe, en échec ou autrement. (Je ne connais pas très bien les autres serveurs SSH.) Dans presque toutes les installations légitimes, le risque inhérent à l’enregistrement intentionnel de mots de passe, dont certaines auraient pu être fournies par des utilisateurs légitimes ou essayé un mot de passe faux, mais correct, pour quelque chose, en clair. Si vous avez une bonne raison de le faire, il serait facile de patcher OpenSSH.

— musicinmybrain

10

Pour compléter la réponse de Stephen Harris, voici une vue en temps réel que j’ai construite et qui montre ce qu’un script d’authentification PAM modifié serait capable de capturer lors de la connexion à une boîte sur ssh (une sorte de pot de miel). J'utilise une version modifiée de la bibliothèque PAM lib-storepw.

https://livesshattack.net

https://livesshattack.net/about

— Willie S.
source

4

Les réponses qui sont principalement des liens sont mal vues si le lien devient indisponible (on dirait que vous maintenez ce site personnellement, mais quand même). Vous devriez décrire un peu comment vous avez géré cela avec votre script d'authentification pour lecteurs.

— Centimane

son ne fonctionne plus, j'ai envoyé une énorme chaîne comme mot de passe, je pense que cela aurait pu le casser, désolé: - /

— scottydelta

@scottydelta Bien que je ne me sois pas penché sur la question, il peut exister une limite de mémoire tampon pour la taille du mot de passe que le module PAM ou le démon SSH peut accepter lors d'une tentative d'authentification. Le site fonctionne toujours comme je le souhaitais, même s’il gérera jusqu’à la limite de mémoire tampon acceptée par sshd ou le module PAM si tel est bien le cas.

— Willie S.

Par intérêt, la source de votre lib-storepw modifiée est-elle accessible aux autres utilisateurs?

— Tim Fletcher

2

SSH est un protocole qui nécessite une confiance mutuelle. C’est la raison pour laquelle le client OpenSSH maintient un fichier known_hosts afin de mettre en œuvre son schéma de confiance lors de la première utilisation.

Lorsque vous essayez de vous connecter à un serveur SSH, quel que soit le fournisseur du logiciel ou les données que ce dernier est configuré pour consigner, vous participez à une procédure d'authentification. Lorsque vous utilisez l'authentification par mot de passe, vous transmettez votre mot de passe à ce serveur. C'est l'une des raisons pour lesquelles la cryptographie asymétrique (clé publique, certificats) est recommandée. La cryptographie à clé publique réduit considérablement le risque de divulgation de vos informations d'identification. (Bien que cela ne vous protège peut-être pas contre une attaque MitM si vous utilisez le transfert ssh-agent ou un système similaire.)

— jvoorhis
source

SSH ne nécessite pas de confiance mutuelle, ou du moins pas de confiance symétrique. Il est important d'être précis: known_hosts concerne l'authenticité, pas la confiance. Comme vous le signalez, il est prudent de placer une clé publique sur un hôte moins fiable. En effet, utiliser un mot de passe pour se connecter est également "sûr", à condition que vous ne réutilisiez pas ce mot de passe. (C'est aussi sûr que le degré de confiance envers le serveur, bien sûr.) Même les connexions SSH basées sur l'hôte dépendent d'une confiance asymétrique.

— Markhahn