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


248

Voglio comunicare tra più computer sulla mia rete (Ethernet statica), tramite SSH. Per fare ciò devo eseguire ssh-add ogni volta che eseguo l'accesso su una macchina specifica, come posso farlo in modo che sia impostato una volta e non mi chieda la passphrase ogni volta che eseguo l'accesso o riavvio la mia macchina?

So che esiste un modo per aggiungere alcune righe al bash_profilefile, ma devo comunque digitare la password ogni volta che riavvio / accesso a una macchina specifica.

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

Risposte:


348

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

ssh-key con passphrase, no ssh-agent

Ora la passphrase deve essere inserita ogni volta che la chiave viene utilizzata per l'autenticazione. Sebbene questa sia l'opzione migliore dal punto di vista della sicurezza, offre la peggiore usabilità. Ciò può anche portare alla scelta di una passphrase debole per ridurre l'onere di inserirla ripetutamente.

ssh-key con passphrase, con ssh-agent

Aggiungendo quanto segue ~/.bash_profilesi avvierà ssh-agente caricherà automaticamente le chiavi ssh all'accesso:

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

Ora la passphrase deve essere inserita ad ogni accesso. Sebbene leggermente migliore dal punto di vista dell'usabilità, questo ha lo svantaggio che ssh-agentrichiede la passphrase indipendentemente dal fatto che la chiave debba essere utilizzata o meno durante la sessione di accesso. Ogni nuovo accesso genera anche ssh-agentun'istanza distinta che rimane in esecuzione con le chiavi aggiunte in memoria anche dopo il logout, a meno che non sia stata esplicitamente uccisa.

Per terminare ssh_agental logout, aggiungi quanto segue a~/.bash_logout

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

o il seguente a ~/.bash_profile

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

La creazione di più ssh-agentistanze può essere evitata creando un socket di comunicazione persistente all'agente in una posizione fissa nel file system, come nella risposta di Collin Anderson . Questo è un miglioramento rispetto alla generazione di istanze di più agenti, tuttavia, a meno che la chiave decodificata non rimanga esplicitamente rimasta in memoria dopo il logout.

Sui desktop, gli agenti ssh inclusi nell'ambiente desktop, come l' agente SSH di Gnome Keyring , possono essere un approccio migliore in quanto in genere possono essere richiesti per richiedere la passphrase la prima volta che si utilizza ssh-key durante una sessione di accesso e archivia la chiave privata decifrata in memoria fino alla fine della sessione.

ssh-key con passphrase, con ssh-ident

ssh-identè un'utilità che può gestire ssh-agentper tuo conto e caricare identità se necessario. Aggiunge le chiavi solo una volta quando sono necessarie, indipendentemente da quanti terminali, ssh o sessioni di accesso richiedono l'accesso a un ssh-agent. Può anche aggiungere e utilizzare un agente diverso e un diverso set di chiavi a seconda dell'host a cui si è connessi o da cui viene invocata la directory ssh. Ciò consente di isolare le chiavi quando si utilizza l'inoltro dell'agente con host diversi. Inoltre, consente di utilizzare più account su siti come GitHub.

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

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

ssh-key con passphrase, con keychain

keychainè una piccola utility che gestisce ssh-agentper tuo conto e consente ssh-agentdi rimanere in esecuzione al termine della sessione di accesso. Su accessi successivi, keychainsi connetterà ssh-agentall'istanza esistente . In pratica, ciò significa che la passphrase deve essere inserita solo durante il primo accesso dopo un riavvio. Negli accessi successivi, ssh-agentviene utilizzata la chiave non crittografata dall'istanza esistente . Questo può essere utile anche per consentire l'autenticazione RSA / DSA cronsenza password in lavori senza ssh-key senza password.

Per abilitarlo keychain, installalo e aggiungi qualcosa di simile al seguente a ~/.bash_profile:

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

Da un punto di vista della sicurezza, ssh-idente keychainsono peggiori delle ssh-agentistanze limitate alla durata di una determinata sessione, ma offrono un elevato livello di praticità. Per migliorare la sicurezza di keychain, alcune persone aggiungono l' --clearopzione alla loro ~/.bash_profilechiamata portachiavi. In questo modo le passphrase devono essere reinserite all'accesso come sopra, ma i cronlavori avranno comunque accesso alle chiavi non crittografate dopo che l'utente si è disconnesso. La keychain pagina wiki contiene ulteriori informazioni ed esempi.

ssh-key senza passphrase

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

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

Mentre potrebbe sembrare un'idea semplice passare la passphrase ssh-addda una sceneggiatura, ad esempio echo "passphrase\n" | ssh-add, non è così semplice come sembra ssh-add non leggere la passphrase stdin, ma si apre /dev/ttydirettamente alla lettura .

Questo può essere risolto con expect, uno strumento per automatizzare le applicazioni interattive. Di seguito è riportato un esempio di uno script che aggiunge una ssh-key usando 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

Si noti che poiché la passphrase è memorizzata in testo normale nello script, dal punto di vista della sicurezza, ciò non è affatto meglio che avere una ssh-key senza password. Se si deve utilizzare questo approccio, è importante assicurarsi che lo expectscript contenente la passphrase abbia le autorizzazioni appropriate impostate su di esso, rendendolo leggibile, scrivibile e eseguibile solo dal proprietario della chiave.


1
Va bene, ma quando inserisco il tuo codice in ~ / .bash_profile devo digitare la password ogni volta che eseguo l'accesso, non lo voglio neanche io. Non sono affatto preoccupato per la sicurezza. echo "pass \ n" | ssh-add non funziona
zdun8

3
@ user1607072 Sì, è così che si comporta lo ssh-agentsnippet ~/.bash_profilecome spiegato nella risposta. Potresti voler guardare l' keychainutilità. Con keychainè necessario inserire la password al primo accesso dopo il riavvio, ma agli accessi successivi keychainsi collegherà a ssh-agentun'istanza esistente con la chiave decodificata in memoria. A parte questo, c'è la possibilità di generare una ssh-key senza passphrase, ma questo ovviamente non è raccomandato.
Thomas Nyman,

3
@ user1607072 Mentre suggerirei fortemente uno degli approcci più sicuri, c'è un modo per passare la passphrase ssh-addda uno script. Il motivo echo "pass\n" | ssh-addnon funziona è che ssh-addnon legge la password stdin, ma si apre /dev/ttydirettamente per la lettura. Aggiornata la risposta per includere una soluzione alternativa, utilizzando un'utilità chiamata expect.
Thomas Nyman,

1
@ user1607072 Potrebbe essere un po 'eccessivo per il tuo caso d'uso, ma Kerberos in combinazione con il supporto GSSAPI ssh può essere usato anche per accessi ssh senza password. Viene chiamato il metodo di autenticazione corrispondente in ssh gssapi-with-mic. Questo è di solito usato in reti più grandi, ma ovviamente se ti interessa potrebbe valere la pena di esaminarlo.
Thomas Nyman,

1
@ErickBrown: già risposto qui . L'unità agente SSH deve essere arrestata al logout se l'utente ha la permanenza disabilitata nel gestore login systemd . Se la permanenza dell'utente è abilitata, l'istanza utente di systemd e l'unità SSH Agent continuano a funzionare anche dopo la chiusura dell'ultima sessione di accesso.
Thomas Nyman,

93

Aggiungi questo al tuo ~/.bashrc, quindi disconnettiti e accedi nuovamente per rendere effettive.

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 una password solo al primo accesso dopo ogni riavvio. Continuerà a riutilizzare lo stesso ssh-agentfinché rimane in esecuzione.


1
molto pulito, in questo modo hai solo un agente ssh in esecuzione (: agenti multipli come nella seconda soluzione di @ thomasNyman mi sembra un rischio per la sicurezza ...
drevicko,

1
Dopo aver fatto ricerche in vari siti e aver letto varie soluzioni, questa qui sembra essere la più chiara, diretta al punto. Molto bella. +1
Dr Beco,

1
meglio fare questo: `alias ssh = ssh-check-agent", e fare in modo che la versione di check-agent esegua quanto sopra. in questo modo: a) ottieni solo un agente eb) ottieni l'agente solo se ne hai bisogno
Erik Aronesty,

2
Penso che -s sia l'impostazione predefinita, quindi lo stiamo già facendo.
Collin Anderson,

1
ssh-add -lrestituisce un codice di uscita pari a 0 quando l'agente ha identità e 1 quando non lo fa, quindi è possibile eliminare grep dall'ultimo comando e utilizzaressh-add -l > '/dev/null' || ssh-add
Concedi Humphries il

16

Non strettamente correlato alla domanda del PO, ma potrebbe essere utile ad altri: poiché 7.2.0 ssh (1) ha un'opzione che consente di aggiungere una chiave a ssh-agent alla prima autenticazione; l'opzione è AddKeysToAgente può essere impostata su yes, no, ask, o confirm, sistema o sul personal .ssh/configfile.

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


2
Applicabile a coloro che non conoscono il .ssh/configfile: questo vale per sshtutto ciò che lo utilizza ssh, ad esempio scp, e può essere eseguito su base host.
SEoF

Mi chiede ancora la password ogni volta che eseguo il login e provo ad usare pull per esempio.
trainoasi,

@trainosis Il problema è che probabilmente non hai un'istanza di ssh-agent in esecuzione per contenere le chiavi decifrate in memoria per un uso futuro. Dovresti solo inserire la password per una determinata chiave una volta per sessione di accesso quando usi ssh-agent.
estest

7

ssh-agent memorizza nella cache vari ssh-key sbloccati, così puoi avere ssh-key protetti da password, ma senza doverli digitare ogni volta.

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

Qualsiasi metodo che non richiede l'autorizzazione di un essere umano (ad es. "Digitare una password") non solo renderà il tuo sistema insicuro; renderà inoltre insignificante l'intero scopo dell'agente ssh.

Detto questo, puoi semplicemente usare ssh-keys che non sono protetti da password (premi Enterquando ti viene chiesta una password durante la generazione delle chiavi). Poiché non è presente alcuna password, ssh-agentnon è necessario richiederne una per non memorizzarla nella cache.


Sono d'accordo, purché le tue chiavi siano correttamente autorizzate solo dall'utente, ci sono pochi vantaggi per ssh-agent rispetto alle chiavi senza autorizzazione. mi piace ssh in un server di accesso, e poi quel server ha un sacco di chiavi permssionless, ognuna delle quali può essere utilizzata solo per sbloccare un altro server. il server di login non fa nient'altro, quindi è molto più difficile hackerare / spoofare, ecc ... gli altri server non hanno accesso con password, sono solo chiavi.
Erik Aronesty,

5

Ecco una soluzione alternativa per automatizzare la passphrase SSH.

  1. Crea uno script a riga singola che stampa la passphrase sull'output standard, ad esempio:

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

    Importante: assicurati di copiare lo spazio iniziale per impedire la memorizzazione della password nella cronologia .

E usa uno dei metodi seguenti.

  • utilizzando un approccio di input standard:

    cat ~/.ssh/id_rsa | SSH_ASKPASS=~/.print_ssh_password ssh-add -
    
  • o l' approccio pipe denominato :

    1. Crea una pipe con nome (puoi anche provare una sostituzione di processo ):

      mkfifo --mode 0600 ~/.ssh_fifo
      
    2. Esegui ssh-addspecificando il programma utilizzato per l'autenticazione:

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

    Vedi: man ssh-addper saperne di più SSH_ASKPASS.


2
Il echo my_passphraseè un grosso buco di sicurezza. Prima di averlo digitato, la password è in chiaro nel file della cronologia di qualunque shell tu usi. E gli argomenti della seconda riga di comando sono leggibili da tutti su Unix ( ps -ef). Non inserire mai le password negli argomenti della riga di comando!
ceving

1
@ceving L'aggiunta di ulteriore spazio iniziale risolve il problema con il file della cronologia. Aggiunte informazioni extra.
Kenorb,

@kenorb: questo non risolve il problema più grande della password visibile psnell'output. Il file di cronologia è in genere leggibile comunque solo dall'utente proprietario, ma le righe di comando sono leggibili da tutti gli utenti su un sistema.
Thomas Nyman,

4

Non ti consiglierò ssh-add (che deve aprire un ssh-agent) al login. Questo perché non è possibile controllare quando termina la sezione ssh-agent e si possono creare rischi per la sicurezza quando non è necessario utilizzare i file di chiavi in ​​una sezione di accesso.

Piuttosto, raccomando di scrivere uno script che apre la sottotabella di sezione di un agente ssh, con tutti i file di chiavi aggiunti automaticamente e di essere chiamato 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 una sicurezza debole se i file delle chiavi vengono rubati. (quindi non raccomandato )

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

In entrambi i casi, è possibile scrivere il 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
  • All'interno della sotto-shell, potresti persino fork più terminali che condividono le stesse chiavi sbloccate, usando forse un comando simile /path/to/yourterminal &(dipende dal sistema operativo)

Ad esempio, su Windows in Cygwin, /path/to/yourterminal &==>mintty &
Johnny Wong il

2
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

2

Usavo la sceneggiatura menzionata da steampowered, ora ho creato la seguente, perché non lascia i file in giro.

Funziona zshsolo su shell.

#!/bin/sh

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

1
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 supportata qui: http://mah.everybody.org/docs/ssh


1

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 di dover inserire costantemente la password ogni volta che vuoi accedere a un'altra casella. C'è un modo sicuro per permetterti di accedere a tutte le macchine a cui hai accesso ssh, senza dover inserire un'altra password (diversa da quella con cui hai effettuato l'accesso originariamente).


In realtà questo è abbastanza semplice da fare, in pratica basta creare una coppia di chiavi pubblica / privata per autenticarsi su altre macchine, quindi fare in modo che PAM generi un agente per caricare le chiavi dopo l'accesso, fornendo un'unica soluzione di accesso per accedere a tutto il telecomando macchinari. Questa guida ti guiderà attraverso l'impostazione.

Non ho verificato che funzionerebbe davvero.


0

Aggiungi questo al tuo ~/.bashrcfile:

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

Non vedo come questo si collega alla domanda, che riguarda il fatto che non viene richiesta la password per gli accessi successivi.
Chris Down,

0

Per aggiungere una chiave (possibilmente senza password) e assicurarsi che ssh-addnon richieda una password, non importa quale, anche quando si esegue sotto X :

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

Lo stato di uscita indica l'esito positivo o negativo.


0

Se stai utilizzando un cavalluccio marino come gestore delle password ... Cosa che probabilmente sei; D

Un'altra soluzione che raggiunge l'obiettivo che stai cercando è semplicemente l'aggiunta delle chiavi ssh al cavalluccio marino per lo sblocco automatico al login. Il vantaggio principale di questo è che non devi mai inserire una password per le chiavi dopo aver effettuato l'accesso tramite gdm, o qualunque sia il tuo accesso anche se le chiavi hanno una password. Ciò RICHIEDE sia la chiave privata che la chiave pubblica. DEVONO anche seguire una convenzione di denominazione per i cavallucci marini. L'impostazione predefinita è accettabile (id_rsa per chiave privata e id_rsa.pub per chiave pubblica ... In realtà tutto ciò che è privatekeyname e privatekeyname.pub )

Per aggiungere la chiave ssh al cavalluccio marino per lo sblocco automatico al login; (su fedora25, non sono sicuro di dove si trovi il percorso su altre distro sebbene sia molto probabilmente molto simile)

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

Per me lo era

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

(cavalluccio marino supporrà automaticamente che la chiave pubblica nel mio caso fosse id_rsa.pub)

Dopo aver eseguito il comando, cavalluccio marino aprirà un campo carino password gtk per inserire la password per la chiave privata. o lascialo vuoto se hai generato la chiave senza una password.

Seahorse non ti chiederà se tutto è andato bene. Dovrai tentare di accedere alla macchina target. Quindi il cavalluccio marino ti chiederà di sbloccare graficamente la chiave con una password (QUESTO SARÀ SOLO APERTO) ma questa volta dovrebbe apparire un po 'diverso; P (questa è anche la parte in cui il cavalluccio marino fa un cavalluccio marino per aggiungere magia ssh ) e offri l' OPZIONE per sbloccare la chiave al momento dell'accesso, 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 provare questa risposta. In caso contrario, potrebbe accadere qualcosa di brutto alle tue chiavi, idk.


0

Ecco lo script definitivo.

Aggiorna $ PASSW, quindi copialo e incollalo 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

0

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

La passphrase viene archiviata crittografata con la password di sistema e una pesante funzione di derivazione. All'accesso, la password di sistema viene utilizzata per decrittografare la passphrase e aggiungerla all'agente.

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

Il vantaggio rispetto a qualsiasi altra soluzione presentata è che combina la sicurezza equivalente all'esecuzione manuale di ssh-add all'avvio senza sforzo. Non richiede strumenti aggiuntivi e ha una dipendenza aggiuntiva che è già installata di default sulla maggior parte dei sistemi (OpenSSL).


0

La mia configurazione su macOS è la seguente (in .zshrc, o .bash_profileper le persone bash):

# Kill then Load the ssh-agent and set the necessary env variables it outputs
sshRestart() {
    # if all else fails
    # pkill -u $(whoami) ssh-agent;

    if [ -n "$SSH_AUTH_SOCK" ] ; then
        eval `/usr/bin/ssh-agent -k`
    fi
    eval `ssh-agent -s`
    ssh-add ~/.ssh/YOUR_KEY_FILE
    echo "Restarted SSH agent"
}

if [ -z "$SSH_AUTH_SOCK" ] || [[ $SSH_AUTH_SOCK == *"/private/tmp/"* ]] ; then
    eval `ssh-agent -s` > /dev/null 2>&1
    ssh-add ~/.ssh/YOUR_KEY_FILE > /dev/null 2>&1
fi

La || [[ $SSH_AUTH_SOCK == *"/private/tmp/"* ]]parte è necessaria su macOS perché il valore predefinito è /private/tmp/com.apple.launchd.SOMETHINGHERE/Listeners. Altrimenti la risposta completa di @Thomas Nyman non riesce perché $SSH_AUTH_SOCKè sempre impostata su qualcosa.

Quindi in .zlogout(o .bash_logoutper la gente di bash):

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

Testato su macOS Mojave 10.14.5

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.