☰

KOPS Kubernetes não pode fazer login no bastion host, erro de permissão de chave pública ssh

tag-icon • tag-icon ssh amazon-web-services kubernetes
KOPS Kubernetes não pode fazer login no bastion host, erro de permissão de chave pública ssh

Estou aprendendo sobre Kubernetes e queria provisionar um cluster desse tipo na AWS por meio da ferramenta KOPS. Segui o tutorial oficial e, resumindo, este também https://medium.com/andcloudio/kubernetes-kops-cluster-on-aws-f55d197d8304

Também certifiquei-me de adicionar a chave ssh antes de tentar conectar-me ao host bastião, conforme explicado aqui também https://kops.sigs.k8s.io/bastion/#using-the-bastion

Tudo corre bem, nós, trabalhos, balanceadores de carga, etc. são criados e o host bastião também.

O único problema é que não consigo fazer ssh no host bastião com a chave. Executei o ssh com -vvv para ver a saída detalhada e o log está abaixo. Eu não entendo qual é o 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).

Também estou postando os principais resultados para ajudar na solução de 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

Responder1

Como você pode ver na saída detalhada, o acesso foi negado com base no publickeyque foi usado ao tentar autenticar:

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

Você pode ver acima que todos os arquivos verificados por padrão (se o arquivo específico não foi especificado com -isinalizador) não foram encontrados em seu /root/.ssh/diretório.

Conforme já discutido nos comentários, descobriu-se que você usou o adminusuário que não estava definido no host remoto. Você confirmou que com ubuntuo usuário conseguiu fazer login com sucesso:"agora tentei com o usuário Ubuntu e efetuei login com sucesso no Bastion Host"Como foi suficientemente esclarecido, focarei apenas em responder sua pergunta adicional, postada nos comentários:

Em seguida, foi necessário repetir o processo de cópia das chaves do Host -> bastion e, em seguida, ssh do bastion para o mestre do Kubernetes. Isso funcionou agora, mas eu esperava que o sinalizador -A documentado oficialmente fosse encaminhado de alguma forma para o mestre, mas isso não aconteceu. Tive que duplicar o ssh manualmente e copiar as chaves para o bastião

O sshprocesso de login que você descreveu é conhecido como ssh-ing por meio do chamado host de salto. Lembre-se de que isso não funciona imediatamente e requer configuração adicional. Dê uma olhadaEste artigo, pois explica tudo claramente, você precisa saber sobreconfigurando o encaminhamento do agente SSHo que precisa ser feito se você quiser usar suas chaves locais sshnão apenas para ohospedeiro bastião(que por acaso é umhospedeiro de saltoneste cenário), mas também para ir automaticamente sshde lá para outrohospedeiro remoto.

Resumindo, você precisa criar ~/.ssh/configum arquivo em sua máquina local, se ele não existir, e definir o host para o qual deseja permitir que suas chaves ssh locais sejam encaminhadas e definidas ForwardAgentcomo yes:

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

Além disso, certifique-se de que seu host de saltopermite o encaminhamento do agente SSH em conexões de entrada:

O encaminhamento de agente também pode estar bloqueado em seu servidor. Você pode verificar se o encaminhamento do agente é permitido fazendo SSH no servidor e executando o sshd_config. A saída deste comando deve indicar que AllowAgentForwardingestá definido.

Agora você deve ser capaz de fazer ssh diretamente para seu host remoto de destino por meio de um jumphost diretamente de sua máquina local com um sshcomando. Está bem descritoaqui:

Lista dinâmica de jumphost

Você pode usar a opção -J para passar por um host:

user $ ssh -J host1 host2

Se os nomes de usuário ou portas nas máquinas forem diferentes, especifique-os:

user $ ssh -J user1@host1:port1 user2@host2:port2
Vários saltos

A mesma sintaxe pode ser usada para fazer saltos em múltiplas máquinas:

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

informação relacionada