SSH 鍵 - 版の履歴

Kusanaginoturugi: Category:セキュアシェル

2024-08-16T09:38:23Z

← 古い版		2024年8月16日 (金) 18:38時点における版
1行目:		1行目:
	[[Category:~~Secure Shell~~]]		[[Category:セキュアシェル]]
	[[en:SSH keys]]		[[en:SSH keys]]
	[[es:SSH keys]]		[[es:SSH keys]]

Kusanaginoturugi: 校正（でき・出来）

2024-07-10T11:20:44Z

校正（でき・出来）

← 古い版		2024年7月10日 (水) 20:20時点における版
329行目:		329行目:

	===Keychain===		===Keychain===
	[http://www.funtoo.org/Keychain Keychain] は出来る限りユーザーの手を煩わせることなく SSH 鍵の管理を楽にするために作られたプログラムです。''ssh-agent'' と ''ssh-add'' の両方を動かすシェルスクリプトとして実装されています。Keychain の特徴として、複数のログインセッションで単一の ''ssh-agent'' プロセスを維持することができます。したがって、パスフレーズを入力するのはマシンを起動したときだけで済みます。		[http://www.funtoo.org/Keychain Keychain] はできる限りユーザーの手を煩わせることなく SSH 鍵の管理を楽にするために作られたプログラムです。''ssh-agent'' と ''ssh-add'' の両方を動かすシェルスクリプトとして実装されています。Keychain の特徴として、複数のログインセッションで単一の ''ssh-agent'' プロセスを維持することができます。したがって、パスフレーズを入力するのはマシンを起動したときだけで済みます。

	==== インストール ====		==== インストール ====

Kgx: /* トラブルシューティング */ エージェントが操作を拒否しましたを翻訳して追加

2024-01-21T09:02:42Z

トラブルシューティング: エージェントが操作を拒否しましたを翻訳して追加

← 古い版		2024年1月21日 (日) 18:02時点における版
519行目:		519行目:
	$ chmod 600 ~/.ssh/authorized_keys		$ chmod 600 ~/.ssh/authorized_keys

	リモートマシンの場合は、ターゲットユーザーのホームディレクトリに正しいアクセス許可があることも確認します（グループなどが書き込み可能であってはなりません）。		リモートマシンの場合は、ターゲットユーザーのホームディレクトリに正しいアクセス許可があることも確認します(グループなどが書き込み可能であってはなりません)。

	$ chmod go-w /home/target_user		$ chmod go-w /home/target_user
533行目:		533行目:

	$ ssh -i id_rsa_server user@server		$ ssh -i id_rsa_server user@server

			=== エージェントが操作を拒否しました ===

			秘密鍵にパスワードが必要な場合 (または、たとえば PIN 付きのハードウェアキーがある場合)、ssh-agent にパスワードが提供されていない場合、{{ic\|ssh}} は失敗します:

			sign_and_send_pubkey: signing failed for ECDSA-SK ''user''@''host'' from agent: agent refused operation

			この潜在的な原因の 1 つは、ssh-agent がパスワードの入力を要求できないことです。ssh-agent がディスプレイサーバー ({{ic\|DISPLAY}} 環境変数経由) または TTY にアクセスできることを確認します。

			ハードウェア認証システムを使用している場合、別の原因としては、キーの故障またはプラグが抜けていることが考えられます。

			現在、{{ic\|-O verify-required}} で作成された ED25519-sk や ECDSA-SK などの認証キーを使用すると、"agent refused operation" エラーが発生する未解決の [https://bugzilla.mindrot.org/show_bug.cgi?id=3572 バグ] が存在します。この問題を回避するには、{{ic\|1=-o IdentityAgent=none}} オプションを {{ic\|ssh}} コマンドに使用するか、関連するホストの {{ic\|ssh_config}} ファイルに追加します。

			Host myserver.tld
			IdentityAgent none

	==参照==		==参照==

Kgx: /* ssh エージェントの転送 */

2024-01-21T08:56:51Z

ssh エージェントの転送

← 古い版		2024年1月21日 (日) 17:56時点における版
296行目:		296行目:

	ローカルの {{ic\|ssh-agent}} をリモートに [[OpenSSH#エージェントフォワーディング\|転送]] するとき (たとえば、コマンドライン引数 {{ic\|ssh -A remote}} または設定ファイル内の {{ic\|ForwardAgent yes を介して)}}、リモートマシンが環境変数 {{ic\|SSH_AUTH_SOCK}} を上書きしないことが重要です。したがって、リモートマシンが前述の [[#Start ssh-agent with systemd user\|systemd ユニット]] を使用してエージェントを起動する場合、ユーザーが SSH 経由でログインするときに環境に {{ic\|SSH_AUTH_SOCK}} を設定しないでください。そうしないと、転送が失敗し、リモートマシン上で {{ic\|ssh-add -l}} を使用して既存のキーを確認するときにエラー (例:{{ic\|The agent has no identities}}) が表示される可能性があります。		ローカルの {{ic\|ssh-agent}} をリモートに [[OpenSSH#エージェントフォワーディング\|転送]] するとき (たとえば、コマンドライン引数 {{ic\|ssh -A remote}} または設定ファイル内の {{ic\|ForwardAgent yes を介して)}}、リモートマシンが環境変数 {{ic\|SSH_AUTH_SOCK}} を上書きしないことが重要です。したがって、リモートマシンが前述の [[#Start ssh-agent with systemd user\|systemd ユニット]] を使用してエージェントを起動する場合、ユーザーが SSH 経由でログインするときに環境に {{ic\|SSH_AUTH_SOCK}} を設定しないでください。そうしないと、転送が失敗し、リモートマシン上で {{ic\|ssh-add -l}} を使用して既存のキーを確認するときにエラー (例:{{ic\|The agent has no identities}}) が表示される可能性があります。


	たとえば、bash を使用する場合、{{ic\|.bashrc}} は次のようになります:		たとえば、bash を使用する場合、{{ic\|.bashrc}} は次のようになります:

Kgx: /* SSH エージェント */ ssh エージェントの転送を翻訳して追加

2024-01-21T08:56:30Z

SSH エージェント: ssh エージェントの転送を翻訳して追加

← 古い版		2024年1月21日 (日) 17:56時点における版
292行目:		292行目:

	{{ic\|1=export SSH_AUTH_SOCK="$XDG_RUNTIME_DIR/ssh-agent.socket"}} をシェルのスタートアップファイルに追加してください。例えば [[Bash]] の場合 {{ic\|.bash_profile}} です。その後、サービスを有効化・起動してください。		{{ic\|1=export SSH_AUTH_SOCK="$XDG_RUNTIME_DIR/ssh-agent.socket"}} をシェルのスタートアップファイルに追加してください。例えば [[Bash]] の場合 {{ic\|.bash_profile}} です。その後、サービスを有効化・起動してください。

			==== ssh エージェントの転送 ====

			ローカルの {{ic\|ssh-agent}} をリモートに [[OpenSSH#エージェントフォワーディング\|転送]] するとき (たとえば、コマンドライン引数 {{ic\|ssh -A remote}} または設定ファイル内の {{ic\|ForwardAgent yes を介して)}}、リモートマシンが環境変数 {{ic\|SSH_AUTH_SOCK}} を上書きしないことが重要です。したがって、リモートマシンが前述の [[#Start ssh-agent with systemd user\|systemd ユニット]] を使用してエージェントを起動する場合、ユーザーが SSH 経由でログインするときに環境に {{ic\|SSH_AUTH_SOCK}} を設定しないでください。そうしないと、転送が失敗し、リモートマシン上で {{ic\|ssh-add -l}} を使用して既存のキーを確認するときにエラー (例:{{ic\|The agent has no identities}}) が表示される可能性があります。


			たとえば、bash を使用する場合、{{ic\|.bashrc}} は次のようになります:

			{{hc\|~/.bashrc\|2=
			...
			if [[ -z "${SSH_CONNECTION}" ]]; then
			export SSH_AUTH_SOCK="$XDG_RUNTIME_DIR/ssh-agent.socket"
			fi
			...
			}}

			このように、{{ic\|SSH_AUTH_SOCK}} は、現在のセッションが SSH ログインではない場合にのみ設定されます。これが SSH セッションの場合、転送が機能するように、リモートマシン上の {{ic\|SSH_AUTH_SOCK}} がローカルマシンによって設定されます。

	====ssh-agent をラッパープログラムとして使う====		====ssh-agent をラッパープログラムとして使う====
369行目:		386行目:
	exec openbox-session}}		exec openbox-session}}

	上記の例では、1行目で ''keychain'' を起動し、秘密鍵の名前と場所を渡しています。もし ''keychain'' の起動が初めてでなければ、次の2行で {{ic\|$HOSTNAME-sh}} と {{ic\|$HOSTNAME-sh-gpg}} の内容を読み込みます（存在する場合）。これらのファイルには、以前の ''keychain'' のインスタンスの環境変数が保存されています。		上記の例では、1行目で ''keychain'' を起動し、秘密鍵の名前と場所を渡しています。もし ''keychain'' の起動が初めてでなければ、次の2行で {{ic\|$HOSTNAME-sh}} と {{ic\|$HOSTNAME-sh-gpg}} の内容を読み込みます(存在する場合)。これらのファイルには、以前の ''keychain'' のインスタンスの環境変数が保存されています。

	====ssh-add で x11-ssh-askpass を呼び出す====		====ssh-add で x11-ssh-askpass を呼び出す====
434行目:		451行目:
	==== SSH 鍵のロック解除に別のパスワードを使用する ====		==== SSH 鍵のロック解除に別のパスワードを使用する ====

	鍵のパスフレーズを使うか、（異なる）ログインパスワードを使うかによって、SSH 鍵を解除するかしないかを決めたい場合は、{{ic\|/etc/pam.d/system-auth}} を以下のように変更します。		鍵のパスフレーズを使うか、(異なる)ログインパスワードを使うかによって、SSH 鍵を解除するかしないかを決めたい場合は、{{ic\|/etc/pam.d/system-auth}} を以下のように変更します。

	{{hc\|/etc/pam.d/system-auth\|2=		{{hc\|/etc/pam.d/system-auth\|2=

Kgx: /* ECDSA */ 一部翻訳

2024-01-21T08:48:32Z

ECDSA: 一部翻訳

← 古い版		2024年1月21日 (日) 17:48時点における版
93行目:		93行目:
	それには、2種類の懸念があります。		それには、2種類の懸念があります。

	# ''~~Political concerns~~''~~, the trustworthiness of~~ NIST~~-produced curves~~ [https://crypto.stackexchange.com/questions/10263/~~should~~-we-trust-the-nist-recommended-ecc-parameters ~~being questioned~~] ~~after revelations that the NSA willingly inserts backdoors into softwares, hardware components and published standards were made; well-known cryptographers~~ [https://www.schneier.com/blog/archives/2013/09/the_nsa_is_brea.html#c1675929 ~~have~~] [https://~~safecurves~~.cr.~~yp.to~~/~~rigid~~.~~html~~ ~~expressed~~] [https://~~www~~.~~hyperelliptic~~.~~org~~/~~tanja/vortraege/20130531~~.~~pdf~~ ~~doubts~~] ~~about how the NIST curves were designed, and voluntary tainting has already~~ [https://www.schneier.com/blog/archives/2007/11/the_strange_sto.html ~~been~~] [https://www.scientificamerican.com/article/nsa-nist-encryption-scandal/ ~~proved~~] ~~in the past.~~		# ''政治的懸念''、NSA が進んでソフトウェアやハードウェア部品、公表されている標準規格にバックドアを挿入していることが明らかになった後、NIST が作成した曲線の信頼性が[https://crypto.stackexchange.com/questions/10263/Should-we-trust-the-nist-recommended-ecc-parameters 疑問視されています]、著名な暗号技術者が [https://www.schneier.com/blog/archives/2013/09/the_nsa_is_brea.html#c1675929 NISTの曲線の設計方法について][https://www.hyperelliptic.org/tanja/vortraege/20130531.pdf 疑問][https://safecurves.cr.yp.to/rigid.html を表明しており]、自主的な汚染は[https://www.schneier.com/blog/archives/2007/11/the_strange_sto.html 過去]にすでに[https://www.scientificamerican.com/article/nsa-nist-encryption-scandal/ 証明されています。]
	# ''~~Technical concerns~~''~~, about the~~ [https://blog.cr.yp.to/20140323-ecdsa.html ~~difficulty to properly implement the standard~~] ~~and the~~ [https://www.gossamer-threads.com/lists/openssh/dev/57162#57162 ~~slowness and design flaws~~] ~~which reduce security in insufficiently precautious implementations.~~		# ''技術的な懸念''として、[https://blog.cr.yp.to/20140323-ecdsa.html 規格を適切に実装することの難しさ]や、[https://www.gossamer-threads.com/lists/openssh/dev/57162#57162 遅さなど設計上の欠陥]があり、十分な注意を払わない実装ではセキュリティが低下します。

	~~Both of those concerns are best summarized in~~ [https://git.libssh.org/projects/libssh.git/tree/doc/curve25519-sha256@libssh.org.txt#n4 libssh curve25519 introduction]. ~~Although the political concerns are still subject to debate, there is a~~ [https://news.ycombinator.com/item?id=7597653 ~~clear consensus~~] ~~that [[#Ed25519]] is technically superior and should therefore be preferred.~~		これらの懸念は、[https://git.libssh.org/projects/libssh.git/tree/doc/curve25519-sha256@libssh.org.txt#n4 libssh curve25519 introduction] に最もよくまとめられています。政治的な懸念はまだ議論の対象ですが、[[#Ed25519]] が技術的に優れており、それゆえ優先されるべきであるという[https://news.ycombinator.com/item?id=7597653 明確なコンセンサス]があります。

	==== Ed25519 ====		==== Ed25519 ====

Kgx: /* FIDO/U2F */ 一部翻訳

2024-01-21T08:21:12Z

FIDO/U2F: 一部翻訳

← 古い版		2024年1月21日 (日) 17:21時点における版
128行目:		128行目:
	通常、生成の確認のため、PIN の入力やトークンのタップが必要になります。サーバに接続する場合は、生成時に {{ic\|-O no-touch-required}} コマンドラインオプションを使用し、サーバで {{man\|8\|sshd\|no-touch-required}} {{ic\|authorized_keys}} オプションが設定されていない限り、通常トークンをタップする必要があります。		通常、生成の確認のため、PIN の入力やトークンのタップが必要になります。サーバに接続する場合は、生成時に {{ic\|-O no-touch-required}} コマンドラインオプションを使用し、サーバで {{man\|8\|sshd\|no-touch-required}} {{ic\|authorized_keys}} オプションが設定されていない限り、通常トークンをタップする必要があります。

			タッチイベントを必要としないキーを作成するには、{{ic\|no-touch-required}} オプションを使用してキーペアを生成します。例えば:
	To create keys that do not require touch events, generate a key pair with the {{ic\|no-touch-required}} option. For example:

	$ ssh-keygen -O no-touch-required -t ed25519-sk		$ ssh-keygen -O no-touch-required -t ed25519-sk
134行目:		134行目:
	{{Note\|すべてのハードウェアトークンがこのオプションに対応しているわけではありません。YubiKey を使用している場合、ed25519-sk の鍵タイプにはファームウェアのバージョン 5.2.3 が必要です。[https://www.yubico.com/blog/whats-new-in-yubikey-firmware-5-2-3/]}}		{{Note\|すべてのハードウェアトークンがこのオプションに対応しているわけではありません。YubiKey を使用している場合、ed25519-sk の鍵タイプにはファームウェアのバージョン 5.2.3 が必要です。[https://www.yubico.com/blog/whats-new-in-yubikey-firmware-5-2-3/]}}

	~~Additionally,~~ {{ic\|sshd}} ~~rejects~~ {{ic\|no-touch-required}} ~~keys by default. To allow keys generated with this option, either enable it for an individual key in the~~ {{ic\|authorized_keys}} ~~file,~~		さらに、{{ic\|sshd}} はデフォルトで {{ic\|no-touch-required}} キーを拒否します。このオプションで生成されたキーを許可するには、{{ic\|authorized_keys}} ファイル内の個々のキーに対してこのオプションを有効にします。

	no-touch-required sk-ssh-ed25519@openssh.com AAAAInN... user@example.com		no-touch-required sk-ssh-ed25519@openssh.com AAAAInN... user@example.com

	~~or for the whole system by editing~~ {{ic\|/etc/ssh/sshd_config}} ~~with~~		または、{{ic\|/etc/ssh/sshd_config}} を編集してシステム全体を対象にします

	PubkeyAuthOptions none		PubkeyAuthOptions none

			ECDSA ベースのキーペアは、{{ic\|ecdsa-sk}} キータイプを使用して生成することもできますが、上記の [[#ECDSA]] セクションの関連する懸念事項が引き続き適用されます。
	An ECDSA-based keypair may also be generated with the {{ic\|ecdsa-sk}} keytype, but the relevant concerns in the [[#ECDSA]] section above still apply.

	$ ssh-keygen -t ecdsa-sk		$ ssh-keygen -t ecdsa-sk

Kusanaginoturugi: /* 予備知識 */ リンクを追加および校正

2023-01-06T08:54:58Z

予備知識: リンクを追加および校正

← 古い版		2023年1月6日 (金) 17:54時点における版
18行目:		18行目:
	SSH サーバがあなたの公開鍵を持っていて、あなたが接続をリクエストしたことを確認したら、SSH サーバーは公開鍵を使ってチャレンジを作成し、あなたに送ります。このチャレンジは暗号化されたメッセージで、サーバがあなたのアクセスを許可するために、適切な応答が必要です。この暗号化されたメッセージを安全に解読できるのは秘密鍵を持っている人だけということが、暗号文を特に安全なものにしています。公開鍵を使ってメッセージを暗号化することはできる一方で、公開鍵を使ってメッセージを復号化することはできません。秘密鍵を持っている、あなただけが、チャレンジを解読して適切なレスポンスを作成することができるわけです。		SSH サーバがあなたの公開鍵を持っていて、あなたが接続をリクエストしたことを確認したら、SSH サーバーは公開鍵を使ってチャレンジを作成し、あなたに送ります。このチャレンジは暗号化されたメッセージで、サーバがあなたのアクセスを許可するために、適切な応答が必要です。この暗号化されたメッセージを安全に解読できるのは秘密鍵を持っている人だけということが、暗号文を特に安全なものにしています。公開鍵を使ってメッセージを暗号化することはできる一方で、公開鍵を使ってメッセージを復号化することはできません。秘密鍵を持っている、あなただけが、チャレンジを解読して適切なレスポンスを作成することができるわけです。

	このチャレンジ/レスポンス認証は水面下で行われ、ユーザーが関知するところではありません。秘密鍵を持ってさえいれば (通常は {{ic\|~/.ssh/}} ディレクトリに鍵が保存されます)、SSH クライアントはサーバーに適切なレスポンスを返すことが可能です。		この [[Wikipedia:Challenge-response authentication\|チャレンジ/レスポンス認証]]は水面下で行われ、ユーザーが関知するところではありません。秘密鍵を持ってさえいれば (通常は {{ic\|~/.ssh/}} ディレクトリに鍵が保存されます)、SSH クライアントはサーバーに適切なレスポンスを返すことが可能です。

	秘密鍵は機密情報として考えてよく、暗号化されてディスクに保存されること~~もよくあり~~ます。~~この場合、~~秘密鍵が必要になったとき、最初にパスフレーズを入力して秘密鍵を復号化する必要があります。表面的には、SSH サーバーにログインパスワードを入力するのと変わりないように見えますが、実際にはローカルシステム上の秘密鍵を復号化するための~~パスフレーズで~~す。このパスフレーズはネットワーク経由で送信されることはありません。		秘密鍵は機密情報として考えてよく、暗号化された形式でディスクに保存することをお勧めします。暗号化された秘密鍵が必要になったとき、最初にパスフレーズを入力して秘密鍵を復号化する必要があります。これは表面的には、SSH サーバーにログインパスワードを入力するのと変わりないように見えますが、実際にはローカルシステム上の秘密鍵を復号化するためにのみ使用されます。パスフレーズはネットワーク経由で送信されることはありません。

	==SSH 鍵のペアを生成==		==SSH 鍵のペアを生成==

Kusanaginoturugi: /* 鍵の場所とパスフレーズを選択 */ 飜訳

2022-12-07T06:02:21Z

鍵の場所とパスフレーズを選択: 飜訳

← 古い版		2022年12月7日 (水) 15:02時点における版
153行目:		153行目:
	パスフレーズを設定しないで秘密鍵を作成することも可能です。パスフレーズが不要なことは便利である一方、リスクも伴うということを理解してください。パスフレーズを設定しなかった場合、秘密鍵はディスク上に平文で保存されることになります。秘密鍵ファイルにアクセスすることさえできれば、誰でも (鍵を使って認証を行っている) SSH サーバーの認証を掻い潜ることができてしまいます。さらに、パスフレーズを設定しないということは、root ユーザーを無条件で信頼することになります。root ユーザーはファイルのパーミッションを回避していつでも秘密鍵ファイルにアクセスすることができます。		パスフレーズを設定しないで秘密鍵を作成することも可能です。パスフレーズが不要なことは便利である一方、リスクも伴うということを理解してください。パスフレーズを設定しなかった場合、秘密鍵はディスク上に平文で保存されることになります。秘密鍵ファイルにアクセスすることさえできれば、誰でも (鍵を使って認証を行っている) SSH サーバーの認証を掻い潜ることができてしまいます。さらに、パスフレーズを設定しないということは、root ユーザーを無条件で信頼することになります。root ユーザーはファイルのパーミッションを回避していつでも秘密鍵ファイルにアクセスすることができます。

			{{Note\|以前は、秘密鍵のパスワードは安全でない方法でエンコードされていました: MD5 ハッシュの一回分だけです。OpenSSH 6.5 以降では、秘密鍵をエンコードするための新しい、より安全な形式をサポートしています。この形式は [https://www.openssh.com/txt/release-7.8 OpenSSH version 7.8] 以降のデフォルトです。Ed25519 の鍵は常に新しいエンコーディング形式を使用しています。新しい形式にアップグレードするには、次のセクションで説明するように、鍵のパスフレーズを変更するだけです。}}
	{{Note\|Previously, the private key password was encoded in an insecure way: only a single round of an MD5 hash. OpenSSH 6.5 and later support a new, more secure format to encode your private key. This format is the default since [https://www.openssh.com/txt/release-7.8 OpenSSH version 7.8]. Ed25519 keys have always used the new encoding format. To upgrade to the new format, simply change the key's passphrase, as described in the next section.}}

	====鍵を変更せずに秘密鍵のパスフレーズを変更する====		====鍵を変更せずに秘密鍵のパスフレーズを変更する====

Kusanaginoturugi: /* サーバーによって無視される鍵 */ 一行飜訳

2022-11-09T12:54:25Z

サーバーによって無視される鍵: 一行飜訳

← 古い版		2022年11月9日 (水) 21:54時点における版
508行目:		508行目:

	* パーミッションの設定で問題が解決しないときは {{ic\|sshd_config}} で {{ic\|StrictModes}} を一時的に {{ic\|no}} に設定してみてください。StrictModes off で認証が成功する場合、おそらくファイルのパーミッションにまだ問題が存在します。		* パーミッションの設定で問題が解決しないときは {{ic\|sshd_config}} で {{ic\|StrictModes}} を一時的に {{ic\|no}} に設定してみてください。StrictModes off で認証が成功する場合、おそらくファイルのパーミッションにまだ問題が存在します。
	* ~~Make sure keys in~~ {{ic\|~/.ssh/authorized_keys}} ~~are~~ ~~entered correctly and only use one single line.~~		* {{ic\|~/.ssh/authorized_keys}} のキーが正しく入力されていることを確認し、1 行のみを使用してください。
	* リモートマシンが使用しているタイプの鍵をサポートしていることを確認してください。サーバーが ECDSA 鍵をサポートしていない場合、RSA あるいは DSA 鍵を使ってみてください。		* リモートマシンが使用しているタイプの鍵をサポートしていることを確認してください。サーバーが ECDSA 鍵をサポートしていない場合、RSA あるいは DSA 鍵を使ってみてください。
	* それでも認証できない場合、sshd をデバッグモードで実行して接続時の出力を確認してください:		* それでも認証できない場合、sshd をデバッグモードで実行して接続時の出力を確認してください: