LPIC102/110.3 SSH Authentifizierung mit Schlüsseln: Unterschied zwischen den Versionen

Aus Foxwiki
Meikschwalm (Diskussion | Beiträge)
Keine Bearbeitungszusammenfassung
K Textersetzung - „Kategorie:Secure Shell“ durch „Kategorie:SSH“
 
(39 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
'''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==
==Authentifizierung der Server mit Schlüsseln==
* Server authentifiziert sich am Client mit seinem Hostkey.<br>
* Server authentifiziert sich am Client mit seinem Hostkey
* Ist der Ziel-Host dem Client noch nicht bekannt, erfolgt eine Warnmeldung.<br>
* Ist der Ziel-Host dem Client noch nicht bekannt, erfolgt eine Warnmeldung
* In der Meldung erscheint auch der Fingerprint des Hostkeys:
* In der Meldung erscheint auch der Fingerprint des Hostkeys


  [root@scientific /]# ssh uvm1.nwa-net.de
  # 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
  ECDSA key fingerprint is SHA256:TbVCtl6TJHAHacrTdwh9gqzvx8fB5bzhi1lL/ByFbYE.
  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.
  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)?
  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.
* 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.
* Bei späteren Anmeldungen entfällt entsprechend die Warnmeldung
* Folgendes Kommando zeigt eine Liste der bekannten Hosts
* Folgendes Kommando zeigt eine Liste der bekannten Hosts


Zeile 23: Zeile 21:
  uvm1.nwa-net.de,176.95.26.236 (ECDSA)
  uvm1.nwa-net.de,176.95.26.236 (ECDSA)


* Ändert sich der Schlüssel eines Zielsystems, erfolgt die Warnmeldung:
* Ändert sich der Schlüssel eines Zielsystems, erfolgt die Warnmeldung


  $ ssh scientific
  $ ssh scientific
Zeile 40: Zeile 38:
  Host key verification failed.
  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.
* 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.
* 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==
==Hostkeys==


* 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 58: Zeile 56:
  ssh_host_rsa_key.pub
  ssh_host_rsa_key.pub


* Ohne Dateierweiterung = privater Schlüssel.
* Ohne Dateierweiterung = privater Schlüssel
* Mit Erweiterung .pub = öffentlicher (public) Schlüssel.
* Mit Erweiterung .pub = öffentlicher (public) Schlüssel
* Die Konfigurationsdatei dazu ist ''sshd_config''.
* Die Konfigurationsdatei dazu ist ''sshd_config''


Erläuterung zu den einzelnen Schlüsseldateien:
Erläuterung zu den einzelnen Schlüsseldateien


* 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: 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.<br>
* RSA: etablierter Standard, überall unterstützt, existiert seit 1977<br>
* Ed25519: ähnelt technisch ECDSA, weist jedoch nicht dieselbe Schwäche auf.<br>
* Ed25519: ähnelt technisch ECDSA, weist jedoch nicht dieselbe Schwäche auf<br>
* Wird von sehr neuen SSH-Versionen unterstützt, empfiehlt sich daher nicht als Standalone-Lösung, wenn man auch ältere Clientsysteme im Einsatz hat.<br>
* Wird von sehr neuen SSH-Versionen unterstützt, empfiehlt sich daher nicht als Standalone-Lösung, wenn man auch ältere Clientsysteme im Einsatz hat<br>


* ''ssh-keygen'' generiert neue Schlüssel.
* ''ssh-keygen'' generiert neue Schlüssel
* Optional die Pfadangabe des Users angeben.
* Optional die Pfadangabe des Users angeben
* Option ''–t'' legt den Typ des Schlüssels fest.
* Option ''–t'' legt den Typ des Schlüssels fest
* Zur Auswahl stehen rsa, dsa, ecdsa und ed25519.
* Zur Auswahl stehen rsa, dsa, ecdsa und ed25519


'''Beispiel:'''
'''Beispiel:'''
* Erstellen eines neuen Schlüsselpaares für RSA.
* Erstellen eines neuen Schlüsselpaares für RSA
* Benutzereingaben fett gedruckt.
* Es wurde keine passphrase verwendet
* Es wurde keine passphrase verwendet.


  # ssh-keygen -t rsa
  # ssh-keygen -t rsa
Zeile 93: Zeile 90:
  SHA256:zinmLbZLTBxcCOWN52QBDniQVAE9GfD/MuuQHzk3QQ4 root@scientific
  SHA256:zinmLbZLTBxcCOWN52QBDniQVAE9GfD/MuuQHzk3QQ4 root@scientific


* Generierte Datei ''ssh_host_rsa_key.pub'' enthält den öffentlichen Schlüssel des Systems.
* Generierte Datei ''ssh_host_rsa_key.pub'' enthält den öffentlichen Schlüssel des Systems
* Dieser lässt sich an Clients verteilen.
* Dieser lässt sich an Clients verteilen
* Datei ''ssh_host_rsa_key'' enthält privaten Schlüssel des Servers (geheim halten).
* 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:
Folgende Kommandos können vom Clientsystem verwendet werden um den öffentlichen Schlüssel zu importieren


  # scp scientific:/etc/ssh/ssh_host_rsa_key.pub ./
  # scp scientific:/etc/ssh/ssh_host_rsa_key.pub ./
Zeile 103: Zeile 100:
  # rm ssh_host_rsa_key.pub
  # rm ssh_host_rsa_key.pub


===Benutzerauthentifizierung mit Schlüsseln===
==Benutzerauthentifizierung mit Schlüsseln==


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.&nbsp;B.&nbsp;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:


  $ ssh-keygen -t ecdsa
  $ ssh-keygen -t ecdsa
Zeile 121: Zeile 117:
  SHA256:Br+8SdXitm/XnUmqVQB1/+aO0HkJKsrbAjzvTwV8FNI user@10.0.0.1
  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.<br>
* 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''
Dafür verwendet man das komfortable Tool ''ssh-copy-id'':


  $ ssh-copy-id user
  $ ssh-copy-id user
Zeile 137: Zeile 132:
  prompted now it is to install the new keys
  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.<br>
* 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
Die Dateinamen der Benutzerschlüssel und Serverschlüssel sind Prüfungsrelevant.<br>
Sie befinden sich allesamt im Verzeichnis ~/.ssh eines Benutzers und lauten auf diese Dateinamen:


  id_rsa
  id_rsa
Zeile 151: Zeile 144:
  id_ed25519.pub
  id_ed25519.pub


Die Dateinamen zu den Schlüsseln sind im Unterkapitel Hostkeys beschrieben.<br>
* Die Dateinamen zu den Schlüsseln sind im Unterkapitel Hostkeys beschrieben
Für die Authentifizierung wird nur ein Schlüsselpaar benötigt.<br>
* Für die Authentifizierung wird nur ein Schlüsselpaar benötigt
Server und Client Schlüsseltyp müssen natürlich identisch sein.
* 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.''


===Der Authentifizierungsagent===
''Wichtige Optionen sind:''


Der SSH-Agent ist eine weitere Möglichkeit ohne Passwörter Authentifizierungen auszuführen.<br>
-l – listet die Fingerabdrücke der verfügbaren Schlüssel auf
Es lassen sich mehrere Schlüssel für einen Benutzer verwalten.<br>
-d – entfernt einen einzelnen (angegebenen) Schlüssel vom Agenten
Dafür muss er bei der Startphase von X ausgeführt werden.<br>
-D – entfernt alle Schlüssel vom Agenten
''ssh-add'' kann dem SSH-Agent Schlüssel hinzufügen.<br>
-s – liest Schlüssel von einer Smartcard
Ohne Optionen sucht das Programm automatisch nach<br>
-e – entfernt Schlüssel der Smartcard
~/.ssh/id_rsa, ~/.ssh/id_dsa, ~/.ssh/id_ecdsa, ~/.ssh/id_ed25519 und ~/.ssh/identity.<br>
-x – sperrt den Agenten (mit Passwortschutz)
-X – entsperrt den Agenten


Wichtige Optionen sind:
= Links =
== Intern ==
# [[LPIC102/110.3 Schlüsselerstellung mit GnuPG]]


-l – listet die Fingerabdrücke der verfügbaren Schlüssel auf.
== Weblinks ==
-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.


[[Category:Linux]]
[[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

Links

Intern

  1. LPIC102/110.3 Schlüsselerstellung mit GnuPG

Weblinks