2012-11-29 14 views
10

Ho configurato Ubuntu Linux per eseguire un server OpenSSH. Il mio router DSL sta effettuando il port forwarding della connessione SSH. Quando usoIl client OpenSSH si blocca durante il logout durante l'inoltro delle connessioni X

ssh -X myhost 

e quindi aprire un certo programma GUI, quindi chiudere l'applicazione GUI e l'uscita, poi si blocca SSH logout. <Ctrl>-c sembra funzionare ma è fastidioso doverlo premere ogni volta. Il logout non si bloccherà se non apro una GUI.

Qualcuno ha idee su come risolvere questo problema?

+0

Fare 'ssh -vX myhost' per ottenere alcune informazioni durante il login/logout. Hth. –

+0

Viene lanciato 'DBus'? Quello stava causando il problema per me. Per ragioni sconosciute, non sarebbe terminato quando stavo cercando di disconnettermi. –

risposta

12

Questo perché il processo che si avvia apre uno stream (stdout/stderr) e non lo chiude. Date un'occhiata a here per una spiegazione più approfondita e possibili soluzioni.

+1

Molto probabilmente questo è essenzialmente lo stesso meccanismo di riferimento nel tuo collegamento, tuttavia potrebbe non essere stdout/stderr, ma una connessione X inoltrata, poiché OP sta usando 'ssh -X'. Se c'è ancora una connessione * * aperta su quel tunnel ssh, ssh rimarrà aperto. Mi sono imbattuto in questo durante l'accesso a un sistema e l'avvio di uno strumento/app di Gnome/KDE che avvia alcuni dei daemon/servizi, che non necessariamente vanno via quando l'applicazione stessa ... – twalberg

+0

Grazie per la spiegazione e il link. Probabilmente non volevo sentire questa risposta perché non c'è una soluzione rapida, ma almeno so cosa sta succedendo :) – admiles

+0

@admiles In effetti, c'è un modo semplice. Vedi la mia risposta qui sotto. – Sigi

5

So che questa è una vecchia domanda ma ho avuto lo stesso problema e dopo aver fatto qualche ricerca ho trovato una soluzione utile. Ora chiudo le connessioni SSH con ~. "termina la connessione (e qualsiasi sessione multiplexata)" e questo funziona per me. Il carattere di escape deve essere digitato su una nuova riga e nel mio caso il carattere di escape non viene visualizzato sullo schermo (ho finito per sfuggire al carattere di escape, ovvero ~~). Per vostra informazione è possibile visualizzare le connessioni inoltrate dalla sessione SSH con ~#.

Per un elenco completo di sequenze di escape digitare ~? nella sessione SSH.

sequenze supportati escape:

  • ~. - chiudere la connessione (ed eventuali sessioni multiplati)
  • ~B - invia un'interruzione al sistema remoto
  • ~C - aprire una linea di comando
  • ~R - Richiesta rekey (solo protocollo SSH 2)
  • ~^Z - sospensione ssh
  • ~# - Lista inoltrato connessioni
  • ~& - sfondo SSH (quando in attesa di connessioni a terminare)
  • ~? - questo messaggio
  • ~~ - inviare il carattere di escape digitando due volte

(Nota le fughe vengono riconosciute immediatamente dopo la fine riga.)

+0

Questa funzione è abilitata per impostazione predefinita in qualsiasi versione del client OpenSSH che abbia mai usato. –

+0

L'ho appena ricomposto. È il default anche per il mio, nella mia confusione sul carattere di escape che non viene visualizzato ho pensato che avesse a che fare con il file di configurazione. Il file di configurazione è un modo per cambiare i valori predefiniti. Grazie per la risposta. –

+0

Puoi spiegare di più su come farlo? Lo stdin viene reindirizzato alla shell remota, giusto? –

1

È possibile inviare SSH allo sfondo automaticamente dopo avviare l'applicazione GUI remota:

ssh -X -f remote.host.name 'name_of_gui_application' 

Questo richiederà ancora una password, quindi eseguire l'applicazione e mettere immediatamente SSH sullo sfondo.

Reindirizzerà anche STDIN da /dev/null, quindi la sessione non si "bloccherà" dopo aver chiuso l'applicazione (non che si possa sapere, poiché è comunque in esecuzione sullo sfondo).

Ecco ciò che la pagina di manuale di SSH ha da dire su questo:

Il metodo consigliato per avviare i programmi X11 in un sito remoto è con qualcosa di simile ssh -f host xterm.

+1

Questo non risolve il problema, semplicemente lo nasconde - lasciando un processo di riserva e una connessione SSH che giace senza fare nulla di utile (e di essere alquanto segreti, per l'avvio). –

+0

Cosa fa anche 'ssh -f host xterm', senza l'inoltro X? Sono sorpreso che questo sia nel manuale SSH. E Daniel ha ragione, questo nasconde solo il problema. –

Problemi correlati