ssh-agent non viene impostato (SSH_AUTH_SOCK, SSV_AGENT_PID non sono impostati)

Ho creato un nuovo account utente per un amico su Kubuntu 12.04. Quando usa ssh, riceve questo errore:

Impossibile aprire una connessione al tuo agente di autenticazione

Stiamo eseguendo sshalcuni script bash.

Dopo aver esaminato la grande varietà di cose che possono portare a quell'errore, ho trovato questa soluzione:

$ eval `ssh-agent -s`
$ ssh-add ~/.ssh/some_id_rsa

Quindi può eseguire i sshcomandi (e gli script bash) come previsto.

Prima di eseguire questi due comandi, le variabili env non sono impostate in un terminale:

$ echo $SSH_AGENT_PID

$ echo $SSH_AUTH_SOCK

$ 

Dopo aver eseguito i comandi, le variabili env vengono impostate come previsto. Tuttavia, non rimangono impostati (ad es. In una shell diversa o dopo il riavvio).

Voglio sapere come impostare il suo computer in modo che non debba eseguire quei due comandi per impostare le variabili env. Non ho bisogno di eseguirli sul mio computer (mai). Finora non vedo cosa sia diverso tra le nostre macchine.

Vedo queste informazioni nella pagina man, ma non mi dice come Ubuntu stia configurando automaticamente l'agente o cosa stia succedendo sulla macchina del mio amico in modo che non funzioni per lui.

Esistono due modi principali per configurare un agente: Il primo è che l'agente avvia un nuovo sottocomando in cui vengono esportate alcune variabili di ambiente, ad esempio ssh-agent xterm &. Il secondo è che l'agente stampa i comandi shell necessari (è possibile generare la sintassi sh (1) o csh (1)) che possono essere evitati nella shell chiamante, ad esempio eval ssh-agent -sper shell di tipo Bourne come sh (1) o ksh (1) ed eval ssh-agent -cper csh (1) e derivati.

Dopo l'installazione accte il riavvio, questo è l'output di lastcomm:

ssh-agent         F    newuser __         0.12 secs Wed Aug  7 11:02
ssh-agent         F    newuser __         0.00 secs Wed Aug  7 20:34
ssh-agent         F    newuser __         0.02 secs Wed Aug  7 20:02
ssh-agent         F    newuser __         0.01 secs Thu Aug  8 12:39
ssh-agent         F    newuser __         0.02 secs Thu Aug  8 07:45

Dalla pagina man:

F - comando eseguito dopo un fork ma senza un seguente exec

Non sono sicuro che sia significativo.

Hai detto che il tuo utente sta effettuando sshl'accesso, non accedendo localmente. Quindi use-ssh-agentin /etc/X11/Xsession.optionsè un'aringa rossa: non verrà eseguita su sessioni SSH, solo quando si accede a un desktop della GUI X11 localmente (o usando alcune sessioni X11 virtuali come su VNC o RDP).

Invece, è necessario verificare se libpam-sshè installato su entrambi i sistemi. Può essere configurato per autenticare un utente utilizzando passphrase di chiave privata SSH, ma questo è facoltativo e ~/.ssh/login-keys.d/per tale funzionalità è necessario posizionare specificamente la chiave .

L'altra sua caratteristica, tuttavia, è quella di avviare automaticamente un agente SSH in qualsiasi sessione di accesso e aggiungere automaticamente le chiavi private SSH all'agente se la loro passphrase è la stessa della password di accesso dell'utente. Sto pensando che questa potrebbe essere la causa del diverso comportamento tra i tuoi sistemi.

Per il

$ eval `ssh-agent -s`

costruire per funzionare quando inserito in uno "script di avvio", la sessione e, in definitiva, il terminale in cui ci si aspetta l'ambiente, devono essere discendenti (da forke exec) di quello script. Il motivo è che l'output di ssh-agent -s, quando valutato, imposta le variabili di ambiente nella chiamata della shelleval . Da lì, possono essere tramandati e potrebbero anche essere persi lungo la strada.

Quindi, se ssh-agentviene eseguito dallo script A da qualche parte durante l'accesso, ma il terminale B in cui si avvia lo script della shell non è un discendente di A, non è possibile vedere l'ambiente in B.

Se ti capita di essere ssh-agentavviato come systemd --userservizio, potrebbe essere necessario utilizzare invece la convenzione: non consentire di ssh-agent specificare le variabili, ma utilizzare le conoscenze comuni all'avvio dell'agente e all'avvio della sessione. Ad esempio, il mio ~/.config/systemd/user/ssh-agent.serviceassomiglia a questo:

[Unit]
Description=SSH agent

[Service]
Type=simple
Environment=SSH_AUTH_SOCK=%t/ssh-agent.socket
ExecStart=/usr/bin/ssh-agent -D -a $SSH_AUTH_SOCK

[Install]
WantedBy=default.target

E nel mio ~/.profileho la linea

export SSH_AUTH_SOCK="${XDG_RUNTIME_DIR}/ssh-agent.socket"

Si noti che %tnel primo corrisponde a ${XDG_RUNTIME_DIR}nel secondo.

Nota: non sono contento di questo!

Ho trovato la risposta qui:

http://www.bernatchez.net/userauth.html

Su Ubuntu l'utility ssh-add non riesce a caricare i file di certificato. Si verifica quando l'agente è quello implementato da gnome-keyring. La soluzione è smettere di usare il componente ssh di gnome-keyring. Dato che il processo di inizializzazione avvia effettivamente un vero ssh-agent e quindi avvia gnome-keyring-ssh.desktop che blocca AUTH_SOCKET per sostituirlo, possiamo ripristinare lo ssh-agent originale disabilitando gnome-keyring-ssh.desktop.

Disabilita gnome-keyring-ssh.desktop:

cd /etc/xdg/autostart/
sudo emacs gnome-keyring-ssh.desktop

Aggiungi la seguente riga al file desktop e salvalo, quindi riavvia:

X-GNOME-Autostart-enabled=false

L'hai detto tu

$ eval `ssh-agent -s`
$ ssh-add ~/.ssh/some_id_rsa

funziona come desiderato. Quindi hai solo bisogno di quelli da eseguire al momento giusto, in .bash_profile o .xsession. Aggiungi istruzioni di debug come (date; env|sort) >> /tmp/logper aiutarti a capire esattamente quando vengono eseguite.