KOPS Kubernetes kann sich nicht beim Bastion-Host anmelden, Berechtigungsfehler für öffentlichen SSH-Schlüssel

Question

Ich lerne gerade etwas über Kubernetes und wollte einen solchen Cluster in AWS über das KOPS-Tool bereitstellen. Habe das offizielle Tutorial befolgt und dann kurz auch dieses hier https://medium.com/andcloudio/kubernetes-kops-cluster-on-aws-f55d197d8304

Ich habe auch darauf geachtet, den SSH-Schlüssel hinzuzufügen, bevor ich versucht habe, eine Verbindung zum Bastion-Host herzustellen, wie auch hier erklärt https://kops.sigs.k8s.io/bastion/#using-the-bastion

Alles läuft reibungslos, Knoten, Workes, Load Balancer usw. werden erstellt, ebenso der Bastion-Host.

Das einzige Problem ist, dass ich mit dem Schlüssel kein SSH auf den Bastion-Host anwenden kann. Ich habe das SSH mit -vvv ausgeführt, um eine ausführliche Ausgabe zu sehen, und das Protokoll ist unten. Ich verstehe nicht, wo das Problem liegt.

ssh -A admin@${bastion_elb_url} -vvv

Warning: Permanently added 'bastion-single-k8s-local-noarfe-151938406.eu-central-1.elb.amazonaws.com,3.121.65.83' (ECDSA) to the list of known hosts.
debug3: send packet: type 21
debug2: set_newkeys: mode 1
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug3: receive packet: type 21
debug1: SSH2_MSG_NEWKEYS received
debug2: set_newkeys: mode 0
debug1: rekey after 134217728 blocks
debug2: key: /root/.ssh/id_rsa (0x55d6af4ea570), agent
debug2: key: /root/.ssh/id_dsa ((nil))
debug2: key: /root/.ssh/id_ecdsa ((nil))
debug2: key: /root/.ssh/id_ed25519 ((nil))
debug3: send packet: type 5
debug3: receive packet: type 7
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,[email protected],ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,[email protected]>
debug3: receive packet: type 6
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug3: send packet: type 50
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey
debug3: start over, passed a different list publickey
debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /root/.ssh/id_rsa
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey
debug1: Trying private key: /root/.ssh/id_dsa
debug3: no such identity: /root/.ssh/id_dsa: No such file or directory
debug1: Trying private key: /root/.ssh/id_ecdsa
debug3: no such identity: /root/.ssh/id_ecdsa: No such file or directory
debug1: Trying private key: /root/.ssh/id_ed25519
debug3: no such identity: /root/.ssh/id_ed25519: No such file or directory
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey).

Ich veröffentliche auch wichtige Ergebnisse, die bei der Fehlerbehebung helfen sollen:

root@vagrant:/srv# ssh-add -L
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCq9cN3EAEy0WiASY/IBkF9SPIpLv/bZt1tpLc95cb5fG++ac5VX36rA4XukJFtCAk6I4P82ysuqfZGUQNsB57yibz9rbKZ1bFfxRPyGZS22/1Omqb/8B2NlNpJx42sK4odyUj3G+KLCGCmID/AEDhbjeY7d99ZuE6g8aqrtSo0fwsmNHnpvDS8Dt0IjbLxg41Sms9tmYDLlc/tncAs9BmRvuhPbg+BDw+z7ecLneI7+TexDfhXbnZkYfjFLsfI8vWivOu8ptuGVvPkQz/MJo+MokZEzoGbVCAZP5mYSIz+LIFnnCoh5WOMsB3OZuwvelR5bBgWjQhvOaWOX8BuSU5v /root/.ssh/id_rsa

Answer 1

Wie Sie in der ausführlichen Ausgabe sehen können, wurde der Zugriff verweigert, basierend auf dem, publickeywas beim Authentifizierungsversuch verwendet wurde:

debug1: Authentications that can continue: publickey
debug1: Trying private key: /root/.ssh/id_dsa
debug3: no such identity: /root/.ssh/id_dsa: No such file or directory
debug1: Trying private key: /root/.ssh/id_ecdsa
debug3: no such identity: /root/.ssh/id_ecdsa: No such file or directory
debug1: Trying private key: /root/.ssh/id_ed25519
debug3: no such identity: /root/.ssh/id_ed25519: No such file or directory
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey).

Sie können oben sehen, dass alle Dateien, die standardmäßig aktiviert sind (wenn die jeweilige Datei nicht mit dem Flag angegeben wurde ), nicht in Ihrem Verzeichnis -igefunden wurden ./root/.ssh/

Wie bereits in den Kommentaren erläutert, stellte sich heraus, dass Sie den adminBenutzer verwendet haben, der auf dem Remote-Host nicht definiert war. Sie haben bestätigt, dass ubuntuSie sich mit dem Benutzer erfolgreich anmelden konnten:„jetzt mit Ubuntu-Benutzer versucht und erfolgreich beim Bastion-Host angemeldet“Da es ausreichend geklärt wurde, werde ich mich nur auf die Beantwortung Ihrer zusätzlichen Frage konzentrieren, die in den Kommentaren gepostet wurde:

Dann musste ich den Vorgang wiederholen, die Schlüssel vom Host -> Bastion kopieren und dann per SSH von Bastion zum Kubernetes-Master. Das hat jetzt funktioniert, aber ich hatte erwartet, dass das Flag -A, wie offiziell dokumentiert, irgendwie an den Master weiterleitet, aber das ist nicht passiert. Musste per SSH manuell verdoppeln und die Schlüssel in Bastion kopieren – Kristi Jorgji 31. Dez. 2020 um 19:35

Der sshvon Ihnen beschriebene Anmeldevorgang wird als SSH-Verfahren über einen sogenannten Jump-Host bezeichnet. Beachten Sie, dass dies nicht von vornherein so funktioniert und zusätzliche Konfigurationen erfordert. Sehen Sie sich Folgendes an:Dieser Artikel, da es alles klar erklärt, was Sie wissen müssen überEinrichten der SSH-Agent-WeiterleitungDies ist erforderlich, wenn Sie Ihre lokalen Schlüssel sshnicht nur für dieBastion-Host(was zufällig einSprunghostin diesem Szenario), sondern auch automatisch sshvon dort zu einem anderenRemote-Host.

Kurz gesagt müssen Sie eine Datei auf Ihrem lokalen Computer erstellen ~/.ssh/config(falls sie noch nicht vorhanden ist) und den Host festlegen, an den Ihre lokalen SSH-Schlüssel weitergeleitet werden dürfen, und ForwardAgentFolgendes festlegen yes:

Host example.com # it can be either domain name or IP address
  ForwardAgent yes

Stellen Sie außerdem sicher, dass Ihr Jump-Hostermöglicht SSH-Agent-Weiterleitung bei eingehenden Verbindungen:

Die Agentenweiterleitung kann auch auf Ihrem Server blockiert sein. Sie können überprüfen, ob die Agentenweiterleitung zulässig ist, indem Sie sich per SSH mit dem Server verbinden und ausführen sshd_config. Die Ausgabe dieses Befehls sollte anzeigen, dass AllowAgentForwardingfestgelegt ist.

Jetzt sollten Sie in der Lage sein, mit einem Befehl direkt von Ihrem lokalen Rechner aus über einen Jumphost per SSH auf Ihren Ziel-Remote-Host zuzugreifen ssh. Es ist gut beschriebenHier:

Dynamische Jumphost-Liste

Mit der Option -J können Sie durch einen Host springen:

user $ ssh -J host1 host2

Wenn Benutzernamen oder Ports auf den Computern unterschiedlich sind, geben Sie diese an:

user $ ssh -J user1@host1:port1 user2@host2:port2

Mehrere Sprünge

Die gleiche Syntax kann verwendet werden, um Sprünge über mehrere Maschinen hinweg durchzuführen:

user $ ssh -J user1@host1:port1,user2@host2:port2 user3@host3