AABlog：So-netブログ

	ブログをはじめるログイン

2020年02月04日｜ 2020年05月30日｜2020年05月31日ブログトップ

AWS EBSマウントしてEC2インスタンスへのsshログインを復旧させた話　 [クラウド]

コロナウイルスも下火になってきたことだし、ブログを更新しておくか。
ということで、本日は、AWSで「やってしまった話」である。

EC2インスタンスの自動停止

ご存知のように、AWS EC2インスタンスは、動いている間だけ課金される。なので、開発用に必要なインスタンスは、夜間を停止しておけばコスト的に「うれしい」ことになる。ならば、ということで自動的に午後8:00に停止して、午前8:00に起動するようにCloud Watch Eventでスケジューリングしたのが「ハマった」きっかけなのではあるが...

スケジュールの設定自体は、結構簡単で、AMIでポリシーを作ってやって、Cloud Watchのルールを作成してやればOK。停止の方は、ポリシー自動生成でできたようだが、インスタンス起動の方は、ポリシー作ってSSMだかなんだかで起動してやる必要がある。

まぁ、開発用のサーバーで自分ひとりしか使ってないので、失敗しても手動で立ち上げればOKでしょ？と気楽な感じでやってみた。
それが、昨日のことである。朝、メールチェックすると、要メンテナンスな内容が飛び込んできていた。早速、データを確認すべく、sshで開発用のEC2にログインすると...

接続できない感じ。そうそう、昨日自動停止して、起動するようにしたからね。ちゃんと起動していないか、IPアドレスが変更されたのであろう。AWSのコンソールで確認する。

ああ、やっぱりIP変わってる。常時起動にしていたから、Elastic IPは割り当てていなかった。多分起動し直したらこうなっちゃうかも、と思いつつも夜間停止したので、慌てることなく、sshの接続先を変更して「事なきを得た」。

以下のようにシェルスクリプトを作って、sshログインしていたが、IPアドレスのところを変更した、ということ。

ssh -i "キーペアのファイルパス" ec2-user@EC2インスタンスのIPアドレス

これで、ちゃんとログインできた。
OK、OK、ということで作業を進めていくが、sshの他、scpでファイル転送っていうこともやっている。ローカルでWebアプリを作って、AWSのEC2インスタンスにWebアプリのtarボールイメージをアップロード、EC2インスタンスでtarボールを展開しDockerイメージを作って、リポジトリにアップロード。ECSのタスクを更新して、Webアプリを更新。というリリース方法を取っているので、scpでのファイル転送がWebアプリの更新には必須となっている。

scpによるファイル転送についても、IPアドレスだけ変更すれば問題ないはず。scpについてもスクリプトを作っているので、IPアドレスの部分を変更すればOK。

scp -i "キーペアのファイルパス" $1 ec2-user@EC2インスタンスのIPアドレス:$1

のようになっているので、IPアドレスの部分だけを変更したつもりであった。
じゃあこれでAWSのEC2インスタンスにコピーっと。ん？いつもと様子が違う。いつもならファイル転送の様子が、表示されていたのだがこれがない。なぜ？エラーになった様子もなく、コマンドはすぐに終了している。

インスタンスを起動し直したことで、セキュリティ関係の何かが変わったのか？
ググってみるとpermissionからみならchmodで権限を変えればOKみたいな記事を発見。/home/ec2-userのパーミッションを777に変更してみる。これでイケるんじゃないと思えたが、状況は変わらず。ファイル転送はできない。

sshログインはできるけど、scpファイル転送はできないって、そんなことある？

ポートは同じだから、フィルタリングされちゃっているっていう話はないよな。scpコマンドはすぐに終了している。接続できなくてタイムアウトしている感じはない。エラーも出ていない。サーバー側のsyslogも参照してみたが、エラーなし。IPアドレスも確認している。

別のPCからやってみよう、と思いssh接続すると今度は「permissionエラー」で接続できないではないか。
ありゃリャ、さっきまでは接続できていたじゃない。なんで、パーミッションがダメ？
接続できていたPCに戻って再度接続してみる。あーんやっぱりできなくなってる。
えっ、やってしまったかも。落ち着いて原因を考えてみよう。直前にやったことといえば、/home/ec2-userのパーミッションを変えたっていう事くらい。ホームディレクトリのパーミッションをchmodで777にしちゃダメだったか？

EBSを別のEC2でマウント

もう、お手上げ。sshログインできないんじゃ、EC2インスタンスの作り直しか?

かと思われたが、そんなことはちゃんとAWSでは「想定済み」みたいである。別のEC2インスタンスにEBSストレージをマウントしてファイルシステムをいじるということが可能になっている。
やり方は結構面倒な作業になる。
まずは、問題が発生しているEC2を停止させる。終了ではないよ。ここで終了するとインスタンスが消えてしまうので注意。
EC2で使用していたEBSボリュームをデタッチして解放する。インスタンスが停止していないと解放できない。
AMIが同じ別のEC2を、同じAZに用意する。EC2はボタンひとつで作成できるが、同じAZにするにはオプション指定する必要がある。
EC2が立ち上がったら先ほど解放したEBSボリュームを別に起動したEC2にアタッチする。アタッチではマウントまではしてくれないので、EC2にログインして、mountコマンドを使ってファイルシステムにマウントする。
マウントすればEBSボリュームの仲が見れるようになるので、後は、お好きなようにできる。
今回は、/mnt/home/ec2-userのパーミッションを元の700に戻した。
ファイルシステムの修復ができたら、アンマウントしてデタッチ、元のEC2にアタッチし直す。アタッチする際に起動デバイスとしてアタッチしないとダメだったので注意。
アタッチできたらEC2を起動する。

やった、これでssh接続が復旧できた。やれやれという感じで一服したのだが、この時点でもう昼近くになってしまっている。

scpはまだできない

ssh接続できるものの、scpでファイル転送はできないままである。
何気にクライアント側でlsしてみると、

「ec2-user@IPアドレス」という名前のファイルができているじゃない。

なんだ、そういうことか。scpのスクリプトでコピー先のファイル名を入力しなくても良いように、$1って書いてあった部分がなくなって、scpコマンドが普通のcpコマンドのように機能してローカルコピーになっていただけか。
つまり、次のようになっていた

scp -i "キーペアのファイルパス" $1 ec2-user@EC2インスタンスのIPアドレス

これを

scp -i "キーペアのファイルパス" $1 ec2-user@EC2インスタンスのIPアドレス:$1

のように変更したらちゃんと元のように動いた。

permissionいじる必要なかったじゃない。

といえばそうなのだが、EC2インスタンスに接続できなくなってしまった際の「復旧方法」がわかったのでよしとする。
でも疲れタァ。