Perché l'inoltro dell'agente ssh non funziona?

58

Nel mio computer, con MacOSX, ho questo in ~ / .ssh / config

Host *
ForwardAgent yes
Host b1
ForwardAgent yes

b1 è una macchina virtuale che esegue Ubuntu 12.04. Lo ssh in questo modo:

ssh pupeno@b1

e accedo senza che mi venga chiesta una password perché ho già copiato la mia chiave pubblica. A causa dell'inoltro, dovrei essere in grado di inviare a pupeno @ b1 da b1 e dovrebbe funzionare, senza chiedermi una password, ma non funziona. Mi chiede una password.

Cosa mi sto perdendo?

Questo è l'output dettagliato del secondo ssh:

pupeno@b1:~$ ssh -v pupeno@b1
OpenSSH_5.9p1 Debian-5ubuntu1, OpenSSL 1.0.1 14 Mar 2012
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to b1 [127.0.1.1] port 22.
debug1: Connection established.
debug1: identity file /home/pupeno/.ssh/id_rsa type -1
debug1: identity file /home/pupeno/.ssh/id_rsa-cert type -1
debug1: identity file /home/pupeno/.ssh/id_dsa type -1
debug1: identity file /home/pupeno/.ssh/id_dsa-cert type -1
debug1: identity file /home/pupeno/.ssh/id_ecdsa type -1
debug1: identity file /home/pupeno/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9p1 Debian-5ubuntu1
debug1: match: OpenSSH_5.9p1 Debian-5ubuntu1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.9p1 Debian-5ubuntu1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA 35:c0:7f:24:43:06:df:a0:bc:a7:34:4b:da:ff:66:eb
debug1: Host 'b1' is known and matches the ECDSA host key.
debug1: Found key in /home/pupeno/.ssh/known_hosts:1
debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /home/pupeno/.ssh/id_rsa
debug1: Trying private key: /home/pupeno/.ssh/id_dsa
debug1: Trying private key: /home/pupeno/.ssh/id_ecdsa
debug1: Next authentication method: password
pupeno@b1's password:

— pupeno
fonte

94

Si scopre che la mia chiave non era nell'agente e questo l'ha risolto:

OS X :

ssh-add -K

Linux / Unix :

ssh-add -k

Puoi elencare le chiavi caricate usando:

ssh-add -l

ssh-add -L # for more detail

— pupeno
fonte

5

Nota che ssh-add -Kè specifico per OS X.

— Roger Lipscombe

Devi farlo ad ogni riavvio?

— Krauser,

8

Controlla se i tuoi ./ssh/id_rsa .ssh/id_dsa .ssh/id_ecdsafile hanno le autorizzazioni corrette che dovrebbero essere di proprietà del tuo utente e avere un codice 600.
Controlla di avere la chiave pubblica corretta pupeno/.ssh/authorized_keyssu b1 e controlla se authorized_keysc'è un'interruzione di riga alla fine della chiave.
Controlla se hai ssh-agent in esecuzione, prova a caricare le chiavi tramite ssh-add
Prova l'autenticazione e l'inoltro basati su GSSAPI con ssh -K

— Daniel Prata Almeida
fonte

L'autorizzazione delle chiavi va bene e la chiave in authorized_keys va bene (altrimenti penso che avrei problemi a connettermi in primo luogo).

— pupeno,

Avevi ssh-agent in esecuzione? Cosa succede quando fai un ssh-add, poi ssh -A pupeno @ b1 e poi ssh pupeno @ b1?

— Daniel Prata Almeida,

Perché non aggiorni la risposta per menzionare ssh-add -K e accetterò la tua anziché la mia (poiché le informazioni sono state pubblicate quasi contemporaneamente).

— pupeno,

6

Ho avuto problemi con il server sshd che ha rifiutato la richiesta di inoltro dell'agente a causa della mancanza di spazio in / tmp. Questo perché sshd ha bisogno di creare socket in / tmp. La pulizia del disco ha risolto il mio problema.

ssh -v disse allora:

debug1: Remote: Agent forwarding disabled: mkdtemp() failed: No space left on device

— BartBiczBoży
fonte

1

Ho avuto lo stesso problema, solo le autorizzazioni erano / tmp errate. GRAZIE!!

— nevyn,

6

Un altro possibile motivo è la condivisione della connessione: uno potrebbe essere già connesso sull'altro host senza inoltro agente e condivisione della connessione abilitata. Il secondo accesso con ssh -A(o equivalentemente specificato nel file di configurazione) tramite la connessione condivisa ignorerà silenziosamente il -Aflag. Solo dopo la disconnessione completa o la disabilitazione della condivisione della connessione per il secondo accesso, l'inoltro dell'agente funzionerà.

— W.Mann
fonte

2

A beneficio di altri googler che sono arrivati anche a questa domanda:

Gli spazi bianchi errati in un file ~ / .ssh / config possono anche causare alcuni graffi alla testa.

Di recente ho aiutato uno dei miei collaboratori che aveva questo:

# incorrect
host foobar ForwardAgent yes

Invece di questo:

# correct
host foobar
  ForwardAgent yes

Ho anche incontrato casi in cui il rientro mancante delle direttive nell'elenco degli host ha fatto la differenza per la funzionalità, anche se non dovrebbe.

— Dale Anderson
fonte

0

Aggiungi le seguenti righe al file .ssh / config

  Host **Server_Address**
     ForwardAgent yes

Aggiungi chiave all'agente SSH

 ssh-add -K

Connetti al server remoto

ssh -v **username**@**Server_Address**

Esegui test di connessione su GitHub

ssh -T git@github.com

Esegui il test remoto sul repository git mirato

git ls-remote --heads git@github.com:**account**/**repo**.git

— Tahsin Turkoz
fonte