Vagrant VMに vagrant ssh コマンドではログインできるけれど、 ssh コマンドではログインできないときの対応について、少しハマったので原因を記載してみます。
vagrant up後にAnsible等で追加セットアップするときなどに使っていますが、うまくいかないと結構面倒です。
※config.vm.network :private_network, ip: "192.168.56.100" のようにHost Only NICにIPを定義している前提とします。
1. pingでの疎通確認
ホストからVMのIP自体に ping 192.168.56.100 を打って、レスポンスがあるかを確認します。
レスポンスがあればOKですが、レスポンスがない場合は、利用しているHost Onlyのネットワークセグメントに当該IPが間違いなく含まれているのかを確認します。
2. sshでの疎通確認
pingのレスポンスがある場合には、 ssh -vv vagrant@192.168.56.100 のようにDebugログを出力しながらSSHを試行します。
鍵認証の失敗なのか、そもそもPort 22でのコネクションが張れないのか、それとも違った原因なのか材料を得ます。
3. MACアドレスの確認
今回、pingはOKだけれどSSHは Protocol not available のエラーでログイン不可という状況でした。
arp 192.168.56.100 でどのMACアドレスだと思っているのかを確認します。
続いて、 vagrant ssh でVMにログインし、 ifconfig などで該当NICのMACアドレスを表示し、arpの結果と比較します。
今回はVMのMACアドレスがarpの結果と異なっており、SSHに失敗したとわかりました。
ping応答ありということはそのIPが存在しているはずですので、Vagrantプロバイダとして利用しているアプリケーション(VirtualBoxなど)を起動して、起動中のVM一覧から怪しいホストのIPを確認していきます。
4. DHCPサーバの確認
起動中のVMが他に存在しない場合、DHCPサーバとして同IPを利用していないか確認します。
結論としては今回は、VirtualBoxのホストオンリーネットワークアダプタのDHCPサーバのIPが、VMのIPと重複していることが原因とわかりました。
DHCPサーバのIPを変更するか、DHCP自体を無効化すると問題も解消されました。
5. その他確認事項
上記のいずれも関係しない場合は、ログからIPやMACアドレスで検索して原因箇所を推定するのが良さそうです。
また、ホストとVMの双方でtcpdumpを取りながら、どこまでパケットが届いていてどこからNGなのか、を確認するのも役に立ちます。
それでもよくわからなければIPを変える、新しくホストオンリーネットワークを作成するなどで回避する他なさそうです。