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“
 
(62 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
==Authentifizierung der Server mit Schlüsseln==
danach profil erstellung in konsole um einfache handhabung zu zeigen
* 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


Server authentifiziert sich gegenüber dem Client mit seinem Hostkey.<br>
  # ssh uvm1.nwa-net.de
Ist der Ziel-Host dem Client noch nicht bekannt, erfolgt eine Warnmeldung.<br>
In der Meldung erscheint auch der Fingerprint des Hostkeys:
 
  [root@scientific /]# 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.<br>
* 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
Eine Liste der bekannten Hosts können Sie mithilfe des folgenden Kommandos bekommen:
* Folgendes Kommando zeigt eine Liste der bekannten Hosts


  [root@scientific /]# ssh-keygen -l -f ~/.ssh/known_hosts
  # ssh-keygen -l -f ~/.ssh/known_hosts
  256 SHA256:VOrsAcZc//9EiAATV2DfSN2jHONQBEuJpyrmW+Q3CWQ
  256 SHA256:VOrsAcZc//9EiAATV2DfSN2jHONQBEuJpyrmW+Q3CWQ
  user,192.168.178.2 (ECDSA)
  user,192.168.178.2 (ECDSA)
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


==/etc/ssh/ssh_known_hosts==
* 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 ssh_known_hosts ist ausdrücklich als Prüfungsthema genannt und wird deshalb ausführlich bearbeitet.<br>
==Hostkeys==
Sie 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
OpenSSH erstellt in der Regel automatisch Hostkeys.
Sie dienen der Authentifizierung zwischen Server und Clientcomputer.
Die folgenden Dateien enthalten jeweils eine den privaten und die andere den öffentlichen Schlüssel:


  ssh_host_dsa_key
  ssh_host_dsa_key
Zeile 62: Zeile 56:
  ssh_host_rsa_key.pub
  ssh_host_rsa_key.pub


Ohne Dateierweiterung = privater Schlüssel.<br>
* Ohne Dateierweiterung = privater Schlüssel
Mit Erweiterung .pub = öffentlicher (public) Schlüssel.<br>
* 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>
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.<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>


ssh-keygen generiert neue Schlüssel.<br>
* DSA: veraltet, bekannte Schwächen, wird nicht mehr unterstützt<br>
Optional die Pfadangabe des Users angeben.<br>
* ECDSA: Standard bei Linux-Distros, kleinere Schlüsselgrößen als etwa RSA, Verdacht gleiche Schwächen aufzuweisen wie DSA
Option –t legt den Typ des zu generierenden Schlüssels fest.<br>
* RSA: etablierter Standard, überall unterstützt, existiert seit 1977<br>
Zur Auswahl stehen rsa, dsa, ecdsa und ed25519.<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>


'''Beispiel:'''<br>
* ''ssh-keygen'' generiert neue Schlüssel
Erstellen eines neuen Schlüsselpaares für RSA.<br>
* Optional die Pfadangabe des Users angeben
Benutzereingaben fett gedruckt.<br>
* Option ''–t'' legt den Typ des Schlüssels fest
Es wurde keine passphrase verwendet.
* Zur Auswahl stehen rsa, dsa, ecdsa und ed25519


  [root@scientific /]# ssh-keygen -t rsa
'''Beispiel:'''
* Erstellen eines neuen Schlüsselpaares für RSA
* 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 96: 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.<br>
* Generierte Datei ''ssh_host_rsa_key.pub'' enthält den öffentlichen Schlüssel des Systems
Lässt sich an Clients verteilen.<br>
* Dieser lässt sich an Clients verteilen
Datei ssh_host_rsa_key enthält privaten Schlüssel des Servers (geheim halten).<br>
* 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:


root@client:/# scp scientific:/etc/ssh/ssh_host_rsa_key.pub ./
Folgende Kommandos können vom Clientsystem verwendet werden um den öffentlichen Schlüssel zu importieren
root@client:/# cat ssh_host_rsa_key.pub >> /etc/ssh/ssh_known_hosts
root@client:/# rm ssh_host_rsa_key.pub


===Benutzerauthentifizierung mit Schlüsseln===
# 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


Schlüsseltypen wie die der Hostkeys können auch zur Authentifizierung von Benutzern verwendet werden. <br>
==Benutzerauthentifizierung mit Schlüsseln==
Verzichtet man nun auf die Eingabe eines Passwortes, lassen sich ssh oder scp in Skripten z. B. für Backups zu verwenden.<br>
 
Die Generierung der Schlüssel geschieht ebenfalls mittels ssh-keygen.<br>
* Hostkeys können auch zur Authentifizierung von Benutzern verwendet werden
Die generierten Schlüssel werden automatisch an der richtigen Stelle abgelegt:<br>
* 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''
* Schlüssel werden automatisch an der richtigen Stelle abgelegt


  $ ssh-keygen -t ecdsa
  $ ssh-keygen -t ecdsa
Zeile 122: 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.
* 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 müssen sich lediglich darüber einigen, welcher Schlüsseltyp für die Authentifizierung verwendet werden soll.
* Server und Client Schlüsseltyp müssen natürlich identisch sein
 
===Der Authentifizierungsagent===
 
Weitere Möglichkeit ohne Passwörter Authentifizierungen auszuführen. (der SSH-Agent)<br>
Mehrere Schlüssel für einen Benutzer verwalten.<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>
Ohne Optionen sucht das Programm automatisch nach<br>
~/.ssh/id_rsa, ~/.ssh/id_dsa, ~/.ssh/id_ecdsa, ~/.ssh/id_ed25519 und ~/.ssh/identity.<br>
Schlüssel können angegeben werden.<br>
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
==Der Authentifizierungsagent==


Auf einfache Weise Daten verschlüsseln oder signieren.
* Der SSH-Agent ist eine weitere Möglichkeit ohne Passwörter Authentifizierungen auszuführen
Bietet asymmetrisches Verschlüsselungsverfahren. Bedeutet, ein Schlüsselpaar ist erforderlich.
* Es lassen sich mehrere Schlüssel für einen Benutzer verwalten
Der öffentliche Schlüssel ist der Verschlüsselungsschlüssel, der private Schlüssel ist der Entschlüsselungsschlüssel.
* Dafür muss er bei der Startphase von X ausgeführt werden
Der private Schlüssel wird beim Generieren von Signaturen verwendet.
* ''ssh-add'' kann dem SSH-Agent Schlüssel hinzufügen
Das sind zwei gute Gründe, den Schlüssel wie seinen eigenen Augapfel zu schützen.
* Ohne Optionen sucht das Programm automatisch nach
''~/.ssh/id_rsa, ~/.ssh/id_dsa, ~/.ssh/id_ecdsa, ~/.ssh/id_ed25519 und ~/.ssh/identity.''


Zur Sicherheit können Sie den Schlüssel der symmetrischen Verschlüsselung anschließend mit einem asymmetrischen<br>
''Wichtige Optionen sind:''
Schlüssel verschlüsseln. <br>
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)  
-l – listet die Fingerabdrücke der verfügbaren Schlüssel auf
für GNOME das Programm Seahorse, und für KDE wurde KGpg entwickelt.
-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


Damit Windows-Computer in einem solchen Umfeld nicht zur Sicherheitslücke werden, können diese Gpg4win einsetzen,
= Links =
das übrigens absolut kompatibel zu den Linux-Versionen ist.
== Intern ==
# [[LPIC102/110.3 Schlüsselerstellung mit GnuPG]]


== Weblinks ==


[[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