☰

KOPS Kubernetes が要塞ホストにログインできない、SSH 公開鍵の権限エラー

tag-icon • tag-icon ssh amazon-web-services kubernetes
KOPS Kubernetes が要塞ホストにログインできない、SSH 公開鍵の権限エラー

私はKubernetesについて学んでおり、KOPSツールを使用してAWSでそのようなクラスターをプロビジョニングしたいと考えていました。公式チュートリアルに従い、簡単に言えばこれも https://medium.com/andcloudio/kubernetes-kops-cluster-on-aws-f55d197d8304

ここでも説明されているように、要塞ホストに接続する前にSSHキーを追加するようにしました。 https://kops.sigs.k8s.io/bastion/#bastion の使用

すべて正常に進み、ノード、ワーク、ロード バランサーなどが作成され、要塞ホストも作成されます。

唯一の問題は、キーを使って要塞ホストに ssh できないことです。詳細な出力を確認するために -vvv で ssh を実行したところ、ログは以下のとおりでした。何が問題なのかわかりません。

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 ユーザーで試したところ、要塞ホストに正常にログインできました」十分に説明されているので、コメントに投稿された追加の質問にのみ答えることに焦点を当てます。

その後、ホストから要塞へのキーのコピープロセスを繰り返し、要塞から Kubernetes マスターに SSH する必要がありました。これで動作しましたが、公式に文書化されているように -A フラグが何らかの方法でマスターに転送されることを期待していましたが、実行されませんでした。手動で SSH を 2 回実行し、要塞にキーをコピーする必要がありました – Kristi Jorgji 2020 年 12 月 31 日 19:35

あなたが説明したログインプロセスsshは、いわゆるジャンプホスト経由のSSH接続として知られています。この方法はそのままでは機能せず、追加の設定が必要であることに注意してください。この記事、あなたが知っておくべきすべてのことをわかりやすく説明しているので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接続できるようになりますssh。これはよく説明されています。ここ:

動的ジャンプホストリスト

-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

関連情報