wie IP-Adresse zur list of known_hosts?

[markeese]

...immer diese lästigen aber doch essentiellen Kleinigkeiten.
Liebes Forum,
vielleicht könnt Ihr mir auch hier einen Tipp geben.
Ich versuche ein
ssh -p 2345 IPAdresseauf einen entfernten Linux PC. Dieser ist mir via DynIP bekannt.
Da er eine dynamische IP hat, ändert sich diese leider auch von Zeit zu Zeit.
Das Sytem meldet dann
RSA host key for IP-Adresse not in list of known hosts.und lässt mich nicht rein.
Ich kannte immer die Variante mit "Warning: IP added to list of known_hosts".
Was kann ich tun?

Grüße.
Markeese...

[marce]

aus dem Kopf heraus müsste IgnoreUserKnownHosts in der sshd_config dafür zuständig sein.

[markeese]

Hi marce,

das hat leider so nicht funktioniert.
Um die ganze Wahrheit loszuwerden, versuche ich ein
ssh -p 2222 -l backup DynIpAdresseauf die entfernte Maschine.
D.h. ich versuche mich als User "backup" anzumelden.
Aber sowohl
IgnoreUserKnownHosts yes als auch IgnoreRhosts yes (und einem sshd restart natürlich) ändern was an der Meldung!?!

[cane]

Du musst die Einstellungen auf dem Client machen, nicht auf dem Server.

mfg
cane

[markeese]

Jop. Das habe ich so getan.

Jetzt das Kuriose:
Alle Einstellungen in der sshd_conf (auf dem Client) waren schon zuvor entsprechend gesetzt.
Und:
Die Datei known_hosts in .ssh für den User "backup" auf dem Client PC ist ellenlang.
Dementsprechend wurde diese wohl bereits bei Bedarf mit neuen IP's angereichert.
Und seit letzter Nacht plötzlich klaptt's nicht mehr!?!

Hier noch ein weiterer Hinweis:
Es gibt mehrere PC's (drei Clients) die sich von Zeit zu Zeit auf den selben Server, wie beschrieben als User 'backup' einwählen. Auf denen habe ich jetzt ebenfalls mal nachgesehen.
Alle drei haben seit letzter Nacht das selbe Problem!?!

[cane]

Hmm, da das eine clientspezifische einstellung ist:

Muss die Configoption nicht in /etc/ssh/ssh_config statt /etc/ssh/sshd_config ?

mfg
cane

[temir]

Mal eine Frage zwischen: wieso eine dynIP verwenden statt eines dynNames?
Denn der Name dürfte wohl der gleiche bleiben (bei dynDNS registriert?), somit
würde das Problem mit den übergroßen known_hosts entfallen...

[markeese]

Die Idee mit DynIP bzw. DynName habe ich noch nicht in Betracht gezogen. Danke für den Hint.
Allerdings löst das mein eigentliches Problem nicht.
Mir will einfach nicht in den Kopf, wieso ein User (backup) bei jedem ssh auf eine andere Maschine,
bei Bedarf immer schön ordentlich die list of known hosts weiterschreibt, zu irgend einem Zeitpunkt damit aufhört
und jetzt meckert, dass eine neue IP nicht in dieser Liste vorhanden ist und den Zugriff verweigert!?!
Ich habe noch nicht mal eine Idee, wo genau ich anfangen könnte zu suchen.

Gruß.
Markeese...

Ach ja; cane:
Ich habe bisher alle ssh-spezifischen Einträge (i.e port, protocol, IgnoreUserKnownHosts etc.) in der sshd_config gemacht.
Dementsprechend haben die SSH Verbindungen auch immer funktioniert. Mir ist nicht klar, wofür die Datei ssh_config steht.

[Aqualung]

Vemutlich klappt es dann nicht mehr mit dem login, wenn auf dem Zielrechner z.B. der Hostkey im Rahmen eines Update geändert wurde.

Dann sollte helfen:


ssh -o stricthostkeychecking=no backup@DynIpAdresse

[temir]

sshd_config - daemon-config (sollte auch chmod 640, owner root:root haben)
ssh_config - client-config

Wenn man also auf der lokalen Machine `ssh user@host.domain` aufruft, dann
wird die /etc/ssh/ssh_config (globale) oder ~/.ssh/config (User-spezifische) auf
der lokalen Machine, und /etc/ssh/sshd_config auf der remote-Machine angezogen.

[markeese]

Hi,

habe mittlerweile alles mögliche ausprobiert und bin der Sache ein wenig näher gekommen.
Allerdings mit einer neuen Frage.
Ich starte dazu ein neues thread, http://www.linuxforen.de/forums/showthread.php?t=262158 damit dieses hier nicht ausufert.

Gruß.
Markeese...

[fubar]

Wie hast Du das SSH-Problem nun beseitigt?

regards
fubar

[markeese]

Das Problem ist nicht behoben aber ich habe dank marce einen 'Workaround' gefunden.
Wie im Link (siehe weiter) oben beschrieben, tauchten die Anmeldeprobleme immer nur in Verbindung mit der crontab auf.
Jobs, die unter einem bestimmten User (nicht root) hier drin standen, hatten plötzlich Anmeldeprobleme (wie oben geschildert) auf dem Remote PC.
Diese Jobs habe ich aus der allgemeinen crontab entfernt und in die Tabelle des entsprechenden Users wieder eingetragen.
Und voila; Jetzt geht es wieder.
Unklar ist mir, warum die Variante mit der allgemeinen crontab bestimmt ein Jahr lang funktioniert hatte und plötzlich den Dienst quittiert?!?

Gruß.
Markeese...