Kleine Tool-Ü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 Protokoll 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 Tastatur,
Maus und Bildschirm verzichten und arbeitet quasi headless.
SSH-Clients gibt es auf fast jedem System z.B.
- PuTTY SSH-Client unter Windows.
- heise ssh-client unter Windows 10 und neuer.
-
F-Droid
ConnectBot (open source ssh-client) für Android.
Siehe auch puttygen.com 10 best SSH clients for Android -
Mac & Linux haben von Haus aus ein Terminal
in dem mansshdirekt eingeben kann.
Einen SSH-Server gibt es ebenfalls für fast jedes System z.B.
- microsoft.com OpenSSH for windows 10 server.
- F-Droid SimpleSSHD (open source ssh-server daemon) für Android.
- osxdaily.com Artikel von 2011 wie man SSH unter Mac einrichtet.
Zum Anfang
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 heißt 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
Zum Anfang
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 als auch 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.
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, stets 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 als auch 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 abhgä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, heißt 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,
als auch ü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...
Zum Anfang
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.
Das lässt sich trotz DHCP in der Fritzbox konfigurieren.
Siehe: Home-Netz > Netzwerk > Bearbeiten Button >
Häkchen für immer gleiche IPv4 zuweisen > mit OK bestätigen
Zum Anfang
fail2ban
Wenn ich nun den Benutzer m kenne, könnte ich nun tagelang Passwörter durch testen,
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 … 2020-08-14 10:08:02,211 fail2ban.filter [3833]: INFO [sshd] Found 2001:d021:abcd:64:7385:c2:9a:0815 … 2020-08-14 10:08:09,325 fail2ban.filter [3833]: INFO [sshd] Found 2001:d021:abcd:64:7385:c2:9a:0815 … 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]
Zum Anfang
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, mit den Einen verschlüssel ich,
was ich mit den Anderen wieder entschlüsseln kann
oder umgekehrt.
Ähnlich wie bei
openpgp.org,
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 Backup-Server, welcher eigenständig auf
fremde Computer zugreifen möchte, macht das z.B. wenig Sinn.
Wohingegen ein normaler entwendbarer Laptop
eine zusätzliche Passwortabfrage im private-key haben sollte.
Schlüssel-Paar auf dem Klienten erzeugen
Entsprechend dem vorher gesagtem, erzeuge ich auf dem Klienten 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 (unsicher) oder ECDSA sein kann,
lege ich mit den Parameter z.B. -t rsa explizit fest, welcher Algorithmus verwendet werden soll.
RSA mit (default 2048 Bits) wird zurzeit von allen SSH Klienten unterstützt, ist aber nicht mehr zu empfehlen.
Entweder geht man bei RSA mit den Parameter -b 4096 auf 4096 Bits oder
verwendet einen anderen Algorithmus z.B. Parameter -t ed25519 .
Dieser wird allerdings unter Umständen noch nicht überall unterstützt.
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
sollte nur vom Benutzer selber (hier m ) gelesen werden können (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 Klienten-Namen und den Benutzer-Namen erkennen kann.
Danach logge ich mich auf den SSH-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 Klienten 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 Klienten 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 -> Return.
Das 2. Passwort ist für den Zugriff auf den Web-Server nötig.
Den Spezial-Befehl ssh-copy-id habe ich bewusst 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 meiner 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 autorisierten 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 rein gucken, 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 autorisiert) 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:...
Zum Anfang
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 oder Klienten etwas ändern (neuer Name, andere IP, neues System),
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-Klienten 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.
ab1_a1 gehört zum PC ab1 und dem Benutzer a1.
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 der IP-Adresse fehlt.
Zum Anfang
neuer Rechner mit selber IP
Wenn ich auf den Host-Computer, auf dem der SSH-Server läuft, ein neues Betriebssystem installiert habe,
bleibt zwar für den Computer die IP-Adresse gleich, aber der sog. Fingerabdruck ändert sich.
Entsprechend erhalte ich eine Warnung, daß sich etwas geändert hat.
ssh -X m@bs3.fritz.box @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: POSSIBLE DNS SPOOFING DETECTED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ The ECDSA host key for bs3.fritz.box has changed, and the key for the corresponding IP address 2a91:c123:8291:9a0b:2291:8bdd:e491:164d is unknown. This could either mean that DNS SPOOFING is happening or the IP address for the host and its host key have changed at the same time. @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ 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:gbqV7VAix1WUsjeKyYiscTqRZOi2aQXCQTD4m8dcfyB. Please contact your system administrator. Add correct host key in /home/a1/.ssh/known_hosts to get rid of this message. Offending ECDSA key in /home/a1/.ssh/known_hosts:36 remove with: ssh-keygen -f "/home/a1/.ssh/known_hosts" -R "bs3.fritz.box" ECDSA host key for bs3.fritz.box has changed and you have requested strict checking. Host key verification failed.
Glücklicherweise enthält die Meldung auch einen Lösungsansatz.
Daher anbei eine kleine Übersicht der wichtigsten Parameter von ssh-keygen
ssh-keygen Parameter
-fName oder Pfad mit Namen von z.B. known_hosts-F hostnameNach einen "Hostname" suchen-R hostnamelöscht alle Schlüssel, welche zu den Hostname passen.-tSchlüsseltyp definieren z.B. rsa-b bitsSchlüssellänge z.B. 4096 defnieren-Agenerate new host keys-Efingerprint
ssh-keygen -F "bs3.fritz.box" # Host bs3.fritz.box found: line 36 |1|/IJViwO4sGpsv6yYxhBuJFVaRKk=|pyjMx4UUReMeS5Bl27+RLtARIC4= ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItb… ssh-keygen -R "bs3.fritz.box" # Host bs3.fritz.box found: line 36 /home/a1/.ssh/known_hosts updated. Original contents retained as /home/a1/.ssh/known_hosts.old ssh -X m@bs3.fritz.box The authenticity of host 'bs3.fritz.box (2a91:c123:8291:9a0b:2291:8bdd:e491:164d)' can't be established. ECDSA key fingerprint is SHA256:gbqV7VAix1WUsjeKyYiscTqRZOi2aQXCQTD4m8dcfyB. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'bs3.fritz.box,2a91:c123:8291:9a0b:2291:8bdd:e491:164d' (ECDSA) to the list … Enter passphrase for key '/home/a1/.ssh/id_rsa': Return m@bs3.fritz.box's password: Geheim Linux bs3 5.10.0-11-amd64 #1 SMP Debian 5.10.92-1 (2022-01-18) x86_64 The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law.
Zum Anfang