web-dev-qa-db-ja.com

SSHで2つのポートを2つの異なる認証スキームで開くことは可能ですか?

現在、SSHサーバーをセットアップして、ネットワークの外部からのアクセスがSSHキーを使用してのみ許可され、ルートへのアクセスや他のユーザー名/パスワードの組み合わせによるアクセスを許可しないようにしています。

同時に、ネットワーク内の内部ユーザーは、同じシステムに接続できる必要がありますが、ユーザー名とパスワードを使用して従来の意味でログインすることを期待しています。

外部と内部の両方のユーザーがPuttySSHを使用してWindowsからシステムにアクセスし、外部アクセスは55000などの任意に選択された高い番号のポートで外部ポートに送信元ポートを開くポート転送ファイアウォールを介してシステムに入ります(または管理者が決定すること)

次の図は、トラフィックフローをより適切に示しています。

SSH Setup

キーだけを使用するように実際のログインを設定する方法を知っています。ルートを拒否する方法も知っています。2つのログインタイプを分離する方法はわかりません。

同じIPの異なるポートでリッスンしているSSHDの2つのコピーを実行し、ポートごとに2つの異なる構成を持つことを検討していました。

「一致」ルールの設定も検討しましたが、これらのオプションを使用してサーバー全体の構成を分離できるかどうかはわかりません。

最後に、ログインする外部ユーザーは常に同じユーザーであり、この質問では「フランク」と呼びましょう。そのため、「フランク」は外部IPからのログインのみが許可され、実際に前に座ることはありません。内部で接続するシステムの場合、システムの他のすべてのユーザーは内部でのみ接続し、外部IPからは接続しません。

彼が接続するFranks IPは動的に割り当てられたものですが、接続しているパブリックIPも静的で変更されません。同様に、ポートフォワーダーの内部IPも変更されず、SSHサーバーの内部IPアドレスも変更されません。

内部クライアントは常に、内部SSHサーバーIPが一部であり、16ビットマスクであるプライベートネットワーク範囲のIPから接続しますEG:192.168.0.0/16

これは、1つの構成ファイルと1つのSSHサーバーインスタンスを使用して設定できますか?もしそうなら、どうすればいいですか?

または

構成が異なる2つの実行中のサーバーを使用する方がはるかに良いですか?

参考のために、SSHサーバーはUbuntu 18.04で実行されています。

16
shawty

だから、答えは実際に思ったより簡単だったことがわかりました。

しかし、彼のコメントに対して '@jeff schaller'に感謝しなければなりません。もし彼のコメントがなければ、SSHの 'Match'構成がどのように機能するかを調べ始めなかったでしょう。

とにかく

トリックは、/ etc/ssh/sshd_configファイルをデフォルトとして設定し、外部インターネット接続からのアクセスに必要な構成にすることです。

私の場合、これは次の設定を意味しました

PermitRootLogin no
PasswordAuthentication no
UsePAM no

これを行うことで、SSHキーを使用したキーベースのログインである必要があるために、どこから来てもすべてのログインを強制します。

次に、Windowsマシンで「PuttyGen」を使用してディスクに保存した公開鍵と秘密鍵のペアを生成し、外部ユーザーのホームディレクトリにある「authorized_hosts」ファイルの適切なsshエントリを作成しました。

このsshキーをユーザーのホームフォルダーの正しい場所に貼り付け、PutyGenが生成したプライベート(ppk)ファイルを使用してログインし、プロファイルを保存するようにPuTTYを設定しました。

次に、プロファイルを保存し、安全な方法(パスワードで保護されたZipファイルが添付された暗号化された電子メール)を使用して、そのユーザーとppkキーファイルを外部ユーザーに送信しました

ユーザーがPuTTYのコピーにppkとプロファイルを持ち、ログインできるようになったら、sshd_configファイルの最後の2行として次を追加しました

Match Host server1,server1.internalnet.local,1.2.3.4
    PasswordAuthentication yes

「一致」行で、自分のサーバーの名前を保護するためにサーバー名を変更しました。

各サーバードメインはカンマで区切られ、スペースはありません。これは重要です。その中にスペースを入れると、SSHDが構成をロードせず、エラーを報告する場合、そこにある3つの一致は次のようになります。

server1-ドメインなしで「server1」だけを使用して接続するすべてのユーザーに一致しますEG:「fred @ server1」

server1.internalnet.local-完全修飾内部ドメイン名EGを使用するすべてのユーザーに一致します。例: '[email protected]'(注:これを正しく機能させるには内部DNSが必要です)

1.2.3.4-特定のIPに一致SSHサーバーに割り当てられたアドレスEG: '[email protected]'これはワイルドカードを使用できます。ワイルドカードを使用する場合は、さらに優れたnet/mask cidr形式EG:1.2。*または192.168.1.0/8を参照してください。いくつかの重要な注意事項については、以下のfchurcaの回答。

提供されたパターンのいずれかがアクセスされているホストと一致する場合、実行中の構成に対して行われる唯一の変更は、インタラクティブなパスワードログイン機能をオンにすることです。

ここに他の構成ディレクティブを配置することもできます。これらのディレクティブは、一致リストにリストされている内部ホストに対してもオンに戻ります。

しかしこれを読んでください:

https://man.openbsd.org/OpenBSD-current/man5/ssh_config.5

マッチブロック内ですべての構成オプションを使用できるわけではないので注意して、「UsePAM yes」を使用してPAM認証をオンに戻そうとしたときにこれがわかりました。

変更を加えたら、次のように入力します

sshd -T

次に、サーバーを再起動する前に、テストに戻るために戻ります。エラーがある場合は報告されます。

上記のすべてに加えて、私は次の2つのリンクからも多くの助けを得ました。

https://raymii.org/s/tutorials/Limit_access_to_openssh_features_with_the_Match_keyword.html

https://www.cyberciti.biz/faq/match-address-sshd_config-allow-root-loginfrom-one_ip_address-on-linux-unix/

29
shawty

1.2。*-サーバーEGの16ビットネットマスクにあるSSHサーバーに割り当てられたアドレスを使用して、ローカルネットのすべてのユーザーに一致します。例: '[email protected]'

気をつけて! .ssh/configのパターンマッチングは、必ずしもIPアドレスではなく、文字列のグロビングに基づいています。あなたが読んでいる同じマンページによると:

パターン

パターンは、ゼロ個以上の空白以外の文字、 ‘*’(ゼロ個以上の文字と一致するワイルドカード)、または ‘?’(正確に1文字と一致するワイルドカード)で構成されます。たとえば、「。co.uk」ドメインセット内の任意のホストの宣言セットを指定するには、次のパターンを使用できます。

Host *.co.uk

次のパターンは、192.168.0。[0-9]ネットワーク範囲のすべてのホストに一致します。

Host 192.168.0.?

誰かが1.2.badguy.comにパブリックに逆解決するIPからログインしようとすると、1.2.*ルールに一致します。

https://man.openbsd.org/OpenBSD-current/man5/ssh_config.5#PATTERNS

[完全性のために更新]

他の場所で述べたように、Match Address 1.2.0.0/16の代わりにMatch Host 1.2.*を使用できます。

[/更新]

8
fchurca

調査する必要があるのは、ssh構成を分割することだと思います。例えば;/etc/ssh/ssh_configをセットアップして、デフォルトですべてのユーザーに必要なグローバル変数(sshキー認証、ポート転送など)を設定します。

次に、ユーザー(Bobと呼ぶことにします)にローカル(またはマウントされたnfs)のホームディレクトリがある場合は、/ home/bob/.ssh /にそのユーザー専用の設定を配置します。この構成には、一致ステートメントと、証明書ではなくパスワードで接続する必要があるかどうか、および独自のキープアライブ値などが含まれます。

私はこれを以前に行っており、現在、特定のローカルアカウントをロックして1つのIPアドレスのみから取得し、証明書ベースの認証のみを許可する一方で、他のユーザーアカウントは代わりにPAM認証を使用しており、パスワードベースの認証を持っている可能性があります。

つまり、ユーザーのニーズに基づいて個別のユーザー設定ファイルを構築および維持する方が、sshのデフォルト設定ファイルの下にすべてを維持するよりも管理が簡単です。

1
jmatzke