検証用OpenStackを構築して、CirrOSをデプロイしたときに、SSHキーペアがインポートされず、インスタンスにSSH公開鍵方式によるログインができない事象が発生した。OSはCirrOSもDebianでも同様。
発生事象
起動したインスタンスに設定したSSHキーペアの秘密鍵でログインできない。
(パスワード認証に切り替わりパスワード入力を要求される)
OpenStackバージョン:Pike (Version: 12.0.2)
構成概要
OpenStackはPackStackを使用してCentOS7上にスタンドアロン環境で構築している。
インストールした手順はこちら
エラーログ
事象が発生した際の起動ログの抜粋は以下の通り。
... udhcpc (v1.23.2) started Sending discover... Sending select for 192.168.1.212... Lease of 192.168.1.212 obtained, lease time 86400 checking http://169.254.169.254/2009-04-04/instance-id failed 1/20: up 20.64. request failed //FAILED MESSEAGE// failed 2/20: up 33.14. request failed //FAILED MESSEAGE// ... failed 20/20: up 252.96. request failed //FAILED MESSEAGE// failed to read iid from metadata. tried 20 failed to get instance-id of datasource Top of dropbear init script Starting dropbear sshd: failed to get instance-id of datasource OK ... === cirros: current=0.4.0 uptime=260.09 === ____ ____ ____ / __/ __ ____ ____ / __ \/ __/ / /__ / // __// __// /_/ /\ \ \___//_//_/ /_/ \____/___/ http://cirros-cloud.net login as 'cirros' user. default password: 'gocubsgo'. use 'sudo' for root. cirros login:
http://169.254.169.254/2009-04-04/instance-id
へのアクセスを試行して、20回失敗して諦めている。
OpenStackコミュニティの情報
上記エラーはインスタンスのMetadata設定に失敗したもので、その中にSSH公開鍵インポートが含まれている。 なお、SSH公開鍵はインポートされていないものの、OS自体は正常に起動し、パスワード認証でログインすることは可能。(CirrOSはデフォルトパスワードあり)
コミュニティでも同様にSSHキーペアでログインできない系の質問がいくつかある。NOVA_METADATA_IPの設定やnova-apiサービス起動、Firewall設定が起因していることが疑われているが、上記記事で記載したPackStack手順でインストールした場合はいずれも正しく設定されていた。
https://ask.openstack.org/en/question/59837/cant-ssh-to-new-created-instances-any-more/ask.openstack.org
https://ask.openstack.org/en/question/59837/cant-ssh-to-new-created-instances-any-more/ask.openstack.org
https://ask.openstack.org/en/question/42729/unable-to-connect-metadata/ask.openstack.org
# vi /etc/neutron/metadata_agent.ini
nova_metadata_ip=<Master IP> //設定済み
ポートも空いている。
# ss -tuna | grep 8775 tcp LISTEN 0 128 *:8775 *:*
キーペア生成後にKeystoneやNovaの再起動が必要という情報もあり再起動したが状態変わらず...
ネットワーク構成の見直しでSSH公開鍵認証できるようになった
極力シンプルな環境で検証したかったため、当初は、extnetと紐付けてブリッジ接続によるフラットなネットワークを使用していた。下図の青のdesignetが自宅内のネットワークの一部で、そこにフラット接続していた。私の環境ではこのネットワーク構成見直しによりSSHキーペアの問題が解消した。
下図オレンジ部分のinternalネットワークを追加構築し、Routerで接続し、フロントからのアクセスはFloating IPを使用して接続する構成とした。
これにより、指定したSSHキーペアの公開鍵がCirrOSインスタンスにインポートされ、SSH秘密鍵を指定して接続することで、期待通りログインできた。
問題解消後のログ出力
Starting network... udhcpc (v1.23.2) started Sending discover... Sending select for 100.64.0.19... Lease of 100.64.0.19 obtained, lease time 86400 route: SIOCADDRT: File exists WARN: failed: route add -net "0.0.0.0/0" gw "100.64.0.1" checking http://169.254.169.254/2009-04-04/instance-id successful after 1/20 tries: up 19.10. iid=i-00000033 failed to get http://169.254.169.254/2009-04-04/user-data warning: no ec2 metadata for user-data Top of dropbear init script Starting dropbear sshd: OK
failed to get http://169.254.169.254/2009-04-04/user-data
となっているのが気になるが、Connection Timeoutではなくなっている。
SSH公開鍵ログイン確認
192.168.1.212
はAllocateしたFloating IP。
# ssh -i <key> cirros@192.168.1.212 The authenticity of host '192.168.1.212 (192.168.1.212)' can't be established. ECDSA key fingerprint is SHA256:xxx. ECDSA key fingerprint is MD5:xxx. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '192.168.1.212' (ECDSA) to the list of known hosts. $ uname -a Linux cirros-03 4.4.0-28-generic #47-Ubuntu SMP Fri Jun 24 10:09:13 UTC 2016 x86_64 GNU/Linux $ ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc pfifo_fast qlen 1000 link/ether fa:16:3e:cb:11:e0 brd ff:ff:ff:ff:ff:ff inet 100.64.0.19/24 brd 100.64.0.255 scope global eth0 valid_lft forever preferred_lft forever inet6 fe80::f816:3eff:fecb:11e0/64 scope link valid_lft forever preferred_lft forever
まとめ - OpenStack外部ネットワーク構成のときにSSHキーペアがインポートされない
検証用に構築したOpenStackで、CirrOSをデプロイしたときにSSHキーペアがインポートされず、インスタンスにSSH公開鍵方式によるログインができない事象が発生した。
詳細動作原理までは追求していないが、ネットワーク構成の見直しにより問題解消し、期待通りSSH公開鍵認証によるSSHアクセスが可能となった。
NG構成:ブリッジ(extnet)フラット構成
OK構成:Internal + Router + Floating IP構成