web-dev-qa-db-ja.com

特定のユーザーのみが1つのポートでsshを介してログインできるようにし、他のユーザーは別のポートを介してログインできるようにする

次の使用例があります。

  • ユーザーが安全で信頼できるネットワークからログインできるようにする必要がある
  • そして、カップル（2人だけ）のモバイルユーザーがLinux Centosマシンにリモートでログインできるようにします。

Sshdを異なるポートで実行することができます：

  • 他のポートに接続させたくないので、22で実行しても問題ありません（スクリプトを混乱させます）。
  • 外部のモバイルユーザーの場合は、sshdを別のポート（ポートXなど）で実行します（セキュリティの向上-これは小規模なオフィス向けのセットアップです）。

セキュリティを強化するために、ポートXで特定のユーザーのみにアクセスを許可するようにsshdを構成することを望んでいました（その後、ユーザーがポートXを介してログインしていることを確認できるようにアラートを構成します）。

ただし、sshdのドキュメントでこのような構成を見つけることができません。このような解決策がない場合、誰かがポートXでsshdログインを完了するたびに、実行するシェルスクリプトをトリガーすることは少なくとも可能ですか？ iptablesのドキュメントを見て、sshdログインがあるときにアラートをトリガーできるかどうかを確認しましたが、何も考え出せませんでした。

高く評価された入力

centossshd
13
doon

代替ポートでSSHを実行しても、セキュリティとしてはカウントされなくなりました。それは、ほんの少しのあいまいさを追加するだけであり、ユーザーに複雑さの追加のステップを追加します。自動化されたポートスキャナーを使用していて、どのポートで実行されているかを気にしていない、ネットワークを壊そうとしている人にとっては、障害はありません。

リモートのインターネットベースのインバウンドSSHを許可しているシステムのセキュリティを強化したい場合は、@ Anthonが示すように_sshd_config_でユーザーを制御し、PAMに直接セキュリティを実装します。

lusersとrusersの2つのグループを作成します。リモートモバイルユーザーをrusersグループに追加します。 pam_succeed_if.so PAMモジュールを使用して、これらのユーザーへのアクセスを許可します。 sshのpam構成に行を追加します。

_account     sufficient  pam_succeed_if.so user ingroup lusers
account     sufficient  pam_succeed_if.so user ingroup rusers
_

一部のpam_succeed_if.soモジュールでは、_group = lusers_。のようなわずかに異なる構文を使用する必要がある場合があります

次に、sshdが接続できるユーザーを制限するだけでなく、sshdにバグが発生した場合でも、PAMベースの制限が提供する保護を利用できます。

リモートユーザーの追加手順の1つは、パスフレーズでssh_keysの使用を強制することです。したがって、ローカルユーザーはキーまたはパスワードを使用してログインできますが、リモートユーザーはキーを持っている必要があります。それらのキーを作成すると、キーにパスフレーズが関連付けられていることを確認できます。したがって、SSHキーおよびパスフレーズを実際に所有している場所へのアクセスを制限します。また、ユーザーのパスワードが改ざんされている場合、潜在的な攻撃ベクトルを制限します。

_sshd_config_内：

2つの設定を変更します。

_ChallengeResponseAuthentication yes
_

そして

_PasswordAuthentication yes
_

に：

_ChallengeResponseAuthentication no
_

そして

_PasswordAuthentication no
_

したがって、デフォルトでは、キー認証のみを許可するようになっています。次に、ローカルユーザーの場合、match構成設定を使用して、ローカルユーザーのデフォルトを変更できます。ローカルプライベートネットワークが192.168.1.0/24であると仮定して、_sshd_config_に追加します。

_Match Address 192.168.1.0/24
PasswordAuthentication yes
_

これで、ローカルユーザーはパスワードまたはキーで接続できるようになり、リモートユーザーはキーの使用を強制されます。パスフレーズでキーを作成するのはあなた次第です。

追加の利点として、単一の_sshd_config_を管理するだけで済み、単一のポートでsshを実行するだけでよいので、独自の管理が容易になります。

edit 2017-01-21-_authorized_keys_ファイルの使用を制限します。

ユーザーがssh鍵を自分で生成するだけでなく、それを_authorized_keys_ファイルで使用してログインできないようにする場合は、sshdの特定の場所を設定することで、認証された鍵を探すように制御できます。

_/etc/ssh/sshd_config_で、以下を変更します。

_AuthorizedKeysFile  %h/ssh/authorized_keys
_

次のようなものに：

_AuthorizedKeysFile  /etc/.ssh/authorized_keys/%u
_

ユーザーに書き込み権限がない制御されたディレクトリを指すと、ユーザーは独自のキーを生成できず、それを使用して、配置したルールを回避できます。

12
Tim Kennedy

次のようなものを/etc/ssh/sshd_configに追加できます。

AllowUsers mobileuser1 mobileuser2 *@10.0.0.0/8

上記は、許可されたリモートユーザーの名前がmobileuser1およびmobileuser2であり、信頼できるネットワークがサブネットマスク255.0.0.0の10.0.0.0であることを前提としています。

これにより、2人のモバイルユーザーはどこからでもログインでき、誰もが信頼済みネットワークからログインできます。これらのパターンのいずれにも一致しないユーザー（リモートからログインしているユーザーfooなど）は、アクセスを拒否されます。

8
Richard Hansen

これを行うには、2つのsshデーモンと2つのsshd_configファイルを起動します。既存のものをコピーします（例：/etc/ssh/sshd_config/etc/ssh/sshd_alt_configから）および代替構成設定（sshd_configのmanページから：

ポート

Specifies the port number that sshd(8) listens on.  The default
is 22.  Multiple options of this type are permitted.  See also
ListenAddress

AllowUsers

This keyword can be followed by a list of user name patterns,
separated by spaces.  If specified, login is allowed only for
user names that match one of the patterns.  Only user names are
valid; a numerical user ID is not recognized.  By default, login
is allowed for all users.  If the pattern takes the form
USER@Host then USER and Host are separately checked, restricting
logins to particular users from particular hosts.  The
allow/deny directives are processed in the following order:
DenyUsers, AllowUsers, DenyGroups, and finally AllowGroups.

おそらく、別のsshログを別のファイルに保存したいと思うでしょう。そのファイルに書き込まれた内容に従って、異常なログイン試行を確認します。

2
Anthon