どうも、Tです。
先日、Windwos Server 2019にOpenSSHをインストールしましたが、何も設定しないとローカルユーザーでもドメインユーザーにも権限に関係なくSSHもSFTPも接続できる状態です。
さすがに、それは困るのでマイクロソフトの情報をもとに、接続制限が行えるか確認します。
目次
やりたいこと
- ローカル・ドメイングループからのSSH接続制限
- SSH接続不可、SFTP接続のCHROOT化
まずグループ単位でSSH接続を制限できるか確認します。また、SFTPだけ使う環境を想定して、SSH接続をできなくしてSFTP接続(WinSCPなどのクライアントソフトからの接続）のみを許可、かつ公開したフォルダ配下した触れないようにCHROOT化を行います。
可能であれば、ドメインユーザー単位で制御したいなぁと思っておりました。下記のような記載もあったためドメインユーザー単位の制御も可能と考えてましたが、どうしてもドメインユーザー単位の制御ができなかったので諦めめてグループ単位の制御に変更しました。
※ローカルユーザー単位の制御は行えました。
ドメイン ユーザーまたはグループを使用してユーザー/グループ ベースの規則を構成する場合は、
user?domain*の形式を使用します。 Windows では、ドメイン プリンシパルを指定するために複数の形式を使用できますが、標準の Linux パターンと競合するものが多数あります。 そのため、FQDN をカバーするために * が追加されています。 また、この方法では、@ の代わりに “?” を使用して、username@host 形式との競合を回避しています。
環境
- OpenSSHインストール：Windows Server 2019
- ADドメインのコントローラ：Windows Server 2019
SSHのコンフィグファイルが上書き禁止になってしまうため、作業はローカルAdministratotrもしくはドメインのAdministratorで行います。今回は、ドメインのAdministratorを使っています。
事前確認
SSH設定ファイルの場所
既定のSSH設定ファイルは、「%programdata%\ssh\sshd_config」になります。今回もこれを使います。
SSH設定ファイルの追記箇所
sshd_configは、テキストファイルで編集しますが、末尾にMatch構文が入っていました。Match構文のブロックは、宣言から最終行までをMatch構文として扱ってしまうため想定外の動作を極力なくすため、Mach構文の前に追加した設定を書いていきます。
Matchブロックは、Match Allで終わる
Match Allを入れるとMatch構文を終わらせることもできますが、Windows版のOpenSSHということもあり、個人的にどこまで正確に働くか不安があるため極力既存の設定項目をいじらないようにしました。
sshd_configを編集・保存したとは、設定を反映させるためOpenSSH SSH Serverサービスを手動で再起動します。
ローカルとドメイングループからのSSH制限
事前準備
テストで使うグループとユーザーを作成します。
ドメイングループ・ユーザー作成
下記のドメイングループとユーザーを作成しました。
- ドメイングループ：sftpusers
- ドメインユーザー：sftpuser
ドメイングループには、他に所属しているグループはありません。
ドメインユーザーは、デフォルトのDomain Usersグループと作成したグループのみに所属している状態です。
ローカルグループ・ユーザー作成
下記のローカルグループとユーザーを作成しました。これは、OpenSSHサーバーをインストールしたOS上のローカルグループとユーザーになります。
- ローカルグループ：localsftpusers
- ローカルユーザー：localsftpuser
ローカルユーザーは、デフォルトのUsersグループと作成したローカルグループのみに所属しています。
設定
sshd_configに下記の設定を追記して、サービスを再起動します。これで、指定したグループに所属するユーザーからのみSSH接続を許可した意味になります。Denyの指定をしなくともAllowした以外のグループは拒否されます。
- ドメイングループの場合：<ドメイン名>\<ドメイングループ名>
- ローカルグループの場合：<ローカルグループ名>
ダブルウォーテーションの必要性
設定値にダブルクォーテーションは必須ではありません。下記のようにグループ名に空白がある場合は、ダブルクォーテーションで囲う必要があります。
AllowGroups “testdev.lab\Domain Admins”
作成したドメイングループに所属するユーザーでSSH接続すると正常に接続できます。
作成したローカルグループに所属するユーザーでSSH接続すると正常に接続できます。
管理者権限を持っていても、Allowしたグループ以外のユーザーはSSH接続をすることはできません。再度パスワードを聞かれるようになります。
ユーザーとグループの両方のAllow設定
AllowUsersとAlloｗGroupsがある場合、AllowUsersが先に処理されAlloGroupsは無視されます(Linuxでも同様です)。そのため、制限をかける場合は、AllowUsersを使うのかAllowGroupsを使うのか先に決めておきましょう。個人的には、後々ユーザーを追加してもSSH設定変更が必要のないAllowGroupsが運用上も楽かと考えています。
allow/deny ディレクティブは、次の順序で処理されます。DenyUsers、AllowUsers、DenyGroups、最後に AllowGroups。
SSH接続不可、SFTP接続のCHROOT化
事前準備
SFTP接続時のルートディレクトリとなるフォルダを作成します。
設定
SFTPの接続とCHROOTの設定を行います。ざっくりですが、マイクロソフトのマニュアルにも記載があります。
ChrootDirectory (v7.7.0.0 に追加されたサポート)
このディレクティブは、sftp セッションでのみサポートされます。 cmd.exe へのリモート セッションでは、このようなことはできません。 sftp 専用の chroot サーバーをセットアップするには、ForceCommand を internal-sftp に設定します。 scp と sftp だけを許可するカスタム シェルを実装することで、chroot を使用する scp をセットアップすることもできます。
sshd_configに下記の設定を追記して、サービスを再起動します。
- ForceCommand internal-sftp
- ChrootDirectory <接続時のルートディレクトリのパス>
ドメインユーザーで接続します。
接続できました。ルートディレクトリ(ChrootDirectoryで指定したディレクトリ)以外は表示されません。ファイルコピーが行えました。
SFTP側でファイルを新規作成することもできます。
サーバー側とみるとCHROOTのディレクトリに作成されていることがわかります。
ローカルユーザーで接続しても同様です。
この状態でTeratermなどでSSH接続を行うと、認証は通りますがアプリのウインドウが即時閉じられます。
コマンドラインからアクセスすると「This service allows sftp connections only.」とSFTPのみ許可されるメッセージが表示され接続できません。
なぜデフォルトのドメインユーザーで書き込みできるのか
CHROOTのフォルダにデフォルトの権限しかないドメインユーザーで書き込みできる理由を念のため・・・・。
下記は、SSHサーバーに作成したテスト用のドメインユーザーでログインした状態ですが、ログインを行うとBUILTIN\Usersグループが割り当たります。
これはローカルのUsersグループに、Domain Usersに所属しているためになります。
先ほどのCHROOTように作ったフォルダのNTFSアクセス権を確認してみます。
プリンシパルにBUILTIN\Usersが特殊で割り振られています。
特殊の中を見るとこのフォルダとサブフォルダに対しては、ファイル・フォルダの作成の権限が付きます。また、削除は与えられていませんが、前述の画面でデフォルトCREATOR OWNERはフルコントロールが付いているので削除、変更なども問題なくできます。
この辺りは、Windowsを使っている通常の動作と変わりないようなので、フォルダ・ファイル操作を厳密に制御した場合は、フォルダやファイルに対してNTFSアクセス権を細かく指定していけば問題なくできそうですね。
参考
まとめ
この辺り、あまり記載しているサイトがなかった・・・・まぁSFTPとか必要ならLinuxで作っちゃうか・・・・。
でも、個人的にLinuxない環境というのも多いので、Windows2019でSFTPが使えるようになったのは大きな意味があるなと感じます。