Come configurare un collegamento per una connessione SSH attraverso un tunnel SSH

I server di produzione della mia azienda (FOO, BAR ...) si trovano dietro due server gateway (A, B). Per connettermi al server FOO, devo aprire una connessione ssh con il server A o B con il mio nome utente JOHNDOE, quindi da A (o B) posso accedere a qualsiasi server di produzione aprendo una connessione SSH con un nome utente standard (chiamiamolo WEBBY).

Quindi, ogni volta che devo fare qualcosa del tipo:

ssh johndoe@a
...
ssh webby@foo
...
# now I can work on the server

Come puoi immaginare, questa è una seccatura quando devo usare scpo se devo aprire rapidamente più connessioni.

Ho configurato un tasto SSH e anche sto usando .ssh / config per alcune scorciatoie.

Mi chiedevo se posso creare un qualche tipo di configurazione ssh per scrivere

ssh foo

e lascia che SSH apra / inoltri tutte le connessioni per me. È possibile?

modificare

La risposta di womble è esattamente quello che stavo cercando, ma sembra che al momento non riesca a usare netcat perché non è installato sul server gateway.

weppos:~ weppos$ ssh foo -vv
OpenSSH_5.1p1, OpenSSL 0.9.7l 28 Sep 2006
debug1: Reading configuration data /Users/xyz/.ssh/config
debug1: Applying options for foo
debug1: Reading configuration data /etc/ssh_config
debug2: ssh_connect: needpriv 0
debug1: Executing proxy command: exec ssh a nc -w 3 foo 22
debug1: permanently_drop_suid: 501
debug1: identity file /Users/xyz/.ssh/identity type -1
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug2: key_type_from_name: unknown key type 'Proc-Type:'
debug2: key_type_from_name: unknown key type 'DEK-Info:'
debug2: key_type_from_name: unknown key type '-----END'
debug1: identity file /Users/xyz/.ssh/id_rsa type 1
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug2: key_type_from_name: unknown key type 'Proc-Type:'
debug2: key_type_from_name: unknown key type 'DEK-Info:'
debug2: key_type_from_name: unknown key type '-----END'
debug1: identity file /Users/xyz/.ssh/id_dsa type 2
bash: nc: command not found
ssh_exchange_identification: Connection closed by remote host

Come versione più concreta della risposta di Kyle, quello che vuoi mettere nel tuo ~/.ssh/configfile è:

host foo
  User webby
  ProxyCommand ssh a nc -w 3 %h %p

host a
  User johndoe

Quindi, quando si esegue "ssh foo", SSH tenterà di eseguire SSH johndoe@a, eseguire netcat( nc), quindi eseguire un SSH webby@fooattraverso questo tunnel. Magia!

Naturalmente, per fare ciò, netcat deve essere installato sul server gateway; questo pacchetto è disponibile per tutte le principali distribuzioni e sistemi operativi.

È possibile utilizzare la direttiva ProxyCommand nel file ~ / .ssh / config, ad esempio per utilizzare netcat come relay:

host server2
    ProxyCommand ssh server1 nc server2 22

Utilizzeresti semplicemente "ssh server2". Le informazioni sulla pagina man per questa direttiva si trovano in "man ssh_config"

Preferisco un approccio diverso che mantenga un tunnel pre-autenticato sul server gateway. In ~/.ssh/config:

Host a
    ControlMaster auto
    ControlPath ~/.ssh/control-master/%r@%h:%p

Quindi in .bashrc:

s () {
        if ( ssh -O check a 2>&1 > /dev/null 2>&1 )
        then
                ssh -t a ssh $1
        else
                if [[ -S ~/.ssh/control-master/insyte@a:22 ]]
                then
                        echo "Deleting stale socket..."
                        rm ~/.ssh/control-master/insyte@a:22
                fi
                echo "Opening master session..."
                if ssh -Nf a
                then
                         ssh -t a ssh $1
                fi
        fi
 }

Quindi per connettersi a pippo:

s foo

La prima volta che ti connetti ti autenticherà contro "a" e aprirà un tunnel ssh persistente e in background. Le chiamate successive a "s" si apriranno quasi istantaneamente attraverso il tunnel pre-autorizzato.

Funziona alla grande.

Questo tipo di funzionalità esiste nelle versioni più recenti di OpenSSH e può essere utilizzato facendo

ssh -W server2 server1

Dov'è server2la destinazione prevista ed server1è l'host proxy. Puoi semplificarlo usando l' ProxyCommandopzione nella tua configurazione ssh, qualcosa del tipo:

host = *.example.com
user = packs
port = 22
ProxyCommand ssh -W %h:%p server1

Quando netcatnon è disponibile sul proxy, prova questo trucco:

host foo
  User webby      
  ProxyCommand ssh a 'exec 3<>/dev/tcp/foo/22; cat <&3 & cat >&3;kill $!'

host a
  User johndoe

Quindi dovresti essere in grado di farlo ssh foo.

Inoltre, se hai una versione recente di ssh su un (cioè, con il -Wcomando per inoltrare input e output standard), potresti essere in grado di usare:

host foo
  User webby
  ProxyCommand ssh -W foo:%p a

host a
  User johndoe

Infine, proprio perché l'ho trovato interessante (e non perché funzionerà nel tuo caso particolare, a causa delle differenze di nome utente), il post sul blog di un amico sottolinea come rendere questo tipo di cose dinamiche e concatenare in modo ricorsivo i proxy SSH (insieme ad alcune cose che non funziona bene):

host */*
  ProxyCommand ssh ${$(dirname %h)/\%%/@} nc ${$(basename %h)#*%%} %p

E poi ssh machine1/machine2dovresti darti una granata machine2, attraversata da un tunnel machine1.

Mi chiedo se l'utilizzo di sedcomandi personalizzati anziché dirnamee basenamepotrebbe non risolvere il problema con nomi utente diversi?

Questo può essere realizzato facendo ssh -At johndoe@a ssh webby@foo. Il -Acomando inoltra il tuo agente ssh (in modo da poter evitare di dover eseguire nuovamente l'autenticazione sul proxy), mentre -tassicura che esista un terminale sul proxy. Potrebbe essere utile la seguente funzione bash:

ssh-bounce () {
    local cmd=""
    for i in "$@"; do
        cmd+="ssh -At $i "
    done
    $cmd
}

weppos:~ weppos$ ssh foo -vv
[..]
bash: nc: command not found

Netcat non è installato su a. Quando corri ssh host "command arg", commandviene eseguito su host, non sul tuo computer locale.

A partire da OpenSSH 7.3 (01-08-2016) l' ProxyJumpopzione e il corrispondente -Jflag della riga di comando sono disponibili per consentire una più semplice indiretta attraverso uno o più bastioni SSH o "jump host".

Ciò rimuove la dipendenza dal nccomando esterno come si trova nella soluzione di Womble .

ssh -J johndoe@a webby@foo 

stabilirà una connessione SSH dalla stazione di lavoro al server gateway acome utente johndoe e eseguirà il tunneling della sessione SSH per ospitare foo per l'utente Webby.

Per semplificare la creazione di definizioni host sia per te ~/.ssh/configche per te, puoi semplicemente eseguiressh foo

Host a
    User johndoe

Host foo
    User Webby 
    ProxyJump a