web-dev-qa-db-ja.com

SSHキーを管理する

Linuxサーバーは約2500台あります。 Jumpstartサーバーがあり、そこからシステム管理者関連のタスクのために任意のサーバーにSSHで接続できます。単一のIDファイルを展開し、すべてのサーバーで同じ公開鍵を使用しています。しかし、これは大きなセキュリティの脅威です。

サーバーごとに異なるキーをデプロイする必要があります。しかし、それでは多数のキーが作成され、管理が困難になります。簡単にできる方法を教えてください。

linuxsshssh-keys
7
user3114179

FreeIPAはSSHキー管理をかなりうまく行います。私は自宅でそれをうまく使用していますが、多くの企業が本番環境で使用しています（freeipa-usersメーリングリストは非常に活発です）。これは、Red HatのID管理ソリューションをベースにした上流のフリーソフトウェアプロジェクトです。また、freeipa-usersメーリングリストでRed Hat開発者がモデレートおよび支援しています。

基本的には、Unix/Linux環境用のActive Directoryのようなサービスです。 ADと同期することもできます。 NFS自動マウント、集中化されたSudoポリシーなどの* nixネイティブ機能を備えています。

各ユーザーは、SSHキーをFreeIPAプロファイルに追加できます。次に、sshdを構成して、FreeIPAサーバーを照会するように構成されているsssdパッケージによって提供されるAuthorizedKeysCommandを使用できます。 Sudoポリシーと組み合わせると、特権の昇格と監査（Sudoをだした人）が得られます。

RedHatプロジェクトであるため、FedoraまたはCentOSにインストールするのは簡単ですが、DebianボックスをFreeIPAクライアントとして正常にインストールして構成しました。ただし、ネイティブにサポートされているプラ​​ットフォームであるFedoraサーバーに認証サーバーをインストールします。

http://www.freeipa.org/page/Main_Page

6
Alexandre de Verteuil

2500ホストの場合、構成管理システムが既にある場合がありますが、ない場合は SaltStack を使用できます。ルート認証のためにこれを持っています：

user1auth:
  ssh_auth:
    - present
    - user: root
    - source: salt://resources/ssh_keys/user1

user2auth:
  ssh_auth:
    - present
    - user: root
    - source: salt://resources/ssh_keys/user2

ジャンプホストに秘密キーを置く必要はありません。ログイン時にエージェント転送を使用するだけです：ssh -A root@Host。

他のシステムもあります（Pupet、cfengineなど）。

4
Halfgaar

どこでも同じSSHキーを使用する場合に発生する問題は、説明責任の欠如です。

代わりに、各ユーザーに独自のSSHキーを持たせ、集中認証と承認システムを使用します。

このように、公開鍵はターゲットシステムに配布する必要すらなく、 FreeIPA のような中央ディレクトリサービスに格納できます。

説明責任を獲得することに加えて、きめ細かいロールベースのアクセス制御（RBAC）ポリシーを定義することもできます。

4
dawud

各サーバー上の単一のIDファイルは、PCI、HIPAAなどのほとんどのセキュリティフレームワークに違反します。各ユーザーは独自のアカウントを必要とし、それらのアカウントは削除できる必要があります。

これを処理できる商用およびオープンソースのソリューションはたくさんあります。たとえば、Userify（私が作業している場所）、Universal Key Manager、SSH Key Boxなどです。

どちらを選択するかは、ニーズと予算が何であるか、そして重要だと思う機能によって異なります。たとえば、多くの集中システムは集中化されているため、たとえばLDAPサーバーがダウンしている場合、どのサーバーにもログインできない可能性があります。より高い信頼性と制御のために実際の操作を分散しながら、SSH権限を一元管理できることが重要です。

以下のSlantディスカッションも参照してください。

https://www.slant.co/topics/8010/~managers-for-ssh-keys

1
Jamieson Becker

ログインしているすべてのサーバーに公開鍵をコピーすることは、通常、SSHで行う方法です。あなたがやったことがジャンプスタートサーバーでプライベート/パブリックキーパーを作成し、パブリックキーをsshしたいホストの~/.ssh/authorized_keysファイルにコピーした場合、それは（部分的に） ）sshを介してリモートログインを保護するための受け入れられている方法。 sshをさらに保護するために考慮すべき他の事項は次のとおりです。

  • /etc/ssh/sshd_configを変更してPasswordAuthentication NoとPubkeyAuthentication yesを設定
  • /etc/ssh/sshd_configのLogLevelをVERBOSEに変更し、異常がないか/var/log/auth.logを監視します。
  • /etc/security/access.confを編集して、特定のIPからのユーザーによるログインのみを許可する
  • /etc/pam.d/loginを編集し、account required pam_access.soを設定して、access.confに加えた変更を有効にします

「サーバーごとに異なるキー」をデプロイすると、各サーバーの~/.ssh/authorized_keysに異なるpublicキーが必要になることを意味しているようです。この理由は不明ですが、必要な場合は、Jumpstartサーバー上に各行にホストを含​​むテキストファイルを作成します。 forループを使用してファイルを解析し、ssh-keygen -f $line_from_fileを実行して各ホストのキーペアを作成します。同じforループを使用して各ホストにsshし、~/.ssh/authorized_keysなどを使用してsed -iにpubkeyを追加することもできます。

1
Server Fault

バスティリオンを試す- https://www.bastillion.io/

インストールが簡単で、ユーザーは自分に割り当てられたプロファイルに基づいて自分のSSHキーを管理します。

https://www.bastillion.io/docs/using/keymanagement/

（開示：これは私が開発した製品です。これはオープンソースであり、AGPLの下で無料で使用できます。または、商用ライセンスを購入できます）

0
skavanagh