個人またはビジネスユーザーとしてbitbucketに送信できるように、同じホストで異なるsshキーをサポートするように.ssh / configを取得しようとしています。一方、他のsshエントリは依然として私の仕事ユーザーを使用しています。
私の設定ファイルは次のとおりです。
Host bitbucket-personal
HostName bitbucket.com
User git
IdentityFile ~/.ssh/personal
IdentitiesOnly yes
Host *
AddKeysToAgent yes
UseKeychain yes
IdentityFile ~/.ssh/work
予想されたキーとは異なるキーをssh bitbucket-personal使用する場合（以下のドキュメントを参照してください。最初に一致するIdentityFileを使用する必要があります）、~/.ssh/work他のすべてのパラメータは正しく引用されました（例：[Eメール保護]）。 Host *部分を削除すると、正しいキーが使用されます。
私は何が間違っていましたか？ここで優先順位がどのように機能するか誤解しているようです。
各パラメータに対して最初に取得された値が使用されます。構成ファイルには、「ホスト」仕様で区切られたセクションが含まれています。このセクションは、仕様で提供されているパターンの1つと一致するホストにのみ適用されます。一致するホスト名は、コマンドラインで指定されたホスト名です。
各パラメータで最初に取得した値を使用するため、ファイルの先頭にはより多くのホスト固有の宣言を提供し、最後に一般的なデフォルト値を提供する必要があります。
完全な詳細追跡は次のとおりです。
luke$ ssh -v bitbucket-personal
OpenSSH_7.8p1, LibreSSL 2.7.3
debug1: Reading configuration data /Users/luke/.ssh/config
debug1: /Users/luke/.ssh/config line 1: Applying options for bitbucket-personal
debug1: /Users/luke/.ssh/config line 7: Applying options for *
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 48: Applying options for *
debug1: Connecting to bitbucket.com port 22.
debug1: Connection established.
debug1: identity file /Users/luke/.ssh/luke type 0
debug1: identity file /Users/luke/.ssh/luke-cert type -1
debug1: identity file /Users/luke/.ssh/luke-cx type 0
debug1: identity file /Users/luke/.ssh/luke-cx-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_7.8
debug1: Remote protocol version 2.0, remote software version conker_1.1.15-49a70a8 app-154
debug1: no match: conker_1.1.15-49a70a8 app-154
debug1: Authenticating to bitbucket.com:22 as 'git'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: [email protected]
debug1: kex: host key algorithm: ssh-rsa
debug1: kex: server->client cipher: [email protected] MAC: <implicit> compression: none
debug1: kex: client->server cipher: [email protected] MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ssh-rsa SHA256:qqq
debug1: Host 'bitbucket.com' is known and matches the RSA host key.
debug1: Found key in /Users/luke/.ssh/known_hosts:52
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering public key: RSA SHA256:qqqq /Users/luke/.ssh/luke-cx
debug1: Server accepts key: pkalg ssh-rsa blen 535
debug1: Authentication succeeded (publickey).
Authenticated to bitbucket.com ([18.205.93.3]:22).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: pledge: network
debug1: Sending environment.
debug1: Sending env LANG = en_NZ.UTF-8
PTY allocation request failed on channel 0
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
logged in as lukemcgregor-x.
答え1
最近同じ問題が発生しました。 SSHホスト構成は除外を許可するため、必要に応じて機能します（それぞれにIDファイルを使用するbitbucket.comエイリアスを除く）。
Host bitbucket-personal
HostName bitbucket.com
User git
IdentityFile ~/.ssh/personal
IdentitiesOnly yes
Host * !bitbucket-personal
AddKeysToAgent yes
UseKeychain yes
IdentityFile ~/.ssh/work
ssh_config（一部のバージョンの場合）のマニュアルページでは、最初の値セットを使用するように指示されています。しかし、私はこの除外が必要だと思いました（OSXのsshの場合はssh -V OpenSSH_8.1p1, LibreSSL 2.7.3）。
答え2
私はあなたがssh-agentまたは復号化された秘密鍵をキャッシュするのと似たものを使用していると仮定します。これにより、キーが提供される順序が変更される可能性があります。これはより詳細なログレベル（複数を含む-v）で見ることができます。
また、IdentitiesOnlyこのオプションの意味は、考えているものとは少し異なります。つまり、サーバーに提供されるキーは制限されますが、このオプションの前にあるキーは制限されません。主に自動ロードのデフォルトの場所にID（）を提供するのを防ぐために使用されます~/.ssh/id_{rsa,dsa,ecdsa,ed25519}。
このIdentitiyFileオプションはあなたが思うものとは少し異なります。複数の仕様が許可されているので（manページを参照）、Match *セクション1の仕様も使用されます。
特定のキーをデフォルトで使用し、他のキーをその特定のホストでのみ使用するには、「プライマリ」キーをデフォルトの場所に移動して設定~/.ssh/id_rsaファイルから削除します。問題は解決します。