Come posso eseguire ssh-add automaticamente, senza una richiesta di password?

Questo è un tipico esempio di compromesso tra sicurezza e comodità. Fortunatamente ci sono diverse opzioni. La soluzione più appropriata dipende dallo scenario di utilizzo e dal livello di sicurezza desiderato.

chiave ssh con passphrase, no ssh-agent

Ora la passphrase deve essere inserita ogni volta che la chiave viene utilizzata per lautenticazione. Sebbene questa sia lopzione migliore dal punto di vista della sicurezza, offre la peggiore usabilità. Ciò può anche comportare la scelta di una passphrase debole per ridurre il carico di inserirla ripetutamente.

chiave ssh con passphrase, con ssh-agent

Laggiunta di quanto segue a ~/.bash_profile inizierà automaticamente ssh-agent e carica le chiavi SSH allaccesso:

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

Ora la passphrase deve essere inserita ogni Accedere. Anche se leggermente migliore dal punto di vista dellusabilità, ha lo svantaggio che ssh-agent richiede la passphrase indipendentemente dal fatto che la chiave debba essere utilizzata o meno durante la sessione di accesso. Ogni nuovo accesso genera anche unistanza ssh-agent distinta che rimane in esecuzione con le chiavi aggiunte in memoria anche dopo il logout, a meno che non venga uccisa esplicitamente.

Per uccidere ssh_agent alla disconnessione, aggiungi quanto segue a ~/.bash_logout

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

o quanto segue a ~/.bash_profile

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

La creazione di più istanze ssh-agent può essere evitata creando un socket di comunicazione persistente con lagente in una posizione fissa nel file system, come nella risposta di Collin Anderson “. Si tratta di un miglioramento rispetto alla generazione di più agenti istanze, tuttavia, a meno che non venga ucciso esplicitamente, la chiave decrittografata rimane ancora in memoria dopo il logout.

Sui desktop, ssh-agent inclusi nellambiente desktop, come Gnome Keyring SSH Agent , può essere un approccio migliore in quanto tipicamente può essere fatto per richiedere il passaggio frase la prima volta che la chiave ssh viene utilizzata durante una sessione di login e conserva la chiave privata decrittografata in memoria fino alla fine della sessione.

ssh- chiave con passphrase, con ssh-ident

ssh-ident è unutilità che può gestire ssh-agent per tuo conto e caricare le identità secondo necessità. Aggiunge le chiavi solo una volta quando sono necessarie, indipendentemente dal numero di terminali, ssh o sessioni di accesso che richiedono laccesso a un ssh-agent. Può anche aggiungere e utilizzare un agente diverso e un diverso set di chiavi a seconda dellhost a cui è connesso o dalla directory da cui viene richiamato ssh. Ciò consente di isolare le chiavi quando si utilizza linoltro dellagente con host diversi. Consente inoltre di utilizzare più account su siti come GitHub.

Per abilitare ssh-ident, installalo e aggiungi il seguente alias al tuo ~/bash_profile:

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

chiave ssh con passphrase, con keychain

keychain è una piccola utility che gestisce ssh-agent per tuo conto e consente a ssh-agent di rimanere in esecuzione al termine della sessione di accesso. Agli accessi successivi, keychain si connetterà allistanza ssh-agent esistente. In pratica, questo significa che la passphrase deve essere inserita solo durante il primo login dopo un riavvio. Negli accessi successivi, viene utilizzata la chiave non crittografata dallistanza ssh-agent esistente.Ciò può essere utile anche per consentire lautenticazione RSA / DSA senza password in cron lavori senza chiavi ssh senza password.

Per abilitare keychain, installalo e aggiungi qualcosa di simile a ~/.bash_profile:

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

Da un punto di sicurezza di visualizzazione, ssh-ident e keychain sono peggiori delle ssh-agent istanze limitate alla durata di un determinato sessione, ma offrono un alto livello di comodità. Per migliorare la sicurezza di keychain, alcune persone aggiungono lopzione --clear al loro portachiavi ~/.bash_profile invocazione. In questo modo le passphrase devono essere reinserite al login come sopra, ma i lavori cron avranno ancora accesso alle chiavi non crittografate dopo che lutente si disconnette. La keychain pagina wiki contiene ulteriori informazioni ed esempi.

chiave ssh senza passphrase

Dal punto di vista della sicurezza, questa è lopzione peggiore poiché la chiave privata è completamente non protetta nel caso in cui è esposto. Questo è, tuttavia, lunico modo per assicurarsi che la passphrase non debba essere reinserita dopo un riavvio.

ssh-key con passphrase, con ssh-agent, passando la passphrase a ssh-add dallo script

Anche se potrebbe sembra unidea semplice passare la passphrase a ssh-add da uno script, ad es. echo "passphrase\n" | ssh-add, non è così semplice come sembra perché ssh-add non legge il passphrase da stdin, ma apre /dev/tty direttamente per la lettura .

Può essere ha funzionato con expect , uno strumento per lautomazione interattiva applicazioni. Di seguito è riportato un esempio di uno script che aggiunge una chiave ssh utilizzando una passphrase memorizzata nello 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 

Nota che poiché la passphrase è memorizzata in testo normale in lo script, dal punto di vista della sicurezza, non è affatto meglio che avere una chiave ssh senza password. Se è necessario utilizzare questo approccio, è importante assicurarsi che lo script expect contenente la passphrase abbia le autorizzazioni appropriate impostate, rendendolo leggibile, scrivibile ed eseguibile solo dalla chiave proprietario.

Commenti

• Va bene, ma quando metto il tuo codice in ~ / .bash_profile devo digitare la password ogni volta che effettuo il login, non ‘ neanche questo. Non sono affatto preoccupato per la sicurezza. echo ” passa \ n ” | ssh-add non ‘ funziona
• @ user1607072 Sì, è così che lo snippet ssh-agent in ~/.bash_profile si comporta come spiegato nella risposta. Potresti voler esaminare lutilità keychain. Con keychain devi inserire la password al primo accesso dopo il riavvio, ma agli accessi successivi keychain si connetterà a un ssh-agent istanza con la chiave decrittografata in memoria. A parte questo, ‘ è la possibilità di generare una chiave ssh senza passphrase, ma questo ovviamente non è consigliato.
• @ user1607072 Anche se lo farei fortemente suggerire uno degli approcci più sicuri, cè un modo per passare la passphrase a ssh-add da uno script. Il motivo per cui echo "pass\n" | ssh-add non funziona è che ssh-add non legge la password da stdin, ma apre /dev/tty direttamente per la lettura. Aggiornata la risposta per includere una soluzione alternativa, utilizzando unutilità chiamata expect.
• @ user1607072 Potrebbe essere un po eccessivo per il tuo caso duso, ma Kerberos in combinazione con il supporto ssh GSSAPI può essere utilizzato anche per gli accessi ssh senza password. Il metodo di autenticazione corrispondente in ssh si chiama gssapi-with-mic. Questo di solito è usato in reti più grandi, ma ovviamente se sei interessato a questo potrebbe valere la pena esaminarlo.
• @ErickBrown: già risposto qui . Lunità dellagente SSH deve essere arrestata al logout se la permanenza dellutente è disabilitata nel systemd login manager . Se la permanenza utente è abilitata, listanza utente systemd e lunità agente SSH vengono mantenute in esecuzione anche dopo la chiusura dellultima sessione di accesso.

Aggiungila a ~/.bashrc, quindi esci e di nuovo per avere effetto.

 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  

Questo dovrebbe richiedere solo una password la prima volta che accedi dopo ogni riavvio. Continuerà a riutilizzare lo stesso ssh-agent finché rimane in esecuzione.

Commenti

• molto accurato , in questo modo hai un solo agente ssh in esecuzione (: più agenti come in @thomasNyman ‘ La seconda soluzione mi sembra un rischio per la sicurezza …
• Dopo aver cercato in vari siti e letto varie soluzioni, questa sembra essere la più chiara, dritta al punto. Molto carino. +1
• meglio farlo: `alias ssh = ssh-check-agent ” e fai in modo che la versione check-agent esegua quanto sopra. in questo modo: a) ottieni solo un agente eb) ottieni lagente solo se ne hai bisogno
• Penso che -s sia limpostazione predefinita, quindi ‘ lo stiamo già facendo.
• Tieni presente che ssh-add senza argomenti aggiunge ~/.ssh/id_rsa. Potresti voler passare ssh-add argomenti se le tue chiavi private si trovano in un altro file.

Non strettamente correlato alla domanda dellOP, ma potrebbe essere utile ad altri: poiché 7.2.0 ssh (1) ha unopzione che permette di aggiungere una chiave a ssh-agent alla prima autenticazione; lopzione è AddKeysToAgent e può essere impostata su yes, no, ask o confirm, a livello di sistema o nel file .ssh/config personale.

Riferimento : https://www.openssh.com/txt/release-7.2

Commenti

• Applicabile a coloro che sono nuovi al file .ssh/config: questo vale per ssh e tutto ciò che utilizza ssh dietro di esso, ad esempio scp, e può essere eseguito in base allhost.
• Mi chiede ancora la password ogni volta che accedo e provo a eseguire git pull, ad esempio.
• @trainosis Il problema è che probabilmente non hai unistanza ssh-agent in esecuzione per conservare le chiavi decrittografate in memoria per usi futuri. Dovresti inserire la password per una determinata chiave solo una volta per sessione di accesso quando utilizzi ssh-agent.

ssh-agent memorizza nella cache varie chiavi ssh sbloccate, così puoi avere le chiavi ssh protette da password, ma senza doverle digitare ogni volta.

Per memorizzare nella cache le chiavi sbloccate, è ovviamente necessario sbloccare quelle chiavi. Per sbloccare le chiavi che sono bloccate con una passphrase, ovviamente è necessario conoscere queste passphrase.

Qualsiasi metodo che non richiede lautorizzazione di un essere umano (ad esempio “digitare una password”) non solo renderà sistema insicuro; renderà anche insignificante lintero scopo di ssh-agent.

Detto questo, puoi semplicemente usare le chiavi ssh che non sono protette da password (premi Invio quando ti viene chiesto per una password durante la generazione della chiave). Poiché non esiste alcuna password, ssh-agent non ha “bisogno di chiederne una per (non) memorizzarla nella cache.

Commenti

• Sono daccordo, fintanto che le tue chiavi sono correttamente autorizzate solo dallutente, cè poco vantaggio per ssh-agent rispetto alle chiavi senza autorizzazione. mi piace ssh in un server di login, e poi quel server ha un mucchio di chiavi senza permessi, ognuna delle quali può essere usata solo per sbloccare un altro server. il server di accesso non fa nientaltro, quindi ‘ è molto più difficile da hackerare / falsificare, ecc … gli altri server non hanno accesso tramite password, sono solo chiavi.

Ecco una soluzione alternativa per automatizzare la tua passphrase SSH.

1. Crea uno script di una sola riga che stampa la tua passphrase sulloutput standard, ad esempio:

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

   Importante: assicurati copi lo spazio iniziale in per evitare di memorizzare la password nella cronologia .

E utilizza uno dei metodi seguenti.

• utilizzando un approccio di input standard:

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

• o named pipe :

  1. Crea un named pipe (potresti anche provare una sostituzione del processo ):

     mkfifo --mode 0600 ~/.ssh_fifo 

  2. Esegui ssh-add specificando il programma utilizzato per lautenticazione:

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

  Vedi: man ssh-add per ulteriori informazioni su SSH_ASKPASS.

Commenti

• echo my_passphrase è un grosso buco di sicurezza. Per prima cosa, dopo averla digitata, la password è in chiaro nel file di cronologia di qualsiasi shell che usi. E gli argomenti della seconda riga di comando sono leggibili in tutto il mondo su Unix (ps -ef). Non inserire mai password negli argomenti della riga di comando!
• @ceving Laggiunta di spazio iniziale aggiuntivo risolve il problema con il file di cronologia. Aggiunte informazioni extra.
• @kenorb: questo ‘ non risolve il problema più grande della password visibile in ps produzione. Il file della cronologia è in genere leggibile solo dallutente proprietario in ogni caso, ma le righe di comando sono leggibili da tutti gli utenti su un sistema.

Non ti consiglio “ssh-add (che deve aprire un ssh-agent) allaccesso. Questo perché non puoi controllare quando la sezione ssh-agent finisce e puoi creare rischi per la sicurezza quando non è necessario utilizzare i file di chiavi in una sezione di accesso.

Piuttosto, consiglio di scrivere uno script che apra una sotto-shell della sezione ssh-agent, con tutti i file di chiavi aggiunti automaticamente, e venga richiamato quando necessario per usare ssh. Se potessi adottarlo, continua a leggere.

Avresti due scelte:

1. Rimuovi tutte le passphrase per le tue chiavi, che hanno sicurezza debole se i tuoi file chiave vengono rubati. (quindi non consigliato )

2. Usa la stessa passphrase per le tue chiavi. Quindi, quando ssh-add keyfile1 keyfile2 ..., dovrai digitare la passphrase solo una volta, per sezione.

In entrambi i casi, potresti scrivere tale file di script “ssh_keys_section.sh” come di seguito:

#!/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" 

Osservazioni:

• Comando per modificare o eliminare la passphrase: ssh-keygen -p -f keyfile
• Allinterno della sottostruttura, potresti persino eseguire il fork di più terminali che condividono la stessa chiavi sbloccate, magari usando un comando come /path/to/yourterminal & (dipende dal sistema operativo)

Commenti

• Ad es Su Windows allinterno di Cygwin, /path/to/yourterminal & == > mintty &
• Nota: dopo luso, chiudi la sessione con ctrl-d o exit, proprio come hai richiamato un bash shell e devi chiuderla.

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 

Usavo lo script menzionato da steampowered, ho “fatto quello sotto ora, perché non lascia file in giro.

Lavorare su zsh solo shell.

#!/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 

Commenti

• ” Ci sto lavorando solo shell zsh “, ok ma perché la tua riga di Shebang afferma di richiedere solo ” 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 

Dare credito qui: https://www.cygwin.com/ml/cygwin/2001-06/msg00537.html

Questa soluzione è anche approvata qui: http://mah.everybody.org/docs/ssh

Se utilizzi cavalluccio marino come gestore di password … Quale probabilmente sei; D

Unaltra soluzione che raggiunge lobiettivo che stai cercando è semplicemente aggiungere le chiavi ssh a Seahorse per lo sblocco automatico allaccesso . Il vantaggio principale di questo è che non devi mai inserire una password per le chiavi dopo aver effettuato laccesso tramite gdm, o qualunque sia il tuo accesso, anche se le chiavi hanno una password. Questo RICHIEDE sia la chiave privata che la chiave pubblica. Devono inoltre seguire una convenzione di denominazione per il cavalluccio marino. Limpostazione predefinita è accettabile (id_rsa per la chiave privata e id_rsa.pub per la chiave pubblica … In realtà tutto ciò che è privatekeyname e privatekeyname.pub )

Per aggiungere la tua chiave ssh a Seahorse per lo sblocco automatico allaccesso; (su fedora25, non sono sicuro di dove sia il percorso su altre distribuzioni anche se molto probabilmente è molto simile)

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

Per me era

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

(seahorse presumerà automaticamente che la chiave pubblica nel mio caso fosse id_rsa.pub)

Dopo aver eseguito il comando, seahorse aprirà un carino piccolo campo gtk password in cui inserire la password per la chiave privata. o lascialo vuoto se hai generato la chiave senza password.

Seahorse non ti chiederà se tutto è andato bene. Dovrai tentare di eseguire ssh nella macchina di destinazione.Quindi il cavalluccio marino ti chiederà di sbloccare la chiave con una password graficamente (QUESTO ACCADRÀ SOLO UNA VOLTA) ma questa volta dovrebbe sembrare un po diverso; P (questa è anche la parte in cui cavalluccio marino fa un po di cavalluccio marino per ssh-aggiungi magia credo ) e offri OPZIONE per sbloccare la chiave allaccesso, devi selezionare questa opzione per raggiungere il tuo obiettivo.

Solo perché non ho letto tutte le risposte, consiglierei di annullare ciò che tutti ti hanno detto di fare con ssh-add prima di tentare questa risposta. In caso contrario, potrebbe accadere qualcosa di brutto alle tue chiavi, idk.

La soluzione Single Sign-On per SSH potrebbe portarmi a pam_ssh .

Secondo questo articolo , il concetto è:

Se lavori con più macchine basate su * nix tramite ssh, probabilmente sei stanco dei contro dovendo inserire la password ogni volta che si desidera accedere a unaltra casella. Esiste un modo sicuro per consentirti di accedere a ogni macchina a cui hai accesso ssh, senza dover inserire unaltra password (diversa da quella con cui ti sei registrato originariamente).

In realtà è abbastanza semplice da fare, fondamentalmente devi solo creare una coppia di chiavi pubblica / privata per autenticarti sulle altre tue macchine, quindi PAM genera un agente per caricare le chiavi dopo laccesso, fornendo una soluzione single signon per accedere a tutte le macchine remote. Questa guida ti guiderà attraverso la configurazione.

Non ho verificato che funzioni effettivamente.

Aggiungilo al tuo ~/.bashrc file:

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

Commenti

• Non ‘ per vedere come questo si collega alla domanda, che riguarda la mancata richiesta della password agli accessi successivi.

Per aggiungere una chiave (possibilmente senza password) e assicurarti che ssh-add non richiederà una password, qualunque cosa accada, anche se in esecuzione sotto X :

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

Lo stato di uscita indica successo o fallimento.

Ecco il definitivo script.

Aggiorna $ PASSW, quindi copia e incolla nel tuo terminale

# <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 

Il modo migliore di cui sono a conoscenza è usare uno script di login PAM che ho adattato dal lavoro precedente perché non sono riuscito a trovare una risposta soddisfacente a questa domanda.

La tua passphrase ottiene memorizzata crittografata con la password di sistema e una funzione di derivazione pesante. Al login, la password di sistema viene utilizzata per decrittografare la passphrase e aggiungerla allagente.

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

Il vantaggio rispetto a ogni altra soluzione presentata è che combina la sicurezza equivalente allesecuzione manuale di ssh-add allavvio senza alcuno sforzo. nessuno strumento aggiuntivo e ha una dipendenza in più che è già installata di default sulla maggior parte dei sistemi (OpenSSL).

Il mio la configurazione su macOS è la seguente (in .zshrc o .bash_profile per gente bash):

La parte || [[ $SSH_AUTH_SOCK == *"/private/tmp/"* ]] è necessaria su macOS perché il valore predefinito è /private/tmp/com.apple.launchd.SOMETHINGHERE/Listeners. In caso contrario, la risposta completa di @Thomas Nyman fallisce perché $SSH_AUTH_SOCK è sempre impostato su qualcosa.

Quindi in .zlogout (o .bash_logout per gente bash):

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

Testato su macOS Mojave 10.14.5

Questo è stato spiegato molto bene da GitHub su Avvio automatico di ssh-agent su Git per Windows , che a sua volta funziona anche per Linux.

Puoi eseguire ssh-agent automaticamente quando apri bash o Git shell. Copia le seguenti righe e incollale nel tuo file ~/.profile o ~/.bashrc nella 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  

Se la tua chiave privata non è memorizzata in una delle posizioni predefinite (come ~/.ssh/id_rsa), dovrai dire al tuo agente di autenticazione SSH dove trovarlo. Per aggiungere la tua chiave a ssh-agent, digita ssh-add ~/path/to/my_key.

Suggerimento: Se desideri che ssh-agent dimentichi la chiave dopo un po di tempo, puoi configurarlo per farlo eseguendo ssh-add -t <seconds>.