☰

SSHを使用する場合のホストベース認証のホスト名の問題

tag-icon • tag-icon ssh hostname
SSHを使用する場合のホストベース認証のホスト名の問題

これで、チームはSSH公開鍵認証を介してサーバーに接続できます。各チームメンバーは自分のPCに秘密鍵を持ち、~/.ssh/公開鍵はサーバー上のファイルにありますauthorized_key。

各チームメンバーに割り当てられたPCのみがサーバーへのSSH接続を承認するように要求されました。

実際、チームメンバーがそのコンピュータへのルートアクセス権を持っていなくても、理論的にはホームフォルダから秘密鍵をコピーし、別のコンピュータで使用してサーバーに接続できるようになりました。だから私の質問はこれを行う方法です。

私は多くの文書を読んで、私に最適なものが何であるかをテストしました。ホストベース認証。

これが私の問題に対する完璧な解決策のようです。各 PC には、非/etc/ssh/root ユーザーが読み取ることができず、既存の公開鍵認証構成に加えて認証をホストするために使用される秘密鍵があります。

私が経験している問題は、SSHクライアントがサーバーに送信するホスト名にあります。私が接続されているネットワークに従って送信されるホスト名が、、であることを確認fooMachine.localdomainしfooMachine.homeましたfooMachine。

使ってssh -vvv user@ipみると

debug2: userauth_hostbased: chost ...

これに注意してください。

PCが常に同じネットワーク上のSSHサーバーに接続されているわけではなく、VPNや固定IPはありません。

fooMachine.localdomainしたがって、これが意味するのは、SSHサーバーで何度も（、、、fooMachine.home）接続するようにホストを宣言する必要があり、fooMachineネットワークに接続した後に別のサフィックスを持つようになり、fooMachine接続できないことが発生する可能性があることです。私のサーバーに接続してください。

この問題をどのように解決できますか？それとも私が何か間違っているのでしょうか？

fooMachine.test.com再起動後もhostname --fqdn表示されたSSHクライアントfooMachine.test.comで使用されるホスト名は同じですfooMachine.localdomain。

また、サーバーに接続するホストを宣言したSSHサーバーのshosts.equivファイルでワイルドカードを試しましたが、機能しませんでした。読んだ後ソースコードこれはワイルドカード（+rhostsスタイルファイルの場合）が無視されるため意味があります。

答え1

特定の秘密鍵で認証を試みるときに許可される制限を追加する一般的な方法は次のとおりです。 ~/.ssh/authorized_keysfrom="pattern-list"サーバー上のファイル - 特にユースケースに合わせて、このオプションを使用して特定のキーペアを使用できるホストを構成/制限する機能。

たとえば、

# ~/.ssh/.authorized_keys
from="10.80.0.0/14,192.168.1.2,hbruijns-workstation.internal.example.com" ssh-rsa AAAAB3NzaC1y***...***== hbruijn@serverfault

たとえば、一致する秘密鍵を使用して、hbruijns-workstation.internal.example.comIPアドレス192.168.1.2および/または範囲内のすべてのIPアドレスでのみログインを許可します10.80.0.0/14。

追加の改善により、 ~/.ssh/.authorized_keys をサーバー管理者の制御下に置くことで、チームメンバーがこの制限を無視できないようにすることができます。

私がすでに言及していて、あなたが言及したように、ネットワークが信頼できるクライアントに依存するセキュリティモデルを実装するための前提条件をサポートしていない場合、これはあまり役に立ちません。

  • 信頼できる顧客を識別するための信頼できる方法が必要です。

クライアントに固定IPおよび/またはホスト名が割り当てられていない場合、この方法は機能しません（他の方法も同様です）。

だから要求「各チームメンバーに割り当てられたPCのみがサーバーへのSSH接続を承認します。」 チームメンバーPCに必要な静的IPアドレス割り当てを取得したり、チームメンバーがVPNを介して接続したりできる管理ネットワークなどの要求は拒否または拒否する必要があります。

答え2

問題を解決する1つの方法は、SSHクライアント構成ファイル（/etc/ssh/ssh_configまたは~/.ssh/config）のSendEnvオプションを使用して、ホストベースの認証に使用するホスト名を含むカスタム環境変数を送信することです。サーバー側では、AcceptEnvSSHデーモン構成ファイル（）/etc/ssh/sshd_configのオプションを使用してこの環境変数を適用できます。

これを行う方法の例は次のとおりです。

各クライアントコンピュータでSSHクライアント設定ファイル（/etc/ssh/ssh_config or ~/.ssh/config）を編集し、次の行を追加します。

Host *
    SendEnv MY_HOSTNAME

各クライアントコンピュータで、MY_HOSTNAME環境変数を希望のホスト名に設定します。ユーザーのシェルプロファイル（~/.bashrcまたは）に次の行を追加するだけ~/.zshrcです。

export MY_HOSTNAME=fooMachine.test.com

サーバーでSSHデーモン構成ファイル（/etc/ssh/sshd_config）を編集し、次の行を追加します。

AcceptEnv MY_HOSTNAME

サーバーでSSHデーモンを再起動して変更を適用します。これらの手順を完了した後、ユーザーがSSHを使用してサーバーに接続すると、MY_HOSTNAME環境変数がサーバーに送信され、ホストベースの認証に使用できます。

関連情報