Thema: ssh
-
Post-Quanten-Standardeinstellungen von OpenSSH und die Warnung vor nicht quantensicherem Schlüsselaustausch
Die OpenSSH-Warnung auf den ausgewählten Schlüsselaustausch zurückführen, die wirksamen Einstellungen beider Gegenstellen prüfen und die hybride Aushandlung wiederherstellen, ohne die Hostauthentifizierung abzuschwächen.
-
SSH-Warnungen «Host key verification failed» und «REMOTE HOST IDENTIFICATION HAS CHANGED»
OpenSSH verweigert die Verbindung und gibt «Host key verification failed» bzw. das grosse Banner «WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!» aus, wenn der Schlüssel des Servers nicht mit dem Eintrag in known_hosts übereinstimmt. Der Artikel erklärt, warum ein neu aufgebauter Server und ein tatsächlicher Angriff dieselbe Meldung erzeugen und wie sich beide vor einem ssh-keygen -R unterscheiden lassen.
-
SSH-Meldung „Permission denied (publickey)“ mit ssh -v richtig lesen
„Permission denied (publickey)“ in OpenSSH bedeutet, dass alle vom Client angebotenen Schlüssel abgelehnt wurden oder gar keiner angeboten wurde – welcher Fall vorliegt, sagt die Meldung nicht. Der Artikel zeigt, wie ssh -v genau die probierten Schlüssel benennt, und behandelt falsche Benutzernamen, IdentitiesOnly, Rechte von authorized_keys auf dem Server sowie den mit OpenSSH 8.8 deaktivierten Standard ssh-rsa (SHA-1).
-
SSH-Host-Keys und Machine-ID auf einem geklonten Linux-Host neu erzeugen
Ein frisch geklonter Linux-Host braucht eigene SSH-Host-Keys und eine eigene Machine-ID, bevor er in eine Flotte aufgenommen wird. `ssh-keygen -A` und `systemd-machine-id-setup` können diese erzeugen, doch bei einem bereits gebooteten Klon mit doppelter Machine-ID sind ein neu geschriebener Wert und ein Reboot nötig. Nur der Duplikatabgleich über die ganze Flotte belegt wirklich, dass das Klonen nicht einfach überall dieselben Kennungen kopiert hat.
-
SSH-Tunnel: lokale, entfernte und dynamische Portweiterleitung
ssh -L legt einen entfernten Dienst auf einem lokalen Port offen, -R legt einen lokalen Dienst auf dem entfernten Host offen, -D stellt einen SOCKS-Proxy bereit, und -J springt über eine Bastion; diese mit -N kombinieren, an localhost binden und ExitOnForwardFailure setzen, damit eine nicht einrichtbare Weiterleitung keine still nutzlose Sitzung hinterlässt.
-
SSH known_hosts und Host-Key-Prüfung in der Automatisierung: ssh-keyscan plus Out-of-Band-Verifikation
Auch automatisierte SSH-Verbindungen müssen den Host-Key des Servers prüfen; ssh-keyscan allein sammelt nur einen Schlüssel ein, ohne dessen Echtheit zu belegen. StrictHostKeyChecking=accept-new, HashKnownHosts und SSHFP-Records decken jeweils einen anderen Teil einer sicheren Lösung ohne interaktive Rückfrage ab.
-
Exit-Codes von ssh und scp: 255 ist der Fehler von ssh selbst, jeder andere Wert stammt vom Remote-Befehl
ssh reicht den Exit-Status des auf dem Remote-Host ausgeführten Befehls durch und reserviert 255 für Fehler von ssh selbst (Verbindung abgelehnt, Authentifizierungsfehler, abweichender Host-Key) sowie für Remote-Befehle, die durch ein Signal beendet wurden. scp dokumentiert nur die Unterscheidung 0 = Erfolg, ungleich 0 = Fehler; lokale Transportprobleme lassen sich von Remote-Fehlern daher nur anhand der stderr-Ausgabe von ssh unterscheiden, nicht anhand des scp-Codes.
-
CL-Befehle von IBM i in einer SSH/PASE-Shell ausführen: system, qsh und CCSID-Stolpersteine
In einer SSH-Sitzung auf IBM i PASE sind das PASE-for-i-Utility system und die QSH/Qshell-Umgebung die beiden unterstützten Wege, CL-Befehle auszuführen und deren Ausgabe zu erfassen. Beide konvertieren zwischen der CCSID des Jobs und der PASE-eigenen Kodierung, woraus die meisten Integrationsfehler beim ersten Einsatz entstehen.
-
SSH-Bastion-Host betreiben: ProxyJump auf dem Client und Einschränkung dessen, was der Jump-Host weiterleiten darf
Ein Bastion-Host soll ProxyJump-Verbindungen zu internen Hosts weiterreichen, ohne als allgemeines TCP-Relay zu dienen. Diese Methodik setzt ProxyJump auf dem Client, schränkt AllowTcpForwarding und PermitOpen auf der Bastion ein und begrenzt Ausnahmen mit einem Match-Block statt mit einer globalen Freigabe.
-
Integrierten OpenSSH Server unter Windows Server installieren und absichern
Add-WindowsCapability installiert das Feature OpenSSH Server. Die Datei sshd_config liegt unter %ProgramData%\ssh. Öffentliche Schlüssel von Administratoren gehören in administrators_authorized_keys, deren ACL eingeschränkt sein muss, sonst ignoriert der Server sie. DefaultShell legt fest, was eine SSH-Sitzung tatsächlich ausführt.
-
Einen SSH-Server härten, ohne sich selbst auszusperren
Passwort- und Keyboard-Interactive-Login abschalten, root und die erlaubten Nutzenden einschränken, MaxAuthTries und LoginGraceTime eng halten, ProxyJump gegenüber Agent-Forwarding bevorzugen, und jede Änderung an sshd_config mit sshd -t prüfen, während eine zweite Sitzung offen bleibt.
Maschinenlesbar: JSON