あれ？再起動したらEC2インスタンスにSSHできないぞ？今までSSHできていたのになぜだ？AWSでEC2インスタンスを作ったことがある人なら誰でも一度は経験する悲しい事件です。そうなったら選択肢は2 つ。諦めるか、原因を探るかです。今回は諦めない人に対処法を紹介します。
はじめに
今あなたの目の前には、こんなエラーがあることでしょう。
$ ssh -l ec2-user -i keypair.pem XX.XXX.XX.XXX
Enter passphrase for key 'keypair.pem':
ec2-user@XX.XXX.XX.XXX: Permission denied (publickey).
ログイン名かパブリックIPの入力間違いか？いや、違う。
キーペアかパスフレーズが間違っているのか？いいや、違う。
そんな凡ミスはさすがにしない。
そして、このブログに辿り着いたのならもう大丈夫です。EC2インスタンスを再起動したところ今までSSHできていたのにできなくなったという場合、原因は高い確率でauthorized_keysを誤って書き換えてしまったからです。なので、対処法は決まっています。この記事では、その場合の定石をお伝えします。
対処法
概要
やることは簡単です。SSHができなくなってしまった対象EC2インスタンスからボリュームを取り出し、別のEC2インスタンス(お助けEC2インスタンスと呼ぶことにしましょう)からボリューム内のファイルに問題がないか調べて、問題となっているファイルを修正するだけです。
対象EC2インスタンスを停止し、ボリュームをデタッチする
まずは、「EC2 -> インスタンス」から、対象EC2インスタンスを選択して停止します。
停止した対象EC2インスタンスの「ルートデバイス」を選択します。この「EBS ID」をクリックすれば対象のボリュームのページに行きます。
「EC2 -> ボリューム」から、対象のボリュームを選んで「アクション -> ボリュームのデタッチ」をします。
これで、対象EC2インスタンスからボリュームが取り除かれました。
お助けEC2インスタンスにボリュームをアタッチする
次に、「EC2 -> ボリューム」から、先程取り除いたボリュームを選択して、「アクション -> ボリュームのアタッチ」をします。
この時、「インスタンス」にお助けEC2インスタンスを選択し、「デバイス」の値をメモしておきます。デフォルトでは「/dev/sdf」になります。
これでボリュームがお助けECインスタンスにアタッチされました。
お助けEC2インスタンスを起動してボリューム内の問題となっているファイルを修正する
それでは、いよいよ問題となっているファイルの確認と修正です。
お助けEC2インスタンスにログインしましょう。
$ ssh -l ec2-user -i keypair.pem YY.YYY.YY.YYY
ログインしたら、まずはアタッチしたボリュームをマウントします。アタッチ時のデバイスの値は「/dev/sdf」だったので、その情報から対象のボリュームを判断できます。マウント先はどこでもよいですが「/mnt/vol01」としておきます。
$ df -h
ファイルシス サイズ 使用 残り 使用% マウント位置
devtmpfs 488M 64K 488M 1% /dev
tmpfs 497M 0 497M 0% /dev/shm
/dev/xvda1 7.8G 1.1G 6.7G 14% /
$ ll /dev/ | grep sdf
lrwxrwxrwx 1 root root 4 2月 8 05:38 sdf -> xvdf
lrwxrwxrwx 1 root root 5 2月 8 05:38 sdf1 -> xvdf1
$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda 202:0 0 8G 0 disk
└─xvda1 202:1 0 8G 0 part /
xvdf 202:80 0 8G 0 disk
└─xvdf1 202:81 0 8G 0 part
$ sudo mkdir /mnt/vol01
$ sudo mount /dev/xvdf1 /mnt/vol01
$ df -h
ファイルシス サイズ 使用 残り 使用% マウント位置
devtmpfs 488M 64K 488M 1% /dev
tmpfs 497M 0 497M 0% /dev/shm
/dev/xvda1 7.8G 1.1G 6.7G 14% /
/dev/xvdf1 7.8G 1.2G 6.6G 15% /mnt/vol01
マウントが終わればボリュームにアクセスできますので、怪しいファイルを確認してみましょう。私の予想が確かならば、「authorized_keys」が犯人の可能性が高いです。確認して修正しましょう。
$ cd /mnt/vol01
$ cd /home/ec2-user/.ssh
$ vi authorized_keys
ファイルの修正作業が終わったら、ボリュームをアンマウントします。アンマウントが終わればログアウトして作業は終了です。
$ sudo umount /mnt/vol01
$ df -h
ファイルシス サイズ 使用 残り 使用% マウント位置
devtmpfs 488M 64K 488M 1% /dev
tmpfs 497M 0 497M 0% /dev/shm
/dev/xvda1 7.8G 1.1G 6.7G 14% /
$ logout
Connection to XX.XXX.XX.XXX closed.
お助けEC2インスタンスからボリュームをデタッチする
対象EC2インスタンスからボリュームをデタッチした時と同じく、お助けEC2インスタンスからボリュームをデタッチします。お助けEC2インスタンスは起動しながらでもアタッチやデタッチは可能です。
対象EC2インスタンスにボリュームをアタッチして起動し、SSHできるか確認する
「EC2 -> ボリューム」から対象のボリュームを選択して、「アクション -> ボリュームのアタッチ」を選択します。この際に、デバイスの値を最初と同じ「/dev/xvda」にしてから、「アタッチ」します。
ボリュームのアタッチが終わったら、対象EC2インスタンスを起動します。
最後に、起動した対象EC2インスタンスにSSHで接続できれば、復旧成功です！
$ ssh -l ec2-user -i keypair.pem XX.XXX.XX.XXX
Enter passphrase for key 'keypair.pem':
Last login: Thu Feb 8 05:43:47 2018 from ZZZ.ZZZ.ZZZ.ZZZ
__| __|_ )
_| ( / Amazon Linux AMI
___|\___|___|
https://aws.amazon.com/amazon-linux-ami/2017.09-release-notes/
1 package(s) needed for security, out of 1 available
Run "sudo yum update" to apply all updates.
[ec2-user@ip-10-2-11-115 ~]$
最後に
いかがでしたか？いきなりEC2インスタンスにアクセスできなくなると焦りますが、今回の方法で復旧できますので、慌てずに対処しましょう。
環境
- EC2: Amazon Linux AMI
![[tips][Windows][SSH] Windows版OpenSSHでSSHサーバを構築する方法](https://casualdevelopers.com/wp-content/uploads/2015/12/cloud-3017392_1920-700x300.png)