qual è lo scopo di ssh-agent?


70

Ho letto la definizione ufficiale:

ssh-agent è un programma per contenere chiavi private utilizzate per l'autenticazione con chiave pubblica (RSA, DSA, ECDSA). L'idea è che ssh-agent viene avviato all'inizio di una X-session o di una sessione di login e tutte le altre finestre o programmi vengono avviati come client per il programma ssh-agent. Tramite l'uso di variabili d'ambiente l'agente può essere localizzato e usato automaticamente per l'autenticazione quando si accede ad altre macchine usando ssh (1).

"..un programma per contenere chiavi private .." - IMHO - Le chiavi ssh sono generate dall'utente con il comando ssh-keygen e semplicemente e direttamente memorizzate in ~ / .ssh - perché ho bisogno di un demone per contenere queste chiavi? Come li tiene esattamente, non sono solo memorizzati in .ssh?

"sono avviati come client per il programma ssh-agent" - Non capisco. Dove uno ne avrebbe bisogno? Di solito uso solo ssh come questo:

 ssh -i ~/.ssh/private_key_name username@hostname

Cosa significa esattamente "manuale" per manuale - quali client? Non esegui semplicemente il comando ssh dal terminale per connetterti: quali altri client ci sono e perché non possono semplicemente usare un percorso per quel file privato ssh, proprio come il comando ssh?

Risposte:


76

L'agente SSH gestisce per te la firma dei dati di autenticazione. Quando si esegue l'autenticazione su un server, è necessario firmare alcuni dati utilizzando la chiave privata, per dimostrare che si, beh, si.

Come misura di sicurezza, molte persone proteggono sensibilmente le proprie chiavi private con una passphrase, quindi qualsiasi tentativo di autenticazione richiederebbe di inserire questa passphrase. Questo può essere indesiderabile, quindi ssh-agent memorizza nella cache la chiave per te e devi solo inserire la password una volta, quando l'agente vuole decodificarla (e spesso nemmeno, poiché l'agente ssh può essere integrato con pam, che fanno molte distro).

L'agente SSH non consegna mai queste chiavi ai programmi client, ma presenta semplicemente un socket sul quale i client possono inviargli i dati e sul quale risponde con i dati firmati. Un vantaggio di questo è che puoi usare la tua chiave privata anche con programmi di cui non ti fidi completamente.

Un altro vantaggio dell'agente SSH è che può essere inoltrato tramite SSH. Quindi quando si invia ssh all'host A, mentre si inoltra il proprio agente, è possibile quindi ssh da A a un altro host B senza bisogno della chiave presente (nemmeno in forma crittografata) sull'host A.


10
Sento che questa è la risposta più completa, ma manca ancora un punto. L'uso di un key agent consente inoltre di utilizzare facilmente più chiavi. Invece di dover specificare il percorso della chiave, quando si usa un key agent ssh proverà ogni chiave in essa contenuta.
Patrick,

3
@Patrick che potrebbe anche essere uno svantaggio: prova troppe chiavi non valide su un server e chiuderà la connessione prima di arrivare alla chiave valida. Certo, questa è ~/.ssh/configla IdentityFilescelta giusta, con o senza l'agente
Tobias Kienzler,

@Patrick che sembra ugualmente possibile senza un agente
Andrey Fedorov

@AndreyFedorov Sì, puoi avere più chiavi senza un agente, ma puoi anche specificare nella tua ~/.ssh/configchiave quale chiave utilizzare per quale host remoto, in modo che sappia esattamente quale ha bisogno.
Patrick,

3
quindi si può presumere che ssh-agentnon sia necessario se una chiave privata non è protetta da una passphrase?
pkaramol,

16

Il vantaggio ssh-agentè che devi inserire la passphrase solo una volta. Se la tua chiave RSA privata non è crittografata con una passphrase, ssh-agent non è necessario. Il sshcomando sarebbe un esempio di client.


7

Se si sshesegue regolarmente il routing su una varietà di macchine diverse, ognuna con la propria chiave e passphrase, l'esecuzione in esecuzione ssh-agentconsente di immettere la passphrase per ogni chiave una volta 1 all'inizio della sessione e quindi è possibile autenticarsi su ogni macchina tutte le volte come preferisci senza dover reinserire la passphrase.

Un ulteriore vantaggio è che, come da manpagina, l'agente non invia mai una chiave privata sul suo canale di richiesta; quindi se passi da una casella all'altra, le tue chiavi private sono protette.

1 È possibile impostare il lifetempo in cui i tasti sono tenuti nell'agente.


6

L'articolo di Wikipedia ha probabilmente la migliore descrizione:

La verifica al server si basa sull'autenticazione challenge-response. ssh si collega al server con un nome utente e la richiesta di una chiave. Il demone ssh riceve la richiesta e invia una richiesta basata sulla chiave pubblica memorizzata nel file di autenticazione. ssh utilizza la chiave privata per costruire una risposta chiave e la invia a sshd in attesa sull'altra estremità della connessione. Non invia la chiave privata stessa. Il demone ssh convalida la risposta chiave e, se valido, concede l'accesso al sistema. ssh-agent semplifica questo creando un socket che ascolta le connessioni SSH. L'utente avvia semplicemente ssh-agent, dicendogli come trovare le proprie chiavi (se non si trovano nella posizione predefinita), inserisce la passphrase per ogni chiave da usare, una volta sola,

Ancora una volta letteralmente dall'articolo di Wikipedia:

... ssh-agent crea un socket e quindi controlla le connessioni da ssh. Chiunque sia in grado di connettersi a questo socket ha anche accesso all'agente ssh. Le autorizzazioni sono impostate come in un normale sistema Linux o Unix. All'avvio dell'agente, crea una nuova directory in / tmp con autorizzazioni restrittive. Il socket si trova nella cartella.

In genere viene inserito in un file di sistema o dell'utente rc come $HOME/.bashrco $HOME/.profile(per shell bash) in modo che le variabili di ambiente ssh-agentimpostate vengano incorporate completamente nel proprio ambiente.

Sul mio sistema Fedora 14 si avvia abbastanza presto come parte del sottosistema X11. In questo file /etc/X11/xinit/xinitrc-common,:

# Prefix launch of session with ssh-agent if available and not already running.
SSH_AGENT=
if [ -z "$SSH_AGENT_PID" ] && [ -x /usr/bin/ssh-agent ]; then
    if [ "x$TMPDIR" != "x" ]; then
        SSH_AGENT="/usr/bin/ssh-agent /bin/env TMPDIR=$TMPDIR"
    else
        SSH_AGENT="/usr/bin/ssh-agent"
  fi
fi

La variabile $SSH_AGENTviene quindi utilizzata in altri script di avvio X11 come qui /etc/X11/xinit/Xclients:

exec -l $SHELL -c "$SSH_AGENT $XCLIENTS_D/Xclients.$1.sh"

Incorporandolo qui, le seguenti variabili d'ambiente vengono impostate come parte di una shell genitore, quindi anche tutti i figli biforcati dovrebbero averle, ad esempio:

SSH_AUTH_SOCK=/tmp/ssh-PspRF18958/agent.18958; export SSH_AUTH_SOCK;
SSH_AGENT_PID=18959; export SSH_AGENT_PID;

C'è un po 'più di complessità in questo, ma in poche parole questo è fondamentalmente quello che sta succedendo ssh-agent.

Ad esempio in GNOME, ssh-agentviene effettivamente avviato per utente come applicazione di avvio:

                     ss di app di avvio

TL; DR

In conclusione, ssh-agentesiste in modo tale che quando sono necessarie le chiavi ssh è necessario sbloccarle una sola volta con la loro passphrase (supponendo che ne abbiano una), e da quel momento in poi sono disponibili nella loro forma decifrata in memoria (RAM).


1

"vengono avviati come client per il programma ssh-agent" si riferisce all'idea che ssh-agent viene avviato durante l'inizializzazione della sessione di accesso (locale) in modo che tutti i programmi ottengano le variabili di ambiente $SSH_AGENT_PIDe $SSH_AUTH_SOCKche sono necessarie per connettere l'agente.

Un altro vantaggio derivante dall'estrarre la gestione della chiave privata da ssh è che ssh-agent può essere sostituito da gpg-agent. Quindi puoi usare le chiavi OpenPGP (con funzionalità di autenticazione) per SSH. Questa è una buona soluzione per le chiavi OpenPGP su una smart card.

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.