Comment puis-je exécuter ssh-add automatiquement, sans invite de mot de passe?

Ceci est un exemple typique de compromis entre sécurité et la commodité. Heureusement, il existe un certain nombre doptions. La solution la plus appropriée dépend du scénario dutilisation et du niveau de sécurité souhaité.

ssh-key avec mot de passe, pas de ssh-agent

Maintenant, la phrase de passe doit être saisie à chaque fois que la clé est utilisée pour lauthentification. Bien que ce soit la meilleure option du point de vue de la sécurité, elle offre la pire utilisabilité. Cela peut également conduire au choix dune phrase de passe faible afin de réduire le fardeau de la saisir à plusieurs reprises.

clé ssh avec phrase de passe, avec ssh-agent

Lajout de ce qui suit à ~/.bash_profile démarre automatiquement ssh-agent et chargez la (les) clé (s) ssh lors de la connexion:

if [ -z "$SSH_AUTH_SOCK" ] ; then eval `ssh-agent -s` ssh-add fi 

Maintenant, la phrase de passe doit être saisie à chaque connexion. Bien que légèrement meilleur du point de vue de la convivialité, cela présente linconvénient que ssh-agent demande la phrase secrète, que la clé soit utilisée ou non pendant la session de connexion. Chaque nouvelle connexion génère également une instance ssh-agent distincte qui reste en cours dexécution avec les clés ajoutées en mémoire même après la déconnexion, à moins quelle ne soit explicitement tuée.

Pour tuer ssh_agent à la déconnexion, ajoutez ce qui suit à ~/.bash_logout

if [ -n "$SSH_AUTH_SOCK" ] ; then eval `/usr/bin/ssh-agent -k` fi 

ou ce qui suit à ~/.bash_profile

trap "test -n "$SSH_AUTH_SOCK" && eval `/usr/bin/ssh-agent -k`" 0 

La création de plusieurs instances ssh-agent peut être évitée en création dune prise de communication persistante vers lagent à un emplacement fixe dans le système de fichiers, comme dans la réponse de Collin Anderson . Il sagit dune amélioration par rapport à la création de plusieurs agents Cependant, à moins dêtre explicitement tuée, la clé déchiffrée reste toujours en mémoire après la déconnexion.

Sur les bureaux, les agents ssh inclus avec lenvironnement de bureau, tels que Gnome Keyring SSH Agent , peut être une meilleure approche car ils peuvent généralement être amenés à demander le pass phrase la première fois que la clé ssh est utilisée pendant une session de connexion et stocke la clé privée déchiffrée en mémoire jusquà la fin de la session.

ssh- clé avec mot de passe, avec ssh-ident

ssh-ident est un utilitaire qui peut gérer ssh-agent en votre nom et charger les identités si nécessaire. Il ajoute des clés une seule fois selon les besoins, quel que soit le nombre de terminaux, ssh ou sessions de connexion qui nécessitent un accès à un ssh-agent. Il peut également ajouter et utiliser un agent différent et un ensemble de clés différent en fonction de lhôte auquel se connecter ou du répertoire à partir duquel ssh est appelé. Cela permet disoler les clés lors de lutilisation du transfert dagent avec différents hôtes. Il permet également dutiliser plusieurs comptes sur des sites comme GitHub.

Pour activer ssh-ident, installez-le et ajoutez lalias suivant à votre ~/bash_profile:

alias ssh="/path/to/ssh-ident" 

Clé ssh avec phrase de passe, avec keychain

keychain est un petit utilitaire qui gère ssh-agent en votre nom et permet au ssh-agent de continuer à fonctionner lorsque la session de connexion se termine. Lors des connexions suivantes, keychain se connectera à linstance ssh-agent existante. En pratique, cela signifie que la phrase de passe doit être saisie uniquement lors de la première connexion après un redémarrage. Lors des connexions suivantes, la clé non chiffrée de linstance ssh-agent existante est utilisée.Cela peut également être utile pour autoriser lauthentification RSA / DSA sans mot de passe dans les travaux cron sans clés ssh sans mot de passe.

Pour activer keychain, installez-le et ajoutez quelque chose comme ce qui suit à ~/.bash_profile:

eval `keychain --agents ssh --eval id_rsa` 

Dun point de sécurité de vue, ssh-ident et keychain sont pires que les ssh-agent instances limitées à la durée de vie dun particulier session, mais ils offrent un haut niveau de commodité. Pour améliorer la sécurité de keychain, certaines personnes ajoutent loption --clear à leur trousseau ~/.bash_profile invocation. En faisant cela, les mots de passe doivent être ressaisis lors de la connexion comme ci-dessus, mais les tâches cron auront toujours accès aux clés non chiffrées après la déconnexion de lutilisateur. La keychain page wiki contient plus dinformations et dexemples.

ssh-key sans mot de passe

Du point de vue de la sécurité, cest la pire option car la clé privée est entièrement non protégée au cas où elle est exposée. Cest, cependant, le seul moyen de sassurer que la phrase de passe na pas besoin dêtre ressaisie après un redémarrage.

ssh-key avec mot de passe, avec ssh-agent, en passant la phrase de passe à ssh-add from script

Bien que cela puisse semble être une idée simple de passer la phrase de passe à ssh-add à partir dun script, par exemple echo "passphrase\n" | ssh-add, ce nest pas aussi simple quil y paraît car ssh-add ne lit pas le phrase de passe de stdin, mais ouvre /dev/tty directement pour la lecture .

Cela peut être a travaillé avec expect , un outil dautomatisation interactive applications. Voici un exemple de script qui ajoute une clé ssh en utilisant une phrase de passe stockée dans le script:

#!/usr/bin/expect -f spawn ssh-add /home/user/.ssh/id_rsa expect "Enter passphrase for /home/user/.ssh/id_rsa:" send "passphrase\n"; expect "Identity added: /home/user/.ssh/id_rsa (/home/user/.ssh/id_rsa)" interact 

Notez que comme la phrase de passe est stockée en texte brut dans le script, du point de vue de la sécurité, ce nest guère mieux que davoir une clé ssh sans mot de passe. Si cette approche doit être utilisée, il est important de sassurer que le script expect contenant la phrase de passe dispose des autorisations appropriées, ce qui le rend lisible, inscriptible et exécutable uniquement par la clé propriétaire.

Commentaires

• Daccord, mais lorsque je mets votre code dans ~ / .bash_profile, je dois taper le mot de passe à chaque fois que je me connecte, je ne ‘ que vous ne le voulez pas non plus. Je ne suis pas du tout préoccupé par la sécurité. echo  » passe \ n  » | ssh-add ne ‘ t fonctionne
• @ user1607072 Ouais, cest ainsi que lextrait de code ssh-agent dans ~/.bash_profile se comporte comme expliqué dans la réponse. Vous voudrez peut-être consulter l’utilitaire keychain. Avec keychain, vous devez entrer le mot de passe lors de la première connexion après le redémarrage, mais lors des connexions suivantes, keychain se connectera à un ssh-agent avec la clé déchiffrée en mémoire. En dehors de cela, il existe ‘ la possibilité de générer une clé ssh sans phrase secrète, mais ce nest bien sûr pas recommandé.
• @ user1607072 suggèrent lune des approches les plus sûres, il existe un moyen de passer la phrase de passe à ssh-add à partir dun script. La raison pour laquelle echo "pass\n" | ssh-add ne fonctionne pas est que ssh-add ne lit pas le mot de passe de stdin, mais ouvre /dev/tty directement pour la lecture. Mise à jour de la réponse pour inclure une solution de contournement pour cela, en utilisant un utilitaire appelé expect.
• @ user1607072 Cela peut être un peu exagéré pour votre cas dutilisation, mais Kerberos en combinaison avec le support ssh GSSAPI peut également être utilisé pour les connexions ssh sans mot de passe. La méthode dauthentification correspondante dans ssh est appelée gssapi-with-mic. Ceci est généralement utilisé dans les grands réseaux, mais bien sûr, si cela vous intéresse, cela peut valoir la peine de lexaminer.
• @ErickBrown: Déjà répondu ici . Lunité de lagent SSH doit être arrêtée lors de la déconnexion si lutilisateur est désactivé dans le gestionnaire de connexion systemd . Si la fonction dattente de lutilisateur est activée, linstance utilisateur systemd et lunité de lagent SSH continuent de fonctionner même après la fermeture de la dernière session de connexion.

Ajoutez ceci à votre ~/.bashrc, puis déconnectez-vous et revenir pour prendre effet.

 if [ ! -S ~/.ssh/ssh_auth_sock ]; then eval `ssh-agent` ln -sf "$SSH_AUTH_SOCK" ~/.ssh/ssh_auth_sock fi export SSH_AUTH_SOCK=~/.ssh/ssh_auth_sock ssh-add -l > /dev/null || ssh-add  

Cela ne devrait demander quun mot de passe la première fois que vous vous connectez après chaque redémarrage. Il continuera à réutiliser le même ssh-agent tant quil reste en cours dexécution.

Commentaires

• très soigné , de cette façon, vous navez quun seul agent ssh en cours dexécution (: plusieurs agents comme dans la deuxième solution de @thomasNyman ‘ me semble un risque pour la sécurité …
• Après avoir fait des recherches sur divers sites et lu diverses solutions, celle-ci semble être la plus claire, allant droit au but. Très bien. +1
• mieux vaut faire ceci: `alias ssh = ssh-check-agent « , et demandez à la version check-agent de faire ce qui précède. de cette façon: a) vous nobtenez quun seul agent et b) vous nobtenez lagent que si vous en avez besoin
• Je pense que -s est la valeur par défaut, donc nous ‘ faisons déjà cela.
• Notez que ssh-add sans arguments ajoute ~/.ssh/id_rsa. Vous souhaiterez peut-être passer des arguments ssh-add si vos clés privées se trouvent dans un autre fichier.

Pas étroitement lié à la question de lOP, mais cela pourrait être utile à dautres: depuis 7.2.0 ssh (1) a une option qui permet dajouter une clé à ssh-agent lors de la première authentification; loption est AddKeysToAgent et peut être définie sur yes, no, ask, ou confirm, à léchelle du système ou sur votre fichier personnel .ssh/config.

Référence : https://www.openssh.com/txt/release-7.2

Commentaires

• Applicable aux nouveaux utilisateurs du fichier .ssh/config: cela sapplique à ssh et à tout ce qui utilise ssh derrière, par exemple scp, et peut être effectué par hôte.
• Il me demande toujours un mot de passe chaque fois que je me connecte et que jessaye de git pull par exemple.
• @trainosis Le problème est que vous navez probablement pas dinstance ssh-agent en cours dexécution pour conserver la ou les clés déchiffrées en mémoire pour une utilisation future. Vous ne devriez avoir à saisir le mot de passe pour une clé donnée quune seule fois par session de connexion lorsque vous utilisez ssh-agent.

ssh-agent met en cache diverses clés ssh déverrouillées, afin que vous puissiez avoir des clés ssh protégées par des mots de passe, mais sans avoir à les saisir à chaque fois.

Afin de mettre en cache les clés déverrouillées, il doit évidemment déverrouiller ces clés. Pour déverrouiller les clés qui sont verrouillées avec une phrase de passe, il doit évidemment connaître ces phrases de passe.

Toute méthode qui ne nécessite pas lautorisation dun être humain (par exemple « saisir un mot de passe ») ne fera pas que vous système non sécurisé; cela rendra également tout le but de lagent ssh inutile.

Après avoir dit tout cela, vous pouvez simplement utiliser des clés ssh qui ne sont pas protégées par mot de passe (appuyez sur Entrée lorsque vous y êtes invité pour un mot de passe lors de la génération de clé). Puisquil ny a pas de mot de passe, ssh-agent na pas besoin de vous en demander un pour (ne pas) le mettre en cache.

Commentaires

• Je suis daccord, tant que vos clés sont correctement autorisées par lutilisateur uniquement, il y a peu davantages à ssh-agent par rapport aux clés sans autorisation. jaime ssh dans un serveur de connexion, et ensuite, ce serveur a un tas de clés sans autorisation, chacune ne pouvant être utilisée que pour déverrouiller un autre serveur. le serveur de connexion ne fait rien dautre, donc il ‘ est beaucoup plus difficile à pirater / usurper, etc … les autres serveurs nont pas daccès par mot de passe, sont uniquement à clé.

Voici une solution de contournement pour automatiser votre phrase de passe SSH.

1. Créez un script à une ligne qui imprime votre phrase de passe sur la sortie standard, par exemple:

    echo "echo MY_SSH_PASSWORD" > ~/.print_ssh_password && chmod 700 ~/.print_ssh_password 

   Important: Assurez-vous vous copiez lespace de début dans empêchez le stockage de votre mot de passe dans votre historique .

Et utilisez lune des méthodes ci-dessous.

• en utilisant une approche dentrée standard:

  cat ~/.ssh/id_rsa | SSH_ASKPASS=~/.print_ssh_password ssh-add - 

• ou approche de canal nommé :

  1. Créez un tube nommé (vous pouvez également essayer une substitution de processus ):

     mkfifo --mode 0600 ~/.ssh_fifo 

  2. Exécuter ssh-add en précisant le programme utilisé pour lauthentification:

     cat ~/.ssh/id_rsa >~/.ssh_fifo | SSH_ASKPASS=~/.print_ssh_password ssh-add ~/.ssh_fifo 

  Voir: man ssh-add pour en savoir plus sur SSH_ASKPASS.

Commentaires

• Le echo my_passphrase est une grande faille de sécurité. Tout dabord, après lavoir tapé, le mot de passe est en texte clair dans le fichier historique de tout shell que vous utilisez. Et les arguments de deuxième ligne de commande sont lisibles partout dans le monde sous Unix (ps -ef). Ne mettez jamais de mots de passe dans les arguments de ligne de commande!
• @ceving Lajout despace de début supplémentaire résout le problème avec le fichier dhistorique. Ajout dinformations supplémentaires.
• @kenorb: Cela ne ‘ résout pas le plus gros problème du mot de passe visible dans ps production. Le fichier dhistorique nest généralement lisible que par lutilisateur propriétaire de toute façon, mais les lignes de commande sont lisibles par tous les utilisateurs dun système.

Je ne vous recommanderai pas ssh-add (qui doit ouvrir un agent ssh) lors de la connexion. Cest parce que vous ne pouvez pas contrôler la fin de la section ssh-agent et peut créer un risque de sécurité lorsque vous navez pas besoin dutiliser les fichiers de clés dans une section de connexion.

Je recommande plutôt décrire un script qui ouvre le sous-shell de la section dun agent ssh, avec tous les fichiers de clés automatiquement ajoutés, et dêtre appelé lorsque nécessaire pour utiliser ssh. Si vous pouviez ladopter, lisez la suite.

Vous auriez deux choix:

1. Supprimer toutes les phrases de passe pour vos clés, qui ont sécurité faible si vos fichiers clés sont volés. (donc déconseillé )

2. Utilisez la même phrase de passe pour vos clés. Ensuite, lorsque vous ssh-add keyfile1 keyfile2 ..., vous naurez besoin de saisir la phrase de passe quune seule fois, par section.

Dans les deux cas, vous pouvez écrire un tel fichier de script « ssh_keys_section.sh » comme ci-dessous:

#!/bin/bash # This script run a ssh-agent on a sub-shell and automatically ssh-add all keyfiles at once. # This agent ends when you type `exit` to close the sub-shell. exec ssh-agent bash -c "ssh-add /path/to/keyfile1 /path/to/keyfile2 ...; exec bash" 

Remarques:

• Commande pour changer ou supprimer la phrase de passe: ssh-keygen -p -f keyfile
• Dans le sous-shell, vous pourriez même créer plus de terminaux partageant le même clés déverrouillées, en utilisant peut-être une commande comme /path/to/yourterminal & (dépend du système dexploitation)

Commentaires

• Par exemple Sous Windows dans Cygwin, /path/to/yourterminal & == > mintty &
• Remarque: après utilisation, fermez la session avec ctrl-d ou exit, comme vous avez invoqué un bash et vous devez le fermer.

if [ ! -S ${HOME}/.ssh/ssh_auth_sock ]; then eval $(ssh-agent) ln -sf "${SSH_AUTH_SOCK}" ${HOME}/.ssh/ssh_auth_sock fi export SSH_AUTH_SOCK=${HOME}/.ssh/ssh_auth_sock ssh_keys=$(find -E ~/.ssh -type f -regex ".*(rsa$|pem)") ssh_agent_keys=$(ssh-add -l | awk "{key=NF-1; print $key}") for k in "${ssh_keys}"; do for l in "${ssh_agent_keys}"; do if [[ ! "${k}" = "${l}" ]]; then ssh-add "${k}" > /dev/null 2>&1 fi done done 

Javais lhabitude dutiliser le script mentionné par steampowered, jai fait celui ci-dessous maintenant, car il ne laisse pas de fichiers traîner.

Travailler sur zsh shell uniquement.

#!/usr/bin/env zsh AGENT_BIN=`which ssh-agent` AGENT_ADD_BIN=`which ssh-add` AGENT_PID=`ps -fe | grep ${AGENT_BIN} | awk -vuser=$USER -vcmd="$AGENT_BIN" "$1==user && $8==cmd{print $2;exit;}"` if [ -z "$AGENT_BIN" ]; then echo "no ssh agent found!"; return fi if [ "" -eq "$AGENT_PID" ]; then if read -sq "YN?Do you want to unlock your ssh keys?"; then echo "" output=`$AGENT_BIN | sed "s/echo/#echo/g"` eval $output $AGENT_ADD_BIN fi else for f in "/proc/"* do cmdline=`cat "$f/cmdline"` if [ "${AGENT_BIN}" -ef "${cmdline}" ]; then export SSH_AUTH_SOCK=`cat $f/net/unix | grep --binary-file=text -oP "((/[^/]*?)+/ssh-[^/]+/agent\.\d+$)"` export SSH_AGENT_PID=${f##*/} break; fi done fi 

Commentaires

•  » Travail sur zsh shell uniquement « , daccord mais pourquoi votre ligne shebang indique-t-elle de ne nécessiter que  » sh « ?

SSH_ENV="$HOME/.ssh/environment" function start_agent { echo "Initialising new SSH agent..." /usr/bin/ssh-agent | sed "s/^echo/#echo/" > "${SSH_ENV}" echo succeeded chmod 600 "${SSH_ENV}" . "${SSH_ENV}" > /dev/null /usr/bin/ssh-add; } # Source SSH settings, if applicable if [ -f "${SSH_ENV}" ]; then . "${SSH_ENV}" > /dev/null #ps ${SSH_AGENT_PID} doesn"t work under cywgin ps -ef | grep ${SSH_AGENT_PID} | grep ssh-agent$ > /dev/null || { start_agent; } else start_agent; fi 

Donner du crédit ici: https://www.cygwin.com/ml/cygwin/2001-06/msg00537.html

Cette solution est également approuvée ici: http://mah.everybody.org/docs/ssh

Si vous utilisez Seahorse comme gestionnaire de mots de passe … Ce que vous êtes probablement; D

Une autre solution qui atteint lobjectif que vous recherchez consiste simplement à ajouter les clés ssh à seahorse pour un déverrouillage automatique lors de la connexion . Le principal avantage est que vous navez jamais à entrer un mot de passe pour les clés après vous être connecté via gdm, ou quel que soit votre connexion, même si les clés ont un mot de passe. Cela nécessite à la fois la clé privée et la clé publique. Ils DOIVENT également suivre une convention de dénomination pour lhippocampe. La valeur par défaut est acceptable (id_rsa pour la clé privée et id_rsa.pub pour la clé publique … Vraiment tout ce qui est privatekeyname et privatekeyname.pub )

Pour ajouter votre clé ssh à lhippocampe pour un déverrouillage automatique lors de la connexion; (sur fedora25, je ne sais pas trop où se trouve le chemin sur dautres distributions, bien que ce soit très probablement très similaire)

/lib64/seahorse/seahorse-ssh-askpass /path/to/keys/here 

Pour moi, cétait

/lib64/seahorse/seahorse-ssh-askpass ~/.ssh/id_rsa 

(seahorse supposera automatiquement que la clé publique dans mon cas était id_rsa.pub)

Après avoir exécuté la commande, seahorse ouvrira un adorable petit champ de mot de passe gtk dans lequel entrer le mot de passe de la clé privée. ou laissez-le vide si vous avez généré la clé sans mot de passe.

Seahorse ne vous demandera pas si tout sest bien passé. Vous devrez essayer de ssh dans la machine cible.Ensuite, lhippocampe vous demandera de déverrouiller la clé avec un mot de passe graphiquement (CELA SEULEMENT UNE FOIS), mais cela devrait être un peu différent cette fois; P (cest aussi la partie où lhippocampe fait un hippocampe pour ssh-ajouter de la magie, je crois ), et offrez l OPTION pour déverrouiller la clé lors de la connexion, vous devez cocher cette option pour atteindre votre objectif.

Simplement parce que je nai pas lu toutes les réponses, je vous recommande dannuler ce que tout le monde vous a dit de faire avec ssh-add avant dessayer cette réponse. Sinon, cela pourrait entraîner un problème à vos clés, idk.

La solution dauthentification unique pour SSH pourrait me conduire à pam_ssh .

Daprès cet article , le concept est:

Si vous travaillez avec plusieurs machines basées sur * nix via ssh, vous êtes probablement fatigué des inconvénients avoir à saisir votre mot de passe à chaque fois que vous souhaitez accéder à une autre boîte. Il existe un moyen sécurisé pour vous permettre daccéder à toutes les machines auxquelles vous avez accès ssh, sans avoir à entrer un autre mot de passe (autre que celui avec lequel vous vous êtes connecté à lorigine.)

Cest en fait assez simple à faire, vous créez simplement une paire de clés publique / privée pour vous authentifier auprès de vos autres machines, puis PAM génère un agent pour charger vos clés après votre connexion, fournissant une solution de connexion unique pour accéder à toutes vos machines distantes. Ce guide vous guidera tout au long de la configuration.

Je nai pas vérifié que cela fonctionnerait réellement.

Ajoutez ceci à votre ~/.bashrc fichier:

ssh-add -L|grep identities > /dev/null && ssh-add /path/to/ssh/private/key 

Commentaires

• Je ne ‘ pas voir comment cela se rapporte à la question, qui est de ne pas être invité à entrer le mot de passe lors des connexions suivantes.

Afin dajouter une clé (éventuellement sans mot de passe) et assurez-vous que ssh-add ne demandera pas de mot de passe, quoi quil arrive, même sous X :

DISPLAY= ssh-add -k /path/to/key </dev/null &>/dev/null 

Le statut de sortie indique un succès ou un échec.

Voici le définitif scénario.

Mettez à jour $ PASSW, puis copiez-collez-le dans votre terminal

# <sshpass> via typinator # Updated: 2017-01-18_21h36 # # apt-get update -y; apt-get install expect -qy # Pass this value to ssh-add PASSW="myfancypass123" # Define a name for this script THIS_SCRIPT="$(date +%Y-%m-%d_%H-%M-%S-%N)".sh # Create a fresh directory to work from / Clean up rm -rf ~/temp; mkdir -p ~/temp; cd ~/temp; ls -la # Output our bash script file - BEGIN cat <<< " #!/bin/bash set -u # Stop if an unbound variable is referenced set -e # Stop on first error export HISTIGNORE="expect*"; # Normal CMDs echo && echo "The process should take about 10 seconds:" && echo eval "$(ssh-agent -s)"; sleep 0.5; # Define VAR passed when this bash-script was launched password="$@" # Launch the expect magic expect -c " spawn ssh-add /root/.ssh/id_rsa expect "?assword:" send \"$password\r\" expect "?password:" send \"$password\r\" expect eof" export HISTIGNORE=""; export password=""; " > $THIS_SCRIPT # Output our bash script file - END # Ensure we are in the right path cd ~/temp; ls -la; sleep 1; # Run the bash script chmod +x ./$THIS_SCRIPT; ./$THIS_SCRIPT "$PASSW"; unset password; # Clean up rm -rf ~/temp; mkdir -p ~/temp; cd ~/temp; ls -la 

La meilleure façon dont je connaisse est dutiliser un script de connexion PAM que jai adapté dun travail précédent car je nai pas pu trouver de réponse satisfaisante à cette question.

Votre phrase de passe est stocké chiffré avec votre mot de passe système et une fonction de dérivation lourde. Lors de la connexion, votre mot de passe système est utilisé pour déchiffrer votre phrase secrète et lajouter à lagent.

https://github.com/capocasa/systemd-user-pam-ssh

Lavantage par rapport à toutes les autres solutions présentées est quelle combine une sécurité équivalente à lexécution manuelle de ssh-add au démarrage sans effort. Cela nécessite aucun outil supplémentaire et a une dépendance supplémentaire qui « est déjà installée par défaut sur la plupart des systèmes (OpenSSL).

Mon la configuration sur macOS est la suivante (dans .zshrc, ou .bash_profile pour les gens bash):

La partie || [[ $SSH_AUTH_SOCK == *"/private/tmp/"* ]] est nécessaire sous macOS car la valeur par défaut est /private/tmp/com.apple.launchd.SOMETHINGHERE/Listeners. Sinon, la réponse complète de @Thomas Nyman échoue car $SSH_AUTH_SOCK est toujours défini sur quelque chose.

Puis dans .zlogout (ou .bash_logout pour les gens bash):

if [ -n "$SSH_AUTH_SOCK" ] ; then eval `/usr/bin/ssh-agent -k` fi 

Testé sur macOS Mojave 10.14.5

Cela a été très bien expliqué par GitHub sur Lancement automatique de ssh-agent sur Git pour Windows , qui à son tour fonctionne aussi pour Linux.

Vous pouvez exécuter ssh-agent automatiquement lorsque vous ouvrez bash ou Git shell. Copiez les lignes suivantes et collez-les dans votre fichier ~/.profile ou ~/.bashrc dans le shell Git:

 env=~/.ssh/agent.env agent_load_env () { test -f "$env" && . "$env" >| /dev/null ; } agent_start () { (umask 077; ssh-agent >| "$env") . "$env" >| /dev/null ; } agent_load_env # agent_run_state: 0=agent running w/ key; 1=agent w/o key; 2= agent not running agent_run_state=$(ssh-add -l >| /dev/null 2>&1; echo $?) if [ ! "$SSH_AUTH_SOCK" ] || [ $agent_run_state = 2 ]; then agent_start ssh-add elif [ "$SSH_AUTH_SOCK" ] && [ $agent_run_state = 1 ]; then ssh-add fi unset env  

Si votre clé privée nest pas stockée dans lun des emplacements par défaut (comme ~/.ssh/id_rsa), vous « devrez indiquer à votre agent dauthentification SSH où le trouver. Pour ajouter votre clé à ssh-agent, tapez ssh-add ~/path/to/my_key.

Conseil: Si vous voulez que ssh-agent oublie votre clé après un certain temps, vous pouvez configurez-le pour le faire en exécutant ssh-add -t <seconds>.