SSHキーは、SSHプロトコルにおけるアクセスクレデンシャルです。 その機能はユーザー名やパスワードに似ていますが、鍵は主に自動化されたプロセスや、システム管理者やパワーユーザーによるシングルサインオンの実装に使用されます。

SSH鍵は認証資格です

SSH (Secure Shell)は、ネットワーク、オペレーティングシステム、および設定を管理するために使用されます。 また、多くのファイル転送ツールや設定管理ツールの中にも入っています。

SSHキーは、現代のクラウドサービスやその他のコンピュータに依存したサービスを可能にし、費用対効果を高める自動化を可能にします。

機能的には、SSH鍵はパスワードに似ています。 アクセスを許可し、誰が何にアクセスできるかを制御します。 アイデンティティとアクセス管理においては、ユーザーアカウントやパスワードと同様のポリシー、プロビジョニング、および終了が必要です。

技術的には、鍵は公開鍵暗号システムを使った暗号鍵です。

技術的には、鍵は公開鍵暗号システムを使用した暗号鍵ですが、機能的には認証証明書であり、そのように管理する必要があります。

認証された鍵は、各システムにアクセスできる人を定義します

認証された鍵は、アクセスを許可する公開鍵です。

詳細については、認証されたキーに関する専用ページをご覧ください。

Identity key identified users and provide access

Identity keyは、SSHクライアントがSSHサーバーにログインする際に、自分自身を認証するために使用するプライベートキーです。

認証された鍵とアイデンティティキーを合わせてユーザーキーと呼びます。

認証された鍵とアイデンティティキーは、合わせてユーザーキーと呼ばれ、ホスト認証に使用されるホストキーとは対照的に、ユーザー認証に関連しています。 この場合、ユーザーは秘密鍵を持っていますが、その鍵に関連付けられた証明書も持っています。 この技術はTectia SSHとOpenSSHの両方でサポートされていますが、いくつかの違いがあります。

デバイス認証キー

ホストキーはサーバーを認証する

ホストキーはホスト、つまりコンピュータを認証するために使われます。 その目的は、中間者攻撃を防ぐことです。

証明書ベースのホスト認証は、大規模な組織では非常に魅力的な選択肢となります。

既知のホスト鍵

SSH のユニークな特徴のひとつは、デフォルトでは、最初の接続時にホストの鍵を信頼し、記憶することです。 1995年当時、ホストの鍵を集中的に管理するインフラは存在しませんでしたし、WebサーバーのSSL証明書を除けば現在（2017年）でも存在しませんので、これがSSHを草の根的に展開するための重要な差別化要因でした。

記憶されたホスト鍵は既知のホスト鍵と呼ばれ、OpenSSHではknown_hostsというファイルに保存されています。 ホスト鍵が変更されない限り、この方法は非常に簡単に使用でき、かなり良いセキュリティを提供します。 しかし、大規模な組織では、鍵が変更されると、既知のホストファイルを維持するのに非常に時間がかかります。 そのような場合には、ホスト鍵に証明書を使うことをお勧めします。 Tectia SSHはホスト用の標準的なX.509証明書をサポートしています。 OpenSSH は独自の証明書フォーマットを持っています。 標準ベースの証明書の利点は、どんな認証局 (CA) からでも発行してもらえることですが、OpenSSH の鍵には信頼できる CA が存在しません。

セッションキー

SSHのセッションキーは、接続中のデータの大部分を暗号化するために使われる暗号化キーです。 セッションキーは、接続中にネゴシエートされ、対称暗号化アルゴリズムとメッセージ認証コードアルゴリズムを用いてデータを保護します。

キーベース認証の設定方法

SSHにおけるキーベース認証は公開鍵認証と呼ばれています。 デフォルトの設定では、エンドユーザーが簡単に設定できます。

OpenSSHでの公開鍵認証の設定方法

SSHの鍵は通常、ユーザーのホームディレクトリ内の.sshサブディレクトリにあるauthorized_keysファイルに設定されます。 通常、システム管理者はまず ssh-keygenssh-copy-id ツールを使ってサーバーに認証された鍵としてインストールします。

私たちは、インタラクティブなアクセスに使われるすべての ID キーにパスフレーズを使うことを推奨します。

シングルサインオンのために鍵を ssh-agent に保存する

SSH には ssh-agent というプログラムが付属しており、これはユーザーの復号化された秘密鍵をメモリに保持し、ログインの認証に使うことができます。 このエージェントは、スマートカードやハードウェアセキュリティモジュール (HSM) にある鍵にアクセスするためにも使用できます。

SSHエージェントへの接続をサーバーに転送することで、そのサーバーからもシングルサインオンができるようになります。

エージェントへの接続をサーバーに転送し、そのサーバーからもシングルサインオンができるようにすることができます。 しかし、エージェント フォワーディングは、セキュリティの重要性が低い環境のパワー ユーザーにとっては、非常に便利な機能となります。

エージェント転送を有効にするには、次のようにします。 サーバの/etc/ssh/sshd_configでAllowAgentForwardingyesに設定し、クライアントの構成ファイル/etc/ssh/ssh_configでForwardAgentyesに設定します。

推奨される鍵のサイズ

NIST SP 800-57に従って鍵のサイズを選択することをお勧めします。 ssh-keygenツールで使用されているデフォルトのキー サイズは、一般的に許容できる強度のものです。

RSA鍵については、現在（2017年）ではおそらく2048ビットが良い選択でしょう。

RSA鍵については、現在（2017年）では2048ビットが良いでしょう。しかし、現在では多くの暗号学者がECDSA鍵への切り替えを推奨しており、大きな整数の因数分解の進歩により、近い将来または中期的にRSA鍵が脆弱になる可能性があると考えています。 ECDSAでは、384ビットや256ビットの鍵でもおそらく安全であるにもかかわらず、521ビット（正確には！）の鍵を使うことを推奨しています。

アイデンティティ キーの場所

アイデンティティ キーは通常、ユーザーの .ssh.ssh/ssh_id_rsa に保存されます。 デフォルトのIDキーファイル名はid_<algorithm>で始まります。 しかし、秘密鍵の作成時に任意のファイル名と任意の場所を指定することが可能で、そのパス名をSSHクライアントの-issh -i /home/ylo/secure/my-key [email protected]my-keyというファイルの秘密鍵を認証に使用します。

デフォルトのIDキーの場所は、/etc/ssh/ssh_configまたはユーザーの.ssh/configIdentityFileオプションを使用して設定することもできます。

認証された鍵の場所

ユーザーが鍵ベースの認証を使ってログインしようとしたとき、OpenSSH サーバーは認証された鍵を AuthorizedKeysFile オプションを使ってサーバー構成で指定されたディレクトリから探します。

しかし、認証された鍵がユーザのホームディレクトリに保存されているということは、ユーザが自分のアカウントへのログインを認証する新しい鍵を追加できるということです。 これは便利なことですが、ユーザーはこの鍵を友人や同僚に渡したり、ビットコインで売ったりすることができます (これは実際に起こったことです)。

認証された鍵をルートアカウントやサービスアカウントに追加すると、それをインストールした人が組織を離れた後でも、簡単に有効になります。

これらの理由から、ほとんどの大規模な組織では、認証されたキーをルートが所有する場所に移動し、制御されたプロビジョニングと終了のプロセスを確立したいと考えています。

Moving SSH keys to a root-owned location

原理的には、SSH キーをルート所有の場所に移動させるのは簡単です：

  1. 適切なルート所有のディレクトリを作成します。

  2. このディレクトリの下に、各ユーザー用のサブディレクトリを作成し、各ユーザーのauthorized_keys/etc/ssh/keys/<user>/authorized_keysに移動します。

  3. 最後に、AuthorizedKeysFile /etc/ssh/keys/%u/authorized_keys/etc/ssh/sshd_configに変更します。

しかし、実際には、特に大規模な環境では、これはそれほど単純ではありません。 ユーザ名はディレクトリ (例: Active Directory や LDAP) から取得することもあります。 多くの組織では OpenSSH のバージョンがまちまちで、非常に古いシステムや、標準的でない組み込みパスを持つカスタム SSH ビルドも含まれています。 大規模な環境では、この複雑さを隠すために Universal SSH Key Manager のような鍵管理ツールを使うことをお勧めします。

OpenSSH の秘密鍵の数に関する制限

OpenSSH サーバには、特定の鍵が認証に使えるかどうかをテストすることを、認証の試みとしてカウントするという機能 (私はこれをバグと呼んでいます) があります。 これは結果として、ユーザが .ssh-iMaxAuthTries セッションを調整することもできますが、これは完全な解決策ではなく、また、パスワード認証の試行回数を増やすことは望ましくありません。

SSHの鍵はどのようなものか

認証された鍵は次のようなものです：

ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBN+Mh3U/3We4VYtV1QmWUFIzFLTUeegl1Ao5/QGtCRGAZn8bxX9KlCrrWISIjSYAwCajIEGSPEZwPNMBoK8XD8Q= ylo@klar

ID鍵は次のようなものです：

-----BEGIN EC PRIVATE KEY-----MHcCAQEEIJWbvSW7h50HPwG+bWR3DXgQ6YhOxYbe0ifr1rRUvsUuoAoGCCqGSM49AwEHoUQDQgAE34yHdT/dZ7hVi1XVCZZQUjMUtNR56CXUCjn9Aa0JEYBmfxvFf0qUKutYhIiNJgDAJqMgQZI8RnA80wGgrxcPxA==-----END EC PRIVATE KEY-----

SSHの認証はどのように行われるのか

まず、認証された鍵は次のようになります。

SSHでの接続の初期化は次のようになります。

  • 使用するプロトコルのバージョンのネゴシエーション

  • 使用する暗号アルゴリズムやその他のオプションのネゴシエーション

  • 暗号化のための1回限りのセッションキーのネゴシエーション

    li

  • 残りのセッションを暗号化するための1回限りのセッションキーのネゴシエーション

  • そのホストキーを使用したサーバーホストの認証

  • パスワードを使用したユーザーの認証。 公開鍵認証などでユーザーを認証する。

    SSH Key - Authentication Using SSH Keys

    Public key authentication

    SSHにおける鍵を使った認証の仕組みを公開鍵認証といいます。 基本的に、いくつかのセッション固有のデータは、秘密のIDキーを使って署名されます。 この署名はサーバーに送られ、サーバーは署名に使われた鍵が認証された鍵として設定されているかどうかをチェックします。 その後、サーバーは認証された鍵の公開鍵を使用してデジタル署名を検証する。

    公開鍵認証の本質は、あるサーバーがパスワードを入力することなく別のサーバーにアクセスできることです。

    公開鍵認証で重要なのは、あるサーバーが別のサーバーにパスワードなしでアクセスできることです。この強力な機能により、ファイル転送（SFTPプロトコルを使用）や設定管理に広く使用されています。

    How common are SSH keys and what is the risk

    SSHキーは非常に一般的で広く使われていることがわかります。 多くの大規模な組織では、何の管理もせずに20年間も蓄積してきました。 典型的なFortune 500企業では、サーバーへのアクセスを許可する数百万個の鍵を持っています。 あるお客様のケースでは、500のアプリケーションと15,000のサーバを調査したところ、300万個の認証された鍵と75万個のユニークな鍵ペアが見つかりました。 また、この組織では、鍵を使ったログインが毎日500万回以上行われていました。

    ほとんどの大企業が数十万から数百万の鍵を持っていることがわかってきました。

    SSHキーを完全に排除する方法

    PrivX On-Demand Access Managerを使用すると、サーバーからSSHキーを完全に排除し、企業全体でポリシーベースのアクセス制御とセッションロギングを確立することができます。 また、鍵の管理に伴う管理者の負担がほとんどなくなり、自動化やシングルサインオンなどのメリットも得られます。

By: adminPosted on

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です