ssh sshd 設定方法

業務でよく使用するssh client, ssh serverの設定についてまとめます。ssh clientは/etc/ssh/ssh_configで設定し、ssh serverは/etc/ssh/sshd_configで設定します。

読者の方が所属する組織の要件に応じて、厳しいすぎず緩すぎないセキュリティ設定をして頂ければと思います。

ルートログイン事故の元

sshの基本的な設定

sshd (ssh server) の基本的な設定

sshd (ssh server) の基本的な設定 – 設定一覧

sshdはssh接続を受け付けるプログラムで、/etc/ssh/sshd_configに設定を記述します。SSH接続を受ける側のサーバの/etc/ssh/sshd_configを編集する事で、セキュリティ要件を制御する事ができます。

/etc/ssh/sshd_configの中で特に重要な設定を6つ挙げました。他にも着目すべき設定は多数ありますが、私が一番最初にチェックする項目は以下6つです。なお、参考値としてCentOS 6.5のデフォルト設定を記載しましたが、デフォルト設定はディストリビューションやバージョンによって異なる事に注意ください。また、クラウド環境では、クラウドが意図した設定が自動的に投入される事にも注意が必要です。

項目デフォルト値説明
Port22sshをListenするポート版語を指定します。
Protocl2sshのバージョンを指定します。
PasswordAuthenticationYesパスワード認証を許容するかどうかです。
PubkeyAuthenticationyes公開鍵認証を許可するかどうかです。
HostbasedAuthenticationNoホストベース認証を許可するかどうかです。
PermitRootLoginNoルートログインを許可するかどうかです。
sshd (ssh server) の基本的な設定 – セキュリティ設定

sshdで最も気を付けるのはセキュリティ関連の設定です。万が一侵入されてしまえば、被害甚大です。守るべき資産の大きさに応じて、セキュリティ設定を行う必要があります。セキュリティ対策と対応可能な脅威を表にまとめると以下の通りです。

 ノーガードポート番号変更パスワード認証禁止
辞書攻撃×
ポートスキャン××
秘密鍵の流出×××

Firewallなどで守られていない環境ならば、最低限、ポート番号の変更くらいは行いましょう。sshdのデフォルト設定が許されるのは小学生までだよねローカルPC上のVirtual Boxくらいです。

「ポート番号変更」はスキャンポートされたら効果のない対策ですが、泥棒が狙いやすい家があるのと同様に、狙われづらいサーバにするだけでも充分効果があります。(ちなみに、私はさくらVPSをport 22でsshをListenする状態にして放置したら、わずか24時間で侵入されました。)

最も手堅い対策は「パスワード認証の禁止」です。この対策も完全ではない事を頭の片隅に置いておきましょう。近年、「うっかり秘密鍵をGitHubに公開してしまった」のような流出事故が多発しております。

sshd (ssh server) の基本的な設定 – 認証種別の許可設定

sshdは様々な認証方式を備えています。よく使用する認証方式は、PasswordAuthentication, PubkeyAuthentication, HostbasedAuthenticationです。PasswordAuthenticationを禁止する事によって、辞書攻撃による侵入を防ぐことができます。

sshd (ssh server) の基本的な設定 – レガシー対応

/etc/ssh/sshd_configの”Protocol”の指定は、許可するsshのバージョンです。多くの場合は、デフォルト設定のversion 2のみの対応で良いでしょう。しかし、もし、意図的にversion 1を許可している場合は、何らかのレガシーな仕組みが残っている可能性を疑った方が良いでしょう。

恐らく、インフラエンジニア固有の勘である「嫌な予感」警報がガンガン鳴っています。

ssh (ssh client) の基本的な設定

ssh_configはssh client(SSH接続を行う側)の設定ファイルです。/etc/ssh/ssh_configはシステム全体の設定を定義するファイルで、~/.ssh/configはユーザ毎の設定を定義するファイルです。

特殊な要件がない限りは、デフォルト設定の/etc/ssh/ssh_configでも充分運用可能なので、ssh_configの説明を省略します。

ノーパスワード ログイン

ある程度規模の大きなインフラになると、サーバをまたぐ処理を手作業で行うのが不可能になります。サーバをまたぐ処理を自動的に行なうツールには、ジョブネット、オーケストレーションツール、デプロイツール等があります。これらツールは、パスワードなしでログインできる事を前提しているものもあります。

私が実運用で経験したパスワードなしログインの方法は以下3通りです。この章では、パスワードなしでログインする方法についてまとめます。

  • 空パスワード
  • 公開鍵認証
  • ホストベース認証

公開鍵認証, ホストベース認証は、どちらも秘密鍵, 公開鍵の仕組みを使った認証方式です。非常に用語の使い方が紛らわしいのですが、sshdの文脈では、PubkeyAuthentication(公開鍵認証)とはユーザ単位の鍵認証と指し、HostbasedAuthentication(ホストベース認証)とはOS単位の鍵認証を指す言葉と思って下さい。

空パスワード

セキュリティ上の危険はありますが、空パスワードのユーザを作成する事によって、パスワードなしのログインを実現する事ができます。以下の要領で、空パスワードのユーザを作成します。あまり見慣れないですが、passwdコマンドに-dオプションを渡す事によって、パスワードを削除する事ができます。

# useradd <user>
# passwd -d <user>

デフォルトでは空パスワードによるログインは許容されませんので、sshd_configのPermitEmptyPasswords, PasswordAuthenticationを以下のように編集します。

--- sshd_config.org     2014-10-13 17:48:41.542029424 +0900
+++ sshd_config 2014-10-13 18:07:51.529779947 +0900
@@ -61,8 +61,8 @@
 #IgnoreRhosts yes

 # To disable tunneled clear text passwords, change to no here!
-PermitEmptyPasswords no
-PasswordAuthentication no
+PermitEmptyPasswords yes
+PasswordAuthentication yes

 # Change to no to disable s/key passwords
 #ChallengeResponseAuthentication yes

CentOS 6.X以降限定の話ですが、sshd_configのMatchブロックを使用すると特定のホストに対しての設定を施す事ができます。sshd_configを以下のように編集し、特定のセグメントのみパスワードなしログインを許容する事もできます。

--- sshd_config.org     2014-10-13 17:48:41.542029424 +0900
+++ sshd_config 2014-10-13 18:03:44.339624947 +0900
@@ -135,3 +135,6 @@
 #      X11Forwarding no
 #      AllowTcpForwarding no
 #      ForceCommand cvs server
+Match Address 127.0.0.0/24,192.168.0.0/16
+  PermitEmptyPasswords yes
+  PasswordAuthentication yes

最後に、sshdを再起動し設定を反映させます。

# /etc/init.d/sshd restart

公開鍵認証

秘密鍵, 公開鍵認証を用いた認証方式には、PubkeyAuthentication (公開鍵認証)とHostbasedAuthentication(ホストベース認証)があります。どちらかと言えば、PubkeyAuthenticationの方が多数派であり、ブログなどの情報源も多数あります。GitHubやAWSもPubkeyAuthenticationを前提とした構成になっております。特別な理由がない限り、PubkeyAuthenticationを使用する事をお勧めします。

以下、PubkeyAuthenticationの使い方について説明します。

公開鍵認証 クライアント側の設定

sshクライアントとなるサーバで秘密鍵と公開鍵を生成します。ssh-keygenコマンドで鍵を生成する事ができます。なお、passphraseは空文字を指定して下さい。passphraseに空文字以外を指定すると、sshログインの際にpassphraseを求められてしまいます。

[sys_admin@ssh_client ~]$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/sys_admin/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/sys_admin/.ssh/id_rsa.
Your public key has been saved in /home/sys_admin/.ssh/id_rsa.pub.
The key fingerprint is:
e9:36:b6:59:62:80:ed:d6:69:2f:1a:70:5f:3a:9f:0f sys_admin@ssh_client.sakura.ne.jp
[sys_admin@ssh_client ~]$

秘密鍵と公開鍵が生成された事を確認します。id_rsaが秘密鍵で、id_rsa.pubが公開鍵です。

[sys_admin@ssh_client ~]$ ls -l .ssh/
total 12
-rw------- 1 sys_admin sys_admin 1675 Feb 15 01:44 id_rsa
-rw-r--r-- 1 sys_admin sys_admin  413 Feb 15 01:44 id_rsa.pub
-rw-r--r-- 1 sys_admin sys_admin  809 Feb 15 01:43 known_hosts
[sys_admin@ssh_client ~]$

公開鍵をsshクライアントからssh serverに転送します。

[sys_admin@ssh_client ~]$ scp -P <port> .ssh/id_rsa.pub ssh_server.sakura.ne.jp:~/id_rsa.pub.tmp
sys_admin@ssh_server.sakura.ne.jp's password:
id_rsa.pub                                    100%  413     0.4KB/s   00:00
[sys_admin@ssh_client ~]$
公開鍵認証 サーバ側の設定

sshサーバは~/.ssh/authorized_keysというファイルで公開鍵を管理します。sshサーバの~/.ssh/authorized_keysに公開鍵を加筆します。なお、この設定はpermissionに注意して下さい。.sshは700、authorized_keysは600にしないとノーパスワードログインが機能しません。

[sys_admin@ssh_server ~]$ mkdir ~/.ssh
[sys_admin@ssh_server ~]$ cat id_rsa.pub.tmp >> ~/.ssh/authorized_keys
[sys_admin@ssh_server ~]$ 
[sys_admin@ssh_server ~]$ chmod 700 .ssh/
[sys_admin@ssh_server ~]$ chmod 600 ~/.ssh/authorized_keys
[sys_admin@ssh_server ~]$ rm id_rsa.pub.tmp

sshクライアントからsshサーバへノーパスワード ログインが可能である事を確認します。

[sys_admin@ssh_client ~]$ ssh ssh_server.sakura.ne.jp -p <port>
Last login: Wed Feb 15 01:54:37 2012 from ssh_client.sakura.ne.jp

SAKURA Internet [Virtual Private Server SERVICE]

[sys_admin@ssh_server ~]$

ホストベース認証

ホストベース認証とはOS単位の鍵認証です。今日(2014/10/03)のAWS, GitHubのようなIaaS, PaaSの考え方とは合わない思想なので、よっぽど特別な要件がない限りはホストベース認証を使用しない方が良いでしょう。ユーザ単位の認証であるPubkeyAuthenticationをお勧めします。

以下、私がホストベース認証を運用していた頃の残念な記憶を元に、ホストベース認証の設定方法を説明します。

ホストベース認証 クライアント側設定

ホストベース認証を行なうには、sshクライアント側でEnableSSHKeysign, HostbasedAuthenticationを有効にします。”/etc/ssh/ssh_config”に以下の設定を加筆して下さい。

”HostbasedAuthentication”はホストベース認証を有効化する指定で、”EnableSSHKeysign”は後述のssh-keyscanによる公開鍵の読み取りを許可する設定です。

Host *
  EnableSSHKeysign yes
  HostbasedAuthentication yes
ホストベース認証 サーバ側設定

sshクライアントの公開鍵(ssh_host_rsa_key.pub)をssh serverへ転送し、”/etc/ssh/ssh_known_hosts”へ登録します。

このような操作を行う時は、ssh-keyscanという公開鍵を収集するユーティリティを使うと便利です。sshサーバで以下のようなコマンドを実行する事で、sshクライアントの公開鍵を”/etc/ssh/ssh_known_hosts”に登録する事ができます。

[root@ssh_server ~]# ssh-keyscan -p <port> -t rsa ssh_client.sakura.ne.jp > /etc/ssh/ssh_known_hosts
# ssh_client.sakura.ne.jp SSH-2.0-OpenSSH_4.3
[root@ssh_server ~]#

“/etc/ssh/shosts.equiv”にホストベース認証を許可するホストとユーザを定義します。なお、ユーザ名を省略すると全ユーザに対してアクセスを許可する事ができます。

[root@ssh_server ~]# cat << EOF >> /etc/ssh/shosts.equiv
> ssh_client.sakura.ne.jp <user>
> EOF
[root@ssh_server ~]#

ホストベース認証はデフォルトでは許可されていません。/etc/ssh/sshd_configの”HostbasedAuthentication”を以下のように編集します。

--- sshd_config.org     2014-10-13 18:09:04.610825177 +0900
+++ sshd_config 2014-10-13 18:52:14.914730074 +0900
@@ -53,7 +53,7 @@
 # For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
 #RhostsRSAAuthentication no
 # similar for protocol version 2
-#HostbasedAuthentication no
+HostbasedAuthentication yes
 # Change to yes if you don't trust ~/.ssh/known_hosts for
 # RhostsRSAAuthentication and HostbasedAuthentication
 #IgnoreUserKnownHosts no

最後に、sshdを再起動し設定を反映させます。

# /etc/init.d/sshd restart

 

 

 

 

タイトルとURLをコピーしました