SSH公開鍵

暗号資産におけるSSH公開鍵とは？

SSH公開鍵はSSH鍵ペアの共有可能な半分であり、サーバーがリモートアクセスを許可する前に、ユーザーが対応する秘密鍵を保持していることを検証するために使われます。

暗号資産業界では、ノード運営者、バリデーター、マイニング運営者、インフラエンジニア、開発者がブロックチェーンソフトウェアを実行するサーバーへアクセスするためにSSHを使用することが多いため、SSH公開鍵は重要です。

SSHはSecure Shellの略で、安全なリモートログイン、コマンド実行、ファイル転送、サーバー管理に使用されるプロトコルです。公式のGitHub SSHドキュメントでは、SSHは安全でないネットワーク上で安全な通信チャネルを提供すると説明されています。

SSH公開鍵は、ウォレット公開鍵、ブロックチェーンアドレス、シードフレーズ、バリデーター署名鍵とは異なります。これはオンチェーンで暗号資産を使用する鍵ではなく、コンピューターおよびサーバーのアクセス制御認証情報です。

公開鍵は秘密鍵を明らかにしないため、通常は安全に共有できます。対応する秘密鍵はSSH認証時にユーザーのIDを証明するため、秘密に保つ必要があります。

公式のMicrosoft OpenSSHの鍵ベース認証ドキュメントでは、公開鍵はSSHサーバー上に配置され、秘密鍵を危険にさらすことなく共有できると説明されています。

簡単に言えば、SSH公開鍵は、通常のパスワードに依存せずにクリプトインフラ運営者がマシンへアクセスする際に役立つ、安全に共有可能なサーバーログインIDです。

暗号資産でSSH公開鍵が重要な理由

ブロックチェーンインフラはリモートのLinuxサーバーやクラウドサーバーを通じて管理されることが多いため、SSH公開鍵は重要です。

バリデーター運営者は、コンセンサスクライアントの更新、ログ確認、サービス再起動、証明書ローテーション、ディスク使用量の監視、OSへのパッチ適用にSSHを使用する場合があります。

フルノード運営者は、実行クライアントの管理、ネットワーク設定、ストレージ管理、RPCエンドポイントの保護にSSHを使用する場合があります。マイニング運営者は、プールサーバー、監視ツール、ファームウェアコントローラー、マイニング運用を支えるインフラの管理に使用する場合があります。

開発者は、コードのデプロイ、ソース管理プラットフォームへの接続、本番インフラへのアクセスにSSH鍵を使う場合があります。公式のEthereumノード実行ガイドでは、ノードおよびバリデーターの実行にはソフトウェア、クライアント、同期、API、運用設定が必要と説明されています。

これらのサーバーは価値あるクリプトインフラを制御する可能性があるため、アクセスセキュリティが弱いと重大な金銭的リスクになり得ます。パスワードログインは、ブルートフォース攻撃、パスワード使い回し、フィッシング、マルウェア、誤った共有により危険にさらされる可能性があります。

SSH鍵ベース認証は、非対称暗号を使用してパスワードへの依存を減らします。適切に管理されたSSH公開鍵は、クリプト運用における基本的かつ重要なインフラセキュリティ要素となり得ます。

SSH公開鍵認証の仕組み

SSH公開鍵認証は、対応する公開鍵と秘密鍵を使用して機能します。

公開鍵は、アクセスを許可すべきサーバーアカウントにコピーされます。秘密鍵は、ユーザーのローカルコンピューター、ハードウェアデバイス、または安全な鍵マネージャーに保管されます。

ユーザーがサーバーへ接続すると、SSHクライアントは秘密鍵をサーバーへ送信せずに、その秘密鍵を保有していることを証明します。サーバーはその証明を保存済み公開鍵と照合し、証明が有効でアカウント権限が正しければログインを許可します。

秘密鍵が保存済み公開鍵と一致しない場合、認証は失敗します。MicrosoftのOpenSSHドキュメントでは、鍵ベース認証中にSSHサーバーとクライアントがサーバー側公開鍵とクライアント側秘密鍵を照合すると説明されています。

このモデルは秘密鍵がネットワークを移動する必要がないため強力ですが、秘密鍵が盗まれると、対応する公開鍵が認可された場所に攻撃者がログインできる可能性があるため危険でもあります。

公開鍵と秘密鍵

SSH公開鍵とSSH秘密鍵は、鍵ペアとして同時に作成されます。

公開鍵は、サーバー、コードホスティングアカウント、ユーザーを認識する必要があるその他のシステムへコピーするよう設計されています。秘密鍵は、ユーザーのデバイスまたは安全な鍵ストレージ上で秘密に保つよう設計されています。

公式のOpenBSD ssh-keygenマニュアルでは、ssh-keygenはSSH認証鍵を作成し、秘密鍵と同じ名前に.pub拡張子を付けたファイルへ公開鍵を保存すると説明されています。

公開鍵だけを取得しても、通常、他者がユーザーとしてログインすることはできません。しかし、秘密鍵と必要なパスフレーズを取得した場合、公開鍵が信頼されているサーバーにユーザーとしてログインできる可能性があります。

そのため、公開鍵は共有できる一方、秘密鍵は高価値の秘密情報として保護する必要があります。クリプトインフラでは、SSH秘密鍵の盗難により、サーバー侵害、バリデーターの停止、設定改ざん、マルウェアのインストール、機密ファイルの盗難につながる可能性があります。

公開鍵はIDマーカーであり、秘密鍵はその証明です。秘密鍵をサーバー、チャットアプリ、チケットシステム、公開リポジトリ、共有ドキュメントにアップロードしてはいけません。

SSH公開鍵と暗号資産ウォレット公開鍵の違い

SSH公開鍵は、暗号資産ウォレットの公開鍵とは異なります。

SSH公開鍵はサーバー認証に使われます。ウォレット公開鍵はブロックチェーン暗号技術で使われ、アドレス、署名、資産所有に関連します。

SSH公開鍵はブロックチェーン上で暗号資産を受け取りません。ウォレット公開鍵またはそこから導出されたアドレスは、通常、SSH経由でサーバーにログインしません。

両方とも公開鍵暗号を使用しますが、別のシステムに属する概念です。混同すると重大なミスにつながる可能性があります。

ウォレットのシードフレーズをSSHツールに貼り付けないでください。バリデーター署名鍵を通常のSSH鍵として使用しないでください。インフラアクセス鍵は、ウォレット鍵、バリデーター鍵、出金鍵、APIキーと分離して保管してください。

SSH公開鍵とブロックチェーンアドレスの違い

SSH公開鍵はブロックチェーンアドレスではありません。

ブロックチェーンアドレスは通常、ウォレット公開鍵またはアカウント構造から導出された短い表現です。SSH公開鍵は通常、ユーザーまたはホストを認証するSSHソフトウェアで使用される、より長いテキスト文字列です。

ブロックチェーンアドレスは他者がトークンを送付したりオンチェーン活動を閲覧したりできるように共有できます。SSH公開鍵は、サーバー管理者がログインアクセスを許可できるように共有できます。

ブロックチェーンアドレスの共有は、公開オンチェーン履歴を確認できるため、金融上のプライバシーに影響する場合があります。SSH公開鍵の共有で明らかになる金融情報は通常少ないものの、インフラログ内で人物やデバイスを識別できる可能性があります。

ブロックチェーンアドレスは資産の送付先を示し、SSH公開鍵はどの秘密鍵がサーバーアカウントにアクセスできるかを証明します。いずれも慎重に扱うべきですが、異なる信頼関係のために使われます。

SSH公開鍵の形式

SSH公開鍵は通常、1行のテキストです。

多くの場合、ssh-ed25519、ecdsa-sha2-nistp256、ssh-rsaなどの鍵タイプで始まります。中央部分には長いエンコード済み鍵値があり、末尾にはユーザー名、メールアドレス、デバイス名、作成ラベルなどのコメントが含まれる場合があります。

コメントは後で人間が鍵を識別するのに役立ちますが、それ自体にセキュリティ機能はありません。公開鍵ファイルは多くの場合.pubで終わり、対応する秘密鍵ファイルは.pubを除いた類似の名前になります。

OpenBSD ssh-keygenマニュアルでは、公開鍵は秘密鍵と同じ名前に.pubサフィックスを付けたファイルに保存されると説明されています。ユーザーは、秘密鍵ファイルではなく.pubファイルをコピーしていることを常に確認してください。

authorized_keys

authorized_keysファイルは、特定のユーザーとしてログインを許可されたSSH公開鍵を一覧表示する、一般的なサーバー側ファイルです。

多くのUnix系システムでは、このファイルはユーザーの.sshディレクトリ内にあります。公開鍵をauthorized_keysに追加すると、権限およびSSHサーバー設定が許可する場合、その対応する秘密鍵で当該アカウントを認証できます。

このファイルは鍵ベース認証でログインできる人物を定義するため、非常に重要です。authorized_keysに残された忘れられた古い鍵は、隠れたバックドアになり得ます。誤ったユーザーアカウントに公開鍵をコピーすると、誤った権限へのアクセスを与える可能性があります。

rootアカウントのauthorized_keysファイルは、rootアクセスがサーバー全体を制御できるため、特に機密性が高いものです。

クリプトノード運営者はauthorized_keysを定期的に見直し、不要な鍵を削除すべきです。可能な場合は直接のrootログインではなく、sudoを持つ名前付きユーザーアカウントにアクセスを付与してください。適切なauthorized_keys管理は、秘密鍵が盗まれた場合の影響範囲を抑えるのに役立ちます。

ssh-keygen

ssh-keygenは、OpenSSHでSSH鍵ペアを作成・管理する標準ツールです。

OpenBSD ssh-keygenマニュアルでは、ssh-keygenはSSH認証鍵の生成、管理、変換を行うとされています。同マニュアルでは、鍵タイプを指定しない場合、ssh-keygenはデフォルトでEd25519鍵を生成すると説明されています。

Ed25519は、多くのSSH認証ワークフローで最新、コンパクト、効率的であるため、今日では一般的に使用されています。一部のシステムでは互換性のためにRSAまたはECDSA鍵もサポートされています。

古いアルゴリズムや短い鍵長は、環境およびポリシーにより推奨されない場合があります。鍵タイプを選ぶ際は、現在のOSおよびOpenSSHのガイダンスに従ってください。

鍵の作成時には、後で識別できる明確なコメントを付ける必要があります。クリプトインフラでは、validator-admin-laptop-2026やnode-maintenance-keyなどのコメントが監査を容易にする場合があります。識別できない鍵を本番サーバーで信頼し続けるべきではありません。

パスフレーズ

パスフレーズは、保存中の秘密鍵を暗号化または保護します。

OpenBSD ssh-keygenマニュアルでは、ssh-keygenは鍵生成時にパスフレーズを要求し、失われたパスフレーズは復元できないと説明されています。

パスフレーズは、秘密鍵ファイルがノートPCからコピーまたは盗難された場合に保護を追加します。パスフレーズがなければ、盗まれた秘密鍵を攻撃者が直ちに使える可能性があります。パスフレーズがあれば、攻撃者はそれも推測または盗難する必要があります。

これは脆弱なシステムを安全にするものではありませんが、防御を強化します。クリプトインフラ運営者は通常、重要なSSH秘密鍵を強力なパスフレーズで保護すべきです。

無人のパスフレーズ入力によりスクリプトが停止する可能性があるため、自動化システムには特別な対応が必要な場合があります。自動化には、状況に応じて制限付き鍵、限定権限、コマンド制限、短命証明書、安全なシークレット管理ツールを使用してください。

パスフレーズは、アクセスレビュー、最小権限、鍵ローテーションの代替ではありません。

ssh-agent

ssh-agentは、復号済みの秘密鍵をメモリに保持し、ユーザーが接続ごとにパスフレーズを入力しなくて済むようにするツールです。

MicrosoftのOpenSSHドキュメントでは、鍵ベース認証ワークフロー中に秘密鍵を安全に保管するツールとしてssh-agentとssh-addが挙げられています。

ssh-agentは利便性を高めますが、エージェントフォワーディングまたはローカルマシンのセキュリティが弱い場合、リスクも生じます。エージェントフォワーディングにより、ユーザーはローカルエージェントを使用して1つのサーバー経由で別のサーバーに接続できます。

これは管理者には便利ですが、中間サーバーが侵害されると認証の機会を露出する可能性があります。クリプト運営者は、バリデーターおよびノードインフラで不必要なエージェントフォワーディングを避けるべきです。

必要な場合は、信頼できるホストと限定的なセッションでのみ使用してください。多くの場合、安全な管理用ワークステーションから直接接続するか、堅牢化された踏み台ホストを利用する方が望ましい方法です。

ssh-agentは有用ですが、セキュリティ境界の一部として扱う必要があります。侵害されたワークステーションは、エージェントに読み込まれたすべてのSSH IDを侵害する可能性があります。

バリデーターノード向けSSH公開鍵

バリデーターノードでは、運営者がソフトウェア更新、稼働状況の監視、ログ確認、インシデント対応を行う必要があるため、安全なサーバーアクセスが必要です。

SSH公開鍵により、攻撃者の標的となる可能性があるサーバーで、パスワードベースのログインを避けられます。

Ethereumのソロステーカーは、実行クライアント、コンセンサスクライアント、バリデータークライアント、ファイアウォール、監視エージェント、システムサービスの管理にSSHを使う場合があります。

Ethereumノードガイドでは、自身のバリデーターを運用することはネットワークを支援する最もトラストレスな方法ですが、インフラとバリデーターデポジットが必要であると説明されています。バリデーターの停止は報酬を減少させる可能性があるため、このインフラは慎重に保護すべきです。

侵害されたバリデーターサーバーは、アテステーションの見逃し、設定ミス、運用の中断につながる可能性があります。SSHアクセスは、出金認証情報が別の安全な場所に保管されている場合、通常はそれを直接制御できません。

ただし、サーバー侵害はマルウェア、データ盗難、設定変更、鍵の発見を通じて重大なリスクを生じさせる可能性があります。SSH鍵はバリデーター署名鍵および出金鍵と分離してください。インフラへのアクセスを資産カストディと同じセキュリティドメインとして扱ってはいけません。

フルノード向けSSH公開鍵

フルノードもSSH公開鍵認証の恩恵を受けます。

フルノードはブロックチェーンデータを保存し、ローカルAPIを公開し、ウォレットにサービスを提供し、トランザクションを検証し、アプリケーションを支援する場合があります。

Ethereumノードガイドでは、RPCエンドポイントを公開すると、設定が誤っている場合にローカルネットワークやパブリックIPアドレスから到達可能になる可能性があると警告されています。SSHアクセスは、これらのノード設定およびファイアウォールルールの管理によく使用されます。

攻撃者がフルノードへのSSHアクセスを得ると、RPC設定の変更、設定ファイルの閲覧、サービス妨害、トラフィックのリダイレクトを行える可能性があります。フルノードはウォレットの秘密鍵を保有していない場合でも、セキュリティ上重要な場合があります。

例えば、侵害されたノードはユーザーに不正なデータを提供し、アプリケーションを妨害し、内部ネットワークの詳細を露出する可能性があります。SSH公開鍵アクセスは、必要な管理者に限定してください。

請負業者、従業員、デバイス、スクリプトにアクセスが不要になった後は、古い鍵を削除してください。フルノードはクリプトの信頼モデルの一部であるため、サーバーのアクセス制御は重要です。

クリプト開発者向けSSH公開鍵

クリプト開発者は、コードホスティング、デプロイ、テスト環境、サーバー管理にSSH公開鍵を使用します。

Gitプラットフォームでは、ユーザーがSSH公開鍵を追加することで、毎回パスワードを入力せずにリポジトリをpushおよびpullできる場合があります。公式のSSH鍵の生成とssh-agentへの追加に関するGitHubガイドでは、新しいSSH鍵を生成しssh-agentに追加する方法が説明されています。

ソースコード、デプロイスクリプト、インフラリポジトリは高い機密性を持つ場合があるため、これはクリプトチームにとって重要です。侵害された開発者SSH鍵により、スマートコントラクトコード、デプロイパイプライン、ビルドシステム、本番サーバーが露出する可能性があります。

開発者は、個人作業、会社インフラ、本番システム、自動デプロイ用に別々のSSH鍵を使用すべきです。デバイスの交換やチームメンバーの離脱時には、コードプラットフォームから古い鍵を削除してください。

秘密鍵をリポジトリにコミットしないでください。また、プロジェクトでより強いソース管理の完全性が必要な場合は、署名済みコミットなどの検証方法を使用してください。SSH鍵は、単なるサーバーログインの利便性ではなく、ソフトウェアサプライチェーンセキュリティの一部です。

SSH公開鍵とマイニングインフラ

マイニング運用では、サーバー、監視システム、プロキシ、ファームウェアツール、バックエンドインフラの管理にSSH鍵を使用することが多くあります。

マイニングデバイス自体が別の管理システムを使用する場合でも、支援サーバーはSSHに依存することがあります。盗まれたSSH秘密鍵により、攻撃者がマイニング運用を妨害したり、設定データをリダイレクトしたりできる可能性があります。

Proof of Workのマイナーでは、マシンが電力を消費し続ける、または有用な作業の提出を停止するため、ダウンタイムは直接的な収益損失を意味する場合があります。

マイニング運営者は、監視、デプロイ、緊急アクセス、自動化に別々の鍵を使用すべきです。マイニングフリート内のすべてのサーバーで1つの秘密鍵を使用することは避けてください。

過度に使い回された1つの鍵は、侵害時に大きな影響範囲を生みます。アクセスは最小権限に従うべきであり、各鍵にはその役割に必要なアクセスのみを許可すべきです。

マイニングインフラはウォレット資金を保有しない場合でも、収益および運用継続性に影響する可能性があります。したがって、SSH公開鍵の管理はマイニング運用セキュリティの一部です。

SSH公開鍵とクラウドサーバー

多くのクリプトノードおよびバリデーターは、仮想プライベートサーバー、ベアメタルホスティング、クラウドインフラ上で稼働しています。

クラウドプロバイダーは新しいサーバーの作成時にSSH公開鍵のアップロードを求めることがよくあります。プロバイダーはその公開鍵をインストールし、サーバーの起動後にユーザーが安全にログインできるようにします。

これは、パスワードをメール送信したり、デフォルトパスワードに依存したりするより安全です。しかし、公開鍵をアップロードしただけでサーバー全体が自動的に安全になるわけではありません。

秘密鍵は引き続き保護する必要があります。サーバーには引き続きパッチを適用する必要があり、ファイアウォールルールも慎重に設定する必要があります。RPCポート、バリデーターAPI、ダッシュボード、管理パネルは、運営者がリスクを理解していない限り公開すべきではありません。

SSH公開鍵は、クラウドサーバーの堅牢化の一部であり、セキュリティ計画全体ではありません。

ホスト鍵とユーザー鍵

SSHでは、ユーザー鍵とホスト鍵の両方を使用します。

ユーザー鍵は、ログインを試みる人物またはシステムを認証します。ホスト鍵は、サーバーをクライアントに対して認証します。

ユーザーが初めてサーバーに接続すると、SSHクライアントはサーバーのホスト鍵フィンガープリントを信頼するか尋ねる場合があります。この確認は、攻撃者がサーバーを装う中間者攻撃の防止に役立ちます。

ユーザー公開鍵はサーバーのauthorized_keysに入ります。ホスト公開鍵はクライアントがサーバーIDを検証するために使われ、受け入れ後は多くの場合known_hostsに保存されます。

クリプト運営者はホスト鍵の警告を無視すべきではありません。ホスト鍵の変更はサーバー再構築後には問題ない場合もありますが、傍受やサーバー置換を示す場合もあります。

ユーザー鍵はログインできる人物を管理し、ホスト鍵はユーザーがどのサーバーに接続しているかを証明するのに役立ちます。

フィンガープリント

SSHフィンガープリントは、検証に使用される公開鍵の短い表現です。

フィンガープリントにより、長い公開鍵文字列全体を読むことなく鍵を比較できます。OpenBSD ssh-keygenマニュアルには鍵フィンガープリントを表示するオプションが含まれています。

サーバーに鍵を追加する際、ユーザーは信頼できる情報源のフィンガープリントと比較して、正しい鍵がインストールされることを確認できます。サーバー接続時には、ホスト鍵フィンガープリントを既知の正常な値と比較できます。

誤った鍵は、誤った人物にアクセスを与えたり、運営者を誤ったサーバーへ接続させたりする可能性があるため、クリプトインフラでは重要です。フィンガープリントは、チケット、アクセス制御システム、セキュリティレビューで鍵が承認されるチームにおいて特に有用です。

公開鍵コメントは容易に変更できますが、フィンガープリントは鍵自体から導出されます。運営者はコメントだけではなく、フィンガープリントをID確認に使用すべきです。適切なフィンガープリント検証は、鍵のプロビジョニングおよびインシデント対応時のミスを減らします。

鍵ローテーション

鍵ローテーションとは、古いSSH鍵ペアを新しいものに置き換え、認可済みシステムから古い公開鍵を削除することです。

ノートPCの紛失、従業員の離職、請負業者の業務終了、鍵の露出の可能性、アルゴリズムの陳腐化が発生した場合、ローテーションは重要です。NIST SP 800-57鍵管理ガイダンスは、暗号鍵マテリアルおよび鍵管理の問題に関する一般的なガイダンスを提供しています。

クリプトチームは、緊急事態が起きる前に鍵ローテーションを計画すべきです。チームは各公開鍵がどこにインストールされているか、誰が各鍵を所有するか、どのサーバー、リポジトリ、デプロイシステムが各鍵を信頼しているかを把握する必要があります。

インベントリがなければ、古いSSH公開鍵は何年も有効なままになる可能性があります。これは不要な攻撃対象領域を生みます。適切な鍵ローテーションにより、SSH鍵は忘れられたファイルではなく、管理された認証情報になります。

鍵インベントリ

鍵インベントリとは、SSH公開鍵、所有者、用途、認可されたサーバー、作成日、削除日の記録です。

SSHアクセス管理に関するNISTIR 7966レポートはSSHユーザー鍵の管理に焦点を当て、SSHベースのアクセスにはプロビジョニング、終了、監視のプロセスが必要であると説明しています。

SSHアクセスは高度な権限を伴う可能性があるため、これはクリプト企業、バリデーター、インフラチームに特に関係します。鍵インベントリでは、各サーバーに誰がアクセスできるか、そのアクセスが存在する理由、いつアクセスを終了すべきかを明らかにする必要があります。

また、その鍵が人、ジョブの自動化、デプロイパイプライン、緊急アカウントのどれに属するかを記録すべきです。インベントリがなければ、誰も古い鍵を自信を持って削除できません。削除されなければ、古い鍵は恒久的な隠れたアクセスとなります。

強力なSSH公開鍵管理は、どの鍵が存在するかを把握することから始まります。

最小権限

最小権限とは、各SSH鍵にその目的に必要なアクセスのみを付与することです。

監視鍵は、メトリクスの読み取りだけが必要であればrootアクセスを持つべきではありません。デプロイ鍵は、資産を出金したり、バリデーター鍵を編集したり、無関係なシークレットを読み取ったりできるべきではありません。

請負業者の鍵はプロジェクト終了時に期限切れとなるべきです。自動化鍵は、可能な場合、必要なコマンドまたはディレクトリに制限すべきです。

1つの管理鍵をどこでも使うことは便利ですが、高いリスクを生みます。その秘密鍵が侵害された場合、信頼するすべてのサーバーが露出する可能性があります。

クリプトインフラは、SSHアクセスを権限付き制御システムとして扱うべきです。異なる役割では異なる鍵を使用し、テスト、ステージング、本番などの異なる環境では異なるアクセスルールを使用すべきです。

SSH公開鍵とrootログイン

rootログインはサーバーへの直接的な管理者アクセスを提供します。

直接のroot SSHログインは、ログインに成功した場合、攻撃者に直ちに完全な制御を与えるため危険になり得ます。多くの運営者は直接のrootログインを無効化し、代わりにsudoを使用する名前付きユーザーアカウントを利用します。

これにより、管理コマンドを特定のアカウントに関連付けられるため、説明責任を改善できます。また、rootユーザーを狙う自動攻撃のリスクを下げる可能性があります。

クリプトノードおよびバリデーターサーバーでは、直接のrootアクセスを慎重に制限すべきです。名前付き管理者アカウントには、実際の運営者に必要なSSH公開鍵だけを付与してください。

サーバー監査中に古いroot authorized_keysエントリを削除してください。緊急アクセスは即興で用意するのではなく、文書化して保護すべきです。rootアクセスはウォレット資金を直接使用できない場合でも、ブロックチェーンインフラを妨害できるほど強力です。

SSH公開鍵とパスワードログイン

SSH公開鍵認証は、パスワードログインを削減または無効化するためによく使用されます。

MicrosoftのOpenSSHドキュメントでは、システムがドメインまたはクラウド環境をまたいで運用される場合、ユーザー名とパスワード認証はブルートフォース侵入に対して脆弱になり得るとされています。

インターネットに公開されたサーバーでは、パスワードログインが継続的な自動推測攻撃を招くことがあります。鍵ベース認証では、攻撃者に単なる推測済みパスワードではなく秘密鍵が必要となるため、これらの攻撃の効果を低下させる可能性があります。

ただし、鍵ベース認証は万能ではありません。秘密鍵が盗まれた、暗号化されていない、またはあらゆる場所で使い回されている場合、リスクは深刻になります。

適切な設定には、SSH鍵、パスワードログインの無効化、直接rootログインの禁止、ファイアウォールルール、アップデート管理、監視が含まれることが多くあります。一部のチームはVPN、踏み台ホスト、ハードウェアにより保護された鍵、証明書ベースのSSHも使用します。

攻撃者はパスワードと鍵の両方を標的にする可能性があるため、クリプトインフラでは多層防御を使用すべきです。パスワードログインの無効化は有用ですが、鍵のライフサイクル管理は依然として不可欠です。

ハードウェアにより保護されたSSH鍵

ハードウェアにより保護されたSSH鍵は、秘密鍵マテリアルをハードウェア認証器またはセキュリティデバイスに保存します。

これにより、マルウェアがノートPCから秘密鍵ファイルを単純にコピーする可能性を低下させられます。最新のOpenSSHは、互換性のある認証器をサポートする環境で、ecdsa-skやed25519-skなどのセキュリティ鍵タイプをサポートしています。

OpenBSD ssh-keygenマニュアルでは、サポート対象の鍵生成オプションとしてセキュリティ鍵タイプが挙げられています。サーバーアクセスは高度に機密となる可能性があるため、ハードウェアにより保護されたSSH鍵はクリプトインフラ管理者に役立つ場合があります。

一方で、デバイス紛失時には復旧と鍵交換が必要になるため、運用計画も必要です。チームは1人のハードウェア鍵に依存しない緊急アクセス手順を維持すべきです。

ハードウェア鍵は、適切なインベントリ、役割分離、古い公開鍵の削除と組み合わせることで最も効果を発揮します。正規のログイン後に実行される悪意のあるコマンドなど、すべての攻撃を防ぐわけではありません。より広範なセキュリティシステムにおける1つの強力な管理策として理解するのが適切です。

SSH証明書

SSH証明書は、より一元的で時間制限付きのアクセス管理を支援できる、署名済みSSH公開鍵です。

各ユーザーの公開鍵をすべてのサーバーにコピーする代わりに、サーバーは認証局を信頼し、その認証局が署名したユーザー証明書を受け入れることができます。OpenBSD ssh-keygenマニュアルには、認証局鍵で証明書IDに署名するサポートが含まれています。

SSH証明書は、大規模なクリプトチームがアクセスをより整理して管理するのに役立つ場合があります。エンジニア、請負業者、緊急対応者、自動化に短期間のアクセスを付与できます。また、忘れられたauthorized_keysエントリの問題を減らす可能性があります。

ただし、認証局鍵を慎重に保護する必要があります。認証局鍵が侵害された場合、攻撃者が信頼されるアクセス証明書を発行できる可能性があります。

小規模チームは基本的なauthorized_keysファイルを使用する場合がありますが、大規模チームでは証明書ベースのアクセスが有益な場合があります。最適な設計は、チーム規模、インフラ規模、セキュリティ成熟度によって異なります。

SSH公開鍵と自動化

自動化では、デプロイ、バックアップ、監視、ファイル転送、サーバー間操作にSSH鍵を使用することが多くあります。

自動SSHアクセスは、人間が毎回パスフレーズを入力せずに実行される可能性があるため強力です。そのため、制限されていない自動化鍵は高リスクです。

自動化鍵を無関係なタスク間で使い回すべきではありません。1つのコマンドのみを実行する必要がある場合、対話型シェルアクセスを持つべきではありません。自動化ジョブが廃止された後も有効なままであってはいけません。

クリプトチームは、バリデーター、ノード、監視アラート、デプロイスクリプトに接続された自動化を特に慎重に扱うべきです。侵害されたデプロイ鍵は、多数のマシンに不正なソフトウェアをデプロイしたり、設定を変更したりする可能性があります。

制限付き鍵は、1つのコンポーネントが侵害された際の損害を抑える場合があります。自動化により、鍵管理の重要性は低下するのではなく高まります。

SSH公開鍵のセキュリティベストプラクティス

OSおよびインフラでサポートされる最新の鍵タイプを使用してください。

実用的な場合は、強力なパスフレーズで秘密鍵を保護してください。

役割、デバイス、環境ごとに別々の鍵を使用してください。

authorized_keysファイルおよびコードホスティングアカウントから古い公開鍵を削除してください。

安全な鍵ベースの復旧計画がある場合、インターネットに公開されたサーバーでパスワードログインを無効化してください。

強い理由と追加の管理策がない限り、直接のroot SSHログインを避けてください。

人間用および自動化用の鍵に最小権限を適用してください。

鍵、所有者、用途、有効期限のインベントリを維持してください。

警告を盲目的に受け入れるのではなく、ホスト鍵フィンガープリントを検証してください。

秘密鍵を、強力な暗号化とアクセス制御なしに、公開リポジトリ、共有チャット、スクリーンショット、クラウドフォルダーに保存しないでください。

SSH公開鍵でよくあるミス

よくあるミスには、公開鍵ではなく秘密鍵をコピーすること、すべてのサーバーおよびすべての役割で同じSSH鍵を使うこと、人物またはデバイスにアクセスが不要になった後もauthorized_keysに古い公開鍵を残すことが含まれます。

ノートPCに保管する重要な秘密鍵にパスフレーズを設定しないこと、リスクを理解せずにどこでもエージェントフォワーディングを有効化すること、フィンガープリントを確認せず未知のホスト鍵プロンプトを信頼することも問題です。

自動化鍵に狭いコマンドだけで十分なのに完全なシェルアクセスを与えること、SSH公開鍵と暗号資産ウォレット公開鍵を混同すること、バリデーターのシークレット、ウォレット鍵、SSH鍵を不十分に保護された同じサーバーに保管することも避けるべきです。

公開鍵だけで本番ブロックチェーンサーバーを安全にできると考えることも誤りです。

SSH公開鍵のメリット

SSH公開鍵の第1のメリットは、単純なパスワードのみのアクセスより強力なリモートログインセキュリティです。

第2のメリットは、ブルートフォースによるパスワード推測への露出を減らせることです。

第3のメリットは、定期的な管理が必要なサーバーのアクセス制御を容易にできることです。

第4のメリットは、開発者ワークフロー、ソース管理システム、デプロイツール、クラウドサーバーとの互換性です。

第5のメリットは、パスフレーズ、エージェント、ハードウェア鍵、証明書をより強力な管理に利用できることです。

第6のメリットは、人物および役割ごとに別々の鍵を使用することで監査可能性を高められることです。

第7のメリットは、鍵を適切に管理した場合にクリプトインフラ運用をより安全にできることです。

これらのメリットは、公開鍵をインベントリ化、レビュー、ローテーションし、不要になったときに削除することで最も大きくなります。SSH公開鍵の作成は簡単ですが、適切な管理は継続的な責任です。クリプトチームにとっての利点は、利便性だけでなく運用リスクの低減でもあります。

SSH公開鍵のリスクと制限

第1のリスクは秘密鍵の盗難です。攻撃者が保護されていない秘密鍵を盗むと、対応する公開鍵がサーバーへの侵入経路になる可能性があります。

第2のリスクは鍵の無秩序な増加です。これは、公開鍵が多数のシステムにコピーされ、どこで信頼されているか誰も分からなくなった状態です。

第3のリスクは古いアクセス権です。人物、デバイス、自動化ジョブにアクセスが不要になった後も古い公開鍵が認可されたままである場合に発生します。

第4のリスクは過剰な権限です。rootアクセスを持つ鍵は、狭いタスクに制限された鍵よりはるかに大きな損害を与える可能性があります。

第5のリスクはワークステーションのセキュリティが弱いことです。安全なサーバーでも、感染した管理者用ノートPCから鍵が盗まれることで侵害される可能性があります。

第6のリスクは、SSH鍵、ウォレット鍵、APIキー、バリデーター鍵に関する人為的な混同です。SSH公開鍵は有用ですが、特権的な認証情報として管理する必要があります。

SSH公開鍵の設定を評価する方法

まず、認可されたすべての公開鍵に既知の所有者がいることを確認してください。次に、すべての鍵に明確な用途があることを確認してください。

各鍵が現在も必要か確認し、秘密鍵がパスフレーズ、ハードウェアデバイス、安全な鍵マネージャーで保護されているかを確認してください。

鍵が必要以上のサーバーアクセスを持っていないか、rootログインが無効化または強く管理されているか、適切な場所でパスワードログインが無効化されているかを確認してください。

ホスト鍵フィンガープリントが検証され、known_hostsの警告が調査されているかも確認してください。人員変更、デバイス交換、自動化変更後に古い鍵が削除されているかを確認してください。

健全なSSH設定とは、アクセスを説明、監査、迅速に取り消すことができる設定です。

SSH公開鍵とインシデント対応

SSH秘密鍵が侵害された可能性がある場合、対応する公開鍵を信頼しているすべてのサーバーおよびサービスから削除する必要があります。

ユーザーはクリーンなデバイスで新しい鍵ペアを生成すべきです。影響を受けたサーバーでは、不正ログイン、変更されたファイル、新規ユーザー、変更されたauthorized_keysファイル、マルウェア、予期しないサービスを確認すべきです。

バリデーターおよびノード運営者は、クライアント設定、ファイアウォールルール、RPC露出、監視アラート、サービスログも確認すべきです。本番バリデーターサーバーが侵害された場合、バリデーター署名鍵、スラッシング保護ファイル、出金関連マテリアルが露出した可能性も検討すべきです。

侵害されたSSH鍵は単なるログイン問題ではなく、完全なインフラインシデントになり得ます。チームは緊急事態の前に、文書化されたSSH鍵失効プロセスを用意すべきです。

鍵インベントリがあれば、公開鍵を削除すべき場所をチームが把握できるため、インシデント対応は迅速になります。侵害された鍵を早く失効させるほど、損害が生じ得る期間は短くなります。

FAQ

SSH公開鍵とは何ですか？

SSH公開鍵は、サーバーがユーザーによる対応する秘密鍵の保有を検証するために使う、SSH鍵ペアの共有可能な部分です。

SSH公開鍵は共有しても安全ですか？

はい。SSH公開鍵は通常共有しても安全ですが、対応する秘密鍵は秘密に保つ必要があります。

SSH公開鍵は暗号資産ウォレット公開鍵と同じですか？

いいえ。SSH公開鍵はサーバー認証に使われ、暗号資産ウォレット公開鍵はブロックチェーンの署名およびアドレス生成に使われます。

なぜクリプトバリデーターはSSH公開鍵を使用するのですか？

クリプトバリデーターは、バリデーター、ノード、監視、メンテナンス用ソフトウェアを実行するリモートサーバーに安全にアクセスするためにSSH公開鍵を使用します。

authorized_keysとは何ですか？

authorized_keysは、特定のユーザーアカウントへのログインを許可されたSSH公開鍵を一覧表示するサーバー側ファイルです。

SSH秘密鍵を盗まれた場合はどうなりますか？

SSH秘密鍵が盗まれると、特に強力なパスフレーズまたはハードウェア保護がない場合、攻撃者が対応する公開鍵を認可したサーバーにログインできる可能性があります。

すべてのクリプトサーバーに1つのSSH鍵を使用すべきですか？

いいえ。役割、デバイス、環境ごとに別々のSSH鍵を使用すると、1つの鍵が侵害された場合の損害を抑えられます。

SSH公開鍵は暗号資産資金を管理しますか？

いいえ。SSH公開鍵は暗号資産資金を直接管理しませんが、クリプトインフラを支えるサーバーへのアクセスを管理する場合があります。

SSH公開鍵を削除できますか？

はい。authorized_keysまたはサービスアカウントからSSH公開鍵を削除すると、そのシステム上で対応する秘密鍵のアクセスは取り消されます。

最適なSSH鍵タイプは何ですか？

最適な鍵タイプは環境により異なりますが、最新のOpenSSHではEd25519およびセキュリティ鍵オプションが一般的にサポートされており、互換性要件によっては他のサポート対象鍵タイプが必要になる場合があります。

まとめ

SSH公開鍵は、対応する秘密鍵を保有する者にサーバーアクセスを許可するために使われる、共有可能な認証情報です。

暗号資産分野では、バリデーター、フルノード、マイニングインフラ、クラウドサーバー、デプロイパイプライン、開発者システムがSSHアクセスに依存することが多いため、SSH公開鍵は重要です。

SSH公開鍵は、ウォレット公開鍵、ブロックチェーンアドレス、シードフレーズ、バリデーター署名鍵、出金認証情報ではありません。直接的なオンチェーン資産所有ではなく、インフラアクセス制御に属するものです。

しかし、SSH鍵の不適切な管理は重大なクリプトリスクを生む可能性があります。サーバー侵害により、バリデーターの妨害、ノード設定の露出、デプロイの改ざん、監視システムの弱体化が起こる可能性があるためです。

適切なSSH公開鍵の運用には、秘密鍵の保護、パスフレーズまたはハードウェアにより保護された鍵の使用、rootアクセスの制限、安全な場合のパスワードログイン無効化、鍵インベントリの維持、鍵ローテーション、古いアクセスの削除が含まれます。

チームは、人間用の鍵、自動化鍵、バリデーター鍵、ウォレット鍵、APIキーも分離すべきです。公開鍵はアクセス設定のために共有できますが、秘密鍵を共有またはアップロードしてはいけません。

初心者にとってSSH公開鍵は、サーバーログインにおける公開IDとして理解するのが最も分かりやすいでしょう。上級のクリプト運営者にとっては、ポリシー、監視、最小権限、インシデント対応を通じて管理すべき特権的なインフラ認証情報です。

暗号資産用語集の文脈では、SSH Public Keyとは、ブロックチェーンインフラを実行または支援する可能性があるシステムへの安全なリモートアクセスを認可するために使用されるSSH認証鍵ペアの公開部分を意味します。

重要なポイントは、SSH公開鍵は適切に管理すればクリプトインフラのセキュリティを改善しますが、秘密鍵の盗難、古い公開鍵の放置、過度に広い権限により危険なアクセス経路にもなり得ることです。