Moin,

folgende Ausgangssituation:
- 2 Rechner R1 und R2 im heimischen Netzwerk
- R1 kann nur 1 System booten (Debian11)
- R2 kann 2 Systeme booten (S1 und S2, beide Debian11)

R1 soll per SSH auf R2 zugreifen. Auf R1 und R2.S1 wurden Keys
generiert und die Verbindung per SSH klappt auch.

Die Definition von R2.S1 habe ich dann nach R2.S2 kopiert. Beim
Anmeldung von R1 bei R2.S2 kommt folgende Meldung:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ 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:8u9viJ7Rf0egW5EoFzoOMD8xbeCDmmxSybw4omZyndk.
Please contact your system administrator.
Add correct host key in /home/dgs/.ssh/known_hosts to get rid of this >message.
Offending ECDSA key in /home/dgs/.ssh/known_hosts:1
remove with:
ssh-keygen -f "/home/dgs/.ssh/known_hosts" -R "dlt.home.lan"
ECDSA host key for dlt.home.lan has changed and you have requested
strict checking.
Host key verification failed.

Also entsprechende Zeile in known_hosts entfernt. Nach erneuter
Anmeldung wird der Key in known_hosts übernommen und ich kann mit R2.S2 arbeiten.

Okay, R2 neu gebootet und S1 gestartet. Jetzt kommt aber die obige
Meldung beim Anmelden bei R2.S1. Wenn ich die betreffende Zeile in
known_hosts entferne und mich erneute anmelde, klappt der Zugang zu S1.

A long story short: es geht immer nur eine Anmeldung an einem System.

Bei früheren Debian-Systemen (jessie, stretch) hat das mal
funktioniert, jetzt mit bullseye aber nicht mehr.

Gibt es Wege aus meinem Dilemma?

Dieter

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Diese Meldung ist vollkommend richtig. Es könnte sein, dass sich jemand per SSH dazwischenschaltet (Man-In-The_Middle-Attack).
Deshalb speichert R1 bei der erstmaligen Anmeldung auf R2 den Fingerabdruck von R2 in ~/.ssh/known_hosts (egal ob mit Public-Key oder ohne). Bei erneuter Anmeldung wird dieser verglichen.

Eine Lösung deines Problems wäre, bei R2.S1 und R2.S2 verschiedene Hostnames zu benutzen (z.Bsp. dlt1 und dlt2).
Diese können einfach in der Datei /etc/hostname geändert und anschließend neu gebootet werden.

Natürlich musst du die Konfiguration von R1 entsprechend anpassen. Man kann trotzdem den gleichen Schlüssel verwenden.

Weitere Erläuterungen gibt es auf meiner Webseite:

https://raspi01.i9iewizjfq8pi84q.myfritz.net/linux/raspberrypi/ssh.html

--
Ulf Brüggemann <ulf_brueggemann@t-online.de>

-----BEGIN PGP SIGNATURE-----

iHUEARYIAB0WIQSG7mpaNEdeSMsKqPG6UAsIwsWzaAUCZB3cUgAKCRC6UAsIwsWz aBJ6AP0chKGWOnjhp0+kkx75YzlJU0IKuRp5YLb/Rzz6znEHwQEA9tgXEEdj1KL8 LzipBswNzKW4QwFGq4elYPTz/Edsygo=
=ta50
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi!

* Ulf Brüggemann <ulf_brueggemann@t-online.de> [230324 18:22]:

Eine Lösung deines Problems wäre, bei R2.S1 und R2.S2 verschiedene Hostnames zu benutzen (z.Bsp. dlt1 und dlt2).
Diese können einfach in der Datei /etc/hostname geändert und anschließend neu gebootet werden.

Hostname und /etc/hostname gehen nur indirekt in die known_hosts eines
Client ein (dhcp mit gesendetem Hostname und dynamsichen DNS-Einträgen
wäre ein Beispiel).

Hängt also jetzt im Details davon ab, wie der OP von R1 auf seine R2s
zugreift.


Mit besten Grüßen,
Alexander

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi!

* Dieter Rohlfing <dr-erc@gmx.net> [230324 17:58]:

folgende Ausgangssituation:
- 2 Rechner R1 und R2 im heimischen Netzwerk
- R1 kann nur 1 System booten (Debian11)
- R2 kann 2 Systeme booten (S1 und S2, beide Debian11)

R1 soll per SSH auf R2 zugreifen. Auf R1 und R2.S1 wurden Keys
generiert und die Verbindung per SSH klappt auch.

Die Definition von R2.S1 habe ich dann nach R2.S2 kopiert. Beim
Anmeldung von R1 bei R2.S2 kommt folgende Meldung:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ 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)!

[..]

A long story short: es geht immer nur eine Anmeldung an einem System.

Works as designed :)

Diese Meldung hat mit den User-Keys nichts zu tun. Es geht um die Host
Keys. Damit identifiziert sich der Server gegenüber dem client, und der
Client merkt sich die ihm bekannten Host-Keys normalerweise, und
natürlich zu welchem Server diese gehören.

Normalerweise werden diese während der Installation generiert.
Installierst du zwei unterschiedliche System, hast du also zwei unterschiedliche Host Keys -> Dein Client meckert also nach jedem
umbooten, dass der ihm vom Server präsentierten keys nicht bekannt sind,
und nicht die sind, die er von diesem Server erwartet.

Du kannst nun entweder bei S1 und S2 unterschiedliche IPs und hostnamen Verwenden, oder in S1 und S2 die gleichen Hostkeys in
/etc/ssh/ssh_host_* verwenden.


Mit besten Grüßen,
Alexander

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

R1 braucht einen key für R2.S1 und einen für R2.S2. Und dann in
der ~/.ssh/config von R1 die entsprechenden Einträge.

Es ist immer ratsam für jeden Rechner, mit dem man sich verbinden möchte, ein eigenes Schlüsselpaar zu generieren.
Und Zertifikate zu verwenden.

hth
m.

On Fri, 24 Mar 2023 17:58:11 +0100
Dieter Rohlfing <dr-erc@gmx.net> wrote:

Moin,

folgende Ausgangssituation:
- 2 Rechner R1 und R2 im heimischen Netzwerk
- R1 kann nur 1 System booten (Debian11)
- R2 kann 2 Systeme booten (S1 und S2, beide Debian11)

R1 soll per SSH auf R2 zugreifen. Auf R1 und R2.S1 wurden Keys
generiert und die Verbindung per SSH klappt auch.

Die Definition von R2.S1 habe ich dann nach R2.S2 kopiert. Beim
Anmeldung von R1 bei R2.S2 kommt folgende Meldung:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ 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:8u9viJ7Rf0egW5EoFzoOMD8xbeCDmmxSybw4omZyndk.
Please contact your system administrator.
Add correct host key in /home/dgs/.ssh/known_hosts to get rid of this >>message.
Offending ECDSA key in /home/dgs/.ssh/known_hosts:1
remove with:
ssh-keygen -f "/home/dgs/.ssh/known_hosts" -R "dlt.home.lan"
ECDSA host key for dlt.home.lan has changed and you have requested
strict checking.
Host key verification failed.

Also entsprechende Zeile in known_hosts entfernt. Nach erneuter
Anmeldung wird der Key in known_hosts übernommen und ich kann mit R2.S2 >arbeiten.

Okay, R2 neu gebootet und S1 gestartet. Jetzt kommt aber die obige
Meldung beim Anmelden bei R2.S1. Wenn ich die betreffende Zeile in >known_hosts entferne und mich erneute anmelde, klappt der Zugang zu S1.

A long story short: es geht immer nur eine Anmeldung an einem System.

Bei früheren Debian-Systemen (jessie, stretch) hat das mal
funktioniert, jetzt mit bullseye aber nicht mehr.

Gibt es Wege aus meinem Dilemma?

Dieter

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi!

* m <lacksaufen@0x520.de> [230324 18:13]:

Es ist immer ratsam für jeden Rechner, mit dem man sich verbinden möchte, ein eigenes Schlüsselpaar zu generieren.

Wie begründest du das? Hätte jetzt eher gesagt, dass der Zielrechner
eher egal ist, aber es sinnvoll ist pro Quelle einen eigenen Key zu
generieren.

Argument hier: Falls der private Key auf einer Quelle kompromitiert
wurde, ist ein Keyrollover leichter zu bewerkstelligen.


Mit besten Grüßen,
Alexander

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hallo Alexander,

vielen Dank für Deine Rückmeldung.

Am Fri, 24 Mar 2023 18:14:22 +0100
schrieb Alexander Reichle-Schmehl <alexander@alphamar.org>:

Diese Meldung hat mit den User-Keys nichts zu tun. Es geht um die Host
Keys. ...

Installierst du zwei unterschiedliche System, hast du also zwei >unterschiedliche Host Keys -> Dein Client meckert also nach jedem
umbooten, dass der ihm vom Server präsentierten keys nicht bekannt sind,
und nicht die sind, die er von diesem Server erwartet.

Du kannst nun entweder bei S1 und S2 unterschiedliche IPs und hostnamen >Verwenden, oder in S1 und S2 die gleichen Hostkeys in
/etc/ssh/ssh_host_* verwenden.

Auf die Keys unter /etc/ssh habe ich noch gar nicht geachtet. Werde mal überprüfen, ob sie gleich oder unterschiedlich sind.

Dieter

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Vielen Dank für Deine Rückmeldung.

Am Fri, 24 Mar 2023 18:13:35 +0100
schrieb m <lacksaufen@0x520.de>:

R1 braucht einen key für R2.S1 und einen für R2.S2. Und dann in
der ~/.ssh/config von R1 die entsprechenden Einträge.

Leuchtet mir ein, aber wodurch sollen sich R2.S1 und R2.S2 in der
~/.ssh/config unterschieden.

Folgende Dinge sind bei R2.S1 und R2.S2 identisch:
- Hostname
- IP-Adresse
- User
- SSH-Port
- Schlüssel-Paar in ~/.ssh

Dass R2.S1 und R2.S2 nach außen gleich aussehen ist bewußt gewählt und
daran möchte ich auch nichts ändern. Ich frage mich, wodurch merkt R1,
dass ihm mal der SSH-Server von R2.S1 und mal der von R2.S2 antwortet.

Dieter

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hallo Ulf,

vielen Dank für Deine Rückmeldung und ein dickes Lob für Deine
Webseite, da hast Du Dir aber wirklich viel Mühe gegeben.

Am Fri, 24 Mar 2023 18:22:26 +0100
schrieb Ulf Brüggemann <ulf_brueggemann@t-online.de>:

Deshalb speichert R1 bei der erstmaligen Anmeldung auf R2 den Fingerabdruck von R2 in ~/.ssh/known_hosts (egal ob mit Public-Key oder ohne). Bei erneuter Anmeldung wird dieser verglichen.

Das hat Alexander sehr schön beschrieben.

Eine Lösung deines Problems wäre, bei R2.S1 und R2.S2 verschiedene >Hostnames zu benutzen (z.Bsp. dlt1 und dlt2).

Das möchte ich eigentlich vermeiden. Nach außen sollen R2.S1 und R2.S2
sich nicht unterscheiden, sondern nur inhaltlich.

Dieter

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Dieter Rohlfing schrieb:

Am Fri, 24 Mar 2023 18:22:26 +0100
schrieb Ulf Brüggemann <ulf_brueggemann@t-online.de>:

Eine Lösung deines Problems wäre, bei R2.S1 und R2.S2 verschiedene >Hostnames zu benutzen (z.Bsp. dlt1 und dlt2).

Das möchte ich eigentlich vermeiden. Nach außen sollen R2.S1 und R2.S2
sich nicht unterscheiden, sondern nur inhaltlich.

Ulf meint wohl nicht den Hostname im DNS sondern nur wie Du R2 von R1 aus mit ssh ansprichst.

~/.ssh/config auf R1:

Host r2system1
HostKeyAlias R2System1
Hostname R2 (oder IP)

Host r2system2
HostKeyAlias R2System2
Hostname R2 (oder IP)

Und dann eben mit 'ssh r2system1' verbinden.

Ich bin mir gerade nicht sicher aber HostKeyAlias wird wohl notwendig sein weil eben
normalerweise der Hostname zur Unterscheidung in known_hosts genutzt wird und der
ist ja eben bei beiden installierten Systemen gleich.

Und etwas nervig wäre das man dann vorm verbinden wissen müsste welche Installation
gerade auf dem Rechner R2 gebootet ist.
Eventuell gibt es aber doch noch Kriterien zur Unterscheidung, die von außen erkennbar
sind, andere geöffnete Ports vielleicht?
Dann könnte man ja ein kleines Wrapper-Skript zum bestimmen des hosts mit dem verbunden
werden soll nutzen.
Oder man nimmt eben genau den Punkt warum Du aktuell gegen die Wand rennst zur Unterscheidung welches OS gerade läuft :-)
nmap --script ssh-hostkey hostname
Das funktioniert hier in bullseye aber gerade nur mit nmap aus backports UND wenn der
sshd auf dem Standardport 22 läuft. Vielleicht ist das aber auch doch ein Fehler meinerseits.

Ansonsten könnte man auch einfach in beiden Systemen die gleichen ssh-host-keys in
/etc/ssh nutzen, aber "best practice" ist das dann nicht gerade.
Das könnte man nach Abwägung aber auch als OK einstufen, hängt halt von der Umgebung
ab ob man das als gangbare Lösung ansieht.

--
Tschau,
Manfred

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hallo Manfred,

vielen Dank für Deine Rückmeldung.

Am Sat, 25 Mar 2023 15:04:53 +0100
schrieb Manfred Schmitt <expires-230331@slashproc.org>:

Ansonsten könnte man auch einfach in beiden Systemen die gleichen ssh-host-keys in
/etc/ssh nutzen, aber "best practice" ist das dann nicht gerade.

Eigentlich bin ich auch ein Freund von "best practice", aber hier
handelt es sich ausschließlich von SSH-Connects zwischen Rechnern im heimischen Netz (also nichts mit Outbound Traffic). Ich glaube, da muss
ich die Messlatte für Sicherheit nicht so hoch hängen.

Dieter

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)