LPIC102/110.3 Daten durch Kryptografie schützen: Unterschied zwischen den Versionen

Aus Foxwiki
Versionsgeschichte interaktiv durchsuchen
← Zum vorherigen Versionsunterschied
VisuellWikitext
Meikschwalm (Diskussion | Beiträge)
331 Bearbeitungen
K Textersetzung - „Kurzbeschreibung“ durch „Beschreibung“
 
(131 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
Ausführliche Informationen zur Funktionsweise von SSH werden im Artikel [[SSH (secure shell)]] erläutert.<br>
'''topic''' - Beschreibung
In diesem Artikel geht es nur um LPIC prüfungsrelevante Themen zu SSH.
== Beschreibung ==
 
=== Wissensgebiete ===
==Wichtigste Wissensgebiete==
* OpenSSH-2-Client grundlegend konfigurieren und verwenden
 
* Bedeutung von OpenSSH-2-Rechnerschlüsseln verstehen
* einen OpenSSH-2-Client grundlegend konfigurieren und verwenden
* die Rolle von OpenSSH-2-Rechnerschlüsseln verstehen
* GnuPG grundlegend konfigurieren und verwenden
* GnuPG grundlegend konfigurieren und verwenden
* GPG verwenden um Dateien zu verschlüsseln, entschlüsseln, signieren und zu überprüfen
* GnuPG verwenden um Dateien zu verschlüsseln, entschlüsseln, signieren und zu überprüfen
* SSH-Port-Tunnel (auch X11-Tunnel) verstehen
* SSH-Port-Tunnel (auch X11-Tunnel) verstehen


==Liste wichtiger Dateien, Verzeichnisse und Anwendungen==
=== Dateien, Verzeichnisse, Anwendungen ===
 
==== Anwendungen ====
* ssh
* ssh
* ssh-keygen
* ssh-keygen
* ssh-agent
* ssh-agent
* ssh-add
* ssh-add
==== Dateien ====
; User
* ~/.ssh/authorized_keys
* ~/.ssh/id_rsa und id_rsa.pub
* ~/.ssh/id_rsa und id_rsa.pub
* ~/.ssh/id_dsa und id_dsa.pub
* ~/.ssh/id_dsa und id_dsa.pub
* ~/.ssh/id_ecdsa und id_ecdsa.pub
* ~/.ssh/id_ecdsa und id_ecdsa.pub
* ~/.ssh/id_ed25519 und id_ed25519.pub
* ~/.ssh/id_ed25519 und id_ed25519.pub
; System
* /etc/ssh/ssh_host_rsa_key und ssh_host_rsa_key.pub
* /etc/ssh/ssh_host_rsa_key und ssh_host_rsa_key.pub
* /etc/ssh/ssh_host_dsa_key und ssh_host_dsa_key.pub
* /etc/ssh/ssh_host_dsa_key und ssh_host_dsa_key.pub
* /etc/ssh/ssh_host_ecdsa_key und ssh_host_ecdsa_key.pub
* /etc/ssh/ssh_host_ecdsa_key und ssh_host_ecdsa_key.pub
* /etc/ssh/ssh_host_ed25519_key und ssh_host_ed25519_key.pub
* /etc/ssh/ssh_host_ed25519_key und ssh_host_ed25519_key.pub
* ~/.ssh/authorized_keys
 
* ssh_known_hosts
== SSH ==
* gpg
=== Server ===
* gpg-agent
; Das Paket ''openssh-server'' installiert die serverseitige Komponente von SSH
* ~/.gnupg/
;  SSH Dienst starten mit [[systemd]]
==SSH Daemon installieren==
Das Paket openssh-server installiert die serverseitige Komponente von SSH.<br>
Folgende Befehle starten unter systemd den SSH Dienst.
  # systemctl start sshd.service
  # systemctl start sshd.service
  # systemctl enable sshd.service
  # systemctl enable sshd.service


==SSH-Client-Verbindung==
=== Client ===
Um eine Verbindung zwischen zwei Linux-Systemen aufzubauen, startet man ssh und übergibt den Host-Namen bzw. die IP-Adresse.<br>
* Die Verbidung startet ssh
Anschliessend folgt die Eingabe eines Kennwortes:
* Host-Namen bzw.&nbsp;die IP-Adresse wird angegeben
* Anschliessend folgt die Eingabe des Kennwortes
  $ ssh server
  $ ssh server
  root@server's password:
  root@server's password:


Möchte man sich nicht mit seinem lokalen Benutzerkonto anmelden, gibt es zwei Wege:
* Zwei Wege um sich mit einem alternativen Benutzerkonto anzumelden
  $ ssh -l willi server
  $ ssh -l willi server
  $ ssh willi@server
  $ ssh willi@server


===Grafische Anwendungen unter X tunneln===  
==== Grafische Anwendungen unter X tunneln ====
 
* SSH-Verbindung wird von einem X-Terminal aus mit der zusätzlichen Option -X (großes X) initiiert
Zuerst wird die SSH-Verbindung von einem X-Terminal aus mit der zusätzlichen Option -X (großes X) initiiert.<br>
  $ ssh -X server
 
  # ssh -l willi -X server
 
Auf der Konsole des Remote-Systems führt man die Anwendung aus:


  user@server:~ $ openoffice
* Auf der Konsole des Remote-Systems führt man die Anwendung aus
  $ libreoffice


*Die grafische Ausgabe und die Bedienung erfolgt lokal am SSH-Client-Rechner.
* Grafische Ausgabe und Bedienung erfolgt lokal am SSH-Client-Rechner
*Das hier beschriebene Verfahren wird als X11-Tunnel bezeichnet.
* Das hier beschriebene Verfahren wird als X11-Tunnel bezeichnet


===Weiterleitung anderer Ports durch einen SSH-Tunnel.===
==== Weiterleitung anderer Ports durch einen SSH-Tunnel ====
* Als Beispiel, der Zugriff auf einen Terminalserver im entfernten Netzwerk hinter einem SSH-Server
* IP-Adresse des Terminalservers 192.168.50.10
* Terminalserver lauscht an Port 3389
* IP des SSH-Server 119.117.63.126


Als Beispiel, der Zugriff auf einen Terminalserver im entfernten Netzwerk hinter einem SSH-Server. <br>
Zunächst wird die SSH-Verbindung initiiert
$ '''ssh 119.117.63.126 -L 4711:192.168.50.10:3389'''


IP-Adresse des Terminalservers 192.168.50.10<br>
* Option -L leitet Port 4711 an 192.168.50.10 mit Portnummer 3389 weiter
Terminalserver lauscht an Port 3389<br>
* Verbindungen werden an 192.168.50.10:3389 weitergeleitet
IP des SSH-Server 119.117.63.126
* Terminal-Dienste-Clients (z.&nbsp;B.&nbsp;remmina) nutzen nun als Ziel localhost:4711<br>


Zunächst wird die SSH-Verbindung initiiert:
; Hinweis
: Auch vom Windows-Computer aus kann mittels PuTTy auf einen Linux-Host zugegriffen werden <br>
Läuft ein X-Server auf dem Windows-Computer (z.&nbsp;B.&nbsp;Xming oder Cygwin), ist auch das Tunneln von Ports inklusive X11 durchführbar


# ssh 119.117.63.126 -L 4711:192.168.50.10:3389
=== Konfigurationsdateien ===
 
; /etc/ssh/sshd_config
Option -L leitet Port 4711 an 192.168.50.10 mit Portnummer 3389 weiter.<br>
* Die Konfigurationsdatei sshd_config dient der Konfiguration von sshd, also den SSH-Server
Verbindungen werden an 192.168.50.10:3389 weitergeleitet.<br>
Terminal-Dienste-Clients (z. B. remmina) nutzen nun als Ziel localhost:4711<br>
 
 
'''Hinweis'''<br>
Auch vom Windows-Computer aus kann mittels PuTTy auf einen Linux-Host zugegriffen werden. <br>
Läuft ein X-Server auf dem Windows-Computer (z. B. Xming oder Cygwin), ist auch das Tunneln von Ports inklusive X11 durchführbar.<br>
 
Wiki Artikel zu PuTTy <br>
[[PuTTY - ein freier SSH-Client]]
 
==SSH-Konfigurationsdateien==
 
/etc/ssh/sshd_config
Die Konfigurationsdatei sshd_config dient der Konfiguration von sshd, also den SSH-Server.<br>
z.B.


  Port 22
  Port 22
Zeile 96: Zeile 86:
  HostKey /etc/ssh/ssh_host_ed25519_key
  HostKey /etc/ssh/ssh_host_ed25519_key


Erklärung:
; Erläuterung
* sshd verwendet den Standardport 22
* Ausschließlich SSH-2-Verbindungen
* Zugriff auf Schnittstelle des Rechners: 192.168.0.58
* Kein login für root
* Als Hostkey kommen RSA, ECDSA und Ed25519 in Frage


# sshd verwendet den Standardport 22.
; Hinweis
# Ausschließlich SSH-2-Verbindungen.
: Auf die Authentifizierung mit Schlüsseln und ssh_known_hosts Datei wird später näher eingegangen
# Zugriff auf Schnittstelle des Rechners: 192.168.0.58
# Kein login für root.
# Als Hostkey kommen RSA, ECDSA und Ed25519 in Frage.
<br>
Auf Schlüssel wird etwas später näher eingegangen.
<br>
/etc/ssh/ssh_config
Die Konfigurationsdatei ssh_config dient der clientseitigen Konfiguration von SSH.


z.B.
; /etc/ssh/ssh_config
Konfiguration des SSH-Clients
* Clientseitige X11-Weiterleitung oder Passwortauthentifizierung
* Clientseitige X11-Weiterleitung oder Passwortauthentifizierung
* RSA-Authentifizierung aktiv/inaktiv
* RSA-Authentifizierung aktiv
* Standardport für ausgehende Verbindungen festlegen <br>
* Standardport für ausgehende Verbindungen festlegen
* Die Optionsnamen innerhalb dieser Datei sind ansonsten selbsterklärend oder in der Manpage nachzuschlagen
* Die beiden gerade besprochenen Dateien kann man aufgrund ihrer Namensähnlichkeit schnell verwechseln


Die Optionsnamen innerhalb dieser Datei sind ansonsten selbsterklärend. <br>
; /etc/hosts.allow und /etc/hosts.deny
ACHTUNG! Die beiden gerade besprochenen Dateien kann man aufgrund ihrer Namensähnlichkeit schnell verwechseln.
* Die Dateien steuern wie die oben beschriebenen Dateien, den Zugriff auf SSH
* ''hosts.allow'' hat Vorrang vor der Datei ''hosts.deny
* Wird einem Host der Zugriff auf SSH durch ''hosts.allow'' gewährt, kann das durch keinen Eintrag in hosts.deny zurückgenommen werden


/etc/hosts.allow und /etc/hosts.deny
; /etc/nologin
* Mit dem erstellen einer leeren Datei namens /etc/nologin lässt sich der Zugriff auf SSH verhindern
* Nur root kann sich dann noch am System anmelden
* In dieser Datei kann auch eine Nachricht an Benutzer hinterlassen werden die sich lokal anmelden wollen


Die Dateien /etc/hosts.allow und /etc/hosts.deny steuern wie die oben beschriebenen Dateien, den Zugriff auf SSH.
Wie diese beiden Dateien benutzt werden, wird an anderer Stelle beschrieben.


Wichtig für die Prüfung:
Die Datei hosts.allow hat Vorrang vor der Datei hosts.deny -
Wird einem Host der Zugriff auf SSH durch hosts.allow gewährt, kann das durch keinen Eintrag in hosts.deny zurückgenommen werden.


/etc/nologin
<noinclude>


Mit dem erstellen einer leeren Datei namens /etc/nologin lässt sich der Zugriff auf SSH verhindern.
== Anhang ==
Nur root kann sich dann noch am System anmelden.
=== Siehe auch ===
In dieser Datei kann auch eine Nachricht an Benutzer hinterlassen werden die sich lokal anmelden wollen.
{{Special:PrefixIndex/{{BASEPAGENAME}}}}
 
----
==Authentifizierung der Server mit Schlüsseln==
* [[LPIC102/110.3 SSH Authentifizierung mit Schlüsseln|110.3 SSH Authentifizierung mit Schlüsseln]]
 
* [[Putty|PuTTY - ein freier SSH-Client]]
Server authentifiziert sich gegenüber dem Client mit seinem Hostkey.<br>
* ssh_known_hosts
Ist der Ziel-Host dem Client noch nicht bekannt, erfolgt eine Warnmeldung.<br>
* gpg
In der Meldung erscheint auch der Fingerprint des Hostkeys:
* gpg-agent
 
* ~/.gnupg/
[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.<br>
Bei späteren Anmeldungen entfällt entsprechend die Warnmeldung.
Eine Liste der bekannten Hosts können Sie mithilfe des folgenden Kommandos bekommen:
 
[root@scientific /]# 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 ssh_known_hosts ist ausdrücklich als Prüfungsthema genannt und wird deshalb ausführlich bearbeitet.
Sie macht nichts anderes als die Datei ~/.ssh/known_hosts für jeden Benutzer, nur eben zentralisiert.
 
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.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.
 
DSA gilt als veraltet und weist auch zumindest eine bekannte Schwäche auf.
Sie sollten es nicht mehr verwenden. Ab der Version 7.0 von SSH wird es auch nicht mehr unterstützt.
ECDSA ist Momentan bei den meisten Linux-Distributionen Standard.
Es kommt mit kleineren Schlüsselgrößen aus, als etwa RSA, steht aber leider im Verdacht, die gleichen Schwächen aufzuweisen wie DSA.
RSA ist ein gut etablierter Standard, der überall unterstützt wird.
Es spricht also nichts gegen die Verwendung von RSA, außer dass RSA schon seit 1977 existiert.
Ed25519 ähnelt technisch ECDSA, weist aber nicht dieselbe Schwäche auf.
Es wird nur von sehr neuen SSH-Versionen unterstützt und es empfiehlt sich daher nicht, Ed25519 als Standalone-Lösung zu verwenden, wenn man auch ältere Clientsysteme im Einsatz hat.
 
Das Programm ssh-keygen generiert neue Schlüssel.
Optional muss die Pfadangabe zum entsprechenden Dateinamen des Users angeben werden.
Option –t legt den Typ des zu generierenden Schlüssels fest.
Zur Auswahl stehen rsa, dsa, ecdsa und ed25519.
Das folgende Beispiel zeigt die Erstellung eines neuen Schlüsselpaars für RSA. Benut-zereingaben sind fett gedruckt.
Eine passphrase wurde nicht verwendet.
 
[root@scientific /]# 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
 
Die generierte Datei ssh_host_rsa_key.pub enthält den öffentlichen
Schlüssel des Systems. Sie kann zur Verteilung an Clients verwendet werden.
Die Datei ssh_host_rsa_key hingegen enthält den privaten Schlüssel des Servers und ist entsprechend geheim zu halten.
Auf einem Clientsystem können Sie also folgende.
 
root@client:/# scp scientific:/etc/ssh/ssh_host_rsa_key.pub ./
root@client:/# cat ssh_host_rsa_key.pub >> /etc/ssh/ssh_known_hosts
root@client:/# rm ssh_host_rsa_key.pub
 
=Quellenangaben=


[[Benutzer:Meikschwalm|Meikschwalm]] ([[Benutzer Diskussion:Meikschwalm|Diskussion]]) 11:48, 17. Jul. 2019 (CEST)
==== Links ====
===== Weblinks =====


[[Category:Linux]]
[[Kategorie:Linux/LPIC/102]]
[[Kategorie:Kryptografie/Anwendung]]
[[Kategorie:SSH]]
</noinclude>

Aktuelle Version vom 19. Oktober 2024, 13:35 Uhr

topic - Beschreibung

Beschreibung

Wissensgebiete

  • OpenSSH-2-Client grundlegend konfigurieren und verwenden
  • Bedeutung von OpenSSH-2-Rechnerschlüsseln verstehen
  • GnuPG grundlegend konfigurieren und verwenden
  • GnuPG verwenden um Dateien zu verschlüsseln, entschlüsseln, signieren und zu überprüfen
  • SSH-Port-Tunnel (auch X11-Tunnel) verstehen

Dateien, Verzeichnisse, Anwendungen

Anwendungen

  • ssh
  • ssh-keygen
  • ssh-agent
  • ssh-add

Dateien

User
  • ~/.ssh/authorized_keys
  • ~/.ssh/id_rsa und id_rsa.pub
  • ~/.ssh/id_dsa und id_dsa.pub
  • ~/.ssh/id_ecdsa und id_ecdsa.pub
  • ~/.ssh/id_ed25519 und id_ed25519.pub
System
  • /etc/ssh/ssh_host_rsa_key und ssh_host_rsa_key.pub
  • /etc/ssh/ssh_host_dsa_key und ssh_host_dsa_key.pub
  • /etc/ssh/ssh_host_ecdsa_key und ssh_host_ecdsa_key.pub
  • /etc/ssh/ssh_host_ed25519_key und ssh_host_ed25519_key.pub

SSH

Server

Das Paket openssh-server installiert die serverseitige Komponente von SSH
SSH Dienst starten mit systemd
# systemctl start sshd.service
# systemctl enable sshd.service

Client

  • Die Verbidung startet ssh
  • Host-Namen bzw. die IP-Adresse wird angegeben
  • Anschliessend folgt die Eingabe des Kennwortes
$ ssh server
root@server's password:
  • Zwei Wege um sich mit einem alternativen Benutzerkonto anzumelden
$ ssh -l willi server
$ ssh willi@server

Grafische Anwendungen unter X tunneln

  • SSH-Verbindung wird von einem X-Terminal aus mit der zusätzlichen Option -X (großes X) initiiert
$ ssh -X server
  • Auf der Konsole des Remote-Systems führt man die Anwendung aus
$ libreoffice
  • Grafische Ausgabe und Bedienung erfolgt lokal am SSH-Client-Rechner
  • Das hier beschriebene Verfahren wird als X11-Tunnel bezeichnet

Weiterleitung anderer Ports durch einen SSH-Tunnel

  • Als Beispiel, der Zugriff auf einen Terminalserver im entfernten Netzwerk hinter einem SSH-Server
  • IP-Adresse des Terminalservers 192.168.50.10
  • Terminalserver lauscht an Port 3389
  • IP des SSH-Server 119.117.63.126

Zunächst wird die SSH-Verbindung initiiert 

$ ssh 119.117.63.126 -L 4711:192.168.50.10:3389
  • Option -L leitet Port 4711 an 192.168.50.10 mit Portnummer 3389 weiter
  • Verbindungen werden an 192.168.50.10:3389 weitergeleitet
  • Terminal-Dienste-Clients (z. B. remmina) nutzen nun als Ziel localhost:4711
Hinweis
Auch vom Windows-Computer aus kann mittels PuTTy auf einen Linux-Host zugegriffen werden

Läuft ein X-Server auf dem Windows-Computer (z. B. Xming oder Cygwin), ist auch das Tunneln von Ports inklusive X11 durchführbar

Konfigurationsdateien

/etc/ssh/sshd_config
  • Die Konfigurationsdatei sshd_config dient der Konfiguration von sshd, also den SSH-Server
Port 22
Protocol 2
ListenAddress 192.168.0.58
PermitRootLogin no
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key
Erläuterung
  • sshd verwendet den Standardport 22
  • Ausschließlich SSH-2-Verbindungen
  • Zugriff auf Schnittstelle des Rechners: 192.168.0.58
  • Kein login für root
  • Als Hostkey kommen RSA, ECDSA und Ed25519 in Frage
Hinweis
Auf die Authentifizierung mit Schlüsseln und ssh_known_hosts Datei wird später näher eingegangen
/etc/ssh/ssh_config

Konfiguration des SSH-Clients

  • Clientseitige X11-Weiterleitung oder Passwortauthentifizierung
  • RSA-Authentifizierung aktiv
  • Standardport für ausgehende Verbindungen festlegen
  • Die Optionsnamen innerhalb dieser Datei sind ansonsten selbsterklärend oder in der Manpage nachzuschlagen
  • Die beiden gerade besprochenen Dateien kann man aufgrund ihrer Namensähnlichkeit schnell verwechseln
/etc/hosts.allow und /etc/hosts.deny
  • Die Dateien steuern wie die oben beschriebenen Dateien, den Zugriff auf SSH
  • hosts.allow hat Vorrang vor der Datei hosts.deny
  • Wird einem Host der Zugriff auf SSH durch hosts.allow gewährt, kann das durch keinen Eintrag in hosts.deny zurückgenommen werden
/etc/nologin
  • Mit dem erstellen einer leeren Datei namens /etc/nologin lässt sich der Zugriff auf SSH verhindern
  • Nur root kann sich dann noch am System anmelden
  • In dieser Datei kann auch eine Nachricht an Benutzer hinterlassen werden die sich lokal anmelden wollen



Anhang

Siehe auch

Links

Weblinks
Abgerufen von „https://wiki.foxtom.de/index.php?title=LPIC102/110.3_Daten_durch_Kryptografie_schützen&oldid=111721“