| Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung |
| linux:ssh:tofu_und_cert [22.04.2025 18:48. ] – TOFU - Trust On First Use - SSH Zertifikate kleinere Rechtscheibkorrekturen django | linux:ssh:tofu_und_cert [26.07.2025 17:42. ] (aktuell) – django |
|---|
| {{htmlmetatags>metatag-robots=() | |
| metatag-keywords=(TOFU,SSH,Zertifikate,ED25519,SHA256,Arch Linux, sicherer IT Betrieb,authorized_keys) | |
| metatag-description=(TOFU - Trust On First Use - SSH Zertifikate) | |
| }} | |
| ====== TOFU - Trust On First Use - SSH Zertifikate ====== | ====== TOFU - Trust On First Use - SSH Zertifikate ====== |
| ===== Ausgangssituation ===== | ===== Ausgangssituation ===== |
| Nov 26 23:57:39 pml010002.intra.nausch.org sshd[16129]: Server listening on 10.0.10.2 port 22. | Nov 26 23:57:39 pml010002.intra.nausch.org sshd[16129]: Server listening on 10.0.10.2 port 22. |
| Nov 26 23:57:39 pml010002.intra.nausch.org systemd[1]: Started OpenSSH server daemon.</font> | Nov 26 23:57:39 pml010002.intra.nausch.org systemd[1]: Started OpenSSH server daemon.</font> |
| </pre></html> \\ Nun ist es an der Zeit unsere Konfiguration auch zu testen. Bis jetzt haben wir vermutlich mit Einträgen in der **''~/.ssh/authorized_keys''** gearbeitet. bei Anmeldung mit Zertifikat benötigen wir die Option aber nicht mehr, da der SSH-Client ja sein Zertifikat dem Server zur Authentifizierung schickt.<code> $ rm ~/.ssh/authorized_keys<code> Die Anmeldung mit Hilfe des privaten SSH-Keys des Admins ist nunmehr unterbunden. Der Administrator kann sich nunmehr nur nur mit (s)einem gültigen Zertifikat anmelden. <code> # ssh -v kvm.intra.nausch.org</code> Der SSH-Server präsentiert dem Client sein Host-Zertifikat und wir sehen auch dass kein **known_hosts**-Dateien mehr benitzt werden (können).: <code>... | </pre></html> \\ Nun ist es an der Zeit unsere Konfiguration auch zu testen. Bis jetzt haben wir vermutlich mit Einträgen in der **''~/.ssh/authorized_keys''** gearbeitet. bei Anmeldung mit Zertifikat benötigen wir die Option aber nicht mehr, da der SSH-Client ja sein Zertifikat dem Server zur Authentifizierung schickt.<code> $ rm ~/.ssh/authorized_keys</code> Die Anmeldung mit Hilfe des privaten SSH-Keys des Admins ist nunmehr unterbunden. Der Administrator kann sich nunmehr nur nur mit (s)einem gültigen Zertifikat anmelden. <code> # ssh -v kvm.intra.nausch.org</code> Der SSH-Server präsentiert dem Client sein Host-Zertifikat und wir sehen auch dass kein **known_hosts**-Dateien mehr benitzt werden (können).: <code>... |
| |
| debug1: Server host certificate: ssh-ed25519-cert-v01@openssh.com SHA256:kIe5Ki/ItvQq9Cpfw/qLReo1wiVkdREVOz6a67I8nO4, serial 1000 ID "kvm" CA ssh-ed25519 SHA256:wOyuN+fm0j83vkViB9Lx2PIiQHRkWD9jBJKRqhEplzk valid from 2023-11-27T12:27:00 to 2024-11-26T12:28:44 | debug1: Server host certificate: ssh-ed25519-cert-v01@openssh.com SHA256:kIe5Ki/ItvQq9Cpfw/qLReo1wiVkdREVOz6a67I8nO4, serial 1000 ID "kvm" CA ssh-ed25519 SHA256:wOyuN+fm0j83vkViB9Lx2PIiQHRkWD9jBJKRqhEplzk valid from 2023-11-27T12:27:00 to 2024-11-26T12:28:44 |
django