SSH schlägt beim Senden eines Befehls mit einem Hostschlüsselfehler fehl, funktioniert aber ohne

SSH schlägt beim Senden eines Befehls mit einem Hostschlüsselfehler fehl, funktioniert aber ohne

Ich richte einen Server ein, der SSH mit Hostschlüsselauthentifizierung unterstützen kann, was derzeit von einem alten, sterbenden Server gehandhabt wird. Im Moment kann ich erfolgreich eine Verbindung mit SSH herstellen und wie gewohnt im Terminal interagieren. Wenn ich jedoch einen Befehl einfüge oder SSH in einen RSync-Befehl einfüge, erhalte ich die Fehlermeldung „Hostschlüsselüberprüfung fehlgeschlagen“.

So funktioniert dieser Befehl:

ssh -o StrictHostKeyChecking=no -i /cygdrive/C/keys/id_rsa [email protected]

Während dies bei Folgendem nicht der Fall ist:

ssh -o StrictHostKeyChecking=no -T -i /cygdrive/C/keys/id_rsa [email protected] ssh 192.168.0.2 mkdir -p /mnt/storage/new_folder

Sie funktionieren jedoch beide, wenn sie auf den älteren Server verweisen, daher sollten die Befehle selbst in Ordnung sein. Wenn ich es außerdem schaffe, die Befehle nicht zu ändern, wären wir abwärtskompatibel.

Ich füge unten die sshd_config-Einstellungen auf dem neuen Server ein (die so eingestellt waren, dass sie den alten Server nachahmen), falls sie hilfreich sind. Die einzigen Elemente hier sind diejenigen, die nicht auskommentiert wurden.

HostbasedAuthentication nein
RhostsRSAAuthentication nein
PermitEmptyPasswords nein
ChallengeResponseAuthentication nein
UsePAM ja
X11Forwarding ja
PrintMotd nein
PrintLastLog ja
TCPKeepAlive ja
AcceptEnv LANG LC_*
Subsystem sftp /usr/lib/openssh/sftp-server
PubkeyAuthentication ja
RSAAuthentication ja
LoginGraceTime 2m
PermitRootLogin ja
StrictModes ja

Der neue Server ist Ubuntu 17.10 (wird auf LTS aktualisiert, wenn der nächste bald herauskommt). Der alte Server ist Debian 6.0.6.

Bearbeiten: Ich habe vergessen zu erwähnen, dass dieser Fehler auch auftritt, wenn ich RSync mit „-e“ verwende. Ich habe jedoch festgestellt, dass ich das Problem im RSync-Befehl beheben kann, indem ich [email protected]:/mnt/storage/new_folderden Remote-Pfadparameter verwende. Wenn ich „username@“ entferne, erhalte ich den Fehler erneut. Auch hier funktioniert die fehlerhafte Version auf dem alten Server einwandfrei, schlägt nur auf dem neuen Server fehl. Denken Sie auch daran, dass es sich um Legacy-Code handelt. Wenn ich also die alten Befehle so zum Laufen bekomme, wie sie sind, spare ich viel Zeit beim Pushen von Updates.

Antwort1

OK, Sie sitzen auf Host A (nicht angegeben) und wenn Sie Befehl 1 ausführen:

ssh -o StrictHostKeyChecking=no -i /cygdrive/C/keys/id_rsa [email protected]

und Sie erhalten eine interaktive Shell auf Host B (192.168.0.2). Aber wenn Sie Befehl 2 ausführen:

ssh -o StrictHostKeyChecking=no -T -i /cygdrive/C/keys/id_rsa [email protected] ssh 192.168.0.2 mkdir -p /mnt/storage/new_folder

(von Host A), erhalten Sie eine Fehlermeldung.

OK, führen Sie Befehl 1 von Host A aus aus und erhalten Sie eine interaktive Shell auf Host B. Führen Sie nun auf Host B Befehl 2b aus:

ssh 192.168.0.2 mkdir -p /mnt/storage/new_folder

Was passiert? Wenn auch dies fehlschlägt, dann ist Ihr Problem nicht, dass „SSH beim Senden eines Befehls mit einem Hostschlüsselfehler fehlschlägt, aber ohne einen solchen funktioniert“, sondern dass Host B keine SSH-Verbindung zu sich selbst herstellen kann – oder genauer gesagt, dass der „Benutzer“ auf Host B nicht so konfiguriert ist, dass er eine SSH-Verbindung zu Host B herstellen kann.

Und der Vollständigkeit halber, was passiert, wenn Sie den Befehl 2c ausführen:

ssh -o StrictHostKeyChecking=no -T -i /cygdrive/C/keys/id_rsa [email protected]  mkdir -p /mnt/storage/new_folder

(von Host A)?

verwandte Informationen