鶏口牛後な日々

心の赴くまま、やりたいことを仕事に。

AWSのインスタンスに接続するステップ(備忘)

AWSのEC2で開発環境を立てているが、接続するまでのステップをメモしておく。

1. 接続元IPアドレスの登録

自分のIPアドレスから接続できるよう、接続先のEC2の「セキュリティグループ」を確認して、インバウンド接続が許可されるIPアドレスとして登録しておく

==補足==

この時、グローバルIPアドレスでなければならない。

普通にMacのterminalでifconfigして表示されるのは、ローカルIPアドレスで、 127 などから始まるもの。

これではダメで、グローバルIPは、ルーターにアクセスして、そこに割り振られているIPアドレスを確認しなければならない。

(現時点で、ルーターにアクセスする方法は調べていないが、グローバルIPアドレスを表示してくれるwebサイトはたくさんあるので、そこにて確認)

2. 秘密鍵と公開鍵を生成する

AWSの鍵生成機能を使う手もある。EC2ダッシュボードから、 keypair を選んで、GUIで生成ができる。

自分で通常通り ssh-keygen で鍵を生成する場合は、以下のコマンド。

ssh-keygen -t rsa -f ~/.ssh/秘密鍵の名前 -m pem -b 4096
  • -t :これは方式を指定するオプション。AWSRSAしか受け付けないらしい。多分何も入れなくてもRSAになる気がするが、一応指定。

  • -f :これは鍵の名前を指定するオプション。たくさん生成していると、名前がわかりやすく付いていた方が、混乱しない。

  • -m :これはPEM形式を指定するオプション。AWSはPEM形式しか受け付けないらしい。

  • -b :これはキーのビット数を指定するオプション。AWSは1024、2048、4096を受け付けている。

==補足==

この際、「秘密鍵」というと、大層なものに思えるが、ただのテキストで、中身を見ると、意味不明な文字数字の羅列でできている。 ファイル名、拡張子、置き場所などは大した問題ではなく、これはあとで変更しても問題は起きない。

ファイル名等を変更して、ちゃんと鍵として有効かどうかを確認したい場合は、

ssh-keygen -y -f <秘密鍵のファイル名>

と打ってみる。 -y オプションは、秘密鍵を読み取って、公開鍵を返してくれるオプション。

これで問題なく公開鍵が返ってきたら、大丈夫!

3. 権限設定

秘密鍵のpemファイルの権限は、 400 にしておく。AWSのマニュアルでは 400 とある。

他に、 600 でもいいと聞いている。

おそらく書き込みができなければいいとのこと。

また、pemファイルを通常格納する .ssh フォルダの権限や、その上のユーザーごとのフォルダ(ユーザーの名前と同じ名称のフォルダ)の権限も、 700 とかにしておかないといけないので、注意が必要です。

この辺り、権限系は、よくつまるポイントらしい。注意!

4. インスタンスをstartする

  もちろんもっと前の段階からstartしていても良い。

startしてから、完全に立ち上がるまで数十秒かかる場合がある。 running になっているかステータスを確認。

また、接続元のコンソールから、pingを打つのも有効。

5. ssh接続する

インスタンスが立ち上がると、インスタンス一覧の表の上に、 connect と言うボタンが有効化され(それまではグレーアウトされている)る。

これを押すと、接続するsshコマンドとか表示してくれる。

ユーザーは、AMI(インスタンスを作成しているイメージ)によるが、大体わざわざ変えていなければ表示通りで良い。

自身は、ubuntuのAMIを使っているので、 ubuntu

よくあるエラー

Pemission denied

何かにつけてこれが出るっぽい。

Permission Denied(public key).

とか書いてくれることもある。

結局何で? と言う原因については、明確にここでは示してくれない。

おそらくそこで示しちゃうと、ハッカーとかにもいろいろ教えちゃうことになるんだと思う。

権限の間違いの場合は、よくあるようだ。(この時は上記の、No.3へ戻る)

また、ユーザー名や、キーペアの何らかの間違いなどもよく確認しよう。(この時は上記の、No.2へ戻る)

ssh -vvv うんたらかんたら

と言うオプションをつけてみると、Verbose(冗長)モードというのでコマンドを送信してくれる。

debug1とかなんとか、いろいろどこまで何をやったらどうなった、みたいなことを表示してくれる。

やってみて気付いたのだが、 -v と一個だけつけるより、 -vvv と3つつけた方が、よりいっそう冗長に書いてくれるようだ。(多分)

-v の時は、 debug1 と言う表示のみだったが、 -vvv と3つつけると、 debug1~3 とレベルを分けて書いてくれたように思う(ちゃんと確認はしてないが多分)

ここまできて、それでも原因がわからない場合は、サーバに別の方法で接続して、 sshdのログなどをみる必要がある。

他の人がサーバにアクセスできるならみてもらう。

無理ならば、AWSの場合は、ボリュームを別のssh接続ができるインスタンスにアタッチして、別のインスタンスに接続してボリュームの中身を確認する、と言う手がある。

私が前回した間違い

インスタンスは、そもそも生成するときにキーペアを登録する。

このキーペアの名前は、インスタンス一覧の表のカラムにも記されているので、いつでも確認できる。

このキーペアがないと、ssh接続を鍵を使って実行することはできない。

私は、他の人が作ったこのインスタンスssh接続しようと試みていたのに、キーペアの共有は受けていなかった。

自分で新たにキーペアを生成して接続しようとしていた。

これが間違いだった。

生成したときのキーペアを持っているユーザでないならば、その人に、別の接続用のユーザを作成してもらうのがAWSでは推奨されている。

そして、新規に作ったユーザのためのキーペアを生成し、秘密鍵をユーザに配布すると言うものだ。(AWSのマニュアルに書かれている) 参考資料:https://aws.amazon.com/jp/premiumsupport/knowledge-center/new-user-accounts-linux-instance/ https://qiita.com/kota9/items/d54a70b542da09b0c099

または、ユーザが作ったキーペアの公開鍵を、インスタンス生成し接続ができる管理者に渡して、インスタンス内の .ssh/authority_keys にコピーしてもらうことだ。 参考資料: AWSのEC2インスタンスに複数の端末からアクセスする - Qiita

これでは Permission deniedもそりゃ出ますよね。

経験値は上がりました。(まだまだだとの実感とともに)

最後呟き

インスタンスがおかしいなら、作り立てなら落として作り直せば? と言う助言もいただきました。

確かに、それが仮想環境のいいところですよね。

どんどん上げて、どんどん壊す。

引き続き、勉強していきたいと思います。

以上。