C'è una domanda molto simile che se la risposta potrebbe essere stata la risposta a questa domanda. Sfortunatamente si tratta di "non è necessario rispondere alla domanda che ho posto perché il problema non era quello che pensavo fosse".

Il set up

1. Il server bastion.ec2 accetta una connessione ssh dalla mia workstation tramitessh -i mykey.pem myname@bastion.ec2
2. Il server service1.ec2 accetta connessioni ssh solo da bastion.ec2 tramitessh -i sharedkey.pem shareduser@service1.ec2

I requisiti

1. Entrambe le chiavi sono solo sulla mia workstation, quindi non posso effettivamente eseguire il secondo comando senza copiarle
2. Per motivi di sicurezza, voglio usare l'inoltro di ssh-agent piuttosto che copiare le chiavi ssh su bastion.ec2

La soluzione

È qui che entri. Come posso inoltrare una chiave diversa per la seconda connessione?

Se shareduser avesse mykey.pub in esso ~/.ssh/authorized_keysfunzionerebbe:

ssh -i mykey.pem myname@bastion.ec2 ssh shareduser@service1.ec2

Tuttavia, non voglio che tutti gli utenti debbano inserire la propria chiave pubblica in ogni server.

Passo 1

Assicurati che il tuo agente locale sia pronto

Solo perché puoi ssh nel tuo server bastione senza specificare il percorso della chiave o ottenere la password, non significa che il tuo agente ssh sia in esecuzione e tieni la chiave. Alcuni sistemi operativi moderni (ad esempio: OSX) gestiscono questo per te.

Sul tuo computer locale

$ ssh-add -L
ssh-rsa ObahfCbvagGbLbhSbeHfvatEBG13== ~/.ssh/mykey.pem
ssh-rsa LbhNerWhfgJnnlGbbPyrireEBG13== ~/.ssh/sharedkey.pem

^{Fig. 1}

Ciò significa che il tuo agente è in esecuzione e ha la tua chiave.

$ ssh-add -L
The agent has no identities.

^fig.2

Ciò significa che non hai aggiunto alcuna chiave al tuo agente. Risolvilo con:

ssh-add ~/.ssh/mykey.pem ~/.ssh/sharedkey.pem

^fig.3

Passo 2

Assicurati che il tuo agente remoto sia pronto

SSH nel tuo server bastione e ripetere il controllo da fig.1 e fig.2 . Tuttavia, l'errore che è più probabile che si verifichi è questo:

$ ssh-add -L
Could not open a connection to your authentication agent.

^fig.4

Ciò molto probabilmente significa che il client SSH non sta inoltrando la connessione dell'agente di autenticazione.

Puoi forzarlo con il -Aflag (purché lo permetta la configurazione sshd sul server, che è l'impostazione predefinita ).

$ ssh -A bastion.ec2

^fig.5

Passaggio 3

Assicurati di utilizzare i tasti giusti

Se sono state aggiunte chiavi all'agente, l'agente sta inoltrando e l'agente remoto elenca le chiavi locali. Esistono solo due probabili motivi per cui non si ottiene una connessione. O non stai usando la chiave giusta o non stai usando il nome utente giusto.

Invia la controparte pubblica alla tua chiave privata:

$ cd
$ cd .ssh
$ ssh-keygen -y -f mykey.pem
ssh-rsa ObahfCbvagGbLbhSbeHfvatEBG13
$ ssh-keygen -y -f sharedkey.pem
ssh-rsa LbhNerWhfgJnnlGbbPyrireEBG13

^fig.6

Questi dovrebbero essere gli stessi di quello che stavi vedendo ssh-add -Lfino alla ==fine.

Ora in un modo o nell'altro devi entrare nella casella a cui non riesci a connetterti e guardare il contenuto del $HOME/.ssh/authorized_keysfile per l'utente a cui stai tentando di connetterti. È necessario assicurarsi che la chiave pubblica emessa con il comando sopra sia in quel file su una riga da sola. Non puoi fidarti del fatto sharedkey.pubche i cubi Bro 2 ti hanno inviato per email è giusto. Verificare! Questo potrebbe richiedere a qualcun altro che può accedere a SSH come tale utente per ottenere il file authorized_keys o ottenere l'accesso come root. Se sei arrivato così lontano e continua a non funzionare, non stai prendendo scorciatoie.

Passaggio 4

Rendere più facile

Si spera che i passaggi precedenti ti abbiano fatto entrare. Ora facciamo in modo che questo mal di testa scompaia fintanto che stai usando questa workstation.

Configura il tuo client ssh locale

Host *
    # A lot of people put an IdentityFile line in this Host * section.
    # Don't do that unless you will use only 1 key everywhere forever.
    #IdentityFile id_rsa

Host bastion.ec2
    # You want to make sure you always forward your agent to this host.
    # But don't forward to untrusted hosts. So don't put it in Host *
    ForwardAgent yes
    # Go a head and put the IP here in case DNS ever fails you.
    # Comment it out if you want. Having it recorded is a good backup.
    HostName 172.31.0.1
    # You don't want to create a proxy loop later, so be explicit here.
    ProxyCommand none
    # SSH should try using all keys in your .ssh folder, but if you
    # know you want this key, being explicit speeds authentication.
    IdentityFile ~/.ssh/mykey.pem

# Connect effortlessly by hostname or IP address
# This assumes that your internal DNS uses the fake TLD ec2
# This assumes that 172.31.0.0 is your C-Class subnet
Host *.ec2 172.31.*
    # This command says proxy all ssh connections through bastion as if
    # you had done an ssh -A
    ProxyCommand ssh -W %h:%p bastion.ec2
    ForwardAgent yes
    # These next lines are documentation you leave as a love letter to
    # your future self when all else fails or you have to help a
    # coworker and decide to look at your own config.
    # ssh-add ~/.ssh/*.pem
    # ssh -At bastion.ecs ssh admin@172.31.18.19

^fig.7

Se non togli niente altro dalla fig.7 , dovrebbe essere l'uso corretto di ProxyCommand& ForwardAgent.

Popolare automaticamente il tuo .bash_profile

Non devi fare ssh-addmanualmente ogni volta che accedi al tuo computer. ~/.bash_profileè uno script che viene eseguito ogni volta che accedi **. Metti la linea dalla fig. 3 lì dentro e dovresti sempre avere il tuo agente pronto.

** Non confondere questo con .bashrcquale viene eseguito per ogni nuovo terminale [interattivo]. Il tuo agente continua a funzionare anche se chiudi tutte le sessioni del terminale. Non è necessario ricaricare le chiavi

Alternativa all'utilizzo di .bash_profile

Ho anche creato una sintesi che aggiunge un OSX / macOS Launch Agent . È possibile utilizzare questo metodo per avviare l' ssh-agentavvio. È molto facile da installare:

curl -sSL https://gist.github.com/RichardBronosky/429a8fff2687a16959294bcee336dd2a/raw/install.sh | bash

È qui che entri. Come posso inoltrare una chiave diversa per la seconda connessione?

Non inoltrare le chiavi. Inoltra l'agente e può disporre di chiavi completamente indipendenti rispetto a quelle utilizzate per l'autenticazione nel primo salto. Controlla le chiavi nel tuo agente usando ssh-add -L.

Ma ancora meglio, eseguire la connessione ProxyCommand ssh -W %h:%p myname@bastion.ec2, che eviterà la necessità di inoltrare l'agente, l'heap o le opzioni della riga di comando e la necessità di autenticarsi dall'host immediato.

Puoi semplicemente inserirlo nella tua configurazione (vedi man ssh_config).