Oder wie man das meiste aus SSH herauskitzelt.
SSH wird von den meisten Sysadmins genutzt, aber selten so wie es genutzt werden sollte.
Die meisten Administratoren verwenden das folgende Kommando Tag ein Tag aus.
ssh-keygen -t rsa -b 4096 -C "dummy_user@fqdn_dummy.com"
Zerlegen wir das Kommando mal in seine Einzelteile und versuchen zu verstehen was diese eigentlich tun.
Der Parameter '-t' gibt an welchen Key-Typ wir rsa/dsa/ecdsa/ecdsa-sk/ed25519 erstellen wollen. Hierbei wird von kleineren RSA-Keys unter 4096 Bits inzwischen abgeraten. DSA ist als unsicher deklariert und sollte auch seit Version 7 von OpenSSH auch nicht verwendet werden. ECDSA ist wegen der NSA ggf. problematisch zum nachlesen hier. So bleibt nur ED25519 welchen ich bei meiner täglichen Arbeit kaum sehe. Dies sollte aber heutzutage der De-Facto-Standard-Key sein, mit dem das obige Kommando aufgerufen wird.
'-b' für die Bits welche verwendet werden sollen. Wenn nun an dieser Stelle die Frage aufkommt mit welcher Bits-Anzahl ED25519 erstellt werden sollte, sei gesagt dass dieser eine festgelegte Länge hat und damit diesen Parameter ignoriert.
'-C' steht für Comment und dieser kann beliebig sein. Zumeist wird hier aber zur besseren Nachvollziehbarkeit von den Admins dieser Welt das Pattern Username@Hostname verwendet, damit man sehen kann für wen dieser Key erstellt wurde.
Im obigen Beispiel fehlt der Parameter '-N' welcher für new_passphrase bzw. das Passwort steht, wenn man den fehlenden Parameter '-N' mit "" ohne Zeichenkette angibt erhält man einen passwortlosen, privaten SSH-Schlüssel. Zusätzlich wird ein öffentlicher Schlüssel erstellt.
Verbessern wir das obige Kommando: ssh-keygen -t ed25519 -N'' -C 'dummy_user@fqdn_dummy.com'
Der Output des Beispiels:
ssh-keygen -t ed25519 -N'' -C'dummy_user@fqdn_dummy.com' Generating public/private ed25519 key pair. Enter file in which to save the key (/root/.ssh/id_ed25519): /root/.ssh/dummy Created directory '/root/.ssh'. Your identification has been saved in /root/.ssh/dummy. Your public key has been saved in /root/.ssh/dummy.pub. The key fingerprint is: SHA256:14RQXbFyQCtEZfnGN8O7hV4h9hAEY0SYQN9Y0+9TRp8 root@fqdn_dummy.com The key's randomart image is: +--[ED25519 256]--+ | .oooO%O+o. | | .==o== ..| | oo.+o*.o| | + *+E=| | S . o.=+*| | . .=o| | . .+| | .. | | | +----[SHA256]-----+
[root@fqdn_dummy.com .ssh]# ll total 8 -rw-------. 1 root root 464 Nov 14 22:45 dummy -rw-r--r--. 1 root root 108 Nov 14 22:45 dummy.pub
Damit hätten wir einen Standard-SSH-Schlüsselpaar, welches zumeist in den Unternehmen vergessen wird, wenn Mitarbeiter das Unternehmen verlassen oder die Abteilungen wechseln und auch durch automatisierte Deployments wird es oft als Karteileiche liegen gelassen.
Wie wäre es wenn wir ablaufende SSH-Schlüsselpaare hätten, welche nach einer gewissen Zeit ablaufen und zwar von selbst?
Was vielen nicht bewusst ist, ist dass dies SSH eigentlich schon von ganz allein kann, nur nutzt es kaum jemand.
Beginnen wir mit dem ersten Schritt und generieren uns eine CA (Certificate Authority).
ssh-keygen -t ed25519 -N '' -C 'ca' -f ca
Da diese CA unser Dreh- und Angelpunkt ist bedarf es Achtsamkeit, damit diese nie in falsche Hände gelangt.
Dank dieser CA können wir nun Zertifikate von Hosts und Benutzern signieren.
Als Beispiel nehmen wir einen Benutzer 'test' welcher sich per SSH an den Host namens ColdMoon anmelden soll.
Wir brauchen also für beide Zertifikate und einen SSH Schlüssel.
Bevor wir es vergessen müssen wir unsere vorher erstellte CA auf unserem SSH Server in der sshd_config als 'TrustedUserCAKeys /etc/ssh/ca.pub' eintragen.
Nun nehmen wir von unserem Benutzer 'test' auf seinem Laptop und den dort bereits erstellten öffentlichen Schlüssel mit dem wir ihm begrenzten Zugriff auf unsere Infrastruktur geben wollen in diesem Fall unser Rechner ColdMoon.
Im Vorfeld haben wir schon den Benutzer auf dem Rechner angelegt, und der Kollege 'test' hat uns seinen öffentlichen Schlüssel per Email geschickt.
Von unserem Vorgesetzten wissen wir das der Kollege 'test' nur 1 Woche ein Praktikum bei uns vornimmt und danach das Unternehmen wieder verlässt.
Auf gehts wir erstellen einen zeitlich begrenzten Zugang:
ssh-keygen -s ca -I Azubi_auf_Zeit -n test -V +1w -z 1 test.pub Signed user key test-cert.pub: id "Azubi_auf_Zeit" serial 1 for test valid from 2019-11-13T09:00:00 to 2019-11-20T09:00:00
Das Resultat dieses Kommandos ist das wir ein signiertes 'test-cert.pub' erhalten mit eine Lebenszeit von 1 Woche.
Dieses senden wir umgehend unseren Praktikanten zu mit dem Hinweis das er sich mit dem folgenden Kommando nun an dem Rechner ColdMoon anmelden kann.
ssh -i ~/.ssh/test -i ~/.ssh/test-cert.pub test@ColdMoon -v
Ich habe mal den Verbose-Schalter genommen um zu zeigen wie das Zertifikat sich dann gegen ColdMoon anmeldet.
...
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<rsa-sha2-256,rsa-sha2-512>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: publickey
debug1: Offering public key: test ED25519 SHA256:4A3ab2/7dq0klERi9IevmSnTZd7dkOuuP8yrWCZ24gI explicit
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Offering public key: test ED25519-CERT SHA256:4A3ab2/7dq0klERi9IevmSnTZd7dkOuuP8yrWCZ24gI explicit
debug1: Server accepts key: test ED25519-CERT SHA256:4A3ab2/7dq0klERi9IevmSnTZd7dkOuuP8yrWCZ24gI explicit
debug1: Authentication succeeded (publickey).
Authenticated to 192.168.242.67 ([192.168.242.67]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: pledge: network
debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
debug1: Requesting authentication agent forwarding.
debug1: Sending environment.
debug1: Sending env LC_CTYPE = UTF-8
Last login: Thu Nov 14 11:00:14 2019 from 192.168.242.225
[test@coldmoon ~]$
Die Authentifizierung wird nun die gesamte Woche lang funktionieren in der der Praktikant Zugriff auf dem Rechner braucht, danach weil es nur zeitlich begrenzt ist nicht mehr. Damit ist für den Praktikanten kein Zugriff auf unserer Infrastruktur mehr möglich. Dies funktioniert auch mit anderen Hosts oder Services, welchen man nur für einen Zeitraum einen begrenzten Zugriff per SSH geben möchte.
Der Parameter '-V' gibt den Validity_Interval an, also den Zeitraum der Gültigkeit, und der Parameter '-z' eine Serialnumber, welche von uns frei gewählt werden kann.
Dies kann mit den üblichen Systemmitteln automatisiert werden oder per Ansible/Puppet auch auf Systeme verteilt werden.
Schöner ist es noch wenn es ohne viel manuelle Arbeit geht. Dies zeige ich in meinem nächsten Blogpost welcher Vault aus dem Hause Hashicorp zeigt.
Gruss
David
0 Kommentare