SSH-Befehlsausführung hängt, obwohl die interaktive Shell funktioniert

Wenn ich versuche, führen Sie einen Befehl auf einem remote-server mit ssh die ssh-Befehl hängt sich nach der exec request accepted eine debug-Meldung, und irgendwann mal hin.

Dem fehlerhaften Befehl: ssh -v -v <username>@<server> uptime (habe auch versucht echo hello etc.)

debug1: Authentication succeeded (publickey).
Authenticated to <server> (<ip>:22).
debug1: channel 0: new [client-session]
debug2: channel 0: send open
debug1: Requesting [email protected]
debug1: Entering interactive session.
debug2: callback start
debug2: client_session2_setup: id 0
debug2: fd 4 setting TCP_NODELAY
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
debug2: channel 0: request env confirm 0
debug1: Sending command: uptime
debug2: channel 0: request exec confirm 1
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel 0: rcvd adjust 2097152
debug2: channel_input_status_confirm: type 99 id 0
debug2: exec request accepted on channel 0

Und dort hängt er, auf unbestimmte Zeit.

Wenn ich ssh ohne einen Befehl in meinem remote-server, jedoch bekomme ich eine interaktive shell und alles ist gut.

Erfolgreichen Befehl: ssh -v -v <username>@<server>

Ausgabe:

debug1: Authentication succeeded (publickey).
Authenticated to <server> (<ip>:22).
debug1: channel 0: new [client-session]
debug2: channel 0: send open
debug1: Requesting [email protected]
debug1: Entering interactive session.
debug2: callback start
debug2: client_session2_setup: id 0
debug2: fd 4 setting TCP_NODELAY
debug2: channel 0: request pty-req confirm 1
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
debug2: channel 0: request env confirm 0
debug2: channel 0: request shell confirm 1
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel_input_status_confirm: type 99 id 0
debug2: PTY allocation request accepted on channel 0
debug2: channel 0: rcvd adjust 2097152
debug2: channel_input_status_confirm: type 99 id 0
debug2: shell request accepted on channel 0
Welcome!
<prompt>%
...

Hat jemand eine Idee, warum eine interaktive Sitzung erfolgreich sein würde, aber eine Befehlsausführung nicht?

Wurde, verfolgt mich nun schon seit Monaten, weil ich nicht verwenden können, unison synchronisieren meiner Dateien nicht mehr (es funktioniert). Jede Hilfe sehr geschätzt.

InformationsquelleAutor der Frage Robert Muil | 2011-05-08

  1. 24

    Das problem war in der Tat mein login-Skript, obwohl Sie nicht zu tun, erfordert ein terminal (ich hätte vermutet, dass und getestet, mit der -t und -T Optionen). Das problem war, dass meine .bashrc lief eine exec (in diesem Fall zsh - weil unser system nicht zulässt, dass chsh zu zsh).

    Die betreffende Zeile:

    test -f /usr/bin/zsh && exec /usr/bin/zsh

    Gelöst, indem zuerst die Prüfung für die interaktive shell verlassen und wenn ja:

    [ -z "$PS1" ] && return
test -f /usr/bin/zsh && exec /usr/bin/zsh

    So, im wesentlichen, weil die Schale war execing in zshssh wartete darauf, dieses zu beenden - was noch nie passiert.

    Bin ich ein wenig verwirrt, warum meine .bashrc aufgerufen wurde, habe ich gedacht, dies sei nur für interaktive shells, aber den genauen Zweck und die Reihenfolge der verschiedenen init-Skripten ist etwas, was ich nicht glaube, dass ich je lernen wirst.

    Ich hoffe, dies kann nützlich sein, um andere, die irgendeine Art von exec in Ihrer startup-Skripte.

    BTW - die anderen beiden Antworten waren auf der rechten Spur, ich war also völlig unsicher, ob ich sollte 'Antwort' oder einfach nur Ihren Kommentar Antworten. Wenn die Antwort auf meine eigene Frage moralisch falsch ist, auf stackoverflow, lassen Sie mich wissen, und ich Tue Buße. Danke an die anderen Beantworter.

    InformationsquelleAutor der Antwort Robert Muil

  2. 4

    Dein problem wahrscheinlich liegt in Ihrer shell-startup-oder shell-logout-Skripte. Ohne zu wissen, was drin ist, ist es schwer zu erraten ist das eigentliche problem.

    InformationsquelleAutor der Antwort Mel

  3. 2

    Check für Befehle in der shell-startup-Dateien (ich würde davon ausgehen ~/.cshrc von Ihr aufgefordert, in einer nicht interaktiven Sitzung ~/.login sollte keine Rolle spielen) , benötigen Sie ein terminal aus irgendeinem Grund.

    InformationsquelleAutor der Antwort geekosaur

  4. 2

    Vor kurzem habe ich ein problem festgestellt, das die selben Symptome, aber festgestellt, dass das Problem war nicht ein problem in meinem login-Skripte. Sondern meine lokale .ssh/config - Datei konfiguriert wurde, mit RequestTTY force für die Gastgeber, dass ich versucht habe, zu kopieren.

    InformationsquelleAutor der Antwort MJD

  5. 1

    Ich hatte dieses problem auf fedora-server 22, nach der Auflösung von anderen neue Probleme.

    ssh -t ziimp /bin/true war ok, aber nicht ssh ziimp /bin/true und alle meine git+ssh und scp-wurden gesperrt.

    Die Lösung, die ich fand, war in der authorized_keys - Datei. Ich hatte zu entfernen, command="/usr/bin/bash" - Präfix aus meinen vertrauenswürdigen Schlüssel...

    InformationsquelleAutor der Antwort Tanguy

Schreibe einen Kommentar