SSH-Konfiguration shell.uugrn.org

[Christian Weisgerber <naddy@xxxxxxxxxxxx>]

Kürzlich habe ich mal "ssh -v" zu armshell gemacht und mich gewundert,
warum da kein neuerer KEX verwendet wird. Dann habe ich "ssh -vvv"
gemacht, mich noch mehr gewundert und mir schließlich die sshd_config
angeschaut.

Ein paar grundsätzliche Dinge...

Das größte potentielle Sicherheitsproblem bei SSH ist der Benutzer
und dessen Umgang mit seinen privaten Schlüsseln. Über die
Kryptoalgorithmen sollte man sich nicht den Kopf zu zerbrechen.
Allerdings sind in den letzten Jahren neue Verfahren zum
Verbindungsschlüsselaustausch (key exchange, KEX) hinzugekommen,
so genannte Post-Quanten-Kryptografie (PQC), die ein Mitschneiden
von Verbindungen heute und Entschlüsseln in der Zukunft mit
Quantencomputern unmöglich machen sollen. Diesen Sicherheitsgewinn
kann man mitnehmen.

Es ist in den allermeisten Fällen sinnvoll, einfach die Voreinstellungen
von OpenSSH für die Kryptoalgorithmen zu übernehmen, die sorgfältig
nach Sicherheit, Kompatibilität und Geschwindigkeit abgewogen sind.
Wenn man unbedingt einzelne Verfahren abschalten will, dann
sinnvollerweise mit einer Negativliste "-foo,bar", die nur genau
diese deaktiviert. Eine Positivliste "foo,bar" ist gerne veraltet
und deaktiviert dann neuere Verfahren (oder reaktiviert gar ältere,
die aus der Standardeinstellung herausgenommen wurden).

Ich weiß nicht, wo die Konfiguration auf {x86,arm}shell herkommt,
vielleicht von einem dieser fragwürdigen "SSH Hardening"-Führer,
die da kursieren. Ich gehs mal der Reihe nach durch, auch wenn ich
die Diskussion um einzelne Algorithmen für verfehlt halte, s.o.

> HostKeyAlgorithms ssh-ed25519-cert-v01@xxxxxxxxxxx,ssh-ed25519

Weiß nicht, warum man anderes abschalten will, aber von mir aus.

> KexAlgorithms curve25519-sha256

Traurig, dass hier mit sntrup761x25519-sha512 ein verfügbares neueres
PQ-Verfahren - unabsichtlich? - abgeschaltet wird.

> Ciphers chacha20-poly1305@xxxxxxxxxxx,aes256-gcm@xxxxxxxxxxx

Weiß nicht, warum man AES-128 abschaltet, insbesondere wenn man
oben den PQ-KEX herausnimmt.

> MACs hmac-sha2-512-etm@xxxxxxxxxxx

Da oben nur noch AEAD-Chiffren erlaubt wurden, ist diese Einstellung
bedeutungslos und kann nicht mehr angewendet werden.

> HostbasedAcceptedKeyTypes ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519

Das Schlüsselwort heißt inzwischen HostbasedAcceptedAlgorithms,
Obiges ist nur noch ein Kompatibilitätsalias.

Hostbasierte Authentisierung kann man verwenden, wenn man eine
Gruppe Maschinen zusammen verwaltet, so dass der Benutzer sich nur
beim Login auf einer davon ausweisen muss und Verbindungen zu den
anderen dann nur über die Herkunft von einer vertrauenswürdigen
Maschine authentisiert werden. Das einzurichten ist hinreichend
fummelig, dass ich einen Spickzettel dafür habe. Ich glaube nicht,
dass {x86,arm}shell Teil eines solchen Aufbaus sind.

Wenn man sowas macht, dann gestattet man sinnvollerweise dieselben
Algorithmen wie bei HostKeyAlgorithms, da sich ja der Quellhost
gegenüber dem Zielhost ausweist.

> PubkeyAcceptedAlgorithms sk-ecdsa-sha2-nistp256@xxxxxxxxxxx,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,sk-ssh-ed25519@xxxxxxxxxxx,ssh-ed25519,rsa-sha2-512

Zertifikate und rsa-sha2-256 herausgenommen? Warum nur?

> CASignatureAlgorithms ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519

Warum sollte ich meine Zertifikate, die ich ohnehin nicht verwenden
darf, nicht mit einem FIDO-Authentikator signieren dürfen?

Ja, also das wirkt insgesamt in sich widersprüchlich und nicht recht
durchdacht.

-- 
Christian "naddy" Weisgerber                          naddy@xxxxxxxxxxxx

-- 
Unix User Group Rhein-Neckar e.V.: https://www.uugrn.org
Archiv und An-/Abmeldung:          https://mail2.uugrn.org
Social Media:                      https://social.uugrn.org