EC2インスタンスを建ててSSHするだけなのに奮闘した話

壊してもいい環境がほしかったので、EC2に開発環境を建ててみることにした。

GUIでぽちぽちしてEC2インスタンスを作成して、その過程で作ったキーペアを指定してSSHするだけ。そんな簡単なお仕事。

AWSを触ったことがあれば、躓く人などいないはずだが、ssh コマンドを叩いても一向に何も起ず、タイムアウトする。

> ssh -i "keypair.pem" ubuntu@ec2-XXX-XXX-XXX-XXX.compute-1.amazonaws.com
ssh: connect to host ec2-XXX-XXX-XXX-XXX.compute-1.amazonaws.com port 22: Connection timed out

結論はルートテーブルにインターネットゲートウェイへのルートが設定されてなかったのが原因だった。

2年前くらいに、AWSを使わなくなるからVPC消そうとして、いろんなものをポチポチして回ったときに、ポチ(削除)したものの一つなのだろう。結局VPCは消せなかった。

後でAWSインフラ詳しい人に聞いた話では、VPCを消すには中のEC2やNATを全て消す必要があって、ポチポチだと面倒、とのこと。

そうそう、確かに、「これを消すにはあれを消してくれ」と消して回るうちにデッドロックになって諦めた記憶がある。

ともあれ、解決までにやったことをまとめておく。もしかしたら最後の決め手はルートテーブルでも、それまでの手順が効いていて、誰かの役に立つかもしれないので。

なお、以下は試したことであって、当然、最後の操作以外は操作後に全てsshに失敗している。

とりあえずググった

sshがつながらなくて最初にやったことはとりあえずググること

参考サイト等は何も見ずにポチポチしてたので、そもそも手順が間違ってる可能性は大いにある。

軽く調べた結論として、手順は他の人とほぼ一緒だった。問題など起こりようもない。

パブリックIPの自動割当を有効化する

次に問題あるとすれば、他の人がデフォルトのままにしている設定を私はいじっていたこと。

最初にEC2インスタンスを作るとき、セキュリティが気になってために [パブリックIPの自動割当] がデフォルトで「有効化」とされていたところを「無効化」にしていた。

「無効化」を選択しても、パブリックIPv4アドレスは当たってるように見えたので、問題は無いと思っていた。 とはいえsshできなかったのだからまずはここを疑って「有効化」にしてインスタンスを作りなおした。

コマンドを微調整

次は細かい話だが、ダブルクオーテーションを外したり、DNSではなくIPを直で書いたりを試した

> ssh -i keypair.pem ubuntu@ec2-XXX-XXX-XXX-XXX.compute-1.amazonaws.com
> ssh -i "keypair.pem" ubuntu@XXX.XXX.XXX.XXX

ヘルプページ参照 - インバウンドルール追加

ここらで嫌な予感はしていた。

AWSを使わなくなるからVPC消そうとして、いろんなものをポチポチして回ったときの影響があるんじゃないかと頭の片隅に浮かんだ。

しかしまぁ、何を消したか覚えてないので、ひとまずは公式のヘルプページを見に行った。 まだ試すことはたくさんある。

インスタンスに接続するための一般的な前提条件

IP アドレスからインスタンスへのインバウンド SSH トラフィックを有効にします。

の記述がひっかかった。

インスタンス作成時に、セキュリティグループが増えていくのが嫌で、デフォルトのセキュリティグループを当てていた。

このセキュリティグループは全てのトラフィックを許可するようになっていたが、もしかしたらSSH専用でルールを設定する必要があるかもしれない

新しいセキュリティグループを作ってそちらにSSHのルールを追加した。ソースは自分のIP。ちなみにIPはこちらで確認できる

どうやらインスタンス作成でポチポチするときにデフォルトに従えば、SSHの設定もされたセキュリティグループが作られたらしい。ここでもデフォルトに従ってなかった、、

ヘルプページ参照 - プライベートキーのアクセス許可設定

一応もう一回叩いた

chmod 400 my-key-pair.pem

ちなみに ls -l で権限の状態は確認できる

ブラウザからインスタンスに入ってみようとする

先にあげたヘルプページ上のチェック項目はOKなので、他の原因を考え始める。 もしかしたらsshの受けて側に問題があるのかもしれない。

ブラウザ上でインスタンスのコンソールを開ける機能がなかったかなと思い、コンソールを開こうと、EC2 instance connect とか、セッションマネージャーとか、よく知らないものもポチポチしようとした。

しかしうまくいかず、何をやってるかもよくわからないのでこちらは諦めた。

ブラウザ上でインスタンスのコンソールを開けるのは多分GCP。記憶がごっちゃになってる。

Amazon linuxインスタンスにしてみる

Ubuntuインスタンスを選択していたのだが、最初に調べたときに出てきたQiitaの記事ではAmazon linuxを選択していた。

もしかしたらUbuntuだとopenssl-serverが入ってないのかもしれないと思い、Amazon linuxインスタンスを作成してみた

もちろん結果は変わらなかった

sudo をつけてみる

落ち着いて他のサイトも見てみた。 ssh にsudoをつけているパターンを見つけた。

権限が400だからsudo 権限がいるのかもしれない。 とりあえず試してみた

ヘルプページ再訪

先程 [ブラウザからインスタンスに入ってみようとする] でやろうとして諦めた EC2 instance connectを再度試そうとした。

EC2 instance connect はエラーになっているので、そこに書かれているヘルプページに飛んでみた。SSHとは別の手段にはなるが、関連がある気がしていた。

EC2 Instance Connect を使用して接続 のページから EC2 Instance Connect セットアップ に飛んで Enable internet access にたどり着いた。

最後だけなぜか英語のページに飛ばされた。英語読める人間で良かった。

Enable internet access のページのチェックリストの内容がほとんど理解していなかったが、他に思い当たる節もないので、つぶさに見ていくことにした。

1つ目:インターネットゲートウェイを見ると、ちゃんとVPCに紐付いている

2つ目:サブネットのルートテーブルとやらを開くと、ルートがひとつだけあるが、それが正しい設定になってるか不明

3つ目:globally unique かどうかは知りようがないが、IPv4は当たってる。

4つ目:サブネットのネットワークACLを開くと、SSHはすべて許可してある

怪しいのは2つ目しかない。詳細はわからないが、「送信先」に0.0.0.0/0 、「ターゲット」にインターネットゲートウェイを指定して追加してみた。

繋がった!!!!

よかったよかった。

最後に「送信先」を自分のIPに設定して、もう一度sshできるかを確認した

めでたしめでたし

[追記]

最後の「送信先」を自分のIPに設定するのは余計だった。「送信先」は0.0.0.0/0のままでよかった。

timtoronto634.hatenablog.com