LPIC102/110.3 SSH Authentifizierung mit Schlüsseln: Unterschied zwischen den Versionen
Zeile 44: | Zeile 44: | ||
Wenn es sich um keine echte man-in-the-middle-attack handelt, entfernt man mithilfe eines Editors den veralteten Schlüssel aus der known_hosts-Datei und baut die Verbindung erneut auf. | Wenn es sich um keine echte man-in-the-middle-attack handelt, entfernt man mithilfe eines Editors den veralteten Schlüssel aus der known_hosts-Datei und baut die Verbindung erneut auf. | ||
==/etc/ssh/ssh_known_hosts== | ==/etc/ssh/ssh_known_hosts==<br> | ||
Die | Die Datei macht nichts anderes als die Datei ~/.ssh/known_hosts für jeden Benutzer, nur eben zentralisiert. | ||
===Hostkeys=== | ===Hostkeys=== | ||
Zeile 53: | Zeile 52: | ||
OpenSSH erstellt in der Regel automatisch Hostkeys. | OpenSSH erstellt in der Regel automatisch Hostkeys. | ||
Sie dienen der Authentifizierung zwischen Server und Clientcomputer. | Sie dienen der Authentifizierung zwischen Server und Clientcomputer. | ||
ssh_host_dsa_key | ssh_host_dsa_key | ||
Zeile 66: | Zeile 64: | ||
Ohne Dateierweiterung = privater Schlüssel.<br> | Ohne Dateierweiterung = privater Schlüssel.<br> | ||
Mit Erweiterung .pub = öffentlicher (public) Schlüssel.<br> | Mit Erweiterung .pub = öffentlicher (public) Schlüssel.<br> | ||
Die Konfigurationsdatei dazu ist sshd_config. | Die Konfigurationsdatei dazu ist sshd_config.<br> | ||
Erläuterung zu den einzelnen Schlüsseldateien:<br> | |||
DSA: veraltet, bekannte Schwächen, wird nicht mehr unterstützt.<br> | DSA: veraltet, bekannte Schwächen, wird nicht mehr unterstützt.<br> | ||
ECDSA: Momentan Standard bei Linux-Distributionen, kleinere Schlüsselgrößen als etwa RSA, Verdacht die gleichen Schwächen aufzuweisen wie DSA. | ECDSA: Momentan Standard bei Linux-Distributionen, kleinere Schlüsselgrößen als etwa RSA, Verdacht die gleichen Schwächen aufzuweisen wie DSA. | ||
Zeile 77: | Zeile 76: | ||
ssh-keygen generiert neue Schlüssel.<br> | ssh-keygen generiert neue Schlüssel.<br> | ||
Optional die Pfadangabe des Users angeben.<br> | Optional die Pfadangabe des Users angeben.<br> | ||
Option –t legt den Typ des | Option –t legt den Typ des Schlüssels fest.<br> | ||
Zur Auswahl stehen rsa, dsa, ecdsa und ed25519.<br> | Zur Auswahl stehen rsa, dsa, ecdsa und ed25519.<br> | ||
Zeile 85: | Zeile 84: | ||
Es wurde keine passphrase verwendet. | Es wurde keine passphrase verwendet. | ||
# ssh-keygen -t rsa | |||
Generating public/private rsa key pair. | Generating public/private rsa key pair. | ||
Enter file in which to save the key (/root/.ssh/id_rsa): | Enter file in which to save the key (/root/.ssh/id_rsa): | ||
Zeile 103: | Zeile 102: | ||
Folgende Kommandos können vom Clientsystem verwendet werden um den öffentlichen Schlüssel zu importieren: | 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=== | ===Benutzerauthentifizierung mit Schlüsseln=== | ||
Hostkeys können auch zur Authentifizierung von Benutzern verwendet werden. <br> | |||
Verzichtet man | Verzichtet man auf ein Passwortes, lassen sich ssh oder scp in Skripten z. B. für Backups zu verwenden.<br> | ||
Generierung der Schlüssel ebenfalls mittels ssh-keygen.<br> | |||
Schlüssel werden automatisch an der richtigen Stelle abgelegt:<br> | |||
$ ssh-keygen -t ecdsa | $ ssh-keygen -t ecdsa | ||
Zeile 155: | Zeile 154: | ||
Die Dateinamen zu den Schlüsseln sind im Unterkapitel Hostkeys beschrieben.<br> | Die Dateinamen zu den Schlüsseln sind im Unterkapitel Hostkeys beschrieben.<br> | ||
Für die Authentifizierung wird nur ein Schlüsselpaar benötigt.<br> | Für die Authentifizierung wird nur ein Schlüsselpaar benötigt.<br> | ||
Server und Client müssen | Server und Client Schlüsseltyp müssen natürlich identisch sein. | ||
===Der Authentifizierungsagent=== | ===Der Authentifizierungsagent=== | ||
Der SSH-Agent ist eine weitere Möglichkeit ohne Passwörter Authentifizierungen auszuführen.<br> | |||
Es lassen sich mehrere Schlüssel für einen Benutzer verwalten.<br> | |||
Dafür muss er bei der Startphase von X ausgeführt werden.<br> | Dafür muss er bei der Startphase von X ausgeführt werden.<br> | ||
ssh-add kann dem SSH-Agent Schlüssel hinzufügen.<br> | ''ssh-add'' kann dem SSH-Agent Schlüssel hinzufügen.<br> | ||
Ohne Optionen sucht das Programm automatisch nach<br> | Ohne Optionen sucht das Programm automatisch nach<br> | ||
~/.ssh/id_rsa, ~/.ssh/id_dsa, ~/.ssh/id_ecdsa, ~/.ssh/id_ed25519 und ~/.ssh/identity.<br> | ~/.ssh/id_rsa, ~/.ssh/id_dsa, ~/.ssh/id_ecdsa, ~/.ssh/id_ed25519 und ~/.ssh/identity.<br> | ||
Wichtige Optionen sind: | Wichtige Optionen sind: | ||
Version vom 29. Juli 2019, 11:54 Uhr
Vorführung presentationsrechner überträgt schlüssel zu meik rechner und hinterlegt seinen privatkey danach profil erstellung in konsole um einfache handhabung zu zeigen
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:
[root@scientific /]# 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.
Wenn es sich um keine echte man-in-the-middle-attack handelt, entfernt man mithilfe eines Editors den veralteten Schlüssel aus der known_hosts-Datei und baut die Verbindung erneut auf.
==/etc/ssh/ssh_known_hosts==
Die Datei macht nichts anderes als die Datei ~/.ssh/known_hosts für jeden Benutzer, nur eben zentralisiert.
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: Momentan Standard bei Linux-Distributionen, kleinere Schlüsselgrößen als etwa RSA, Verdacht die gleichen 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.
Benutzereingaben fett gedruckt.
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.
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 Dateinamen der Benutzerschlüssel und Serverschlüssel sind Prüfungsrelevant.
Sie befinden sich allesamt 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.
GnuPG
GNU Privacy Guard, auch kurz als GPG bezeichnet
Auf einfache Weise Daten verschlüsseln oder signieren. Bietet asymmetrisches Verschlüsselungsverfahren. Bedeutet, ein Schlüsselpaar ist erforderlich. Der öffentliche Schlüssel ist der Verschlüsselungsschlüssel, der private Schlüssel ist der Entschlüsselungsschlüssel. Der private Schlüssel wird beim Generieren von Signaturen verwendet. Das sind zwei gute Gründe, den Schlüssel wie seinen eigenen Augapfel zu schützen.
Zur Sicherheit können Sie den Schlüssel der symmetrischen Verschlüsselung anschließend mit einem asymmetrischen
Schlüssel verschlüsseln.
Man spricht dann bei dem verwendeten öffentlichen Schlüssel auch von einem Schlüsselverschlüsselungsschlüssel.
Eine grafische Benutzeroberfläche bietet der GNU Privacy Assistant (GPA) für GNOME das Programm Seahorse, und für KDE wurde KGpg entwickelt.
Damit Windows-Computer in einem solchen Umfeld nicht zur Sicherheitslücke werden, können diese Gpg4win einsetzen, das übrigens absolut kompatibel zu den Linux-Versionen ist.