LoginSignup
8
4

WSLからEC2にSSHしようとして「UNPROTECTED PRIVATE KEY FILE!」と言われた時

Last updated at Posted at 2021-07-28

はじめに

「WSLはWSL内だけで完結させるといいよ」というのが主旨です。

Vscodeでon the WSLの開発をしていると、警告画面で「プロジェクトディレクトリはWSL内に置いてください!」みたいなことを促されたりします。これはアクセス速度の問題ですが、SSHに関してもアクセス権限の問題で、WSL内で完結するのが良さそうです。

ただし、管理者権限やroot権限が上司にいただけない立場で仕事している場合の話です。

現象

WSL から AWS の EC2 インスタンスへSSH 接続するとき、Permission error になります。

wsl
The authenticity of host 'ec2-instance-name.region-name.compute.amazonaws.com (public-ip)' can't be established.
ECDSA key fingerprint is SHA256:???????????????????????????.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'ec2-instance-name.region-name.compute.amazonaws.com (public-ip)'  (ECDSA) to the list of known hosts.
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0555 for '????????.pem' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
Load key "???????.pem": bad permissions
ubuntu@ec2-instance-name.region-name.compute.amazonaws.com: Permission denied (publickey).

この時、Windows 側から同じことをしてみると、

pwsh
he authenticity of host 'ec2-instance-name.region-name.compute.amazonaws.com (public-ip)' can't be established.
ECDSA key fingerprint is SHA256:???????????????????????????.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'ec2-instance-name.region-name.compute.amazonaws.com (public-ip)'  (ECDSA) to the list of known hosts.
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions for '????????.pem' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
Load key "???????.pem": bad permissions
ubuntu@ec2-instance-name.region-name.compute.amazonaws.com: Permission denied (publickey).

8行目が、Powershellだと、Permissions for で WSL だとPermissions 0555 for になっています。

状況

まずは大きく、

WARNING: UNPROTECTED PRIVATE KEY FILE!

と記載されていますので、「警告!保護されていない秘密鍵ファイル」というアラートが出ていることは分かります。

Permissions 0555 for '????????.pem' are too open.

次にこの部分ですが、カタカナを使わずに言うと、「許可が0555なのは、開放的すぎる」と言ってます。
何の許可かというと、ファイルのアクセスです。

この、0555という数字はstatコマンドなどで確認できます。

wsl
stat ????.pem -c '%a'

ここで、AWS のコンソールを確認すると、
image.png

wsl
chmod 400 ???.pem

と書いてあります。

しかし、これを行っても、依然として同じエラーメッセージが出て、SSH接続はできません。

原因追及

なぜなのか確認してみましょう。chmod 400 ???.pemをした直後にstat ???.pem -c '%a'で確認すると、555になっていることが分かります。

恐らく、私と同じ状況にある人は、???.pemファイルの置いてあるディレクトリが、WSLの/mnt/の下位ディレクトリに保管されているのではないでしょうか?

どういうことなのでしょう?これは、???.pemファイルの保存ディレクトリがWindowsの管轄領域にあり、アクセス権限はWindowsでコントロールされているので、WSL側で自由に変更できないように制限がかけられているということです。

WSL側でファイルパーミッションを書き換えた後にWindows側が自動修復するのか、そもそも書き換える直前にWindows側でコマンドを変更されるのかは分かりませんが、chmodコマンドをひたすら試しても意味のないことが分かります。

解決方法

解決方法は3つあります。

1つは、WSL側が管理しているディレクトリに???.pemファイルを移動する方法です。
そして、もう1つは、諦めてWindows側でSSH接続する方法です。
最後の方法はroot権限でSSH接続する方法です。

先に伝えておくと、Windows側の方法を試しても、WSL側でSSH接続はできません。

WSL側で完結させる方法

まず、最初の方法は簡単で、単純にcpコマンドで移動させてから、chmodでファイルパーミッションを変更するだけです。

例えば、???.pemファイルが置いてあるディレクトリに移動したとして、

wsl
cp ./???.pem ~/???.pem

とすると、WSLのホームディレクトリに秘密鍵ファイルがコピーされます。このまま、移動先の秘密鍵のファイルパーミッションを変更します。

wsl
chmod 400 ~/???.pem

一応ファイルパーミッションを変更できているのか確認しましょう。

wsl
stat ~/???.pem -c `%a`

とすると、400と出ました。完璧です。これでSSH接続できますね。

Windows側で解決する方法

Windows側ではGUIでやることもできますが、
Powershellでの方法を紹介します。

簡単に言うと、システム権限をシステムから剝奪します。

pwsh
Copy-Item './???.pem'
Set-Location '~/Desktop'
New-Variable -Name Key -Value './???.pem'
Icacls $Key /c /t /Inheritance:d
Icacls $Key /c /t /Grant $( $env:UserName + ':F' )
Icacls $Key /c /t /Remove Administrator 'Authenticated Users' BUILTIN\Administrators BUILTIN Everyone System Users
Icacls $Key
Remove-Variable -Name Key

上記のPowershellスクリプトの実行には管理者権限が必要です。

秘密鍵ファイルがUSBメモリや外付けHDDなどのリムーバブルメディアに保管されていると上手くいきません。

この時、Icacls $Keyの部分で、ファイルパーミッションがどう設定されたのか確認できます。

.\???.pem PCNAME\USERNAME:(F)

のようになっていれば成功です。
ここで、すぐにWindows側でSSH接続を試すと接続できます。

しかし、このファイルは、WSL側から、stat ./???.pem -c '%a'で確認すると、777となっています。

このことから、Windows側に置いている秘密鍵ファイルを使って、WSL側からSSH接続をすることは非常に難しいと結論づけることが出来ます。

ここで、WSLにて、sudo suをしてから、chmod 400 ./???.pemすると、stat ./???.pem -c '%a'の結果は555になります。
その root 権限のまま SSH接続を試すと、接続することが出来ます。

ここで、「ん?」となるのではないでしょうか?そうです。実はWindows側であれこれする前から555なので、root 権限であれば始めからSSH接続できたのです。

公式の記述

このことは、公式にも書かれてます。

ほかの方法

c ドライブなどのmount方法を変更することで、chmodの効力が変わるようですが、デフォルト設定を変更するのは避けたいところ。

まとめ

WSL側の領域に秘密鍵ファイルを保管するのが最も早そうです。

日常生活では、777というゾロ目は少しだけハッピーな気分にさせてくれます。
この状況では777という数字は見たくないですね。

みなさんの手元に400が出ることを願っています!

8
4
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
8
4