Cache le mot de passe si les clés SSH sont interdites

46

J'ai un serveur auquel je dois accéder fréquemment via ssh, car je calcule dessus. Maintenant, le centre de calcul interdit explicitement les clés SSH car elles sont "peu sûres". Ils estiment que taper mon mot de passe, sur un clavier, à chaque fois, possible devant d'autres humains, est un moyen beaucoup plus sûr de se connecter.

À présent; Je ne peux pas changer d'avis (j'ai essayé).

Existe-t-il un moyen de stocker temporairement au moins temporairement les mots de passe SSH, de la même manière que GIT peut stocker les mots de passe dans un cache pendant une durée définie?

utilisateur2667180
la source
55
the computing center explicitly forbids SSH-keys because they are "insecure"- mon avis sur le sujet? Trouvez un nouvel hôte serveur, car le vôtre est évidemment inepte.
Matt Clark
18
@Matt: "centre informatique" sonne plus comme un système de grille académique, qui n'a pas autant de concurrence, je suppose
grawity
27
Ils ont tort. Ils ont probablement oublié de désactiver les clés ssh lorsqu’ils expirent des comptes, ils ont donc décidé que ce sont les clés ssh qui posent problème.
Josué
10
Grawity a raison. c'est un superordinateur national alors je suis coincé avec. pour ce que ça vaut, la machine est sympa. Joshua a probablement raison aussi, mais bon, c'est le genre de droit qui ne convient à rien
user2667180
7
@TheHansinator Si un enregistreur de frappe est installé, vous avez déjà été compromis au point que le fait de protéger vos connexions SSH n'a plus d'importance. Mais l' publickeyauthentification présente d'autres avantages . Si vous désactivez l' passwordauthentification sur le serveur, vous empêchez tous ces attaquants d'essayer de deviner les mots de passe. Et si un attaquant tente une attaque mitm contre un client qui n'a pas encore stocké la clé publique du serveur, vous êtes beaucoup mieux protégé publickeyque si vous utilisiez l' passwordauthentification.
Kasperd

Réponses:

63

Réutilisation de la connexion

SSHv2 permet à la même connexion authentifiée d'établir plusieurs «canaux» - shell interactif, commande par lots, SFTP, ainsi que les autres, tels que le transfert d'agent ou le transfert TCP. Votre serveur prend probablement en charge le multiplexage de connexion par défaut. (Si vos administrateurs se plaignent, ce n'est pas la mise en cache de votre mot de passe, mais la connexion au complet.)

Avec OpenSSH vous ControlMasteret les ControlPathoptions (-M et S) d'utiliser ceci:

  1. Établissez une connexion «maître» SSH avec -M. (Comme vous n'avez pas encore de chemin de contrôle dans votre configuration, vous devez le spécifier en ligne de commande -S. Il doit durer longtemps, donc j'ajoute les -fNoptions pour passer en arrière-plan; elles sont techniquement optionnelles sinon.)

    $ ssh [email protected] -fNMS ~/.ssh/bar.socket
    [email protected]'s password:
    

    Vous êtes de retour à la coquille locale.

  2. Commencez une nouvelle connexion via le maître:

    $ ssh [email protected] -S ~/.ssh/bar.socket
    

    Vous êtes dans.

  3. Pour rendre cela utile pour Git / rsync / SFTP, vous devez le configurer ControlPathdans votre configuration, car vous ne pourrez pas spécifier -Stout le temps:

    Host *
        ControlPath ~/.ssh/S.%r@%h:%p
    

Vous pouvez automatiser ceci - les versions récentes d'OpenSSH ont également ControlPersistétabli une connexion principale en arrière-plan s'il n'y en a pas encore. Cela vous permet de sauter l'étape 1 et d'utiliser simplement ssh comme vous le feriez normalement.

  1. Configuration en ~/.ssh/config:

    Host *
        ControlPath ~/.ssh/S.%r@%h:%p
        ControlMaster auto
        ControlPersist 15m
    
  2. La première connexion demande le mot de passe:

    $ ssh [email protected]
    [email protected]'s password:
    [foo@bar:~]$ exit
    
  3. La seconde ne:

    $ ssh [email protected]
    [foo@bar:~]$ yay
    

Pour contrôler le maître multiplexé (l’arrêter ou configurer les transferts TCP), utilisez l’ -Ooption.

Une méthode similaire est supportée par les versions récentes de PuTTY .

Grawity
la source
1
merci beaucoup pour cette belle réponse. google n'était pas utile sur ce problème, car il se tournait toujours vers ssh-keys et je ne connaissais pas les bons mots clés. m'a beaucoup aidé!
user2667180
1
Cela devrait aller de soi, mais si vous utilisez cette configuration, il est impératif de vous assurer que votre compte est sécurisé et que votre dossier .ssh est correctement verrouillé, car toute personne ayant accès aux fichiers de canal sur cette machine peut se greffer sur votre ordinateur. connexion, et accéder au serveur comme vous.
shellster
3
@shellster: Vous voulez dire "n'importe qui avec le même UID", comme c'est déjà le cas avec ssh-agent. Même si vous ouvrez délibérément les autorisations du fichier de socket (0600 par défaut), les autres utilisateurs en obtiendront simplement une "disparité multiplex uid".
Grawity
3
@shellster Quelqu'un avec root pourrait installer un enregistreur de frappe et voler votre mot de passe sur le système distant de toute façon, ou faire un certain nombre de choses néfastes. Si nous nous inquiétons de la racine locale, cela n’est pas moins sûr que d’enregistrer une clé privée SSH.
Amalloy
1
Je ne considère pas la racine locale comme une menace, car si cela devenait une menace, vous étiez porté à vous, quoi qu'il arrive. (Comme avec l'espionnage de niveau gouvernemental.) Franchement, une racine locale pourrait simplement remplacer votre client ssh et votre agent ssh par tout ce qu'ils veulent. Stocker tous les mots de passe et clés privées dans /root/.secret? Sûr.
grawity
19

Utilisation sshpass

sshpass ( github , page de manuel ) est un outil qui fournit automatiquement le mot de passe à ssh. La manière sécurisée de l'utiliser est la suivante:

% echo 'correct horse battery staple' > ~/.ssh/compute_password
% chmod go-rw ~/.ssh/compute_password

% sshpass -f ~/.ssh/compute_password ssh foo@host

Cela lira le mot de passe ~/.ssh/compute_password, un peu comme un fichier de clé privée sans phrase secrète. Vous pouvez placer la sshpasscommande dans un petit script shell ou dans un alias de shell pour éviter de saisir cette commande complète. Malheureusement, je n'ai pas trouvé le moyen de le faire ~/.ssh/config.

(Il est également possible de spécifier le mot de passe directement sur la ligne de commande sshpass, mais cela devrait être évité, car le mot de passe sera divulgué à quiconque le pourra. ps)

Comparaison avec d'autres méthodes

Cette approche est bien sûr moins sécurisée que l’authentification par clé publique correctement configurée, mais vous le savez probablement déjà.

Il est également moins sécurisé que la réponse de @ grawity sur la réutilisation de la connexion, mais présente l’avantage de ne pas avoir à entrer le mot de passe de manière interactive.

Vous pouvez considérer la réponse de @ grawity comme une alternative à l'authentification pubkey avec une phrase secrète et la mise en cache de clés privées (c'est-à-dire ssh-agent). Alors ma réponse serait une alternative à l'authentification de pubkey sans phrase secrète sur le fichier de clé privée.

marcelm
la source
3
Si la politique du centre informatique a été écrite sur la base "mais que les paires de clés sont stockées sur un disque où quelqu'un pourrait les voler!", Il semble alors que cette politique va plutôt se retourner contre nous.
grawity
6
@grawity Eh bien, les mauvaises politiques conduisent à des solutions encore pires ¯ \ _ () _ / ¯
marcelm
1
Si vous générez votre mot de passe sous forme d'un flux suffisamment long de caractères aléatoires (par exemple head -c 16 /dev/urandom | base64pour 128 bits) et ne l'utilisez pas sur d'autres systèmes, la sécurité est similaire à une clé. Aussi difficile à forcer que brutal, et aussi simple à utiliser à partir du fichier si ce n’est chiffré. Cela vaut aussi pour le méchant, s’ils récupèrent le fichier. La seule différence est que le mot de passe est envoyé tel quel au serveur, alors que les clés ont de meilleurs calculs pour prouver que vous possédez la clé privée correcte sans la révéler. En termes de facilité d'utilisation, il est plus difficile de chiffrer le fichier contenant le mot de passe outils standard).
ilkkachu
1

Utilisez le gestionnaire de mot de passe.

Certains gestionnaires de mots de passe (ex. KeePassXC) disposent de la fonctionnalité de "saisie automatique". Vous stockez le mot de passe sur le gestionnaire de mots de passe, déverrouillez la base de données lorsque vous exécutez le gestionnaire et sshvous invite à entrer votre mot de passe chaque fois que vous appuyez sur une combinaison de touches permettant au gestionnaire de mots de passe d'écrire votre mot de passe long sur la console.

Pas besoin de copier, rappelez-vous de tout (sauf le mot de passe pour déverrouiller la base de données) et vous pouvez avoir un mot de passe fort sans écraser ces 30 caractères à chaque fois que vous essayez de vous connecter.

Vous pouvez choisir votre favori dans cette liste: https://en.wikipedia.org/wiki/List_of_password_managers

mouche en polystyrène
la source
3
Je ne suis pas sûr que la fonctionnalité de type automatique fonctionne bien avec les programmes basés sur des terminaux. La détection cherchera un titre de fenêtre spécifique, et l'autotypage lui-même n'aurait pas les fonctionnalités "anti-keylogging" sophistiquées que KeePass2 avait ...
grawity
1
@grawity gnome-terminalchange son titre en ssh somehostquand ssh me demande un mot de passe afin que vous puissiez faire correspondre la fenêtre du titre avec cela sans aucun problème. Je ne connais rien aux fonctionnalités «anti-saisie au clavier» - j'utilise quotidiennement KeePassXC dans un terminal et le pire que je dois faire face est de choisir le compte approprié dans la liste.
styromousse voler
2
@grawity Les fonctionnalités anti-keylogging doivent quand même être activées entrée par entrée (précisément parce que de nombreux programmes ne prennent pas en charge le collage).
Bob
0

Une autre alternative consiste à utiliser un client ssh à interface graphique. Sous Windows, le choix évident serait PuTTY . Il existe également une version Linux de PuTTY, notamment la plupart des distributions basées sur Debian comme Ubuntu incluent normalement PuTTY dans leur dépôt.

Un autre très bon client est Termius . Il prend en charge non seulement Windows et Linux, mais également OSX, iOS et Android. Bien que conçue principalement pour les téléphones, la version de bureau est en fait assez bonne.

Si je ne me trompe pas, le vénérable Hyperterminal de Windows a également un client ssh intégré, mais je n’ai pas utilisé Windows depuis très longtemps et je n’en suis donc pas tout à fait certain.

Tous les clients de l'interface graphique incluent la possibilité d'enregistrer les paramètres de connexion, y compris votre nom d'utilisateur et votre mot de passe.

bûcheron
la source
2
"Basé sur une interface graphique" n'implique pas automatiquement qu'il permettra de stocker votre mot de passe, ce que PuTTY refuse explicitement de faire . La version de HyperTerminal fournie avec Windows était uniquement basée sur Telnet et davantage axée sur les liaisons série. Vous pensez peut-être à CKermit pour Windows qui prend en charge SSH, mais son support de chiffrement est tellement obsolète qu'il ne se connecte pas facilement à de nombreux serveurs actuels.
Grawity