Schlagwort-Archive: OpenSSH

BitBastelei #545 – 2FA und FIDO U2F für Linux und SSH

BitBastelei #545 - 2FA und FIDO U2F für Linux und SSH

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

Inhalt

  • 00:00 Vom Passwort zu 2FA
  • 01:40 Faktoren: Wissen, Haben, Sein
  • 02:00 Sein – Biometrische Faktoren
  • 03:21 Haben – Smartcards & Co
  • 03:54 Push-Techniken: SMS/Mail
  • 04:28 Push-Techniken: Apps
  • 05:05 TOTP
  • 07:45 FIDO/U2F
  • 11:30 OS-Login mit U2F / PAM unter Linux
  • 20:07 SSH-Login mit U2F
  • 23:31 Fazit

Ergänzungen

  • 00:55 – Foto „Cyber“ von erdbeernaut · CC0
  • 09:36 – Wobei das in den meisten Fällen nicht zu empfehlen ist

Links zum Thema

Transparenz

Selbst gekauft/allgemeine Werbegeschenke einer Konferenz, wo kostenpflichtig selbst bezahlt, zum Zeitpunkt des Videos nichts mit den Herstellern zu tun. As usual.

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:

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

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

BitBastelei #146 - SSH unter Linux

(41 MB) 00:30:06

2015-04-26 10:00 🛈
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

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.