ssh | Casual Developers Note

あれ？再起動したら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サーバを構築する方法

Windowsを使うエンジニアは誰もがこう考えます。LinuxのようにWindowsを使いたいと。LinuxサーバにSSHするように、WindowsサーバにSSHしたいと。今まさにその夢が現実のものになりました。Windows版OpenSSHのリリースが発表されたのです。（現状はOpenSSH for Windows Updateのブログを読んでください。2016年にはプロダクション版のリリースが予定されています。）

ということで、今回は、Windows版OpenSSHを使用して、Windows上にSSHサーバを構築しましょう。

1. Windows上にSSHサーバを構築する。

基本的に公式のSSHサーバ構築手順通りにやってみます。

(1)Windows版OpenSSHをダウンロードする。

「OpenSSH-Win32.zip」をここからダウンロードし、適当なフォルダ（とりあえず「C:tools」にしてみましょう）に展開します。そして、展開したフォルダ（「C:toolsOpenSSH-Win32」）にPathを通します。

(2)SSHのhost keyをセットアップする。

ssh-keygenコマンドを実行して、host keyを生成します。

> cd C:toolsOpenSSH-Win32
> ssh-keygen -A
C:toolsOpenSSH-Win32ssh-keygen.exe: generating new host keys: RSA DSA ECDSA ED25519
> dir
-a---        2015/XX/XX     XX:XX        680 ssh_host_dsa_key
-a---        2015/XX/XX     XX:XX        607 ssh_host_dsa_key.pub
-a---        2015/XX/XX     XX:XX        232 ssh_host_ecdsa_key
-a---        2015/XX/XX     XX:XX        179 ssh_host_ecdsa_key.pub
-a---        2015/XX/XX     XX:XX        418 ssh_host_ed25519_key
-a---        2015/XX/XX     XX:XX         99 ssh_host_ed25519_key.pub
-a---        2015/XX/XX     XX:XX       1706 ssh_host_rsa_key
-a---        2015/XX/XX     XX:XX        399 ssh_host_rsa_key.pub

(3)ファイアーウォールにSSH用のポート22を開ける。

(3-1)PowerShellの場合、以下のコマンドを実行します。（PowerShell3.0以上）

PS C:Usersuser> New-NetFirewallRule -Protocol TCP -LocalPort 22 -Direction Inbound -ActiolayName SSH

(3-2)普通に設定する場合、以下の手順で行います。

「コントロールパネル->Windows ファイアウォール->詳細設定」を表示します。「受信の規則」をクリックし、右側のウィンドウの「新しい規則」からウィザードを起動します。後はウィザードに従って、「ポート->TCP->特定のローカルポートに「22」と入力->接続を許可する->ネットワークの範囲を選択->名前「SSH」（任意）を付けて完了です。

(4)鍵認証をセットアップする。

管理者権限でsetup-ssh-lsa.cmdを実行して、再起動します。

> setup-ssh-lsa.cmd
C:Usersuser>if AMD64 == x86 (set lsadll=C:toolsOpenSSH-Win32x86ssh-lsa.dll )
C:Usersuser>if AMD64 == AMD64 (set lsadll=C:toolsOpenSSH-Win32x64ssh-lsa.dll )
C:Usersuser>copy C:toolsOpenSSH-Win32x64ssh-lsa.dll C:Windowssystem32
        1 個のファイルをコピーしました。
C:Usersuser>reg add HKLMSystemCurrentControlSetControlLsa /v "Authentication Packages" /t REG_MULTI_SZ  /d  msv1_0ssh-lsa.dll -f
この操作を正しく終了しました。
> shutdown /r /t 0

(5)WindowsサービスとしてSSHサーバを起動する

以下のコマンドでSSHデーモンをインストールして、WindowsサービスとしてSSHデーモンを起動します。

> sshd install
Service installed successfully
> net start sshd
SSHD サービスを開始します.
SSHD サービスは正常に開始されました。
> netstat -nao
アクティブな接続
  プロトコル  ローカル アドレス          外部アドレス        状態           PID
  TCP    0.0.0.0:22             0.0.0.0:0              LISTENING       1792
> tasklist /svc /fi "PID eq 1792"
イメージ名                     PID サービス
========================= ======== ============================================
sshd.exe                      1792 SSHD

もし「システムエラー 1067 が発生しました。」と表示された場合は、(2)で作成したhost keyの場所を確認してみてください。「C:toolsOpenSSH-Win32」配下にあるはずです。

また、Windows起動時に自動で起動するようにするには、以下のコマンドを実行するか、「サービス」の「プロパティ」からポチポチと設定してください。

> sc qc SSHD
SERVICE_NAME: SSHD
...(略)...
        START_TYPE         : 3   DEMAND_START
...(略)...
> sc config SSHD start=auto
> sc qc SSHD
SERVICE_NAME: SSHD
...(略)...
        START_TYPE         : 2   AUTO_START
...(略)...

以上でSSHサーバが構築できました。

(6)(5)のSSHデーモンをアンインストールする方法

念のためのアンインストールコマンドは以下です。

> net stop sshd
> sshd uninstall

2. SSHサーバにSSHしてみる。

それでは、WIndows上に構築されたSSHサーバにSSHでログインしてみましょう。

今回はクライアント側はすでにSSHコマンド実行可能であることを前提として確認します。記事にするほどのことではないので。（Windows上のSSHクライアントは、Windows版OpenSSHを使用してSSHコマンドを実行しても良いですし、PuTTYやらTera Termやらを使用しても良いです。今回は、Git for Windowsに付属しているSSHを使用します。）

> ssh user@XX.XX.XX.XX
...(略)...
Using username "user".
user@XX.XX.XX.XX's password:
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.
 
user@USER-PC C:Usersuser>

確かにWindows上のSSHサーバにログインできましたね。

これで、WindowsサーバにLinuxのようにSSHすることが実現しました！やったぜ！

おまけ

最初の段階で、LinuxのようにWindowsを使いたいと思っていた人は気づいたはずです。「てか、Cygwinあるじゃん」と。

> Cygwin.bat
$ ssh-host-config -y
...(自動的に特権分離のためのユーザ「sshd」が作成される)...
*** Info: Host configuration finished. Have fun!
$ cygrunsrv -S sshd

こんな感じでね。ぶっちゃけ、CygwinでSSHサーバを構築した方が間違いなくLinuxっぽいので、、、悲しくなりました（泣）でも、Cygwinは所詮Cygwinと言うツール上の話、Windows版OpenSSHはWindows全体の話なので、そこがそれぞれの違いであり利点ですかね。ちなみに、Windows版OpenSSHでもCygwinのOpenSSHでもインストール後のサービス名が「SSHD」で同じなので、両方インストールすると重複して怒られるので、気をつけてください。