web-dev-qa-db-ja.com

ssh鍵ベースの認証の安全性

テストに使用するCentos 7サーバーを新しくインストール（および更新）しました。

SshにRSAキーベースの認証を実装し、PermitRootLoginをwithout-passwordに設定しました

今朝ログオンしたとき、私はnetstat -plantを実行し、ポート22で中国とフランスからの確立された接続をいくつか見つけました。

4096ビットのrsa鍵が一晩のうちに解読されるとは信じられません。

OpenSSHでキーベースの認証を回避するために使用できるエクスプロイト/脆弱性はありますか？

鍵ベースの認証は、SSHによるアクセスを許可するための最良のオプションですか？代替案は何ですか？

sshrsaopensshcentos
5
Son of Sam

今朝ログオンしたとき、netstat -plantを実行し、ポート22で中国とフランスから確立された接続をいくつか見つけました。

どのくらいの期間それらを見ましたか？

インターネット上にSSHサーバーがある場合、人々は常にそれをスキャンし、一般的なパスワードの辞書攻撃を試みます。そのため、システムはブルートフォース攻撃を制限したいので、システムは接続して複数のパスワードを試し、試行の間に遅延を強制します。

これは、TCP接続が数秒または数分も「確立」されたことを意味します。接続は認証されたSSHセッションではなく、TCP接続です。

ここで見てください：

$ netstat -tn | grep :22 | egrep -v "[my address]"
tcp        0   1080 192.168.1.2:22         123.183.209.136:25690   ESTABLISHED
tcp        0      1 192.168.1.2:22         123.183.209.136:40117   FIN_WAIT1

数分後：

$ netstat -tn | grep :22
tcp        0   1080 192.168.1.2:22         123.183.209.136:48456   ESTABLISHED

最初のスナップショットでは、1つの確立されたセッションがあり、1つはまだ切断されています。数分後、新しいセッションがあります（クライアントポートが48456に変更されたことに注意してください）。したがって、この人は常にTCP=接続を開いて認証を試みています。その接続がシャットダウンされたときに何度も試行すると、別の接続が開かれます。

4096ビットのrsa鍵が一晩のうちに解読されるとは信じられません。

OpenSSHでキーベースの認証を回避するために使用できるエクスプロイト/脆弱性はありますか？

鍵ベースの認証は、SSHによるアクセスを許可するための最良のオプションですか？代替案は何ですか？

まだ慌てる必要はありません。接続を監視します。最後の1つをかなりの期間表示しない限り、おそらく心配する必要はありません。

lastの出力をチェックして、実際にログインしている人がいるかどうかを確認し、送信元アドレスを関連付けることもできます（たとえば、IPからのログインについては心配しないでくださいyoログイン元）：

$ last
gowenfawr pts/0        192.168.1.3      Thu Aug  3 18:55   still logged in
gowenfawr pts/0        172.16.43.21     Thu Aug  3 03:29 - 03:29  (00:00)
gowenfawr pts/0        172.16.43.21     Thu Aug  3 03:19 - 03:29  (00:09)
gowenfawr pts/0        172.16.43.21     Thu Aug  3 03:04 - 03:06  (00:02)
gowenfawr pts/1        192.168.1.3      Wed Aug  2 19:44 - 21:09  (01:25)

wtmp begins Wed Aug  2 19:44:26 2017

もちろん、誰かがdidシステムに危害を加えたとしても、lastやnetstatを信頼することはできません。

3
gowenfawr

RSA鍵は予見可能な将来に対して十分に安全であり、4096ビットは overkill でさえあるかもしれません。

心配な場合はfail2banのような設定を検討できますが、パスワード認証を許可せず、2048ビット以上のRSAキーがある場合は問題ありません。

認証ログを確認すると、これらのアドレスから多くの認証エラーが見つかると思いますが、それはごく普通のことです。現在、私が公開しているsshサーバーには14MBの認証ログがあり、rootのログイン試行が82,000回以上失敗しています：

Sudo grep -i root /var/log/auth.log -c
82023
3
AndrolGenhald

適切に設定する限り、キーは解読されませんでした。

それらがnetstatにのみ表示されている場合は、おそらくSSHログインプロンプトに表示されています。

/etc/ssh/sshd_configファイルでトンネルクリアテキストパスワードを無効にして、通常のパスワードログインを防止してください。キーを紛失した場合にサーバーにアクセスする別の方法があることを確認してください。

PermitRootLoginはnoに設定する必要があります。特にSSHを介して、rootとしてログインしないでください。 Sudoアクセスを持つ別のアカウントを使用します。

SSHキー認証は、SSHサーバー、特にインターネットに公開されているSSHサーバーに対して認証するための最良の方法です。 Google Authenticatorを使用してSSHログインに2要素認証を実装するソフトウェアもあります。これは調べる価値のあるものです。

1
jamieweb