通常のユーザーが読み取りできない秘密鍵を使用してSSHで接続できるようにする

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

サポートスタッフは、キーを使用して顧客のマシンにログインすることのみが想定されています。さらに、サポートスタッフは進化する可能性があるため、サポートスタッフを離れた人は、お客様のマシンにログインすることはできません。そのため、スタッフはお客様のマシンへのログインに使用される秘密鍵を読み取ることを禁止されています。また、authorized_keysお客様のマシン上でファイルを改変することは禁じられています。

この構成を実現するために、私はサポートスタッフが（LDAP認証を使用してログインしますが、これは別の問題です）秘密鍵を含むSSHプロキシを使用するという考えを持っていました。

問題は、サポートスタッフがSSH秘密キーを読み取ることなく使用できるようにするにはどうすればよいですか。

ユーザーの要求を受け入れ、それらのSSHセッションを開くプロキシマシンでrootとして実行するデーモンを作成する必要があると思いますが、それを行う方法がわかりません。何か案は？

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

1. sshキーを保護sudoし、サポートチームの側での使用を要求します。これは、ラッパーを使用して透過的に行うことができます。ラッパーを呼び出して、/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て、ユーザを/home/ssupport作成します/home/ssupport/.ssh/id_rsa_clientnameと/home/ssupport/.ssh/id_rsa_clientname.pub証明書のペアとして、及び内のホストエントリを持っている/home/ssupport/.ssh/configためclientname、ターゲットマシンのユーザ名、ホスト名、ポート、などを定義しました。おそらく、X11転送、ポート転送などを明示的に無効にします。通常どおり、/home/ssupport/.sshディレクトリは権限で保護する必要があり0700ます。

2. サポートの各メンバーに独自のローカルユーザーアカウントを与え、各ユーザーに独自の秘密sshキーを使用してクライアントのサーバーにアクセスさせます。人がサポートグループを離れると、クライアントのサーバーからsshキーが削除されます。これは、あなたのスタッフが秘密のsshキーを知るのを防ぐことについて心配する必要がなくなったことを意味します。

本当にやりたいことは、各サポート担当者が使用するSSH CAと署名キー（パスポートのような独自のsshキーが必要）を使用TrustedUserCAKeys /etc/ssh/users_ca.pubし、/ etc / ssh / sshd_configでを使用するようにクライアントのサーバーを構成することです。このようにして、サーバーはCAキー（アクセス権を持つ）によって署名されたすべてのキーを受け入れ、authorized_keysに触れることなくサポートされなくなった人々のキーを取り消すことができます。

このチュートリアルを指す「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が必要です

このトピックに関するもう1つの優れたブログエントリは、https：//ef.gy/hardening-sshです（「SSH証明書」までスクロールします）。

キーに署名して一定期間有効にすることで、キーが自動的に期限切れになることに特に注意してください。

sudoまたはsetuid-executable（特定の非rootアカウントに対して）を介して呼び出されるsshのラッパースクリプトに関するいくつかの異なる回答があります。以下のようnkmsは言う、SSHにすべての引数を通過すると、ユーザーは、我々が保護しようとしているSSHキーで任意のものを行うことができます。一部のユーザーが考え出したもう1つの極端な例は、ホスト名のみを許可することです。

OPは、管理者がアップロードできる必要があると述べています。

2つの異なるfixed-args-to-sshラッパーを使用できます。1つはログインシェル用、もう1つはscp用です。ホスト名（およびアップロードするファイル名）以外のユーザー指定の引数はありません。

または、getoptそれ自体を使用して非常に限られたオプションを解析し、ほとんどが修正されたsshコマンドにプラグインするラッパースクリプト。認識されないオプションを無視（またはエラー）するのがよいでしょう。

「危険な」sshオプションを除外するのではなく、対話型ログイン、またはファイルのアップロード（ローカルおよびリモートのファイル名）の2つのことを実行できるラッパーを作成するだけです。あなたはまだそこにいくつかの消毒をする必要があると思います。

実際、これはまだ間違いやすいです。ユーザーがsshキーを保持するファイルをローカルファイルとして提供できないようにする方法を見つける必要があります。したがって、何も許可しないことから始めるのではなく、許可する必要のあるすべてのものを考えようとしています。ファイル名に@or が含まれていないことを確認することから始めます:。

SSHプロキシサーバーを設定すると、スタッフユーザーのシェル（内/etc/passwd）がbashなどのシェルではなく、シェルアクセスを許可しない単純なスクリプトに設定されるようにすることができます。代わりに、ターゲットのホスト名（read target）、次にを要求しexec ssh "support@$target"ます。

このようなプロキシを使用するとscp、顧客のマシンとの間でファイルを転送するなどのツールを使用することが困難になる可能性があることに注意してください。これは問題かもしれませんし、利点かもしれません！

サポート担当者は常にそのプロキシマシンを介して接続し、そのプロキシマシンからのみ接続するため、クライアントはHostbasedAuthenticationを使用してプロキシマシンを簡単に認証できます。

プロキシマシンがsupporters.pcあり、サポートを提供するとしますcustomer.pc

customer.pcにはHostbasedAuthentication yesがあり/etc/ssh/ssd_config、supporters.pcにリストされ/etc/ssh/shosts.equiv、その公開鍵にはがあり/etc/ssh/ssh_known_hostsます。

サポートスタッフがsupport@supporters.pcにログインしてを実行するとssh customer.pc、ssh-keysign（8）（これはsetuidである必要があります）を生成します。接続がsupporters.pcから実際に行われているという証拠をsupporters.pcに提供します。以下のようcustomer.pc信託supporters.pc、あなたのスタッフがなどに記録されますサポート。

ラッパーバイナリを使用する

この特定の使用例（以下の重要な注意を参照）の場合、1つの可能性はsupport-ssh、これらの発信SSH接続専用のユーザーを（たとえば）作成し、実行する小さなラッパーバイナリをインストールすること/usr/bin/sshです。

• sshセキュリティアップデートを適用するたびにバイナリを再コピーすることを覚えていないため、バイナリ自体をコピー+ chmodしないでください。
• そしてroot、私が信頼している理由が明白であるため、より特権的なユーザーとして使用しないでください。

これは、次のトレードオフを使用sudoして、特権をsupport-sshアカウントの特権に昇格するのに使用する機能的に同等の代替手段です。

• これはよりも小さくてスリムなのでsudo、意図したよりも多くの構成エラーが開くリスクが少なくなります。
• 正しくコーディングするのはあなたの責任です- 非常に注意深く、（理想的には）セキュリティ上重要なコーディングの経験がある場合にのみ、これを行ってください。
• これは、より具体的になるように調整できますsudo（ただし、作成するコードが増えるほど、セキュリティのために監査する必要が増えます）。

ラッパーバイナリはHOME、support-sshユーザーのホームディレクトリに設定するssh必要がssh_configあります。これにより、適切な秘密キーが取得されます。ただし、呼び出し元のユーザーは~support-ssh/.ssh/、その内容の読み取りを許可されるべきではありません。

ラッパーは次のように単純にすることができます。

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

int main(int argc, char **argv)
{
    setenv("HOME", "/home/support-ssh", 1);
    /* allow only a single, non-option argument */
    if (argc!=2 || *argv[1]=='-') {
        fprintf(stderr, "Usage: %s <hostname>", argv[0]);
        exit(EXIT_FAILURE);
    }
    execv("/usr/bin/ssh", argv);
    return EXIT_FAILURE;
}

もっと制限したい場合は、引数argv[1]が許可されたホスト名のセットに含まれていることを確認してください。または、制限が少なく、オプションの引数（のサブセット）を許可します。あなたは完全に環境変数を置き換えることもできます（ただし、のような重要なものを維持するTERM、LC_*など）。それを注意LD_LIBRARY_PATHし、LD_PRELOAD特に危険です。

scp必要に応じて、同様のラッパープログラムを提供できます。

適用性に関する注意

この回答は、ユーザーが契約に従って手続きに従う義務があり、違反した場合の制裁措置（解雇など）がある質問の特定の状況に対処します。攻撃者が不正なアクセスを取得するのを防ぐのではなく、従業員が秘密鍵を何気なくコピーするのを防ぎたいと想定しています。

私は、セキュリティは技術的な防御と非技術的な防御の両方によって達成され、ここでまたは使用することによって達成されるバランスsudoは、提示された状況に適切であると考えています。