Come chiudere questo tunnel SSH? [chiuso]


96

Ho aperto un tunnel ssh come descritto in questo post: Zend_Db: come connettermi a un database MySQL tramite un tunnel SSH?

Ma ora non so cosa ho fatto veramente. Questo comando influisce su qualcosa sul server? E come chiudo questo tunnel, perché ora non posso usare correttamente il mio mysql locale.

Uso OSX Lion e il server funziona su Ubuntu 11.10.

Risposte:


241

Supponendo che tu abbia eseguito questo comando: ssh -f user@mysql-server.com -L 3306:mysql-server.com:3306 -N come descritto nel post che hai collegato.

Una ripartizione del comando:

  1. ssh: è abbastanza autoesplicativo. Invoca ssh.
  2. -f: (Dalla man sshpagina)

    Richiede a ssh di andare in background appena prima dell'esecuzione del comando. Questo è utile se ssh chiederà password o passphrase, ma l'utente lo desidera in background.

    In sostanza, invia sshin background dopo aver inserito le password per stabilire la connessione; ti restituisce il prompt della shell a localhostinvece di accedere a remote-host.

  3. user@mysql-server.com: il server remoto a cui desideri accedere.
  4. -L 3306:mysql-server.com:3306: Questa è la parte interessante. -L(dalla man sshpagina):

    [bind_address:] port: host: hostport Specifica che la porta specificata sull'host locale (client) deve essere inoltrata all'host specificato e alla porta sul lato remoto.

    Quindi -L 3306:mysql-server.com:3306associa la porta locale3306 alla porta remota 3306 sull'host mysql-server.com.

    Quando ci si connette alla porta locale3306 , la connessione viene inoltrata sul canale protetto a mysql-server.com. L' host remoto , mysql-server.comquindi si connette alla mysql-server.comporta 3306.

  5. -N: non eseguire un comando. Questo è utile per "solo inoltrare le porte" (citando la pagina man).

Questo comando influisce su qualcosa sul server?

Sì, stabilisce una connessione tra localhost e mysql-server.com sulla porta 3306 .

E come chiudo questo tunnel ...

Se lo hai utilizzato -f, noterai che il sshprocesso che hai aperto passa in background. Il metodo migliore per chiuderlo è eseguire ps aux | grep 3306, trovare pidi file ssh -f ... -L 3306:mysql-server.com:3306 -N, e kill <pid>. (O forse kill -9 <pid>, dimentico se killfunziona e basta ). Questo ha il bellissimo vantaggio di non uccidere tutte le tue altre sshconnessioni; se ne hai più di uno, ristabilirli può essere un leggero ... dolore.

... perché ora non posso usare correttamente il mio mysql locale.

Questo perché hai effettivamente "catturato" il processo locale mysql e inoltrato qualsiasi traffico che tenta di connettersi ad esso, al processo remoto mysql . Una soluzione molto migliore sarebbe quella di non utilizzare la porta locale 3306 nel port forward. Usa qualcosa che non sia usato, come 33060. (I numeri più alti sono generalmente meno usati; è abbastanza comune portare avanti una combinazione come questa: "2525-> 25", "8080-> 80", "33060-> 3306" o simile. Rende il ricordo leggermente più facile).

Quindi, se lo usassi ssh -f user@mysql-server.com -L 33060:mysql-server.com:3306 -N, dovresti puntare la tua funzione Zend connect-to-mysql su localhostsulla porta33060 , che si connetterebbe alla mysql-server.comporta 3306. Ovviamente puoi ancora connetterti alla localhostporta 3306, quindi puoi ancora utilizzare il mysqlserver locale .


5
La migliore spiegazione che ho letto da un po '. Ciò è molto utile quando si accede a un database remoto da ambienti installati localmente come R. ad esempio. Funziona bene con l'autenticazione con chiave pubblica / privata. Non con le password perché non ho trovato un modo per passare le password.
Matt Bannert

Accettare questa risposta nel migliore dei modi grazie alla spiegazione approfondita.
Jacob,

Bella risposta! A proposito, -9non è necessario kill, considerando che il processo funziona ancora bene ;-)
Lucio Paiva

46

Questo ucciderà tutte le sessioni ssh che hai aperto dal terminale.

sudo killall ssh

"Non sono stati trovati processi di abbinamento" dice.
Jacob il

Sembra che lo sia. Anche Mysql ha funzionato bene, ma poi Apache ha iniziato a lamentarsi. Ho fatto un riavvio e tutto funziona come previsto. Problema risolto immagino :)
Jacob il

5
Beh, non vuoi farlo se si tratta di un ambiente prod ...
eliminerai

12
La corsa killall sshè un comando piuttosto sconsiderato. Consiglio di cercare nell'elenco dei processi (ad esempio, ps aux | grep sshcome suggerito da @simont sopra) per scoprire l'ID di processo specifico del processo del tunnel ssh. Quindi puoi uccidere pid in modo specifico.
Ben

Ci sono buone probabilità che tu non voglia ucciderli tutti.
wobbily_col

22

Nota: aggiunta come risposta poiché i commenti non supportano i blocchi di codice.

A mio parere è meglio NON usare -fe invece solo mettere in background il processo come di consueto con &. Questo ti darà il pid esatto che devi uccidere:

ssh -N -L1234:other:1234 server &
pid=$!
echo "waiting a few seconds to establish tunnel..."
sleep 5
... do yer stuff... launch mysql workbench whatever
echo "killing ssh tunnel $pid"
kill $pid

O meglio ancora, crealo come script wrapper:

# backend-tunnel <your cmd line, possibly 'bash'>
ssh -N -L1234:other:1234 server &
pid=$!
echo "waiting a few seconds to establish tunnel..."
sleep 5
"$@"
echo "killing ssh tunnel $pid"
kill $pid

backend-tunnel mysql-workbench

backend-tunnel bash


12
L'uso -fconsente alla sshsessione di continuare anche quando la sessione del terminale è chiusa, a differenza del passaggio in background. Afferrare l' pidutilizzo ps aux | grep ssh | grep <LOCAL-PORT>è piuttosto banale.
simont

1
@simont utilizzando il pid esplicito restituito dal lavoro in background è più sicuro, indipendentemente da come lo si fa in background. se hai più di un processo ssh in esecuzione , passerai un brutto momento
aaron

L'utilizzo -fha anche il vantaggio di richiedere all'utente locale la password di accesso, se necessario. Se si utilizza &, tale prompt non viene visto dall'utente a meno che non porti il ​​processo in primo piano (ad esempio utilizzando fg).
Bdoserror


3
la prima volta che il tuo <LOCAL-PORT> si verifica nel pid di un processo che contiene anche il testo 'ssh' (come un altro processo ssh o sshd o la modifica di un file con 'ssh' nel nome) ti renderai conto che questo l'approccio, sebbene conveniente in scenari semplici, non è a prova di proiettile
Aaron
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.