Utilizzo della direttiva IdentityFile in ssh_config quando AgentForwarding è in uso

È possibile specificare le chiavi inoltrate utilizzando la direttiva IdentityFile in .ssh / config?

Mi sono imbattuto in questa stranezza nel tentativo di distribuire un codice tramite Capistrano / GIT sul nostro server di produzione. Le chiavi GIT personali e personali sono sempre caricate nel mio agente SSH ed è successo che la mia chiave personale è stata aggiunta per prima all'agente. Uso l'inoltro dell'agente durante la distribuzione con Capistrano, quindi quando l'host ha provato ad autenticare l'operazione `git pull` non è riuscito con il seguente errore:

ERRORE: autorizzazione a `alcuni repo` negata a` il tuo utente`.

perché ha tentato di autenticarsi usando la mia chiave git personale prima di provare la chiave appropriata (che è arrivata più tardi nell'agente ssh) e ha ipotizzato che stavo accedendo a un repository esterno a cui non ho il permesso di accedere. Posso potenzialmente consentire al mio utente personale di accedere a tutti i repository di lavoro, ma sul mio computer locale posso aggirare questo problema definendo i domini personalizzati in .ssh / config in questo modo:

Host personal.github.com
Nome host github.com
User git
IdentityFile ~ / .ssh / some_key

Host work.github.com
Nome host github.com
User git
IdentityFile ~ / .ssh / some_other_key

e in questo modo git non viene mai confuso. È possibile creare regole .ssh / config per le chiavi inoltrate sulle mie caselle di produzione in modo che sappiano sempre quale chiave usare quando si inserisce un nuovo codice? Fondamentalmente voglio essere in grado di fare:

Host work.github.com
Nome host github.com
User git
IdentityFile some_forwarded_key

Grazie!

— Skryl
fonte

È possibile utilizzare la parte pubblica di una chiave per specificare quale chiave privata si desidera utilizzare dall'agente inoltrato. Ciò richiede la creazione di un file aggiuntivo (la parte pubblica della chiave) su qualsiasi macchina "intermedia" (macchine a cui si inoltra l' agente ssh locale ).

Disporre che la macchina intermedia abbia una copia della parte pubblica della chiave desiderata in una posizione comoda (ad es ~/.ssh/some_other_key.pub.).

Da qualsiasi macchina che ha già la parte pubblica della chiave:
```
scp some_other_key.pub intermediate:.ssh/
```
oppure, sulla macchina intermedia:
```
ssh-add -L | grep something_unique > ~/.ssh/some_other_key.pub
```
Potresti voler modificare la parte "comment" finale della chiave pubblica per identificare meglio l'origine / il proprietario / lo scopo della chiave (o tentare di nascondere la stessa).
Utilizzare il nome percorso per il file di chiave pubblica sopra con -io IdentityFile.
Potrebbe anche essere necessario utilizzare IdentitiesOnly yes(in .ssh/configo -o) per impedire a ssh di provare a offrire eventuali identità aggiuntive dal proprio agente inoltrato.

— Chris Johnsen
fonte

Questa è l'unica cosa che ha funzionato per me da altre 10 soluzioni.

— Tracy Fu,

Giocando con questo mi sono reso conto che se metti la chiave pubblica associata alla chiave privata che desideri utilizzare in ~ / .ssh / id_rsa.pub sul computer intermedio, verrà utilizzata per impostazione predefinita, non è necessaria alcuna configurazione in ~ / .ssh / config.

— bschlueter,

Grazie Chris e bschlueter! Ora mi collego a: ssh someserver -t "ssh-add -L | grep qualcosa_unico> ~ / .ssh / id_rsa.pub; cd some / other / folder; bash --login"

— blablabla

Quando provo questo con ssh -v -T ...il server accetta la chiave pubblica, ma poi dice ssh No such identity: /home/name/.ssh/id_rsa: No such file or directorye successivamente l'autenticazione fallisce. Ho ForwardAgent abilitato in tutte le mie configurazioni. Quale potrebbe essere il problema?

— Lars Nyström,