Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

SSH Fingerprint ändern/restaurieren

8 views
Skip to first unread message

Bernd Hohmann

unread,
Oct 27, 2012, 1:00:51 PM10/27/12
to
Wenn ich meine Workstation (Debian oder eines der Derivate) rücksichern
muss hab ich natürlich das Problem, dass mein rsnapshot-server sich
beschwert dass sich der Fingerprint (oder wie das hiess) geändert hat
und das zuerst in der known_hosts des Backupservers geändert werden muss.

Wo steht dieser Fingerprint drin und kann man den vom alten System
restaurieren?

Bernd

Ulf Volmer

unread,
Oct 27, 2012, 1:11:00 PM10/27/12
to
Bernd Hohmann <bernd.hohma...@freihaendler.com> schrieb:
/etc/ssh/ssh_host_*

Gruß,
Ulf.

Bernd Hohmann

unread,
Oct 27, 2012, 1:25:18 PM10/27/12
to
Am 27.10.2012 19:11, schrieb Ulf Volmer:

>> Wo steht dieser Fingerprint drin und kann man den vom alten System
>> restaurieren?
>
> /etc/ssh/ssh_host_*

Danke!

Bernd


Juergen Ilse

unread,
Oct 28, 2012, 8:15:11 AM10/28/12
to
Hallo,
ssh merkt sich die public-keys (oder die Fingerprints?) der Server zu
denen eine Verbindung aufgebaut wird in der Datei ${HOME}/.ssh/known_hosts.
Das ist eine einfache Textdatei, aus der du die entsprechende Zeile ein-
fach herausloeschen kannst. Dann wirst du zwar beim naechsten Aufbau
einer ssh-Connection gefragt, ob du den (dann unbekannten) key akzeptieren
moechtest, aber wenn du den dann akzeptierst, wird der Eintrag der Datei
wieder zugefuegt.

Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
--
Ein Domainname ist nur ein Name, nicht mehr und nicht weniger.
Wer mehr hineininterpretiert, hat das Domain-Name-System nicht
verstanden.

Bernd Hohmann

unread,
Oct 28, 2012, 10:57:22 AM10/28/12
to
Am 28.10.2012 13:15, schrieb Juergen Ilse:

> ssh merkt sich die public-keys (oder die Fingerprints?) der Server zu
> denen eine Verbindung aufgebaut wird in der Datei ${HOME}/.ssh/known_hosts.
> Das ist eine einfache Textdatei, aus der du die entsprechende Zeile ein-
> fach herausloeschen kannst. Dann wirst du zwar beim naechsten Aufbau
> einer ssh-Connection gefragt, ob du den (dann unbekannten) key akzeptieren
> moechtest, aber wenn du den dann akzeptierst, wird der Eintrag der Datei
> wieder zugefuegt.

So einfach ist das nicht, denn nicht meine Workstation sondern der
Backupserver mault herum dass sich der Key geändert hat. Und der wird
nicht einfach überschrieben sondern muss erst gelöscht und dann neu
zugefügt werden (bzw. da gibts irgendein Kommando dazu was ich mir nicht
merken kann).

Für dieses Procedere muss ich erst auf den Backupserver, dort in der
rsnapshot-konfiguration nachschauen welcher Key überhaupt fürs Backup
zuständig ist, dann root werden (weil der unter /root/.ssh liegt), ssh
mit dem zuständigen Key starten (ssh -i /root/.ssh/dingenskey
$workstation), das complaint auswerten, die known_hosts nach dem
"offending key" durchsuchen, ssh nochmal starten und den neuen Key
einfügen lassen. Dann rsnapshot starten und schauen ob es funktioniert.

Und das ist mir irgendwie zu mühsam ^^

Bernd




Christian Weisgerber

unread,
Oct 28, 2012, 11:24:57 AM10/28/12
to
Juergen Ilse <jue...@usenet-verwaltung.de> wrote:

> ssh merkt sich die public-keys (oder die Fingerprints?) der Server zu
> denen eine Verbindung aufgebaut wird in der Datei ${HOME}/.ssh/known_hosts.

Es sind schon die vollstï¿œndigen Public Keys.

--
Christian "naddy" Weisgerber na...@mips.inka.de

Juergen Ilse

unread,
Oct 29, 2012, 4:56:25 AM10/29/12
to
Hallo,

Bernd Hohmann <bernd.hohma...@freihaendler.com> wrote:
> Am 28.10.2012 13:15, schrieb Juergen Ilse:
>> ssh merkt sich die public-keys (oder die Fingerprints?) der Server zu
>> denen eine Verbindung aufgebaut wird in der Datei ${HOME}/.ssh/known_hosts.
>> Das ist eine einfache Textdatei, aus der du die entsprechende Zeile ein-
>> fach herausloeschen kannst. Dann wirst du zwar beim naechsten Aufbau
>> einer ssh-Connection gefragt, ob du den (dann unbekannten) key akzeptieren
>> moechtest, aber wenn du den dann akzeptierst, wird der Eintrag der Datei
>> wieder zugefuegt.
> So einfach ist das nicht, denn nicht meine Workstation sondern der
> Backupserver mault herum dass sich der Key geändert hat. Und der wird
> nicht einfach überschrieben sondern muss erst gelöscht und dann neu
> zugefügt werden (bzw. da gibts irgendein Kommando dazu was ich mir nicht
> merken kann).

Das macht nicht den grossen Unterschied.

> Für dieses Procedere muss ich erst auf den Backupserver, dort in der
> rsnapshot-konfiguration nachschauen welcher Key überhaupt fürs Backup
> zuständig ist,

Nein, du muesstest ermitteln, unter welchem User die ssh-Verbindung vom
Backup-Server aus aufgebaut werden soll. Du muesstest dann mit diesem
User auf dem Backup-Server so verfahren wie oben beschrieben.

> dann root werden (weil der unter /root/.ssh liegt), ssh
> mit dem zuständigen Key starten (ssh -i /root/.ssh/dingenskey
> $workstation), das complaint auswerten, die known_hosts nach dem
> "offending key" durchsuchen, ssh nochmal starten und den neuen Key
> einfügen lassen. Dann rsnapshot starten und schauen ob es funktioniert.

Nein, denn die Fehlermeldung ruehrt IMHO daher, dass der Host-Key der
remote-Maschine anders ist als er in der .ssh/known_hosts des Backup-
Users auf dem Backup-Server angegeben ist. Der Host-Key der remote-
Maschine ist aber fuer jede ssh-Connection gleich, er ist nur abhaengig
von dem unterhalb von /etc abgelegten Host-Key auf der remote-Maschine
und keineswegs vom User, der sich remote aufschalten will oder dem von
ihm verwendeten User-Key.
0 new messages