はじめに
AWSの勉強にあたり以下の本にてハンズオンをしていた際に微妙につまずいたのでメモです。
※すごくいい本です。
環境
- OS:MacOS
- ソフト：ターミナル
- AMI：Amazon Linux 2
- セキュリティグループ：独自でHTTP/HTTPS/SSHのインバウンド許可
事象
作成したてのインスタンスにsshログインを試みたところ、エラーが発生
$ ssh -i "/Users/xxxx/.ssh/myserverkey.pem" ec2-user@xx.xx.xx.xx
ec2-user@xx.xx.xx.xx: Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
結論
EC2を「停止」→「起動」したら解消しました。
停止を行うと、パブリックIPやパブリックDNSが変更されますので、新しいパブリックIPを指定したらすんなり接続できました。
以下は、結論に至るまで考えうる原因（試してみて効果がなかったこと）
キーの権限が不正
SSH が機能するには、キーが公開されていないことが必要です。必要な場合は次のコマンドを使用します。
とのことなので、キーならびにキーの上位（ホームディレクトリ）まで権限の制限を行いました。
chmod 400 /Users/xxxx/.ssh/myserverkey.pem
chmod 600 /Users/xxxx/.ssh
chmod 600 /Users/xxxx
事象変わらず
ログインユーザー間違い
AMIによってログインするユーザーの指定が異なります。
Amazon Linux 2 または Amazon Linux AMI の場合は、ユーザー名は ec2-user です。
CentOS AMI の場合、ユーザー名は centos です。
Debian AMI の場合は、ユーザー名は admin または root です。
Fedora AMI の場合、ユーザー名は ec2-user または fedora です。
RHEL AMI の場合は、ユーザー名は ec2-user または root のどちらかです。
SUSE AMI の場合は、ユーザー名は ec2-user または root のどちらかです。
Ubuntu AMI の場合は、ユーザー名は ubuntu です。
EC2の「説明」の「AMI ID」をクリックし、作成した「Amazon Linux 2」で作成していることを確認
コマンドの実行において指定している「ec2-user」で問題ないため、原因ではないことを確認
SSHがインバウンド許可されていない
独自でセキュリティグループを作っていたこともありインバウンドの設定を確認したがSSHは許可。
念の為、デフォルトのセキュリティーグループに切り替えてみたが、タイムアウトした。
$ ssh -i "/Users/xxxx/.ssh/myserverkey.pem" ec2-user@xx.xx.xx.xx
ssh: connect to host xx.xx.xx.xx port 22: Operation timed out
セキュリティグループやIPの打ち間違いといったコマンドミスも関係ないことを確認し、もとのセキュリティグループに戻す
キーペアファイルが不正
何らかの理由でコピーが失敗しているようなことがあるようなので、新しいキーペアを作成してそちらを指定して同コマンドを実行したが、同じエラーになるため、関係がなさそう。
キーをおいているPCそのもののコピーの仕方などに問題がある可能性もあったのでWindowsでも試そうと思いましたが、未実施。
EC2インスタンスがきちんと起動していない可能性
まずは、「インスタンスの状態」が「running」であることを再確認。
現状の状態は問題ないようなので、EC2インスタンスを「再起動」してみるが、事象変わらず。
はじめにに記載した、本に「再起動」と「停止→起動」は挙動が違うことを思い出して試してみたらうまくいきました。
おわりに
検索やAWSのトラブルシューティングにヒットするものでは解決に至らなかったためちょっと困りました。
以前もAWSの勉強（挫折）を行なっている際、作成したEC2インスタンスがうまく起動されずにちょっと手間取っていたので、インスタンスの起動に疑いの目を向けられましたが、この起動の失敗率一体・・・。
また、起動時に割り当てられたIPに問題があったのか、問題があったのであれば何がどうだめだったのか、はたまたIPは関係がない部分でインスタンスに何らかの問題があったのか地味に根本原因がわかっていないので、わかる方いたら教えていただけると嬉しいです。