私は単にx.509証明書の公開RSAキーを_~/.ssh/authorized_keys
_に入れることを意味するのではありません-事前定義されたCAによって署名されたx.509証明書が自動的に署名されるようにsshを設定する方法を探していますリンクされたユーザーアカウントへのアクセスが許可されます。 RFC 6187 はそのような機能を提案しているようですが、これに関するドキュメントが見つからないか、OpenSSHに実装されているかどうかはまったくわかりません。
これが私がやりたいことのより詳細な説明です:
keyUsage=digitalSignature
_(および__id-kp-secureShellClient
_ extendedKeyUsageフィールド)でユーザー証明書に署名するために使用されますauthorized_keys
_に存在する公開鍵を必要としません。代わりに、SSH-CAを信頼して、証明書(または証明書チェーン)の公開鍵と署名、およびユーザー名/ UID(おそらくsubjectAltName
フィールドに直接、またはおそらくサーバー側のマッピングを使用)を検証するように設定されています。通常のRSA認証が行われますでは、(方法)これはOpenSSHで実現できます。パッチが必要な場合は、クライアント側の変更を最小限に抑える方法を教えてください。
別の方法として、独自のCAを必要とせずに、任意のS/MIME証明書とユーザー名からメールアドレスへのマッピングを使用することもできると思います。クライアントはまだRSA秘密鍵のみを使用することもでき、証明書サーバーは公開鍵から証明書を取得するために使用され、さらにPGP証明書を使用する可能性を提供します(例: monkeysphere )ユーザーが公開鍵を提供するだけである限り、ユーザーはこれらすべてについての知識を必要としません。
ネイティブで可能でない場合は、サーバー上のスクリプトにopenssl
(またはgnupg
)を介して何らかの方法で送信された証明書を自動的にチェックさせ、公開鍵をそれぞれのユーザーの_authorized_keys
_ファイル-その時点でIamは多かれ少なかれ サルを再実行しています事業 ...
OpenSSHは、x.509証明書ベースの認証を正式にサポートしていません。
開発者たちは、X.509証明書の複雑さがsshdに許容できない攻撃面をもたらすというスタンスを維持しています。代わりに、[最近]解析がはるかに簡単で、リスクが少ない代替の証明書形式が実装されています。
...
OpenSSHは、OpenSSLの低レベルの暗号化アルゴリズムを使用するだけです。
ただし、 Roumen Petrovは、X.509サポートを含むOpenSSHビルドを公開しています であり、それらを試すことができます。
X.509証明書は、SSHの「公開キー」および「ホストベース」の認証で「ユーザーID」または「ホストキー」として使用できます。
Roumen Petrovのビルドはダウンロードできます このページ経由 。
パスワードの代わりに認証キーを使用したSSHのDebianハウツー これは、ユーザー認証にx509 PKIを受け入れるようにOpenSSHを設定する場合にも役立つことがあります。
ネイティブ証明書ベースの認証は、変更されていないアップストリームOpenSSHで使用できます。ただし、x.509に基づくものではありません。
まず、CAを生成します。
ssh-keygen -f ssh-ca
次に、.authorized_keys
接頭辞を付けてCAキーをcert-authority
にインストールします。
echo "cert-authority $(<ssh-ca.pub)" >>.ssh/authorized_keys
その時点から、ユーザーがキーを生成するときはいつでも:
ssh-keygen -f real-key
...公開部分はSSH CAによって署名できます。その後、そのキー自体をauthorized_keys
に追加しなくても、サーバーによって信頼されます。
ssh-keygen -s ssh-ca -I identifier_for_your_real_key_goes_here real-key.pub
OpenSSHでは不可能です。 @TildalWaveで述べたように、Roumen Petrovのフォークを使用する必要があります [〜#〜] pkixssh [〜#〜] 。
X509証明書を取得したら、authorized_keys
ファイルに公開鍵を追加する必要はありません。
サーバー側で2つのことを設定する必要があります:
sshd_config
ファイルのCACertificatePath
ディレクティブによって設定されたディレクトリにCAの証明書を追加します(通常は/etc/ssh/ca/crt
、私は思う)証明書のハッシュへのリンク付き。
リンクを作成するには、opensslを使用します。 CA証明書が/ect/ssh/ca/crt/ca.crt
の下にコピーされているとすると、コマンドは次のようになります。
cd /etc/ssh/ca/crt/
ln -s ca.crt `openssl x509 -in ca.crt -noout -hash`.0
X509証明書の「件名」情報をユーザーのauthorized_keys
ファイルに追加します(宛先サーバー内)
クライアントでサブジェクトを実行するために、秘密鍵とユーザーのX509証明書がssh/id_rsa
にあるとします。
openssl x509 -noout -subject -in .ssh/id_rsa
そして、サーバー上で、この行をx509v3-sign-rsa subject=
に接頭辞authorized_keys
を付けて追加します。
この行には、次のような内容が含まれます。
x509v3-sign-rsa subject= /C=ES/ST=Pontevedra/L=Vigo/CN=testssh/[email protected]
見てわかるように、認証は実際に行われ、ユーザーからの有効なx509証明書をCAに信頼します。新しい証明書を生成でき、サーバー側の介入なしで受け入れられます。
数日間苦労した後、展開したばかりのブログにプロセス全体を説明する投稿を書きました。 "OpenSSH with X509 certificates HOW TO" で読むことができます。
CA署名付きSSHキー
ユーザーのアクセスを範囲外で管理したい場合、ユーザーがアクセスする必要があるサーバーのauthorized_keysファイルにユーザーの公開鍵をインストールしたくないでしょう。また、個人アカウントを管理するのではなく、プリンシパル(機能アカウント、つまりadmin)を使用してリースを付与します。
Ssh鍵ペアを作成するだけで、Secure Shell用の証明書署名機関(X509 TLS/SSLとは異なります)を作成できます。 CAの公開鍵はすべてのサーバーにインストールされ、そこに存在する必要があるのはそれだけです。 (必要に応じて、ファイルに2つ以上のCAキーを含めることができます。)
$ ssh-keygen -t rsa -b 4096 -f ~/.ssh/ca_ssh
cat ~/.ssh/ca_ssh.pub
このファイルをサーバーにコピーし、/etc/ssh/sshd_config
に追加します。
TrustedUserCAKeys /etc/ssh/trusted-user-ca-keys.pub
アクセスの許可
Fredの公開鍵(fred.pub)に署名して、サーバーへの1週間のアクセスを管理者として許可し、スタッフとして/ var/log/secureにログインするには、このコマンドを実行して、fred.pub-certファイルをFredに送り返します。
ssh-keygen -s ~/.ssh/ca_ssh -I staff -n admin -V +1w fred.pub
キーの取り消し
リース中にログインする必要のない人の公開鍵をplaybook_dir/files/ssh/revoked_keys
に追加します