sshd: Bad packet length

[scientific]

Bedingt durch meine ssh-Geschichte im Thread nebenan hab ich mich mal ein wenig mit dem ssh-Server und der Socket-Activation beschäftigt.

Dabei tritt ein seltsames Phänomen auf.
Wenn ich sshd mit der Option -D starte (bleibt im Vordergrund), kann ich mich einloggen.
Wenn ich sshd mit der Option -i starte (vom Inetd bzw. systemd mit socket-Activation) dann kommt beim Login folgendes:

Code: Alles auswählen

$ ssh localhost
jakob@localhost's password: 
Bad packet length 1097032549.
Disconnecting: Packet corrupt

Ich fand leider nur Infos, die mir gar nichts sagen... Von Rootkit bis zu veralteten Verschlüsselungsalgorithmen...

Kann das vielleicht jemand nachvollziehen?

Die passenden systemd-units sind:
/etc/systed/system/sshd.socket

Code: Alles auswählen

[Unit]
Description=Socket-activated sshd socket

[Socket]
ListenStream=22
Accept=yes
#BindIPv6Only=both
MaxConnections=51

[Install]
WantedBy=sockets.target

und /etc/systemd/system/sshd@.service

Code: Alles auswählen

[Unit]
Description=Socket-activated sshd

[Service]
ExecStart=/usr/sbin/sshd -i -e 
StandardInput=socket

lg scientific

[GregorS]

Kann das vielleicht jemand nachvollziehen?

Ich habe das zwar nicht nachvollzogen, glaube aber, die Lösung irgendwann vor Jahren gefunden zu haben: Es hat wohl beim Protokoll einmal eine Änderung gegeben, die dazu führt, dass man den Server auf die neuere Version „festnageln“ muss. Nachgucken kann ich nicht (mehr), weil ich diesem Problem schon lange nicht mehr begegnet bin und alle Rechner, die involviert waren, nicht mehr existieren.

Guck mal nach einer Konfigurationsoption, die etwas mit Protokoll 1 bzw. 2 zu tun haben.

HTH

Gregor

[scientific]

Kann das vielleicht jemand nachvollziehen?

Ich habe das zwar nicht nachvollzogen, glaube aber, die Lösung irgendwann vor Jahren gefunden zu haben: Es hat wohl beim Protokoll einmal eine Änderung gegeben, die dazu führt, dass man den Server auf die neuere Version „festnageln“ muss. Nachgucken kann ich nicht (mehr), weil ich diesem Problem schon lange nicht mehr begegnet bin und alle Rechner, die involviert waren, nicht mehr existieren.

Guck mal nach einer Konfigurationsoption, die etwas mit Protokoll 1 bzw. 2 zu tun haben.

HTH

Gregor

Klingt gut... aber ich hab in meiner sshd.config "Protocol 2" stehen.

Davon las ich schon... aber das ist nicht das Problem gewesen.

Wie ich schon schrieb: mit Option -D (also im Vordergrund) läuft sshd einwandfrei. Mit Option -i (also als Dienst für inetd bzw. systemd mit Socket-Activation) bekomme ich diese Fehlermeldung.
Pöttering gibt in seinem pideins-Blog auch die Option -i als einzige an.

Denke einmal das muss ein Bug in Debian sein.

lg scientific

[MSfree]

Mit Option -i (also als Dienst für inetd bzw. systemd mit Socket-Activation) bekomme ich diese Fehlermeldung.

Warum willst du den sshd denn über inetd oder systemd mit Socketaktivierung laufen lassen?

Den sshd läßt man als eigenständigen Daemon laufen. Um den Start des Daemons kümmert sich dann entweder das SysV-init bzw. seit Debian 8 der systemd, die starten sshd dann nicht auf Anfrage bei ankommenden Netzwerkpaketen sondern als Daemon, der selbst auf die ankommenden Netzwerkpakete reagiert.

Socketaktivierung bzw. über inetd ist ein ziemlich veraltetes Konzept, das früher mal bei Daemons zum Einsatz kam, die keine langwierige Initialisierung beim Programmstart benötigten. Wie alt ist denn die Anleitung, nach der du den sshd mit inetd konfigurieren willst? So etwas ist mir seit fast 20 Jahren nicht mehr untergekommen.

[scientific]

systemd...

die Anleitung hab ich vom 0pointer-Blog. Dort wird der Start per Socket-Aktivierung beispielhaft am sshd erklärt.

Ich wollts einfach testen. Da ich einige andere Dienste auf meinem Laptop auch auf Socket-Aktivierung umgestellt habe, bootet der jetzt in der halben Zeit. Macht bei einem Schleppi dann schon Sinn.

Ist jetzt aber bei sshd nicht wirklich wichtig. Wenngleich das Phänomen spannend ist... scheint ein Bug in sshd zu sein.

[MSfree]

Ich wollts einfach testen. Da ich einige andere Dienste auf meinem Laptop auch auf Socket-Aktivierung umgestellt habe, bootet der jetzt in der halben Zeit. Macht bei einem Schleppi dann schon Sinn.

Naja, ich habe hier noch einen EeePC 901 von 2008, Single-Core 1.6GHz Atom, der bootet ohne irgendwelche "Optimierungen" Debian 8 in etwa 5 Sekunden bis zum Graphische KDE-Login. Selbst der BIOS-Selbsttest dauert länger. Ich sehe wirklich keinen Sinn darin, Dienste auf inetd (bzw. portaktiviert, was ja das gleiche unter systemd ist wie das, was inetd macht) umzustellen.

Ist jetzt aber bei sshd nicht wirklich wichtig. Wenngleich das Phänomen spannend ist... scheint ein Bug in sshd zu sein.

Das ist nicht unbedingt ein Bug. Bei portaktivierten Diensten lauscht ein Hilfsprogramm wie inetd bzw. systemd auf dem Serviceport und startet den gewünschten Dienst beim Eintreffen eines entsprechenden Netzwerkpaketes. Dabei kann es beim Start vorkommen, daß das erste Netzwerkpaket verloren geht und der Dienst erstmal Müll zu Gesicht bekommt. Das ist bei TCP-Verbindungen normalerweise nicht weiter tragisch, da das Paket einfach noch einmal von der Quelle angefordert wird. Bei verschlüsselten Protokollen wie SSH kann aber das erneut angfeforderte Paket als Replay-Attacke (https://de.wikipedia.org/wiki/Replay-Angriff) von sshd mißverstanden werden, was dann zu dieser Fehlermeldung führt.

Aus diesem Grund wurde sshd schon auf Unixen der 1990er Jahre nicht mehr vom inetd gestartet.

[dufty2]

Hab's mal nach Abschnitt "Starting SSH" auf
http://www.holgerschurig.de/linux/systemd.html
probiert (ohne jetzt systemd neu zu kompilieren), da funktioniert es!

Wenn man die Config der "sshd@.service"-Datei mit Deiner vergleicht, fällt auf:
ExecStart=-/usr/sbin/sshd -i
statt
ExecStart=-/usr/sbin/sshd -i -e

Füge ich nun das "-e" hinzu, bekomme ich auch den "Bad packet length"-Fehler.

[scientific]

ok... werd ich mal testen.