Amazonについて詳しく解説します
AWSのEC2サーバにSSH接続しようとしたら、Permission deniedって言われる！
…という現象が起きている場合、少し参考にしてみてください。
ということで、こんにちは。
EC2のサーバ(インスタンス)にSSHで接続しようとしたのですが、以下のエラーが延々と出てきて、接続できない現象がありました。
ユーザ名@IPアドレス: Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
エラーが出た環境としては以下の通りです。
- Cloud9で作成したEC2 (Amazon Linux2)
- Cloud9では接続できるが、SSH接続ができない
- キーペアは後から新規作成した
- キーペアファイルはローカルに保存済み
- キーペアファイルの権限は変更済み (chmod 600)
- SSHのコマンドは間違っていない (ユーザ名・IP・キーペア情報は正しい)
このPermission deniedのエラーですが、原因は１つではなく複数にわたるようで、それぞれ皆さんの環境によってエラーの原因が異なるようです。
色々そうした情報を元に試行錯誤してみたのですが、そのうちの方法の１つで解決したので、備忘録的にメモを置いておきます。
もし同じ現象で詰んでいる方がいれば、参考にしてみてください。
目次
原因はサーバ側の認証情報の設定の問題でした。
SSHで接続する先のサーバ側には「authorized_keys」というファイルがあります。
EC2、Amazon Linux2の場合、ファイルパスは以下の通り。
/home/ec2-user/.ssh/authorized_keys
このファイルを開くと、以下のような認証情報がauthorized_keysのファイルの中に記載されています。
この情報を元に「SSHしてきている相手がこれと一致するキーペアを持っているかどうか」を判断し、接続を許可する、という動きをします。
ssh-rsa AAAAB3NzaC1yc2E... (長い文字列)
- ローカル側にあるキーペアの認証情報
- サーバ側のauthorized_keys内の認証情報
この２つが一致して、はじめてSSH接続が許可される。
ということは、この正しい認証情報をファイルの中に追記する必要があるということですね。
ローカル側でキーペアを一方的に作って接続しようとしても、そのキーペアの認証情報をサーバ側に登録してなければそもそも接続できないわけです。
いや、考えてみれば当たり前のことですが、EC2のインスタンスを特殊な方法で作ったり、イメージなどから移行してきた場合は、このあたりの認証情報が追記されていないこともあり得えます。
その場合、この辺りの仕組みを知っておかないと…ぼくのように、詰むかもしれません。
【対処方法】サーバにキーペアの認証情報を追記する方法
ということでその具体的に実行した手順もまとめておきます。
①ローカル側で実行するコマンド
まずは、ローカル側のキーペアファイルの認証情報を生成します。
ssh-keygen -y -f キーペアファイルのパス
実行すると「ss-rsa AAAAB3NzaC1yc2E...」みたいな長い文字列が出力されるので、それをそのままコピーしましょう。
②サーバ側で実行するコマンド
次に、サーバ側でauthorized_keysに認証情報を追記します。
ぼくの環境ではCloud9からコンソールが操作できましたが、環境によっては利用できないと思うので、EC2の管理画面から「EC2 Instance Connect」でコンソール操作するのが良さそうです。
viコマンドでファイルを開いて、先程コピーした認証情報を、ファイルの一番下に追記します。
vi /home/ec2-user/.ssh/authorized_keys
モザイク多めで恐縮ですが、こんな感じの追記でOKです。
authorized_keysが保存できたら、再度SSH接続を試してみましょう。
認証情報が一致したので、SSH接続ができました！
まとめ
以上、AWS・EC2のサーバにSSHしようとしたらPermission deniedと言われる場合の対処方法でした。
通常の手順通りにEC2インスタンスを作って、その時にキーペアを一緒に作成する場合はこの手順が不要なので、逆にこのような設定項目自体があることを気づかないまま使っている…なんてこともあるかもしれません。
まあ、自分の話ですけどね。
ということで、ご参考までに！
それでは！
