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 :これは方式を指定するオプション。AWSはRSAしか受け付けないらしい。多分何も入れなくてもRSAになる気がするが、一応指定。
-f :これは鍵の名前を指定するオプション。たくさん生成していると、名前がわかりやすく付いていた方が、混乱しない。
-m :これはPEM形式を指定するオプション。AWSはPEM形式しか受け付けないらしい。
-b :これはキーのビット数を指定するオプション。AWSは1024、2048、4096を受け付けている。
==補足==
この際、「秘密鍵」というと、大層なものに思えるが、ただのテキストで、中身を見ると、意味不明な文字数字の羅列でできている。 ファイル名、拡張子、置き場所などは大した問題ではなく、これはあとで変更しても問題は起きない。
ファイル名等を変更して、ちゃんと鍵として有効かどうかを確認したい場合は、
と打ってみる。 -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もそりゃ出ますよね。
経験値は上がりました。(まだまだだとの実感とともに)
最後呟き
インスタンスがおかしいなら、作り立てなら落として作り直せば? と言う助言もいただきました。
確かに、それが仮想環境のいいところですよね。
どんどん上げて、どんどん壊す。
引き続き、勉強していきたいと思います。
以上。