How can I make SSH only use keys provided by ssh-agent?

Question

I need ssh to only use keys provided by ssh-agent, and ignore any identity files in ~/.ssh. What's the best way to do that?

Background: I need to authenticate against a Git server via SSH. I have a ~/.ssh/id_rsa which authenticates properly, but its associated Git user does not have the correct repository access permissions. So I need to use a different key, which I can only provide via ssh-agent, to authenticate as the correct Git user. However, as SSH seems to give local identity files precedence over agent-provided ones, I always end up being authenticated as the wrong user.

Answer 1

There's no option to do exactly that (aside from renaming id_rsa to id_whatever).

But the real question seems to be "how do I make ssh prefer a specific agent-only key". This is a bit easier to answer, actually – you can do that using the same IdentityFile (-i) option as always.

First use ssh-add -L to extract the public key from the agent to a file; then point IdentityFile to the extracted public key. ssh will accept it even without the private part, and will automatically use ssh-agent for authentication.

Answer 2

I came up with the following code for testing that a user has ssh-key access to github via ssh-agent in an unattended script. I'm testing that a valid key is loaded into ssh-agent, and that I want no other keys automatically loaded. The only way I found to do it is to temporarily remove permissions to read ~/.ssh. I put the github fingerprints in a temporary known_hosts file, too, but one could use -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no as well to ignore the fingerprint checking.

chmod 0 ~/.ssh
ssh-keyscan github.com > /tmp/github_known_hosts
GIT_SSH_COMMAND="ssh -q -o UserKnownHostsFile=/tmp/github_known_hosts" git ls-remote ssh://[email protected]/Account/REPO.git >/dev/null 2>&1
# Return status: 0 if successful, anything else if not
echo $?
chmod 700 ~/.ssh

I also tried using the above method combined with GitHub's recommended test of "ssh -T [email protected]", but the return status here comes from whatever command GitHub runs on their end which as of today is 1.