☰

KOPS Kubernetes no puede iniciar sesión en el host bastión, error de permiso de clave pública ssh

tag-icon • tag-icon ssh amazon-web-services kubernetes
KOPS Kubernetes no puede iniciar sesión en el host bastión, error de permiso de clave pública ssh

Estoy aprendiendo sobre Kubernetes y quería aprovisionar uno de esos clústeres en AWS a través de la herramienta KOPS. Seguí el tutorial oficial y luego, brevemente, este también. https://medium.com/andcloudio/kubernetes-kops-cluster-on-aws-f55d197d8304

También me aseguré de agregar la clave ssh antes de intentar conectarme al host bastión como se explica aquí también. https://kops.sigs.k8s.io/bastion/#using-the-bastion

Todo va bien, se crean nodos, workes, balanceadores de carga, etc., y también el host bastión.

El único problema es que no puedo acceder al host bastión con la clave. Ejecuté ssh con -vvv para ver la salida detallada y el registro se encuentra a continuación. No entiendo cual es el problema

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).

También estoy publicando resultados clave para ayudar a solucionar problemas:

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

Respuesta1

Como puede ver en la salida detallada, se denegó el acceso según lo publickeyque se utilizó al intentar autenticarse:

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).

Puede ver arriba que todos los archivos que están marcados de forma predeterminada (si el archivo en particular no se especificó con -iuna bandera) no se encontraron en su /root/.ssh/directorio.

Como ya se comentó en los comentarios, resultó que utilizó el adminusuario que no estaba definido en el host remoto. Confirmaste que con ubuntuel usuario lograste iniciar sesión exitosamente:"ahora lo intenté con el usuario de ubuntu e inicié sesión exitosamente en el host bastión"Como ya quedó suficientemente claro, me centraré únicamente en responder su pregunta adicional, publicada en los comentarios:

Luego, tuve que repetir el proceso de copiar claves desde el host -> bastión, luego ssh desde bastión a kubernetes master. Esto funcionó ahora, pero esperaba que el indicador -A, como está duplicado oficialmente, se reenviara de alguna manera al maestro, pero no sucedió. Tuve que duplicar ssh manualmente y copiar claves al bastión agregado 31 diciembre 2020 en el 09:35, el autor Kristi Jorgji, fuente

El sshproceso de inicio de sesión que describió se conoce como ssh-ing a través del llamado host de salto. Tenga en cuenta que no funciona de esta manera desde el primer momento y requiere configuración adicional. Echa un vistazo aEste artículo, como explica claramente todo, necesitas saber sobreconfigurar el reenvío de agentes SSHlo cual debe hacerse si desea utilizar sus claves locales sshno solo para elanfitrión bastión(que resulta ser unanfitrión de saltoen este escenario) sino también automáticamente sshdesde allí a otroservidor remoto.

En resumen, debe crear ~/.ssh/configun archivo en su máquina local, si no existe, y configurar el host al que desea permitir que se reenvíen sus claves ssh locales y configurarlo ForwardAgenten yes:

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

Además, asegúrese de que su servidor de saltopermite el reenvío de agentes SSH en conexiones entrantes:

El reenvío de agentes también puede estar bloqueado en su servidor. Puede verificar que el reenvío de agentes esté permitido mediante SSH en el servidor y ejecutando sshd_config. El resultado de este comando debería indicar que AllowAgentForwardingestá configurado.

Ahora debería poder realizar ssh directamente a su host remoto de destino a través de un jumphost directamente desde su máquina local con un solo sshcomando. esta bien descritoaquí:

Lista dinámica de jumphost

Puedes usar la opción -J para saltar a través de un host:

user $ ssh -J host1 host2

Si los nombres de usuario o los puertos de las máquinas difieren, especifíquelos:

user $ ssh -J user1@host1:port1 user2@host2:port2
múltiples saltos

Se puede utilizar la misma sintaxis para realizar saltos sobre varias máquinas:

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

información relacionada