☰

一般ユーザーが読めない秘密鍵を使用してSSHを実行できるようにする

tag-icon • tag-icon ssh security key-authentication privileges
一般ユーザーが読めない秘密鍵を使用してSSHを実行できるようにする

マシンごとに1つのアカウント（サポートアクセスアカウント）のみを使用して、少数の人々（サポートと呼ばれる）だけがSSHを介してアクセスできるようにするマシンセット（ここでは顧客マシンと呼ばれる）があるとします。

サポートスタッフは、お客様のコンピュータにログインするためにのみキーを使用できます。また、サポートスタッフが発展してサポートスタッフを離れる人は、顧客のコンピュータにログインできません。したがって、従業員は顧客のコンピュータにログインするために使用される秘密鍵を読むことを禁止されています。また、authorized_keysクライアントコンピュータのファイルを変更することも禁止されています。

この構成を実装するために、サポート担当者がログインし（LDAP認証を使用しますが、これは別の質問です）、秘密鍵を含むSSHエージェントを使用することを考えました。

問題は、サポートチームがSSH秘密鍵を読み取らずに使用できるようにするにはどうすればよいですか？

ユーザーの要求を受け入れ、SSHセッションを開くことができるエージェントシステムでrootとして実行されるデーモンを作成する必要があると思いますが、どうすればよいかわかりません。どんなアイデアがありますか？

答え1

実際には、SSH CAを使用し、各サポート担当者が使用するキーに署名し（パスポートなどの独自のSSHキーを持つ必要があります）、/etc/ssh/sshd_config.conf TrustedUserCAKeys /etc/ssh/users_ca.pubSSH CAを使用するようにクライアントサーバーを構成することです。からキーに署名します。これにより、サーバーはCAキー（アクセス権を持つ）で署名されたすべてのキーを受け入れ、認証されたキーに触れることなくサポートされなくなったユーザーのキーを取り消すことができます。

「ssh ca」をすばやく検索すると、このチュートリアルを見つけることができます。https://www.digitalocean.com/community/tutorials/how-to-create-an-ssh-ca-to-validate-hosts-and-clients-with-ubuntu（「ユーザーキーの設定方法」までスクロールダウン） - チュートリアルではUbuntuが言及されていますが、展開には依存しませんが、SSH CAをサポートする最新バージョンのOpenSSHが必要です。

このトピックに関する別の良いブログ投稿は次のとおりです。https://ef.gy/hardening-ssh（「SSH証明書」まで下にスクロールします）。

特に、限られた時間だけ有効なキーに署名できるため、キーが自動的に期限切れになることに注意してください。

答え2

いくつかのオプションを提案します。

  1. sudoSSHキーを保護し、サポートチームにそれを使用するように依頼してください。ラッパーを使用すると、これを透過的に実行できます。たとえば、ラッパーを呼び出して、/usr/local/bin/ssh-support次の内容を含めます（テストされていません）。 

    #!/bin/bash
export PATH=/usr/local/bin:/usr/bin:/bin
export IFS=$' \t\n'
export SUSER=ssupport

# Restart if not running under sudo
test "X$1" != 'X-S' && exec sudo -u "$SUSER" /usr/local/bin/ssh-support -S "$@"
shift
export SHOME="$(getent passwd "$SUSER" | cut -d: -f6)"

# Extract single argument as hostname LABEL and validate that we have
# an RSA private key for it. The target username, real hostname, port,
# etc. can be defined in ~/.ssh/config for the user $SUSER (ssupport)
label="$1"
idfile="$SUSER/.ssh/id_rsa_for_$label"
cgfile="$SUSER/.ssh/config"

ok=true
[[ "$label" =~ '/' ]] && { echo "Invalid label: $label" >&2; ok=; }
[[ ! -s "$idfile" ]] && { echo "Missing identity file: $idfile" >&2; ok=; }
[[ ! -s "$cgfile" ]] && { echo "Missing configuration file: $cgfile" >&2; ok=; }

if test -n "$ok"
then
    logger -t ssh-support "$SUDO_USER requested ssh to $label"
    exec ssh -i "$idfile" -F "$cgfile" "$label"
fi
exit 1

    グループのユーザーがツールを使用できるsudoersようにするには、ファイルにエントリが必要です。このコマンドを使用すると、supportユーザーとしてssh-supportツールを実行できますssupport。そのユーザーを作成する必要があります。それ確かにルート権限を付与します。

    %support ALL = (ssupport) /usr/local/bin/ssh-support

    ツールを実行するためにユーザーが自分のパスワードを提供する必要がないようにサポートしている場合（sudoスクリプト自体の呼び出しで必要）、sudoers次のように定義を変更できます。

    %support ALL = (ssupport) NOPASSWD: /usr/local/bin/ssh-support

    PATH含まれていると仮定すると、/usr/local/bin/を使用して呼び出しますssh-support clientname。また、証明書のペアを使用してユーザーを作成し、ターゲットシステムのユーザー、ssupportホスト、ポートなどを定義するホストエントリがあるとします。 X11転送、ポート転送などを明示的に無効にできます。通常どおり、ディレクトリは権限で保護する必要があります。/home/ssupport/home/ssupport/.ssh/id_rsa_clientname/home/ssupport/.ssh/id_rsa_clientname.pub/home/ssupport/.ssh/configclientname/home/ssupport/.ssh0700

  2. 各サポートメンバーに独自のローカルユーザーアカウントを提供し、独自のプライベートSSHキーを使用してクライアントサーバーにアクセスできるようにします。誰かがサポートグループを離れると、クライアントサーバーはそのSSHキーを削除します。これは、従業員がSSH秘密鍵を知らないように心配する必要がないことを意味します。

答え3

sudoまたはsetuid実行可能ファイルを介して呼び出されるsshラッパースクリプトに関連するいくつかの異なる回答があります（特殊目的の場合）。ルートではないアカウント）。 〜のようにnkms 言う、すべてのパラメータをsshに渡すと、ユーザーは保護したいSSHキーを使用して任意の操作を実行できます。一部の人々が提案するもう一つの極端な方法は、ホスト名だけを許可することです。

OPは、管理者がコンテンツをアップロードできる必要があると言います。

SSHラッパーには2つの異なる固定パラメーターがあります。 1つはログインシェル用、もう1つはscp用です。ホスト名（およびアップロードするファイル名）以外には、ユーザーが提供するパラメーターはありません。

getoptあるいは、それ自体は非常に限られたオプションのセットを解析し、主に固定されたSSHコマンドにコンテンツを挿入するラッパースクリプトです。認識できないオプションを無視（またはエラー）することは正しいアプローチです。

「危険な」SSHオプションをフィルタリングしようとするのではなく、対話型ログインまたはファイルのアップロード（ローカルファイルとリモートファイル名）の2つのタスクを実行するラッパーを作成します。私の考えでは、まだそこから消毒作業をしなければならないと思います。

実際、これはまだ間違いが非常に簡単です。ユーザーがSSHキーを持つファイルをローカルファイルとして提供するのを防ぐ方法を見つける必要があります。だから何も許さないことから始めるのではなく、まだ禁止すべきことを考えようとしています。まず、ファイル名に@またはが含まれていないことを確認してください:。

答え4

サポートスタッフは常にこのエージェントシステムを介してのみ接続されるため、顧客は単にHostbasedAuthenticationを使用したプロキシコンピュータの認証。

エージェントシステムがあり、サポートsupporters.pcを提供すると仮定customer.pc

クライアント.PC持つホストベースの認証は存在する/etc/ssh/ssd_config、サポーター.pcに記載されており/etc/ssh/shosts.equiv、公開鍵はにあります/etc/ssh/ssh_known_hosts。

サポート担当者がログインしたとき[Eメール保護]、実行すると、ssh customer.pc次のようになります。ssh-keysign(8)（uidを設定する必要があります）読み取り不可能なファイルを使用してキー署名を処理し、実際に接続が行われているという証拠をsupport.pcに提供します。サポーター.pc。 〜のようにクライアント.PC信頼するサポーター.pc、あなたの従業員は次にログインしていますサポートする。

関連情報