by SSH ist nicht nur ein Protokoll, sondern ein unglaublich mächtiges Framework, weshalb ich in weiteren Beiträgen noch häufiger auf das Thema SSH zurückkommen werde.
Wer einen Server im Internet betreibt und dort für einen sicheren Remote-Zugang einen SSH-Server-Dienst installiert hat, wird beim Prüfen der Logs vielleicht überrascht sein, wieviel Login-Versuche von einer Vielzahl an unterschiedlichen IP-Adressen täglich versucht werden. Das ist leider gar nicht so ungewöhnlich. Deshalb sollte ein Administrator immer bemüht sein, Login-Methoden zu wählen, die einen sehr guten Kompromiss zwischen Sicherheit und Nutzbarkeit bieten. Und da kann ein Passwort noch so lang sein – ist das Passwort einmal kompromittiert, ist der Ärger groß.
Denn Zugangssicherheit wird über das erste A von Triple-A sichergestellt – Authorisierung.
Alles was du grundsätzlich für eine Absicherung von SSH mittels Zertifikaten benötigst, ist einen privaten und einen öffentlichen Schlüssel (Zertifikat) – dass vorzugsweise für jeden einzelnen Endnutzer/Endgerät, welches mit dem Server kommunizieren soll. Denn nur so ist es möglich, das wenn ein privater Schlüssel kompromittiert wird (Verlust der Hardware, wo dieser Schlüssel gespeichert war, etc.), explizit nur dieser Zugang gesperrt wird. Du solltest dir bewusst kein Schlüsselpaar für den Root-Nutzer (System-Administrator) anlegen, da du dich von vornherein mit niedrigen Rechten auf dem Zielsystem einloggen solltest und dann ggf. die Rechte eskalierst (bei Bedarf zu Root upgraden).
Im folgenden ist das Mini-Lab grafisch veranschaulicht. Ziel ist es, das sich Benutzer Alice als Benutzer Bob auf dem Ziel-System per SSH mittels Public-Key-Verfahren einloggt. Ich habe hier bewusst unterschiedliche Benutzer gewählt, um im späteren Verlauf zu verdeutlichen, welcher Account im jeweilgen Schritt eigentlich von Bedeutung ist. Clientseitig kann diese Anleitung auch 1:1 auf Windows 10 angewendet werden, die Befehle sind unter OPENssh identisch.
+----------------+ +----------------+ | ssh | | ssh | | client | | debian-server | | User: alice | | User: bob | | 10.0.0.1 | ==== ssh ===> | 10.0.0.5 | +----------------+ +----------------+
Falls du noch gar keinen SSH-Server installiert hast, solltest du dies erstmal nachholen. Update zunächst deine Paketquellen, installiere den SSH-Server und vergewissere dich, dass dieser anschließend auch fehlerfrei (Status active (runnig)) läuft (zu all dem benötigst du Root-Rechte):
# apt update
...
# apt install openssh-server
...
# systemctl status ssh
● ssh.service - OpenBSD Secure Shell server
Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: enabled)
Active: active (running) since Wed 2021-06-16 10:09:55 CEST; 23h ago
Docs: man:sshd(8)
man:sshd_config(5)
Main PID: 546 (sshd)
Tasks: 1 (limit: 4915)
Memory: 9.1M
CGroup: /system.slice/ssh.service
└─546 /usr/sbin/sshd -D
Nach dem einloggen auf dem Client-System mit Standard-Benutzer-Rechten erstellst du dir zuerst direkt im Home-Verzeichnis des Benutzers ein Schlüsselpaar:
$ ssh-keygen -b 4096
Generating public/private rsa key pair.
Enter file in which to save the key (/home/alice/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/alice/.ssh/id_rsa.
Your public key has been saved in /home/alice/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:MldeE01jc8RD3JPmv/S9d80CJsSUKxVHi+Antom6HDQ alice@10.0.0.1
The key's randomart image is:
+---[RSA 4096]----+
| . .++oB+=|
| . .+o +.Xo|
| +++.+ o o|
| o.B+. . . |
| E + So. .|
| . o + . o ..|
| o o ...=|
| . o ..B|
| o o+|
+----[SHA256]-----+
Dabei wirst du gefragt, ob du eine Passphrase angeben möchtest Ein Login ausschließlich mit Zertifikat (etwas was man besitzt) ist zwar bequem, aber da es hier um Sicherheit geht, empfehle ich dringend die Angabe eines Passwortes bzw. Passphrase (etwas was man weiß). Das ist bereits die einfache Form einer Zwei-Faktor-Autorisierung. Außerdem liegt der Schlüssel dann nicht mehr im Klartext vor, sondern ist zusätzlich AES-CBC verschlüsselt. Ohne Passphrase ist ein späterer Login auf dem Server ohne weitere Angabe eines Passwortes möglich.
Im versteckten Unterverzeichnis .ssh liegen dann folgende neue Dateien, welche sich jeweils auch mit dem Kommando cat anzeigen lassen:
- id_rsa (privater Schlüssel)
- id_rsa.pub (öffentlicher Schlüssel)
Als nächstes musst du den öffentlichen Schlüssel auf den SSH-Server übertragen:
$ ssh-copy-id -i ./.ssh/id_rsa.pub bob@10.0.0.5
bob@10.0.0.5's password:
Now try logging into the machine, with "ssh 'bob@10.0.0.5'", and check in:
~/.ssh/authorized_keys
to make sure we haven't added extra keys that you weren't expecting.Gegebenenfalls wirst du noch nach der Richtigkeit des Footprints (Fußabdrucks) gefragt, sofern du diesen speicherst (YES), allerdings nur bei der ersten Verbindung mit diesem Server. Dieser Footprint wird ebenfalls im Unterverzeichnis .ssh deines Client-Homelaufwerkes unter known_hosts gepeichert.
$ cat .ssh/known_hosts
10.0.0.5 ssh-rsa AAAAB3NzaC5yc2EAAAADWQAB
...
uSMSFX0/J8iV7CdrReBZB3lt73iIiWolJCzWie du bei dem ssh-copy-id-Kommando gesehen hast, wird auf dem SSH-Server im Unterverzeichnis .ssh des Benutzer Bob eine Datei authorized_keys erstellt. Diese enthält die Public Keys der jeweiligen Clients. Am Ende jeden Eintrages steht dann der zugehörige Benutzer/Host:
bob@10.0.0.5~$ less .ssh/authorized_keys
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDTtWO
...
/H/Kl/iAt3UwTL7dCbX1ggPdktfR/HicoCXw6FsSUFgw== alice@10.0.0.1Sollte jemals später erneut die Sicherheitsfrage nach dem Bestätigen des Footprints erfolgen, solltest du vorsichtig sein und dir überlegen, ob du am SSH-Server irgendetwas geändert hast, was zu einem anderen Fußabdruck führen könnte. Eventuell ist das gar nicht mehr dein Server, zu dem du dich gerade verbindest (Man-in-the-Middle-Attack).
Als nächstes testet du die Verbindung zum SSH-Server mittels der neu generierten Key-Authentifizierung
$ ssh -i .ssh/id_rsa bob@10.0.0.5
Authenticating with public key:Du wirst daraufhin nach der Passphrase für den Key gefragt (nicht dein bisheriges Passwort für den SSH-Server), anschließend bist du als Benutzer Bob auf dem SSH-Server eingeloggt.
Abschließend solltest du noch ein paar Einstellungen an deinem neu installierten SSH-Server durchführen. Logge dich dazu auf deinen SSH-Server ein, bearbeite als Root die Datei /etc/ssh/sshd_config und starte den Dienst anschließend neu.
# nano /etc/ssh/sshd_conf
RequiredAuthentications2 publickey # aktiviert Protocol-version 2
PermitRootLogin no # verbietet SSH-Zugriff für Root
PasswordAuthentication no # verbietet grundsätzlich Passwort-Authentifizierung,
# somit ist nur noch Public-Key möglich
# systemctl restart sshFür weitergehende Informationen bezüglich der sshd_conf empfehle ich die Man-Pages.