質問: false ``` という1文を挿入することでさしあたりの問題は解決しました。 いくつかの説明を読んでいると、どうやら`vagrant`が1.7になってからの仕様変更で、 vagrantの提供する共通公開鍵を持つboxを使ったゲストOS作成時では それに対応するホスト側の秘密鍵(`~/.vagrant.d/insecure_private_key`)が 自動的に置き換えられてしまう......らしい......みたいなことになっていると なんとなく理解していました。 ところが今日、OSを`ubuntu`に変えてから初めて、 ``` vagrant init chef/centos-6.6 ``` とした後に、`Vagrantfile`を全く編集しない状態でも ``` vagrant ssh ``` とすると、普通にログインできてしまいました。 これは以前、`windows7`で`vagrant 1.7`を使っていた時には `teraterm`でエラーになっていたはずでした。 これはもしかして1.7.2では何らかのバグが治ったのだろうか? くらいに考え、でも気になるので、試しに `~/.vagrant.d/insecure_private_key`と ``` https://github.com/mitchellh/vagrant/blob/master/keys/ ``` に置いてある、vagrantという名前のファイル (共通公開鍵に対応する秘密鍵のはず) の中身を比較してみると、中身が全く同じです。 **ランダムに置き換えられた秘密鍵に変わるんじゃなかったのか??** と、これまでの理解か、確認の方法、またはその両方が間違っているらしいと 気が付いた次第。 元々公開鍵暗号の仕組みも、秘密鍵を持つ人だけが公開鍵を使って暗号を解ける、 くらいの理解しかなかったので、そもそもそれが間違いなのかもしれませんが、 結局、`vagrant` が初回のbox作成・起動時に`insecure_private_key`を 置き換えていると説明されているのは、具体的に何がどうなっているのでしょうか。 愚問かと思いますが、教えていただけると嬉しいです。 よろしくお願いします。
回答: 自己解決しました。 確かに現在の`vagrant`はゲストOSの初回起動時にホストOS側の鍵情報を自動で変更し、ゲストOSと暗号の再調整を行っています。 ただし、その置換後に使う秘密鍵ファイルの場所は`vagrant ssh-config`というコマンドを使わないと分からないようになっていました。 ``` $ vagrant up ... ... (ゲストOS起動中) ... (ゲストOS起動後に以下を実行) $ vagrant ssh-config HostName 127.0.0.1 User vagrant Port 2222 UserKnownHostsFile /dev/null StrictHostKeyChecking no PasswordAuthentication no IdentityFile /home/xxxx/.vagrant/machines/www/virtualbox/private_key IdentitiesOnly yes LogLevel FATAL ``` `IdentityFile /home/xxxx/.vagrant/machines/www/virtualbox/private_key`の部分が置き換えられた秘密鍵ファイルです。 したがってこのファイルを指定して`ssh`コマンドを実行すると`vagrant ssh`としたときと全く同じ動作をします。 ``` ssh -p 2222 -l vagrant -i /home/xxxx/.vagrant/machines/www/virtualbox/private_key 127.0.0.1 ```