Ich bin wohl zu doof für SSH (Hostkey nicht gecached)

CB_KeinNameFrei

Lieutenant
Dabei seit
Juli 2009
Beiträge
799
Einmal ist immer das erste Mal, richtig? Blöd nur, wenn man es alleine nicht hinkriegt.

Ich möchte auf einer Windows-Maschine einen Task einrichten, der regelmäßig via psftp eine Datei an eine Unix-Maschine überträgt. Um es kurz zu machen: die Übertragung funktioniert, wann immer ich sie manuell ausführe. Private und Public Key, Batchdatei für die Kommandofolge, alles funzt wunderbar, Datei kommt an. Ich kann mich auch via Putty manuell einloggen und komme auf die Shell.

Aber sobald ich das Kommando als Task laufen lasse - das gleiche Kommando, was manuell funktioniert - bekomme ich im Log nur folgende Meldung:

"The server's host key is not cached in the registry. You have no guarantee that the server is the computer you think it is. (...)"

Habe das natürlich schon nachgeschlagen. Das ist eine Standardmeldung, die immer dann auftritt, wenn man versucht, sich automatisch mit einem unbekannten System zu verbinden. Der dazugehörige Standard-Ratschlag, den man überall findet: Man solle sich mal manuell anmelden, dann wird man gefragt ob man der Maschine vertrauen will.

Allerdings habe ich mich wie oben erwähnt schon mehrfach manuell mit der Maschine verbunden. Sowohl via psftp, als auch via Putty. Ich kann es auch beliebig oft wiederholen. Aber ich werde an keiner Stelle gefragt, ob ich dem Zielsystem vertrauen will.

Wie kriege ich diesen ominösen Hostkey jetzt in diesen nebulösen Cache? Ich weiß weder wo ich den ersteren hernehmen soll, noch weiß ich wo ich letzteren suchen muss.
 

blablub1212

Commodore
Dabei seit
Sep. 2009
Beiträge
5.113

fhtagn

Ensign
Dabei seit
Nov. 2009
Beiträge
154
Wenn du dich das erste Mal manuell mit dem entfernten Rechner verbindest, kommt die Frage ob du dem unbekannten Rechner vertraust yes/no. Unter Linux wird der Hostkey in der Datei .ssh/known_hosts in deinem Home-Verzeichnis hinterlegt. Ich weiss nicht wie das unter Windows ist. Hängt von der verwendeten ssh-Software ab.

Ich vermute, dein Skript läuft nicht in deiner Benutzer-Umgebung, sondern mit einem anderen Account. Lösung ist dann, die ssh-Verbindung einmal mit dem anderen Account herstellen und dem entfernten Rechner vertrauen. Oder halt das Skript mit deinem Benutzer ausführen.
 

CB_KeinNameFrei

Lieutenant
Ersteller dieses Themas
Dabei seit
Juli 2009
Beiträge
799
Aaah, okay, das macht Sinn. Der Task läuft tatsächlich mit einem Servicekonto.

Dann geh ich mal googeln, wie sich ein Hostkey zu einem Konto hinzufügen lässt, dass sich gar nicht am System anmeldet. Das von blablub1212 verlinkte Skript sieht in dem Sonderfall irgendwie nicht so hilfreich aus... zumal ich keinen Python-Interpreter zur Verfügung habe.
 

Sturmel

Ensign
Dabei seit
März 2009
Beiträge
161
Wenn Du die Aufgabenplanung benutzt, solltest Du die Option haben "Beim Ausführen der Aufgaben folgendes Benutzerkonto verwenden:" <Benutzer oder Gruppe ändern> - dann "Unabhängig von der Benutzeranmeldung ausführen" - das sollte doch reichen?
 

CB_KeinNameFrei

Lieutenant
Ersteller dieses Themas
Dabei seit
Juli 2009
Beiträge
799
...Ähm... Ja. Damit lasse ich den Task mit dem Servicekonto laufen. Würde ich das nicht tun, hätte ich das Problem nicht, weil der Task dann mit meinem eigenen Konto laufen würde.

Das Problem liegt bei SSH, und nicht in der Windows-Aufgabenplanung.

Habe mittlerweile schon einiges probiert, bis jetzt keine Lösung. Es gibt noch andere Sachen die ich probieren kann, komme aber heute nicht mehr dazu. Morgen dann.
 

Sturmel

Ensign
Dabei seit
März 2009
Beiträge
161
Ich mag widersprechen, ssh kann da nichts für - Du musst manuell einmal bestätigen, dass Du dem Server vertraust. Wenn Du Dich also mit dem Servicekonto - nennen wir es mal "sshuser" - anmeldest, per ssh auf den Server gehst, dem Schlüssel vertraust, dann den Task einrichtest und ihn mit dem Benutzerkonto "sshuser" ausführst, sollte das auch klappen. Tuts zumindest bei mir ;-)
Falls es bei Dir nicht mag / Du einen Sonderfall hast, kannst Du den Abbruch wegen des Hostkeys umgehen, in dem Du ihn mit an gibst:
Code:
pscp.exe -hostkey 09:e5:6f:a7:f4:f9:81:44:5c:e3:1f:bf:34:57:6c:5a <...>
Das sollte auch mit dem Systemuser klappen.
 
Zuletzt bearbeitet:

CB_KeinNameFrei

Lieutenant
Ersteller dieses Themas
Dabei seit
Juli 2009
Beiträge
799
Das Problem dabei ist, dass Servicekonten bei uns nicht zur interaktiven Anmeldung zugelassen sind (siehe weiter oben). Sie existieren nur, um Hintergrundaufgaben zu erledigen.

Im Endeffekt habe ich das Problem übrigens über einen Umweg gelöst, der so dämlich einfach war, dass man erst Tage später darauf kommt. :freak: Shift+Rechtsklick auf PuTTY -> "Als anderer Benutzer ausführen" -> Credentials eingeben. Jetzt kann man im Benutzerkontext des Servicekontos die SSH-Verbindung aufbauen und den Hostkey akzeptieren. Ganz ohne Anmeldung am System.
 
Top