SSH kann auf dem Gitlab-Runner nicht mehr verwendet werden. "Host-Schlüsselüberprüfung fehlgeschlagen."

2890
Sven van Zoelen

Der betreffende Server ist ein Läufer und erstellt Projekte mit einem Systembenutzer gitlab-runner. Dieser Benutzer wird für SSH in andere Server verwendet, um Code usw. bereitzustellen.

Hat immer gut funktioniert, bis wir einen neuen Server als Ziel hinzugefügt haben. Der Befehl SSHschlägt jetzt immer mit dem Fehler "Host-Schlüsselüberprüfung fehlgeschlagen" fehl. . Der Fehler wird auch ausgelöst, wenn ich andere Server versuche, die zuvor funktioniert haben. Die known_hostsDatei wird gelöscht, aber SSH fordert nicht mehr zum Hinzufügen des Servers auf known_hosts, sondern gibt die Fehlermeldung direkt zurück.

Ich habe die Berechtigungen des ~/.sshOrdners und der Dateien geprüft . Dies sind richtig ( .ssh: 700, known_hosts: 600, id_rsa: 600, id_rsa.pub: 644). Als der Server neu gestartet wurde, war dies jedoch kein Erfolg.

SSH funktioniert nicht richtig. Hier ist eine Debug-Ausgabe der Verbindung zu einem Server über SSH.

OpenSSH_7.2p2 Ubuntu-4ubuntu2.4, OpenSSL 1.0.2g 1 Mar 2016 debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 19: Applying options for * debug1: Connecting to megatron.domain.com [10.139.20.204] port 22. debug1: Connection established. debug1: identity file /home/gitlab-runner/.ssh/id_rsa type 1 debug1: key_load_public: No such file or directory debug1: identity file /home/gitlab-runner/.ssh/id_rsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/gitlab-runner/.ssh/id_dsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/gitlab-runner/.ssh/id_dsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/gitlab-runner/.ssh/id_ecdsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/gitlab-runner/.ssh/id_ecdsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/gitlab-runner/.ssh/id_ed25519 type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/gitlab-runner/.ssh/id_ed25519-cert type -1 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.4 debug1: Remote protocol version 2.0, remote software version OpenSSH_7.2p2 Ubuntu-4ubuntu2.4 debug1: match: OpenSSH_7.2p2 Ubuntu-4ubuntu2.4 pat OpenSSH* compat 0x04000000 debug1: Authenticating to megatron.achillescm.nl:22 as 'root' debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: algorithm: curve25519-sha256@libssh.org debug1: kex: host key algorithm: ecdsa-sha2-nistp256 debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none debug1: expecting SSH2_MSG_KEX_ECDH_REPLY debug1: Server host key: ecdsa-sha2-nistp256 SHA256:/zgPQuuy6sG8UuLG9EHFSFAuY1QYNvQzKSyNYq//DJ0 debug1: read_passphrase: can't open /dev/tty: No such device or address Host key verification failed.

Jemand eine Idee?

1
"ssh" versucht Sie zwar zu fragen, ob Sie den Host-Schlüssel akzeptieren (und hinzufügen), aber aus irgendeinem Grund kann "/ dev / tty" nicht geöffnet werden. Ich habe das noch nie gesehen, und es deutet an, dass etwas in Ihrem System ziemlich durcheinander ist, aber mit den gegebenen Informationen habe ich keine Ahnung, was. (Der Funktionsname "read_passphrase" ist hier etwas irreführend; er wird auch von "confirm" in "ssh_connect.c" aufgerufen.) Wenn Sie known_hosts manuell neu erstellen, z. B. mit "ssh-keyscan", sollte dieses spezielle Problem vermieden werden falsch gehen kann ich nicht sagen. dave_thompson_085 vor 6 Jahren 0
@ dave_thompson_085 Thx für den Kommentar. Das System ist ein sehr einfaches Setup. Ubuntu + Gitlab Läufer, mehr nicht. Sven van Zoelen vor 6 Jahren 0

3 Antworten auf die Frage

1
Sven van Zoelen

Ich habe das Problem gefunden. Das Problem war, dass die known_hostsDatei die falschen Berechtigungen hatte.

Es wurde eingestellt 600und sollte es sein 644.

0
kenorb 
debug1: identity file /home/gitlab-runner/.ssh/id_rsa type 1 debug1: key_load_public: No such file or directory

Obenstehende Zeilen deuten an, dass .ssh/id_rsaexists ( type 1) vorhanden ist, der öffentliche Schlüssel ( .ssh/id_rsa.pub) für den Benutzer hat jedoch keine Probleme ( type -1).

Stellen Sie daher sicher, dass die Datei ~/.ssh/id_rsavorhanden ist, über die 600Berechtigung verfügt und dem Benutzer gehört. Und die ~/.ssh/id_rsa.pubÜbereinstimmungen / gehören zu derselben Identität (wie in diesem Beitrag ).

Hier ist ein einfacher Test, um als Sudo Access-Benutzer (zB root) ausgeführt zu werden:

sudo -u gitlab-runner sh -c 'cd; wc -l .ssh/id_rsa; stat .ssh/id_rsa; head -n1 .ssh/id_rsa'

Siehe auch: Was bedeutet "key_load_public: keine solche Datei oder Verzeichnis"?

Genau das Gegenteil; Typ 1 bedeutet, dass id_rsa gelesen werden kann und einen RSA-Schlüssel enthält. (Andere Algorithmen sind andere positive Zahlen; _negative_ one ist ein Fehler.) Korrigiert: Die _subsequent_-Datei `id_rsa-cert` wird nicht gefunden. dave_thompson_085 vor 6 Jahren 0
Der von Ihnen angegebene Befehl gibt `bash: Zeile 0: cd: / root: Berechtigung verweigert. Wc: .ssh / id_rsa: Berechtigung verweigert stat: Keine Stat '.ssh / id_rsa': Berechtigung verweigert`. Wenn ich den Befehl nach `su gitlab-runner -` ausführen, wird Folgendes ausgegeben:` Datei: '.ssh / id_rsa' Größe: 3243 Blöcke: 8 IO Block: 4096 reguläre Datei Gerät: fd01h / 64769d Inode: 283738 Links: 1 Zugriff : (0600 / -rw -------) Uid: (999 / gitlab-runner) Gid: (998 / gitlab-runner) Zugriff..` Sven van Zoelen vor 6 Jahren 0
0
Guest12344

Das gleiche Problem tritt manchmal auf, wenn / dev / tty-Berechtigungen zu restriktiv sind. Dann kann man als User root nur ssh auf einen Server bringen, niemand sonst. Der Fix ist zu chmod 777 / dev / tty, damit die anderen es tun können.

666 ist wahrscheinlich genauso gut (oder vielleicht besser). Ich kenne keinen Grund, einem Gerät die Ausführungsberechtigung zu erteilen. Scott vor 5 Jahren 0

Verwandte Probleme