Ho avuto difficoltà a impostare una configurazione valida per aprire una connessione con una seconda macchina, passandone un'altra e utilizzando un id_rsa (che mi richiede una password) per connettersi alla terza macchina.

Ho fatto questa domanda in un altro forum, ma non ho ricevuto alcuna risposta che potrebbe essere considerata molto utile.

Il problema, meglio descritto, è il seguente:

Local machine: user1@localhost
Intermediary machine: user1@inter
Remote target: user2@final

Sono in grado di fare l'intera connessione usando pseudo-tty:

ssh -t inter ssh user2@final

(questo mi chiederà la password per il file id_rsa che ho nella macchina "inter")

Tuttavia, per accelerare le cose, mi piacerebbe impostare il mio file .ssh / config, in modo da poter semplicemente connettermi alla macchina "final" usando:

ssh final

Quello che ho finora - che non funziona - è, nel mio file .ssh / config:

Host inter
    User user1
    HostName inter.com
    IdentityFile ~/.ssh/id_rsa

Host final
    User user2
    HostName final.com
    IdentityFile ~/.ssh/id_rsa_2
    ProxyCommand ssh inter nc %h %p

Il file id_rsa viene utilizzato per connettersi alla macchina centrale (ciò non richiede la digitazione della password) e il file id_rsa_2 viene utilizzato per connettersi alla macchina "final" (questo richiede una password).

Ho provato a mescolare alcuni LocalForwarde / o RemoteForwardcampi e a inserire i file id_rsa sia nella prima che nella seconda macchina, ma non sono riuscito a riuscirci senza alcuna configurazione.

PS: il thread che ho cercato di ottenere un aiuto da:

http://www.linuxquestions.org/questions/linux-general-1/proxycommand-on-ssh-config-file-4175433750/

— Rubens
fonte

METODO 1 (utilizzare il tasto ssh sull'inter)

Se si desidera conservare il flusso di autenticazione

local -- authenticate --> inter -- authenticate (ask password) --> final

Questo non può essere fatto con .ssh / config proxyhost.

Quello di cui hai bisogno è bash shell alias (spero che tu stia usando bash).

In ~/.bashrc, aggiungi la seguente riga

alias ssh-final='ssh -t inter ssh user2@final.com'

Nel prompt dei comandi, basta digitare quanto segue

ssh-final

finalla sezione in ~/.ssh/confignon è utilizzata.

Dettagli connessione (1)

ssh -t inter ssh user2@final.com può essere visualizzato come segue

local# ssh inter
inter# ssh user2@final.com

localsta solo "parlando" inter. Non esiste una connessione ssh diretta o indiretta tra locale final. localsta solo visualizzando l'output di ssh user2@final.com.

METODO 2 (utilizzare il tasto ssh sul locale)

Autenticazione con la stessa chiave ssh

Host inter
    User user1
    HostName inter.example.com

Host final
    User user2
    Hostname <final.com / final IP Address>
    Port 22
    ForwardAgent yes
    ProxyCommand ssh inter nc %h %p

Copia locale ~/.ssh/id_ras.pub in

/home/user1/.ssh/authorized_keys in `inter`
/home/user2/.ssh/authorized_keys in `final`

Dettagli connessione (2)

tunneling ssh

Prima di entrare nel dettaglio di ProxyCommand, diamo un'occhiata al seguente esempio

Passaggio 1, sulla finestra del terminale 1

local# ssh inter -L 2000:final.com:22

Passaggio 2, sulla finestra del terminale 2

local# ssh localhost -p 2000

Nel terminale 1, viene installato un tunnel tra la porta locale 2000 e la porta 22 di final.com. Qualsiasi cosa inviata alla porta locale 2000 verrà inoltrata alla porta 22 di final.com e viceversa.

Nel terminale 2, ssh si collega alla porta locale 2000, ma in realtà sta comunicando con la porta 22 di final.com, che è la sshd.

Con il tunneling, il client ssh locale nel passaggio 2 è collegato direttamente a sshd final.com.

L '"output" della porta locale 2000 è il traffico demone ssh "raw".

L'uso comune di tale tunnel è l'accesso al server Web interno o al server di posta elettronica. Di seguito è riportato un esempio per il server Web

local# ssh inter -L 2000:final.com:80

Nel browser utilizzare il seguente URL

http://localhost:2000

I due punti finali del tunnel sono la porta locale 2000 e la porta 80 di final.com.

Traffico in entrata e in uscita dal punto finale del tunnel "COSÌ COM'È". Chiamiamo quel traffico "grezzo".

ProxyCommand

Host final
    User user2
    Hostname <final.com / final IP Address>
    Port 22
    ForwardAgent yes
    ProxyCommand ssh inter nc %h %p

Il ProxyCommandprendono un ulteriore passo avanti. Salta il passaggio per creare una porta locale e connettersi ad essa.

Un client ssh eseguirà qualsiasi comando dato dietro ProxyCommande tratterà l'output di quel comando come traffico "grezzo". Sta trattenendo il punto finale locale e quindi avvia una connessione ssh con esso.

Perché uno lavora l'altro no?

Il seguente comando

ssh inter nc final.com 22

sostanzialmente significa (1) connettersi a inter, quindi (2) su inter, eseguire il comando nc final.com 22.

nc - arbitrary TCP and UDP connections and listens

Quindi nc final.com 22si collegherà alla porta 22 di final.com, stampa tutto il traffico in arrivo su stdout e invia tutto lo stdin dall'altra parte. È un "tunnel" tra nc stdin / out e la porta 22 di final.com.

Poiché ncviene eseguito all'interno della sessione ssh, tutto il suo stdout viene restituito al client ssh, come traffico "non elaborato". E il client ssh può trasferire il traffico in nc stdin, che finirà sulla porta 22 di final.com.

Attraverso il "tunnel" sopra, il client ssh locale avvierà direttamente una sessione ssh final.com.

Il seguente comando

ssh -t inter ssh user2@final.com

non funziona ProxyCommandperché il suo out non è traffico " non elaborato " da un demone ssh. È lo stdout di un client ssh . Parlare con un cliente significa niente affari.

Autenticazione con chiave ssh diversa (configurazione originale OP)

Host inter
    User user1
    HostName inter.com
    IdentityFile ~/.ssh/id_rsa

Host final
    User user2
    HostName final.com
    IdentityFile ~/.ssh/id_rsa_2
    ProxyCommand ssh inter nc %h %p

Copia locale ~/.ssh/id_ras.pub in

/home/user1/.ssh/authorized_keys in `inter`

Copia locale ~/.ssh/id_ras_2.pub in

/home/user2/.ssh/authorized_keys in `final`

Entrambi i precedenti consentiranno il seguente utilizzo

local# ssh final

Controllo aggiuntivo

Usa verboso

local# ssh -v final

Ciò dovrebbe aiutare a identificare il problema ssh.

Controlla nc

ProxcyCommandè in esecuzione ncsu inter. Controlla se ncè effettivamente disponibile su inter.

local# ssh inter
inter# nc final.com 22

Verificare che la chiave rsa sia impostata correttamente

Se si devono usare chiavi diverse per intere final, dovrebbero esistere i seguenti file nel computer locale

local# ls ~/.ssh
id_rsa id_rsa_2 id_rsa.pub id_rsa_2.pub

Dal momento che puoi intergià fare ssh , controlla l'impostazione della chiave su final. Dalla tua macchina locale

local# ssh -t inter ssh user2@final
final# cat .ssh/authorized_keys

Dovresti vedere il contenuto di id_rsa_2.publì.

— John Siu
fonte

Mi dispiace, avrei dovuto precisarlo; Sono effettivamente in grado di connettermi usando ssh -t, ma quello che mi piacerebbe fare è simulare esattamente il comportamento che ho usando ssh -tusando solo la configurazione sul .ssh/config.

— Rubens,

Il file di configurazione, anche quello che pubblichi, dovrebbe funzionare. Prova a seguire il checkingpassaggio. Deve esserci qualcosa che manca / che non va.

— John Siu,

Con ssh -t, finalinizia il tuo ssh a inter, che è "quasi" lo stesso di local# ssh interallora inter# ssh final. L'autenticazione è tra intere final. Con proxy / nc, il tuo ssh to final viene avviato dal tuo computer locale, attraverso un tunnel, a final. L'autenticazione è tra locale final.

— John Siu,

@Rubens si basa sul tuo commento, penso che ti sbagli che stai ancora usando interssh-key per autenticarti final. Prova a copiarlo id_rsa_2in local~ / .ssh / id_rsa_2 (NON SUPERARE SCRIVERE id_rsa locale) e il tuo problema potrebbe essere risolto.

— John Siu,

Nota che ssh2 è ncintegrato. Quindi invece di ProxyCommand ssh gateway nc %h %pscrivere ProxyCommand ssh inter -W %h:%p.

— user123444555621

In realtà non ho visto alcun errore elencato o istruzioni ssh -v che potrebbero aiutare a vedere dove si sta riattaccando.

Ehi amico, hai quasi ragione --- il modo migliore e più sicuro è avere entrambe le chiavi sul computer locale. Dovresti quindi usare l'inoltro di ssh-agent per connetterti piuttosto che lasciare le chiavi a passi intermedi. Hai anche il vantaggio di dover digitare la passphrase della chiave una sola volta per accesso.

Se disponi di un sistema operativo moderno / intuitivo come Ubuntu (sul tuo computer locale), questo non dovrebbe funzionare senza problemi * senza * massaggiare *. Ho lasciato intenzionalmente il file di identità, non ne avrai bisogno.

Il tuo file di configurazione sarebbe simile al seguente:

Host inter
    User user1
    ForwardAgent yes
    HostName inter.com

Host final
    ForwardAgent yes
    User user2
    HostName final.com
    ProxyCommand ssh inter nc %h %p

In caso contrario, eseguire questi passaggi per assicurarsi che ssh-agent sia in esecuzione:

'ssh-add -l' (lower case L) will list your private keys if any are loaded, or will be blank, or will say can’t connect to ssh-agent, if so, start ssh-agent.
'eval `ssh-agent`' (those are backticks) starts ssh agent
'ssh-add' will add your key… you can add a path argument if you have a key in a non-default area. At this point you will enter your passphrase.

C'è una bella guida che spiega come funziona, qui.

— MattPark
fonte

Impostazione del file di configurazione ssh con id_rsa tramite tunnel

METODO 1 (utilizzare il tasto ssh sull'inter)

Dettagli connessione (1)

METODO 2 (utilizzare il tasto ssh sul locale)

Autenticazione con la stessa chiave ssh

Dettagli connessione (2)

Autenticazione con chiave ssh diversa (configurazione originale OP)

Controllo aggiuntivo

Usa verboso

Controlla nc

Verificare che la chiave rsa sia impostata correttamente