☰

Seltsames SSH-Problem, ssh funktioniert mit -t, friert aber ohne ein

tag-icon • tag-icon shell ssh login
Seltsames SSH-Problem, ssh funktioniert mit -t, friert aber ohne ein

Wenn ich sshmich bei einem meiner Server anmelde, scheint die Anmeldung zu funktionieren, bleibt dann aber hängen, bevor ich die Eingabeaufforderung ( message debug2: shell request accepted on channel 0 is the last log entry) erhalte.

Allerdings ist es seltsam, dass etwas ssh -t "/bin/bash"funktioniert, obwohl sshes nicht funktioniert.

Was ich bisher herausgefunden habe

  • Normalerweise kann ich mich problemlos von Servern am gleichen geografischen Standort aus anmelden
  • Wenn ich ssh -t '/bin/bash'- ich kann mich von JEDEM Standort aus problemlos anmelden.
  • Wenn ichrsync Zuder Server, es scheint zu funktionieren, und dann sperrt
  • Wenn ichrsync ausder Server, es funktioniert ohne Probleme

Was ich versucht habe

  • Entfernen oder Ändern sämtlicher Anmeldeoptionen .profile,.bashrc /etc/profile
  • Wechselnssh_config und/oder sshd_configzu einem von einem identischen Server, der einwandfrei funktioniert
  • Ich habe die Routenführung überprüft
  • Ich habe es von einem Netzwerkexperten untersuchen lassen, tcpdumpaber ohne Erfolg (obwohl es anscheinend viele Neuübertragungen gibt).

Mir fällt wirklich nichts anderes ein

Abgesehen von einem zweifelhaften Netzwerkkartentreiber/einer zweifelhaften Firmware.

Antwort1

Das kann an einem Problem im Profil liegen.
Wenn Sie eine Verbindung mit ssh -t /bin/bash Ihrer Shell herstellen, wird sie sich nicht anmelden, weder die Quelle /etc/profilenoch das ~/.profileund ~/.bashrc...

Versetzen Sie die Shell nach dem Verbinden in den Debugmodus und geben Sie dann die Quelldatei jeder Datei ein, um herauszufinden, was darin blockiert ist:

set -x 
. /etc/profile 
...and so on

BEARBEITEN

Beachten Sie, dass ich falsch lag. Die .bashrc-Datei wird von jeder interaktiven Shell bezogen (deshalb sind hier nur die Dateien „profile“ und „profile.d“ von Bedeutung).

Versuchen Sie, eine Liste der verschiedenen Phasen des Verbindungsprozesses zu erstellen. So etwas wie das hier

1) SSH-Verbindung herstellen (Konfiguration, …)
2) Anmelden (PAM, TTY, WTMP, …)
3) Shell starten (Profil, Zugriff auf das Home-Verzeichnis, …)

Um (1) zu überprüfen, können Sie den SSHD-Daemon im Debug-Modus starten. Dazu müssen Sie einen weiteren SSHD starten, der auf einem dedizierten Port lauscht (nicht auf Port 22, daher müssen Sie den normalen SSHD-Daemon nicht stoppen).

# /usr/sbin/sshd -p 2222 -ddd

Dieser SSHD akzeptiert nur eine Verbindung und geht nicht in den Hintergrund. Öffnen Sie ein anderes Terminal und stellen Sie eine Verbindung zu dieser SSH-Sitzung her.

# ssh -vvv -p 2222 user@host

Sie können die Nachrichten, die Sie erhalten, mit denen eines anderen Servers derselben Marke vergleichen. Dann wissen Sie, ob das Problem auf der SSH-Seite liegt oder nicht.

(-ddd und -vvv sind die maximalen Debug-Level, die Sie anpassen können)

ich habe das verstandenVerknüpfung, viel detaillierter.

Antwort2

Die Antwort auf mein Problem Es stellte sich heraus, dass es ein Netzwerkproblem war. Irgendwann fand ich heraus, dass das Problem behoben war, wenn ich die MTU aller Netzwerkkarten etwas verringerte.

Höchstwahrscheinlich ist für dieses Netzwerk etwas falsch konfiguriert, aber ich kann das jetzt beweisen und es dem Netzwerkteam übergeben (das mir immer wieder sagte, dass es ein Serverproblem sei).

Beachten Sie jedoch, dass dies der letzte Ausweg ist Die Besonderheit für mich bestand darin, dass der SSH-Server vom selben Subnetz aus, aber nicht außerhalb davon funktionierte, und ssh -t '/bin/bash' von überall aus funktionierte.

Ich hatte auch Rsyncs, die problemlos starteten, aber irgendwann einfach hängen blieben oder die Verbindung abbrachen.

Wenn Sie sich also diese Antwort ansehen, versuchen Sie zuerst die anderen oben, und NUR wenn Sie auf Merkwürdigkeiten stoßen, wie ich sie habe, wird dies wahrscheinlich helfen.

Vielen Dank also für all die Hilfe. Ich habe alles versucht und dabei viel gelernt. Außerdem kann ich bestätigen, dass es nichts mit dem Server zu tun hatte (was genau das ist, was ich mir erhofft hatte).

Vielen Dank an alle, die geholfen haben

Antwort3

Ich habe dasselbe Problem, als ich kürzlich eine verschachtelte Virtualisierungsplattform verwendet habe.

Es funktioniert, nachdem die MTU auf dem Quell- oder Zielserver von 1500 auf 1400 reduziert wurde.

/sbin/ip link set dev eth0 mtu 1400

Antwort4

Wenn Sie das tun ssh some_user@some_host /bin/bash, starten Sieirgendein_Benutzer's Shell (wie in /etc/passwdon definiert)irgendein_host) und führen Sie dann den angegebenen Befehl /bin/bashinnerhalb dieser Shell aus.

Jetzt,irgendein_BenutzerDie Shell von (nehmen wir an, sie ist auch bash) wird nicht interaktiv gestartet (sie führt stattdessen den angegebenen Befehl aus). Sie weist also kein pty zu (einPseudoterminal) und das bedeutet, dass für den ausgegebenen Befehl kein PTY vorhanden ist, sodass er nicht-interaktiv gestartet wird.

Im Beispiel /bin/bashwird der angeforderte Befehl ausgeführt, aber er scheint hängen zu bleiben.

Sie können dies beheben, indem Sie sshtrotzdem die Erstellung eines PTY anfordern, sodass eines für die Shell und ihre untergeordneten Prozesse verfügbar ist. So funktioniert es -t.

    $ ssh -t some_user@some_host bash

Sie können dies auch beheben, indem Sie den Befehl zwingen, ein pty zu erstellen. Für bashtun Sie dies, indem Sie ein -iArgument übergeben. Die folgende Befehlszeile sollte auch funktionieren:

$ ssh some_user@some_host bash -i

Beachten Sie jedoch, dass im letzteren Fall die Shell nicht zugreifen kann /dev/ttyund es zu einer Warnung kommt:

bash: no job control in this shell

Die Gründe hierfür werden erläutertHier. Dies kann, je nachdem, was Sie in der Shell tun möchten, ein Problem darstellen oder auch nicht, aber die Verwendung ssh -tist wahrscheinlich die bessere Option.

bash(Beachten Sie, dass Sie es einfach als Befehl übergeben können, da es sich ohnehin im Pfad der Standard-Shell des Benutzers befinden sollte.)

verwandte Informationen