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

次の使用例があります。

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

sshdを異なるポートで実行できます。例：

• 内部からは、他のポートに接続させたくないので、22で実行してもかまいません（スクリプトを台無しにします）。
• 外部のモバイルユーザーの場合、別のポート、たとえばポートXでsshdを実行します（セキュリティの強化-これは小規模オフィスのセットアップです）。

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

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

入力を歓迎

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

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

2つのグループを作成し、lusersそしてrusers。リモートモバイルユーザーを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を実行するだけでよいため、独自の管理が容易になります。

編集2017-01-21-authorized_keysファイルの使用を制限します。

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

/etc/ssh/sshd_config変更、：

AuthorizedKeysFile  %h/ssh/authorized_keys

次のようなものに：

AuthorizedKeysFile  /etc/.ssh/authorized_keys/%u

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

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

AllowUsers mobileuser1 mobileuser2 *@10.0.0.0/8

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

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

これを行うには、2つのsshデーモンと2つのsshd_configファイルを起動します。既存のものをコピーします（たとえば/etc/ssh/sshd_config /etc/ssh/sshd_alt_config、代替構成セットアップ内および代替構成セットアップ内のmanページからsshd_config：

港

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ログを作成し、そのファイルに書き込まれた内容に従って、異常なログイン試行を通知したいでしょう。