Schlagwort-Archive: OpenSSH

RasPi/OSMC: SSH-Login bricht ab

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:

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:

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.

ArchLinux: Update sperrt root-Login per SSH

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“.

BitBastelei #146 – SSH unter Linux

Vom Verbinden bis zum Tunneln
Alle Angaben beziehen sich auf OpenSSH

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

LUG-MYK

SSH: Fingerprint-Algorithmus ändern

sshmd5Mit 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.