@deansheather I kind of like that idea, but our current implementation has the benefit of working in tandem with SSH agent forwarding, if we used our own agent, the forwarded agent would disable the Coder SSH key. It could be considered acceptable behavior/tradeoff but I suspect it would be unexpected for the user.

@kylecarbs To my knowledge passing -i will only disable the default entries (like ~/.ssh/id_rsa), the user should still be able to specify the identity file manually in the ~/.ssh/config (and/or with additional -i flags). So I'm not exactly sure why this is an issue currently.

The only thing is that the -i flag takes precedence (will be tried first). But usually an SSH server allows up to 6(?) keys to be provided and tried, in the default configuration anyway.

One thing we could do is parse the users SSH config using ssh -G github.com (or whatever hostname we receive). When no specific identity is defined for that host, the output should contain something like:

identityfile ~/.ssh/id_rsa
identityfile ~/.ssh/id_dsa
identityfile ~/.ssh/id_ecdsa
identityfile ~/.ssh/id_ecdsa_sk
identityfile ~/.ssh/id_ed25519
identityfile ~/.ssh/id_ed25519_sk
identityfile ~/.ssh/id_xmss

These are the default values (for me anyway), i.e. user did not change anything. What we could do here is check if any of these files exist -- if yes, add them as -i flags to the SSH command (before ours, just to be safe).

The output is reduced to as many identity files as have been defined for the host, e.g. with a single entry in ~/.ssh/config, it'd be:

identityfile ~/.ssh/id_ed25519_home.pub

I don't know if we should take the value of identitiesonly yes into account (no is default).

PS. If the user wants to to work around the issue right now, one option would be to unset GIT_SSH_COMMAND (they could even put it in their ~/.profile, or similar).

Cannot bring your own SSH key to clone #3126

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions