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?

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 foo@bar.example.com -fNMS ~/.ssh/bar.socket
   foo@bar.example.com's password:
   

   Vous êtes de retour à la coquille locale.

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

   $ ssh foo@bar.example.com -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 foo@bar.example.com
   foo@bar.example.com's password:
   [foo@bar:~]$ exit
   

3. La seconde ne:

   $ ssh foo@bar.example.com
   [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 .

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.

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

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.