Remote-Zugriff


Kleine Übersicht

SSH - Secure Shell ermöglicht es einem sich von einem Kunden-Computer (client) sich aus der Ferne mit einem Arbeitsrechner (host) zu verbinden. Im Gegensatz zum Microsoft proprietären RDP -Remote Desktop Protokol oder dem open source VNC - virtual Network Computing, wird nicht der ganze Bildschirm übertragen, sondern nur die jeweilige Host-Anwendung (bei entsprechenden Parameter auch graphisch). Durch die Remote-Verbindung kann man am Host auf Tastertur, Maus und Bildschirm verzichten und arbeitet quasi headless.

SSH-Clients gibt es auf fast jedem System z.B.

Einen SSH-Server gibt es ebenfalls für fast jedes System z.B.

SSH-Server unter DEB einrichten

Um auf einem DEB-System einen Remote-Zugriff auf den Host (hier DEB 10) zu etablieren ist nicht viel nötig. Danach lauscht die SSH – secure Shell bereits auf dem (default) Port 22. Manche empfehlen einen anderen Port zu wählen, weil "jeder unter Port 22" einen SSH-Dienst erwartet. Ich meine, das bringt wenig, da ich schnell mit einen Port-Scanner die offenen Ports finden kann. Ich versuche daher eher, durch das Begrenzen der Fehlversuche (fail to ban) und Schlüssel unerwünschten Besuch zu vermeiden.

su 
apt install openssh-server

Sollte es sich um einen Raspberry handeln (siehe heise.de SSH auf dem Raspberry Pi einrichten), muss der SSH-Server explizit gestartet werden und als Default bei jedem Start eingestellt werden.

sudo /etc/init.d/ssh start
sudo update-rc.d ssh defaults

Überprüfung auf dem SSH-Servers, kann wie folgt erfolgen.

netstat -tulpn | grep :22
-bash: netstat: command not found                     Befehl fehlt noch

su
apt install netstat
...
E: Unable to locate package netstat                   Paket heist offensichtlich anders...

apt-file search "/netstat "
munin-plugins-core: /usr/share/munin/plugins/netstat  
net-tools: /bin/netstat                               das scheint das Gesuchte zu sein
recap: /usr/lib/recap/core/netstat

apt-get install net-tools

netstat -tulpn | grep :22 
tcp        0      0 0.0.0.0:22         0.0.0.0:*          LISTEN      852/sshd            
tcp6       0      0 :::22              :::*               LISTEN      852/sshd

Mehr ist nicht zu tun um einen Linux-PC remote erreichen zu können. Nun stellt sich noch die Frage unter welcher Adresse...
Bzgl. netstat siehe tecmint.com Anwendung von netstat

Adresse des SSH-Servers

Normalerweise weist der Router über DHCP jedem Computer im lokalem Netz eine IP-Adresse zu. Hier kann man also sowohl die IP-Adresse finden alsauch den Namen finden.
In diesem Beispiel ist ab1 mit der IP-Adresse 192.168.178.47 vom Client, welcher remote auf den Host balt mit der IP-Adresse 192.168.178.35 zugreifen möchte.

Bild von IP des hosts auf der Fritzbox

Ist die IP-Adresse jedoch eine gewisse Zeit nicht verwendet worden, kann es passieren dass der Router die Adressen für einen anderen Computer verwendet. Daher ist es besser, statt mit IP-Adressen, stehts mit den Namen zu arbeiten. So ein Name wurde bereits im Installations-Dialog abgefragt.

Anbei zwei Beispiele mit ping aufgerufen vom Client. Wenn ich statt IP-Adresse den Namen verwenden möchte, ist der sog. FQDN (voller Domain-Name) anzugeben, welcher hier dann balt.fritz.box heißt. Bei anderen Routern entsprechend anders... An dem unten genannten Beispiel ist auch schön ersichtlich, dass der Host sowohl unter IPv4 alsauch IPv6 erreichbar ist, was Einstellungssache des Routers ist. Sollte der Host auch von "außen via Port forwarding" erreichbar sein, ist das auch vom Provider abhänig.

ping 192.168.178.35
PING 192.168.178.35 (192.168.178.35) 56(84) bytes of data.
64 bytes from 192.168.178.35: icmp_seq=1 ttl=64 time=0.992 ms
64 bytes from 192.168.178.35: icmp_seq=4 ttl=64 time=0.733 ms
^C

ping balt.fritz.box                              gestartet vom client
PING balt.fritz.box(b_alt.fritz.box (2001:d021:abcd:64:7385:c2:ee9a:9a56)) 56 data bytes
64 bytes from balt.fritz.box (2001:d021:abcd:64:7385:c2:ee9a:9a56): icmp_seq=1 ttl=255 time=0.778 ms
64 bytes from balt.fritz.box (2001:d021:abcd:64:7385:c2:ee9a:9a56): icmp_seq=5 ttl=255 time=0.754 ms
^C

Möchte ich den Hostnamen ändern, da er doppelt vorkommt oder unglücklich gewählt wurde (z.B. für ein Samba-Laufwerk max. 15 Zeichen), reicht es nicht nur die Dateien /etc/hostname und /etc/hosts zu ändern. Siehe Ergebnisse der Befehle hostname oder hostnamectl.

Der Hostname sollte klein geschrieben sein, mit Buchstaben anfangen, einmalig im lokalem Netzwerk sein und möglichst keine Sonderzeichen, keine Umlaute, etc. enthalten (also nur a bis z, "-" oder 0 bis 9).

ssh -X m@balt.fritz.box                          sich mit Benutzer m auf dem Host balt einloggen

su
nano /etc/hostname                               Hostname geändert 
b41
                                                 oder
hostnamectl set-hostname b41                     setzt ebenso neuen Namen in /etc/hostname

nano /etc/hosts
127.0.0.1   localhost
127.0.1.1   b41                                  /etc/host muss mit geändert werden
...

hostname
b41                                              Anzeige des neuen Namens auf dem Host

hostnamectl
   Static hostname: b41                          hier wird ebenfalls der neue Name angezeigt
         Icon name: computer-desktop
           Chassis: desktop
        Machine ID: def4e179e6f0fc27e0a39e123456789c
           Boot ID: a31928719334ca0815753526d645c22d
  Operating System: https://www.debian.org/Debian GNU/Linux 10 (buster)
            Kernel: Linux 4.19.0-10-amd64
      Architecture: x86-64
                                                 aber den alten Host erreiche ich
ping balt.fritz.box                              vom Cient immer noch...
PING balt.fritz.box(balt.fritz.box (2001:d021:abcd:64:7385:c2:ee9a:9a56)) 56 data bytes
64 bytes from balt.fritz.box (2001:d021:abcd:64:7385:c2:ee9a:9a56): icmp_seq=1 ttl=255 time=0.568 ms
64 bytes from balt.fritz.box (2001:d021:abcd:64:7385:c2:ee9a:9a56): icmp_seq=2 ttl=255 time=0.648 ms
^C

Erst mit Neustart des Hosts oder neu Initialisierung wird der neue Name übernommen.

su
/etc/init.d/hostname.sh                               funktionierte mal mit DEB  (< 9)?
bash: /etc/init.d/hostname.sh: No such file or directory

/etc/init.d/network                                   gefunden und verworfen...
bash: /etc/init.d/network: No such file or directory

service network-manager restart                       soll bei Ubuntu funktionieren...
bash: service: command not found

/usr/sbin/ifdown --exclude=lo -a && /usr/sbin/ifup --exclude=lo -a
...
Cannot find device "eth0"                             ähm. ja heisst auch anders (enp37s0)

/etc/init.d/networking restart
[....] Restarting networking (via systemctl): 
networking.serviceJob for networking.service failed because the control process exited with error code.
See "systemctl status networking.service" and "journalctl -xe" for details.

systemctl restart networking                          geht auch nicht
Job for networking.service failed because the control process exited with error code.
See "systemctl status networking.service" and "journalctl -xe" for details.

/etc/init.d/network-manager restart                   führt zum Erfolg
[ ok ] Restarting network-manager (via systemctl): network-manager.service.

systemctl reboot                                      alternativ, startet host neu

Zumindest neu booten klappt, wenn man remote arbeitet...
Lokal war ich bei DEB 10 & xfce nur mit /etc/init.d/network-manager restart erfolgreich.
Siehe debian.org Netzwerkkonfiguration

SSH ist sowohl über IP-Adresse möglich (IPv4 Beispiel) ssh -X m@192.168.178.35, alsauch über einen Namen ssh -X m@balt.fritz.box. Solte man auf dem Klienten bereits mit gleichen Benutzernamen angemeldet sein, kann man den Benutzernamen weg lassen z.B. ssh -X balt.fritz.box. Ist man sich sicher, dass man auch keine graphischen Tools starten möchte z.B. Thunar, dann kann man den Parameter -X weg lassen...

Zugriffseinschränkungen des SSH-Servers

Um die Zugriffsberechtigungen zu ändern ist lediglich /etc/ssh_config zu editieren. Die Reihenfolge der Parameter entspricht der Ursprungsdatei. Unter Umständen sind dazwischen noch weitere Parameter, welche ich ausgelassen habe. Grundsätzlich arbeite ich remote mit zwei Verbindungen, wenn ich den Zugriff einschränken möchte. Die erste Verbindung ist bereits etabliert und benutze ich zum Editieren. Die zweite Verbindung baue ich zum Testen auf, um zu überprüfen ob ich noch rein komme... Wenn es dann nicht mehr klappen sollte, kann ich es mit der bestehenden Verbindung wieder rückgängig machen.

Zunächst, stelle ich als Minimal-Konfiguration, nur ein das mit Root kein Zugriff möglich ist und definiere den Zugriff nur eines bestimmten Benutzers.

su
nano /etc/ssh/sshd_config
                                                 DEB 10
#Port 22                                         evtl. Port ändern 
#PermitRootLogin prohibit-password               root über public-key verhindern
PermitRootLogin no                               -> kein root-login erlauben
AllowUsers m                                     nur noch m erlauben

/etc/init.d/ssh restart                          und Neustart vom SSH-Daemon

Nun sollte es nicht mehr möglich sein, mit bekannten Benutzernamen root sich einzuloggen. Dass es noch Benutzer mit den Namen m gibt, kann ein Externer nicht unbedingt erahnen. Anbei das erwartete Testergebnis, welches aussieht als ob man sich vertippt hat.

Einlog-Versuche lassen sich in /var/log/auth.log finden.

ssh -X root@b41.fritz.box
root@b41.fritz.box's password: 
Permission denied, please try again.

Damit die folgenden Schritte nicht zu einem Problemen führen, sollte der Router den Name des Client ab1 immer der selben IP, hier 192.168.178.47, zuweisen. Ebenso sollte der Server/Host b41 immer eine konstante IP z.B. 192.168.178.35 haben.

Fritzbox b41 bearbeiten

Das lässt sich trotz DHCP in der Fritzbox konfigurieren.
Siehe:   Homenetz > Netzwerk > Bearbeiten Button >Häkchen für immer gleiche IPv4 zuweisen > mit OK bestätigen

PC feste IP zuweisen

fail2ban

Wenn ich nun den Benutzer m kenne, könnte ich nun tagelang Passwörter durchtesten, bis ich das gewünschte gefunden habe. Eine Möglichkeit das zu erschweren, ist es Fehlversuche mit zu zählen und dann für eine gewisse Zeit zu sperren. Hierfür gibt es neben wikipedia.org   Denyhosts (veraltet) noch die Software fail2ban, welche hier genutzt wird.

In vielen Anleitungen wird empfohlen /etc/fail2ban/jail.conf zu kopieren, um dann mit der Kopie jail.local zu arbeiten. Meiner Meinung macht das überhaupt keinen Sinn, da von den vielen Zeilen, etwa 4 verändert, benötigt werden.

su
apt install fail2ban    
                     
cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local   kann man sein lassen 

nano /etc/fail2ban/jail.local
# 12.08.20
[sshd]
enabled = true
[DEFAULT]
maxretry = 3                                          statt maxretry = 5
#bantime = 3600                                       statt bantime  = 600
#logpath	= /var/log/auth.log                          

systemctl restart fail2ban                            neue Konfig. übernehmen

systemctl status fail2ban                             1. Überprüfung
● fail2ban.service - Fail2Ban Service
   Loaded: loaded (/lib/systemd/system/fail2ban.service; enabled; vendor preset:
   Active: active (running) since Wed 2020-08-12 22:58:34 BST; 4min 46s ago
     Docs: man:fail2ban(1)
  Process: 3832 ExecStartPre=/bin/mkdir -p /var/run/fail2ban (code=exited, statu
 Main PID: 3833 (fail2ban-server)
    Tasks: 3 (limit: 4915)
   Memory: 15.8M
   CGroup: /system.slice/fail2ban.service
           └─3833 /usr/bin/python3 /usr/bin/fail2ban-server -xf start

Aug 12 22:58:34 b41 systemd[1]: Starting Fail2Ban Service...
Aug 12 22:58:34 b41 systemd[1]: Started Fail2Ban Service.
Aug 12 22:58:34 b41 fail2ban-server[3833]: Server ready                 

fail2ban-client status                                2. Überprüfung
Status
|- Number of jail:	1
`- Jail list:	sshd        

Die Anzahl der Sperrungen und übrigen Geschehnisse, lassen sich von nun an in der Datei /var/log/fail2ban.log verfolgen.

su
tail /var/log/fail2ban.log 
2020-08-14 10:07:59,505 fail2ban.filter   [3833]: INFO    [sshd] Found 2001:d021:abcd:64:7385:c2:9a:0815 - 10:07:59
2020-08-14 10:08:02,211 fail2ban.filter   [3833]: INFO    [sshd] Found 2001:d021:abcd:64:7385:c2:9a:0815 - 10:08:01
2020-08-14 10:08:09,325 fail2ban.filter   [3833]: INFO    [sshd] Found 2001:d021:abcd:64:7385:c2:9a:0815 - 10:08:09
2020-08-14 10:08:09,902 fail2ban.actions  [3833]: NOTICE  [sshd] Ban 2001:d021:abcd:64:7385:c2:9a:0815
2020-08-14 10:11:08,318 fail2ban.filter   [3833]: INFO    [sshd] Found 192.168.178.20 - 2020-08-14 10:11:08
2020-08-14 10:11:11,024 fail2ban.filter   [3833]: INFO    [sshd] Found 192.168.178.20 - 2020-08-14 10:11:10
2020-08-14 10:11:18,564 fail2ban.filter   [3833]: INFO    [sshd] Found 192.168.178.20 - 2020-08-14 10:11:18
2020-08-14 10:11:18,866 fail2ban.actions  [3833]: NOTICE  [sshd] Ban 192.168.178.20
2020-08-14 10:18:09,638 fail2ban.actions  [3833]: NOTICE  [sshd] Unban 2001:d021:abcd:64:7385:c2:9a:0815
2020-08-14 10:21:18,018 fail2ban.actions  [3833]: NOTICE  [sshd] Unban 192.168.178.20

Ich hoffe man kann gut erkennen dass erst 3 Versuche über IPv6 erfolgten, dann 3 Versuche über IPv4, mit jeweils getrennten Aussperrungen, gefolgt von verzögerten Entsperrungen.

Weitere Quellen:
bennetrichter.de   SSH-Server mit Fail2Ban absichern
thomas-krenn.com   SSH Login unter Debian mit fail2ban absichern
digitalocean.com   How To Protect SSH & Nginx-Server with Fail2Ban & firewall (2014)
howtogeek.com   How to Secure Your Linux Server with fail2ban
linuxhandbook.com   Secure Your Linux Server With Fail2Ban [Beginner's Guide]

Zugriff nur mit Schlüssel

Um sich mit Schlüssel anzumelden statt mit Passwort, ist es nötig ein Schlüsselpaar zu erzeugen. Die Idee ist, nur mit zwei Schlüsseln komme ich ins Haus. Ähnlich wie bei PGP, habe ich einen öffentlichen Schlüssel, einen sog. public-key zum Verschlüsseln meiner Nachricht. Und einen privaten Schlüssel - private-key zum Entschlüsseln meiner Nachricht. Je nach Anwendung, kann ich beim Aufruf des Schlüssels noch ein Passwort abfragen. Bei einen Backupserver, welcher eigenständig auf fremde Computer zugreifen möchte, macht das z.B. wenig Sinn. Wohingegen ein normaler entwendbarer Laptop eine zusätliche Passwortabfrage im private-key haben sollte.

Schlüssel-Paar auf dem Client erzeugen

Entsprechend dem vorher gesagtem, erzeuge ich auf dem Clienten ein Schlüssel-Paar. Da in diesem Beispiel, die Anwendung Zugriff auf einen Web-server ist, erzeuge ich den private-key mit Passwort. Da der Default-Algorithmus unter Umständen DSA oder ECDSA sein kann, lege ich mit den Parameter -t rsa explizit fest, welcher Algorithmus verwendet werden soll. RSA mit (default) 2048 Bits wird zurzeit von allen SSH Klienten unterstützt. Langfristig ist es wohl nötig auf 4096 Bits, Parameter -b 4096, zu gehen .

Weitere Parameter kann man unter ssh.com   Grundlagen oder openbsd.org   Befehlsübersicht zu ssh-keygen nachlesen.

ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/m/.ssh/id_rsa): Return 
Created directory '/home/m/.ssh'.
Enter passphrase (empty for no passphrase): geheim
Enter same passphrase again:                geheim
Your identification has been saved in /home/m/.ssh/id_rsa.
Your public key has been saved in /home/m/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:JxbjZCNvUnSoj6kMrUK8iXdOk6eHQ08aNBefFiUvHhH m@b41
The key's randomart image is:
+--[ RSA 2048]----+
|.o. .            |
|o  = . o         |
| ...= . +        |
|  .o.oo. .       |
|  . o+  Soo      |
|   .  . =.o.     |
|       + + E     |
|      . .        |
|                 |
+----[SHA256]-----+

Der im Benutzer-Verzeichnis neu erzeugte Ordner ~/.ssh kann nur vom Benutzer selber gelesen werden (700). Als Ergebnis des obigen Befehls, sind dort nun zwei Dateien erzeugt worden.
id_rsa
id_rsa.pub
Um die öffentliche Datei später besser zuordnen zu können, benenne ich sie gleich um, sodass ich anhand des Namens den Client-Namen und den Benutzer-Namen erkennen kann. Danach logge ich mich auf den Host ein wo ich eine Kopie des public-key ablegen möchte. Sollte also ein anderer Benutzer z.B. a1 versuchen sich auf den gleichen Host mit m einzuloggen, wird er scheitern, da kein privat-key dafür angelegt worden ist.

mv id_rsa.pub b41_m.pub

ssh m@gj2.fritz.box                              auf dem host einloggen
mkdir /home/m/.ssh                               nötig für zukünftige Schlüssel 
chmod 700 /home/m/.ssh                           nur für Besitzer sichtbar machen
exit

Vom Client aus kann ich nun den public-key auf den Host/Server in den Ordner .ssh kopieren.

                      
    Achtung! scp überschreibt das Ziel ohne Warnung
                                                  
scp /home/m/.ssh/b41_m.pub m@gj2.fritz.box:/home/m/.ssh/
Enter passphrase for key '/home/m/.ssh/id_rsa':  Return
m@gj2.fritz.box's password:                      Passwort
b41_m.pub                              100%  387   151.8KB/s   00:00 

Da auf dem Client ein private-key existiert, wird das erste Passwort abgefragt. Da die Kommunikation mit Schlüssel noch nicht etabliert ist, kann man es (1. Passwort) getrost ignorieren.
Das 2. Passwort ist für den Zugriff auf den Web-Server nötig.
Den Spezial-Befehl ssh-copy-id habe ich bewust nicht verwendet, weil das nicht so häufig vorkommt. Außerdem kann man hoffentlich an den scp-Befehl gut sehen wie man z.B. Dateien zwischen Host und Client austauscht. Sicherlich könnte man den Befehl noch zusammen kürzen, da auf jedem Rechner Benutzer m verwendet wird, aber dann wird daraus wieder ein Spezial-Fall...

Siehe:
ionos.de   paar allgemeine Informationen über SCP
hypexr.org   Beispiele für die Anwendung von secure copy - scp.
linuxize.com   using the ~/.ssh/config file

Nun kann man sich erneut auf dem Host einloggen, den kopierten Schlüssel der Liste der authorisierten Schlüssel hinzufügen und in der Datei /etc/ssh/sshd_config nur noch Einloggen via key zulassen.

ssh -X m@gj2.fritz.box
Enter passphrase for key '/home/m/.ssh/id_rsa':  Return 
m@gj2.fritz.box's password:                      Passwort

cat ~/.ssh/b41_m.pub >> ~/.ssh/authorized_keys

cat ~/.ssh/authorized_keys                       mal reingucken, z.zt. nur ein key enth. 
ssh-rsa ASWPHdsXzKOjASkryikBsrcx...snBUr m@b41

su
nano /etc/ssh/sshd_config
                                                 DEB 10
#Port 22                                         evtl. Port ändern 
PermitRootLogin no                               -> kein root-login erlauben
#PubkeyAuthentication yes                        ist bereits Default
#AuthorizedKeysFile  .ssh/authorized_keys        auch default
#IgnoreRhosts yes                                default
PasswordAuthentication no                        geändert, de-aktiviert
ChallengeResponseAuthentication no               default
UsePAM no                                        geändert, de-aktiviert
#AllowUsers m                                    nur m erlauben auskommentiert

/etc/init.d/ssh restart                          und Neustart vom SSH-Daemon

Rechner welche keinen entsprechenden Schlüssel haben, können sich nun nicht mehr einloggen.

ssh -X m@gj2.fritz.box                           von ab1 (nicht authorisiert)
Enter passphrase for key '/home/a1/.ssh/id_rsa': 
Permission denied (publickey).

ssh -X m@gj2.fritz.box                           von b41 (public-key eingebunden)
Enter passphrase for key '/home/m/.ssh/id_rsa': 
Last login: Sat Aug 15 11:20:36 2020 from 2001:...

Pflege der Verbindungen

Mit der Zeit sammeln sich in der Datei known_hosts vom z.B. Web-Server die Rechnernamen und Benutzer, welche alle darauf zugreifen. Sollte sich am Host etwas ändern (neuer Name, andere IP), so wird schnell ein ganzer Satz an neuen Daten erzeugt. Sehr wahrscheinlich gibt es dann beim erneuten Einloggen auch eine dicke Warnung.

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@       WARNING: POSSIBLE DNS SPOOFING DETECTED!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
The ECDSA host key for deb has changed,
and the key for the corresponding IP address 192.168.178.23
...
The fingerprint for the ECDSA key sent by the remote host is
e6:01:90:9a:c6:2d:4b:28:a3:46:27:a1:f7:d0:60:07.
...
Host key verification failed.

Manche Benutzer Client Kombinationen sind dann veraltet und blähen die Liste unnötig auf. Um das Aufräumen zu vereinfachen, habe ich jeden pub-key entsprechend benannt.

cd /home/m/.ssh/                                 .ssh vom Web-Server                                 
ls -l
...
-rw-r--r-- 1 m m  388 Aug 15 18:57 ab1_a1.pub
-rw-r--r-- 1 m m 1173 Aug 15 19:11 authorized_keys
-rw-r--r-- 1 m m  387 Aug 15 10:47 b41_m.pub
-rw-r--r-- 1 m m 1110 Aug 15 18:33 known_hosts
-rw-r--r-- 1 m m  398 Aug 15 19:11 T60_m.pub

cat ab1_a1.pub   ssh-rsa AA...UhVttOZb a1@ab1
cat b41_m.pub    ssh-rsa AA...m3Hej2sn m@b41
cat T60_m.pub    ssh-rsa AA...EUC6Wq1p m@m-ThinkPad-T60

cat authorized_keys                              es ist kein key zu viel 
ssh-rsa AA...m3Hej2sn m@b41
ssh-rsa AA...UhVttOZb a1@ab1
ssh-rsa AA...EUC6Wq1p m@m-ThinkPad-T60

cat known_hosts 
|1|oDZweYPfh8Vcq4XD5jcuZYpIPBM=|LQJkPnWtgv+Fuhl3IQScKiNqBPA= ecdsa-sha2-nistp256 AA...nioubOraCLUcXacgcBcz4=
|1|QpuD/xQPjsbN0zoDbGbXwpjQHwA=|wLvSA25z2B6zV0Hbe8UjaEVZ4QM= ecdsa-sha2-nistp256 AA...nioubOraCLUcXacgcBcz4=
|1|cx42+SC6nv9XaMO51Avkefj4KkM=|8B8ka52Rl1NtZ9e1hfpq4ZjGT+Y= ecdsa-sha2-nistp256 AA...uQpJKJqmFMhtHiMZ4Fl0Y=
|1|T+em/5j5iN4Jkrkkf/yo5OycC08=|UXy0IudxLmu/ZQMFv/0miuBlvSU= ecdsa-sha2-nistp256 AA...uQpJKJqmFMhtHiMZ4Fl0Y=
|1|nRJyvdeweDNa6jC6/MnE27fJ18k=|SyFb0uH9re7fnsv2u6hi2lDQCUw= ecdsa-sha2-nistp256 AA...nioubOraCLUcXacgcBcz4=

Leider erschließt sich mir noch nicht welche Zeile nun überflüssig ist, da eine Zuordnung Hash zu IP-Adresse fehlt.

Weiterführende Verküpfungen: