ssh: debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
Wenn ssh plötzlich aus dem Nichts heraus nicht mehr geht, weil "connection closed by [[remote host]]" noch bevor man überhaupt zur Passworteingabe aufgefordert wird, dann kriegt man ja erst mal die Krise, vor allem, wenn es sich um einen Rechner handelt, auf den man anders jetzt erst mal keinen Zugriff hat, weil headless.
Als Erstes geht man mal hin und macht ein
Dann sucht man durchs Internet, und das behauptet, man möge es doch mal mit einer anderen cipher suite versuchen. Hab ich, bringt nichts. Dann behaupten welche, man sollte an der MTU drehen. Bringt nichts, und vor allem scheint das nur für Verbindungen über VPN relevant zu sein, was das hier ja nicht ist.
Schweren Herzens sucht man eine Tastatur mit USB-Anschluss und steckt sie in den Pi ein, wobei man mit seinen dicken Wurstfingern natürlich die verf***te SD-Karte wiedermal auswirft, sodass man auch gleich rebooten darf. Macht aber nichts, denn der Pi mochte es eh nicht, dass das HDMI-Kabel nicht eingesteckt war, als er das letzte Mal gebootet wurde.
Hat man all diese Hürden hinter sich, schaut man ins Log, nachdem man in der sshd_config das LogLevel=DEBUG3 gesetzt hat und erhält noch viel. viel kryptischere Aussagen:
Bringt mich jetzt irgendwie auch auf keinen grünen Zweig. Vom Server aus aufs Notebook geht einwandfrei. Also mal die sshd_config verglichen: Keine wirklich gravierenden Unterschiede. Also, nichts, was solch ein Verhalten rechtfertigen würde.
Habe dann aus Neugier mal einen RSA-Key mit ssh-keygen erstellt, obwohl ich gerne hätte, dass immer alle ihr Passwort zum Login eingeben müssen, und den öffentlichen Schlüssel dann ans Notebook geschickt - in die Richtung geht's ja - aber, ach: No luck!
Langer Rede kurzer Sinn: Ich habe auf Verdacht einfach openssh noch mal neu mit emerge bauen lassen. Server neu gestartet, ssh vom Notebook: Läuft! Es drängt sich also der Verdacht auf, dass irgendeine Dependency mal wieder nicht bedacht worden ist. Ich habe keine Ahnung, wer das gewesen sein könnte, denn weder openssl noch pam noch irgendein anderes sicherheitsrelevantes Paket wurde beim letzten größeren Update angefasst, aber... here we are! :-/
Als Erstes geht man mal hin und macht ein
ssh -vvv, in der Hoffnung, dass man einen Hinweis bekommt, was jetzt wieder schief geht. Die letzte Meldung, bevor der gegnerisches sshd auflegt, ist dort "debug1: expecting SSH2_MSG_KEX_ECDH_REPLY". Ist jetzt nicht so richtig hilfreich.Dann sucht man durchs Internet, und das behauptet, man möge es doch mal mit einer anderen cipher suite versuchen. Hab ich, bringt nichts. Dann behaupten welche, man sollte an der MTU drehen. Bringt nichts, und vor allem scheint das nur für Verbindungen über VPN relevant zu sein, was das hier ja nicht ist.
Schweren Herzens sucht man eine Tastatur mit USB-Anschluss und steckt sie in den Pi ein, wobei man mit seinen dicken Wurstfingern natürlich die verf***te SD-Karte wiedermal auswirft, sodass man auch gleich rebooten darf. Macht aber nichts, denn der Pi mochte es eh nicht, dass das HDMI-Kabel nicht eingesteckt war, als er das letzte Mal gebootet wurde.
Hat man all diese Hürden hinter sich, schaut man ins Log, nachdem man in der sshd_config das LogLevel=DEBUG3 gesetzt hat und erhält noch viel. viel kryptischere Aussagen:
Aug 7 09:08:29 sauserver sshd[11937]: debug1: monitor_read_log: child log fd closed
Aug 7 09:08:29 sauserver sshd[11937]: debug1: do_cleanup
Aug 7 09:08:29 sauserver sshd[11937]: debug1: Killing privsep child 11941Bringt mich jetzt irgendwie auch auf keinen grünen Zweig. Vom Server aus aufs Notebook geht einwandfrei. Also mal die sshd_config verglichen: Keine wirklich gravierenden Unterschiede. Also, nichts, was solch ein Verhalten rechtfertigen würde.
Habe dann aus Neugier mal einen RSA-Key mit ssh-keygen erstellt, obwohl ich gerne hätte, dass immer alle ihr Passwort zum Login eingeben müssen, und den öffentlichen Schlüssel dann ans Notebook geschickt - in die Richtung geht's ja - aber, ach: No luck!
Langer Rede kurzer Sinn: Ich habe auf Verdacht einfach openssh noch mal neu mit emerge bauen lassen. Server neu gestartet, ssh vom Notebook: Läuft! Es drängt sich also der Verdacht auf, dass irgendeine Dependency mal wieder nicht bedacht worden ist. Ich habe keine Ahnung, wer das gewesen sein könnte, denn weder openssl noch pam noch irgendein anderes sicherheitsrelevantes Paket wurde beim letzten größeren Update angefasst, aber... here we are! :-/