Я изучаю Kubernetes и хотел подготовить один такой кластер в AWS с помощью инструмента KOPS. Следовал официальному руководству, а затем, для краткости, и этому https://medium.com/andcloudio/kubernetes-kops-cluster-on-aws-f55d197d8304
Я также добавил ключ SSH перед попыткой подключения к хосту-бастиону, как описано здесь. https://kops.sigs.k8s.io/bastion/#использование-бастиона
Все идет хорошо, создаются узлы, рабочие станции, балансировщики нагрузки и т. д., а также хост-бастион.
Единственная проблема в том, что я не могу подключиться по ssh к хосту bastion с помощью ключа. Я запустил ssh с -vvv, чтобы увидеть подробный вывод, а журнал ниже. Я не понимаю, в чем проблема
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).
Я также публикую основные результаты, которые помогут устранить неполадки:
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
решение1
Как вы можете видеть в подробном выводе, доступ был запрещен на основании того, publickeyчто использовалось при попытке аутентификации:
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).
Выше вы можете видеть, что все файлы, которые проверяются по умолчанию (если конкретный файл не был указан с помощью -iфлага), не были найдены в вашем /root/.ssh/каталоге.
Как уже обсуждалось в комментариях, оказалось, что вы использовали adminпользователя, который не был определен на удаленном хосте. Вы подтвердили, что с ubuntuпользователем вам удалось успешно войти:«сейчас попробовал с пользователем ubuntu и успешно вошел в хост bastion»Поскольку все было достаточно ясно, я сосредоточусь только на ответе на ваш дополнительный вопрос, размещенный в комментариях:
Затем из него пришлось повторить процесс копирования ключей с хоста -> bastion, затем ssh с bastion на kubernetes master. Теперь это сработало, но я ожидал, что флаг -A, как официально документировано, каким-то образом перенаправит на master, но этого не произошло. Пришлось вручную дублировать ssh и копировать ключи на bastion – Kristi Jorgji 31 дек. 2020 в 19:35
Процесс sshвхода, который вы описали, известен как ssh-ing через так называемый jump host. Имейте в виду, что он не работает таким образом из коробки и требует дополнительной настройки. Взгляните наЭта статья, так как он ясно объясняет все, что вам нужно знать онастройка переадресации агента SSHчто необходимо сделать, если вы хотите использовать локальные ключи sshне только дляхозяин бастиона(что, как оказалось, являетсяхост прыжкав этом сценарии), но и автоматически sshоттуда в другойудаленный узел.
Короче говоря, вам нужно создать ~/.ssh/configфайл на локальной машине, если он не существует, и указать хост, на который вы хотите разрешить пересылку ваших локальных ключей SSH, и установить его следующим ForwardAgentобразом yes:
Host example.com # it can be either domain name or IP address
ForwardAgent yes
Кроме того, убедитесь, что ваш хост прыжкапозволяет пересылать агенту SSH входящие соединения:
Переадресация агента также может быть заблокирована на вашем сервере. Вы можете проверить, разрешена ли переадресация агента, подключившись к серверу по SSH и запустив
sshd_config. Вывод этой команды должен показывать, чтоAllowAgentForwardingустановлено.
Теперь вы должны иметь возможность напрямую подключаться по ssh к удаленному хосту назначения через jumphost с локальной машины одной sshкомандой. Это хорошо описаноздесь:
Динамический список jumphost
Для перехода по хосту можно использовать опцию -J:
user $ ssh -J host1 host2Если имена пользователей или порты на машинах отличаются, укажите их:
Многократные прыжкиuser $ ssh -J user1@host1:port1 user2@host2:port2Тот же синтаксис можно использовать для перехода между несколькими машинами:
user $ ssh -J user1@host1:port1,user2@host2:port2 user3@host3