Aufpassen: Das #OpenSSH - Update gegen #RegreSSHion hat unter #Archlinux einen hässlichen Eeffekt: Wenn man aktualisiert und nicht direkt in der selben Sitzung SSH neu startet, dann ist kein Remote-Login mehr möglich. Zugang geht dann nur, wenn man das System neu startet oder sich über einen anderen Weg wie lokales Terminal/KVM/Serial Console anmeldet und den Dienst einmal neu startet.
https://gitlab.archlinux.org/archlinux/packaging/packages/openssh/-/issues/5
(1 GB) 00:24:27
2023-06-25 10:00 🛈Ein Passwort alleine ist heute an vielen Stellen nicht mehr ganz Zeitgemäß. Oft wird heute ein zweiter Faktor genutzt. Diesmal daher ein kleiner Überblick über gängige Faktoren und ein Blick darauf, wie mein FIDO2- bzw. U2F-Sticks für Linux-Systeme und OpenSSH nutzen kann.
Selbst gekauft/allgemeine Werbegeschenke einer Konferenz, wo kostenpflichtig selbst bezahlt, zum Zeitpunkt des Videos nichts mit den Herstellern zu tun. As usual.
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.
Ouch – nicht schön. Nach dem Update einer remote-Kiste war der Login per SSH nicht mehr möglich. Schuld ist offenbar eine Änderung der SSH-Defaults: Während bisher der root-Login auch ohne explizite Angabe in der Konfiguration erlaubt war, muss dies nun in der Konfiguration mit einem PermitRootLogin yes manuell zugelassen werden. Sofern kein anderes Konto besteht heißt das nach einem Update dann: KVM oder Remote-Hands müssen her um den Eintrag zu setzen und den Server so wieder verwaltbar zu machen. Ein Hinweis vorab wäre natürlich einfacher gewesen :/.
Edit: Zu früh gemault: Im Announcement der OpenSSH-Leute ist die Änderung beschrieben, RTFM hätte also geholfen…
Potentially-incompatible Changes
—
[…]
* The default for the sshd_config(5) PermitRootLogin option has
changed from „yes“ to „prohibit-password“.
(41 MB) 00:30:06
2015-04-26 10:00 🛈Befehle:
Verbinden zum Rechner:
ssh evil.server
Verbinden zum Rechner mit Nutzerangabe
ssh anderernutzer@evil.server
Host-Keys anzeigen
ssh-keygen -l -f /etc/ssh/ssh_host_ed25519_key
(bzw. passender Key)
Host-Key aus „Adressbuch“ löschen
ssh-keygen -R evil.server
Neues Schlüsselpaar erzeugen
ssh-keygen
Key auf Server kopieren
ssh-copy-id username@evil.server
Passwort eines Keys ändern
ssh-keygen -f ~/.ssh/id_rsa -p
Argumente
-p 1234 – Port 1234 statt Port 22 nutzen
-C – Kompression einschalten
-v – verbose – zusätzliche Ausgaben zur Fehlersuche
Lokale Weiterleitung
ssh -L 127.0.0.1:1234:192.168.0.2:80 evil.server
Lokale Verbindungen an Port 1234 werden über evil.server an 192.168.0.2 Port 80 weitergeleitet
Remote Weiterleitung
ssh -R 0.0.0.0:1235:127.0.0.1:80 evil.server
Verbindungen auf eine beliebige IP von evil.server auf Port 1235 werden an Port 80 des lokalen PCs weitergeleitet
SOCKS-Proxy
ssh -D 3128 evil.server
Es wird ein SOCKS-Proxy auf Port 3128 gestartet. Dieser kann z.B. mit Firefox genutzt werden
X11-Forwarding
ssh -XY evil.server
Nun können in der Sitzung grafische Programme gestartet werden. Die Anzeige erfolgt auf dem lokalen PC
Config-Files
Alle Argumente und weitere Optionen können global oder pro Ziel in den Konfigurationen hinterlegt werden. Die Benutzerkonfiguration ist unter ~/.ssh/config zu finden, die Systemweite üblicherweise unter /etc/ssh/ssh_config
Escape-Sequenz
In einer SSH-Sitzung kann man üblicherweise mit der Tilde-Taste (~) ein internes Menü aufrufen. Die Wichtigsten Befehle:
~? Hilfe anzeigen
~. SSH-Verbindung beenden (auch wenn Gegenseite nicht mehr reagiert)
~# Liste der Verbindungen (incl. Tunnel) anzeigen
~C Interne Konsole aufrufen – hier kann man nachträglich Tunnel (-L, -R, -D) aufbauen
Weitere Ideen:
– ssh-agent: Kennwörter für SSH-Keys mussen nur alle X Minuten eingegeben werden
– autossh: SSH-Verbindung bei Abbrüchen neu Aufbauen
– SSH mit Pipes: Pipes lassen sich über SSH auch an entfernte Rechner senden
– 2-Faktor-Anmeldung, z.B. mit Google Authenticator
– Host-Keys in DNS hinterlegen
Bild: https://adlerweb.info/blog/wp-content/uploads/2015/04/sshmd5-300×45.pngMit einem der letzten Updates scheint OpenSSH einen Schritt in Richtung Gegenwart getätigt zu haben. Nun werden Fingerprints nicht mehr als MD5 sondern mit SHA256 präsentiert. Was auf der einen Seite eine tolle Sache ist kann aber auch zum Problem werden: Eine hiesige Debian-Kiste kann mit dem dort als stable deklarierten OpenSSH 7.0 auch optional keinen SHA256-Hash herausrücken. Manueller Abgeleich mit dem neueren Client des ArchLinux-Systems unmöglich. Um hier wieder auf einen gemeinsamen Nenner zu kommen bleibt nur den neuen Client auf den älteren Hash-Algorithmus zurückzutrimmen. Das funktioniert über die SSH-Config (/etc/ssh/ssh_config or ~/.ssh/config) mit folgenden Zeilen – zum Glück auch für einzelne Hosts:
Host oldserver.org
FingerprintHash md5
Schon erhält man beim Verbinden wieder den gewohnten MD5-Hash und kann sich – bis auch andere Distros sha256 herausrücken – behelfen.
