Mal wieder ein Fehler, der im ersten Moment nicht wirklich zu erklären ist: An einem meiner Mediacenter konnte ich mich nicht mehr per SSH anmelden. Alle anderen Netzwerkfunktionen sahen OK aus, der SSH-Client meines Rechners zeigt jedoch folgendes:
> ssh osmc@1.2.3.4 -v OpenSSH_7.5p1, OpenSSL 1.1.0f 25 May 2017 debug1: Reading configuration data /home/adlerweb/.ssh/config debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 20: Applying options for * debug1: Connecting to 1.2.3.4 [1.2.3.4] port 22. debug1: Connection established. […] debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_7.5 debug1: Remote protocol version 2.0, remote software version OpenSSH_6.7p1 Raspbian-5+deb8u3 debug1: match: OpenSSH_6.7p1 Raspbian-5+deb8u3 pat OpenSSH* compat 0x04000000 debug1: Authenticating to 1.2.3.4:22 as 'osmc' debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: algorithm: curve25519-sha256@libssh.org debug1: kex: host key algorithm: ecdsa-sha2-nistp256 debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none debug1: expecting SSH2_MSG_KEX_ECDH_REPLY debug1: Server host key: ecdsa-sha2-nistp256 SHA256:xyz debug1: Host '1.2.3.4' is known and matches the ECDSA host key. debug1: Found key in /home/adlerweb/.ssh/known_hosts:853 debug1: rekey after 1234 blocks debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: rekey after 1234 blocks debug1: SSH2_MSG_SERVICE_ACCEPT received Authentication failed. >
Da es vor dem „Authentication failed“ ein paar Sekunden Wartezeit gibt kam mir ein alter Bekannter in den Sinn: DNS. Meldet man sich per SSH an versucht dieser standardmäßig den zur IP gehörenden Hostname zu ermitteln. Erhält der SSH-Daemon keine Antwort kann es zu einem Timeout kommen und die Verbindung abbrechen. Auch in meinem Fall fand ich in der Konfiguration einen veralteten DNS-Server.
Die ultimative Lösung besteht natürlich darin die Netzwerkkonfiguration zu fixen und somit DNS wieder lauffähig zu bekommen. Um zukünftig den hier nötigen Gang zum Raspi zu sparen und SSH auch ohne DNS lauffähig zu bekommen kann man folgende Zeilen in /etc/ssh/sshd_config hinzufügen:
GSSAPIAuthentication no UseDNS no
UseDNS schaltet den Reverse-DNS ab – im LAN wohl zu verkraften. GSSAPI kann ohne DNS ebenfalls Fehler verursachen und wird bei einfachen Setups ohnehin nicht aktiv sein, daher auch dies nochmal explizit abgeschaltet. Nach dem nächsten Neustart des sshd sollte der Login dann auch ohne DNS immer und so die Reparatur der Netzwerkkonfiguration auch übers Netz möglich sein.