LPIC102/110.3 SSH Authentifizierung mit Schlüsseln: Unterschied zwischen den Versionen
K Textersetzung - „Netzwerke:Informationssicherheit“ durch „Netzwerksicherheit“ |
K Textersetzung - „Kategorie:Secure Shell“ durch „Kategorie:SSH“ |
||
(16 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) | |||
Zeile 4: | Zeile 4: | ||
* In der Meldung erscheint auch der Fingerprint des Hostkeys | * In der Meldung erscheint auch der Fingerprint des Hostkeys | ||
# ssh uvm1.nwa-net.de | |||
The authenticity of host | The authenticity of host | ||
uvm1.nwa-net.de (176.95.26.236)' can't be established | uvm1.nwa-net.de (176.95.26.236)' can't be established | ||
Zeile 103: | Zeile 103: | ||
* Hostkeys können auch zur Authentifizierung von Benutzern verwendet werden | * Hostkeys können auch zur Authentifizierung von Benutzern verwendet werden | ||
* Verzichtet man auf ein Passwortes, lassen sich ''ssh'' oder ''scp'' in Skripten z. B. für Backups zu verwenden | * Verzichtet man auf ein Passwortes, lassen sich ''ssh'' oder ''scp'' in Skripten z. B. für Backups zu verwenden | ||
* Generierung der Schlüssel ebenfalls mittels ''ssh-keygen'' | * Generierung der Schlüssel ebenfalls mittels ''ssh-keygen'' | ||
* Schlüssel werden automatisch an der richtigen Stelle abgelegt | * Schlüssel werden automatisch an der richtigen Stelle abgelegt | ||
Zeile 169: | Zeile 169: | ||
= Links = | = Links = | ||
== Intern == | == Intern == | ||
# [[LPIC102 | # [[LPIC102/110.3 Schlüsselerstellung mit GnuPG]] | ||
== Weblinks == | == Weblinks == | ||
[[ | [[Kategorie:Linux/LPIC/102]] | ||
[[ | [[Kategorie:SSH]] | ||
Aktuelle Version vom 30. Dezember 2023, 03:25 Uhr
Authentifizierung der Server mit Schlüsseln
- Server authentifiziert sich am Client mit seinem Hostkey
- Ist der Ziel-Host dem Client noch nicht bekannt, erfolgt eine Warnmeldung
- In der Meldung erscheint auch der Fingerprint des Hostkeys
# ssh uvm1.nwa-net.de The authenticity of host uvm1.nwa-net.de (176.95.26.236)' can't be established ECDSA key fingerprint is SHA256:TbVCtl6TJHAHacrTdwh9gqzvx8fB5bzhi1lL/ByFbYE ECDSA key fingerprint is MD5:c8:db:4a:6f:99:7a:e9:9d:ca:82:c7:36:99:ac:14:c9 Are you sure you want to continue connecting (yes/no)?
- Bestätigt man mit yes, wird der Hostkey des Servers in die Datei ~./ssh/known_hosts des Benutzers eingetragen und die Verbindung hergestellt
- Bei späteren Anmeldungen entfällt entsprechend die Warnmeldung
- Folgendes Kommando zeigt eine Liste der bekannten Hosts
# ssh-keygen -l -f ~/.ssh/known_hosts 256 SHA256:VOrsAcZc//9EiAATV2DfSN2jHONQBEuJpyrmW+Q3CWQ user,192.168.178.2 (ECDSA) 256 SHA256:TbVCtl6TJHAHacrTdwh9gqzvx8fB5bzhi1lL/ByFbYE uvm1.nwa-net.de,176.95.26.236 (ECDSA)
- Ändert sich der Schlüssel eines Zielsystems, erfolgt die Warnmeldung
$ ssh scientific @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that a host key has just been changed. The fingerprint for the ECDSA key sent by the remote host is SHA256:r+9OEu2EM5ubr0P5wl4lLgUo5n/8/AkX2exIiPqQ9rs. Please contact your system administrator. Add correct host key in /root/.ssh/known_hosts to get rid of this message. Offending ECDSA key in /root/.ssh/known_hosts:15 ECDSA host key for scientific has changed and you have requested strict checking. Host key verification failed.
- Bei einer echten man-in-the-middle-attack, Schlüssel aus der known_hosts-Datei entfernen und Verbindung neu aufbauen
- Die Datei /etc/ssh/ssh_known_hosts macht nichts anderes als die Datei ~/.ssh/known_hosts für jeden Benutzer, nur eben am Client
Hostkeys
- OpenSSH erstellt in der Regel automatisch Hostkeys
- Sie dienen der Authentifizierung zwischen Server und Clientcomputer
ssh_host_dsa_key ssh_host_dsa_key.pub ssh_host_ecdsa_key ssh_host_ecdsa_key.pub ssh_host_ed25519_key ssh_host_ed25519_key.pub ssh_host_rsa_key ssh_host_rsa_key.pub
- Ohne Dateierweiterung = privater Schlüssel
- Mit Erweiterung .pub = öffentlicher (public) Schlüssel
- Die Konfigurationsdatei dazu ist sshd_config
Erläuterung zu den einzelnen Schlüsseldateien
- DSA: veraltet, bekannte Schwächen, wird nicht mehr unterstützt
- ECDSA: Standard bei Linux-Distros, kleinere Schlüsselgrößen als etwa RSA, Verdacht gleiche Schwächen aufzuweisen wie DSA
- RSA: etablierter Standard, überall unterstützt, existiert seit 1977
- Ed25519: ähnelt technisch ECDSA, weist jedoch nicht dieselbe Schwäche auf
- Wird von sehr neuen SSH-Versionen unterstützt, empfiehlt sich daher nicht als Standalone-Lösung, wenn man auch ältere Clientsysteme im Einsatz hat
- ssh-keygen generiert neue Schlüssel
- Optional die Pfadangabe des Users angeben
- Option –t legt den Typ des Schlüssels fest
- Zur Auswahl stehen rsa, dsa, ecdsa und ed25519
Beispiel:
- Erstellen eines neuen Schlüsselpaares für RSA
- Es wurde keine passphrase verwendet
# ssh-keygen -t rsa Generating public/private rsa key pair. Enter file in which to save the key (/root/.ssh/id_rsa): /etc/ssh/ssh_host_rsa_key /etc/ssh/ssh_host_rsa_key already exists. Overwrite (y/n)? y Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /etc/ssh/ssh_host_rsa_key. Your public key has been saved in /etc/ssh/ssh_host_rsa_key.pub. The key fingerprint is: SHA256:zinmLbZLTBxcCOWN52QBDniQVAE9GfD/MuuQHzk3QQ4 root@scientific
- Generierte Datei ssh_host_rsa_key.pub enthält den öffentlichen Schlüssel des Systems
- Dieser lässt sich an Clients verteilen
- Datei ssh_host_rsa_key enthält privaten Schlüssel des Servers (geheim halten)
Folgende Kommandos können vom Clientsystem verwendet werden um den öffentlichen Schlüssel zu importieren
# scp scientific:/etc/ssh/ssh_host_rsa_key.pub ./ # cat ssh_host_rsa_key.pub >> /etc/ssh/ssh_known_hosts # rm ssh_host_rsa_key.pub
Benutzerauthentifizierung mit Schlüsseln
- Hostkeys können auch zur Authentifizierung von Benutzern verwendet werden
- Verzichtet man auf ein Passwortes, lassen sich ssh oder scp in Skripten z. B. für Backups zu verwenden
- Generierung der Schlüssel ebenfalls mittels ssh-keygen
- Schlüssel werden automatisch an der richtigen Stelle abgelegt
$ ssh-keygen -t ecdsa Generating public/private ecdsa key pair. Enter file in which to save the key (/home/harald/.ssh/id_ecdsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/harald/.ssh/id_ecdsa. Your public key has been saved in /home/harald/.ssh/id_ecdsa.pub. The key fingerprint is: SHA256:Br+8SdXitm/XnUmqVQB1/+aO0HkJKsrbAjzvTwV8FNI user@10.0.0.1
- Der Schlüssel wurde ohne passphrase erstellt und muss jetzt auf die Zielsysteme verteilt werden
- Dafür verwendet man das komfortable Tool ssh-copy-id
$ ssh-copy-id user /usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/harald/.ssh/id_ecdsa.pub" The authenticity of host 'archangel (192.168.178.2)' can't be established. ECDSA key fingerprint is SHA256:VOrsAcZc//9EiAATV2DfSN2jHONQBEuJpyrmW+Q3CWQ. ECDSA key fingerprint is MD5:8d:28:e5:f1:3b:e2:fd:69:cf:28:d9:06:5e:30:f3:30. Are you sure you want to continue connecting (yes/no)? yes /usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed /usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
- Der Schlüssel wurde in die Datei ~/.ssh/authorized_keys des Zielsystems (user) eingetragen und muss nun bei weiteren Anmeldungen nicht mehr angegeben werden
- Die Schlüsseldateien befinden sich im Verzeichnis ~/.ssh eines Benutzers und lauten auf diese Dateinamen
id_rsa id_rsa.pub id_dsa id_dsa.pub id_ecdsa id_ecdsa.pub id_ed25519 id_ed25519.pub
- Die Dateinamen zu den Schlüsseln sind im Unterkapitel Hostkeys beschrieben
- Für die Authentifizierung wird nur ein Schlüsselpaar benötigt
- Server und Client Schlüsseltyp müssen natürlich identisch sein
Der Authentifizierungsagent
- Der SSH-Agent ist eine weitere Möglichkeit ohne Passwörter Authentifizierungen auszuführen
- Es lassen sich mehrere Schlüssel für einen Benutzer verwalten
- Dafür muss er bei der Startphase von X ausgeführt werden
- ssh-add kann dem SSH-Agent Schlüssel hinzufügen
- Ohne Optionen sucht das Programm automatisch nach
~/.ssh/id_rsa, ~/.ssh/id_dsa, ~/.ssh/id_ecdsa, ~/.ssh/id_ed25519 und ~/.ssh/identity.
Wichtige Optionen sind:
-l – listet die Fingerabdrücke der verfügbaren Schlüssel auf -d – entfernt einen einzelnen (angegebenen) Schlüssel vom Agenten -D – entfernt alle Schlüssel vom Agenten -s – liest Schlüssel von einer Smartcard -e – entfernt Schlüssel der Smartcard -x – sperrt den Agenten (mit Passwortschutz) -X – entsperrt den Agenten