2

Good morning, I have one ed25519-sk key (using a hardware token), which I need only on my personal machine for some high security servers (all Debian). This key type is supported by OpenSSH 8.3+. We still have two machines running RHEL 7 which offers OpenSSH 7.2.

There is now an implementation glitch in the agent forwarding. It seems to send all the keys in the ~/.ssh/ dir as a byte stream. It does not check whether the keys are needed or compatible on the server side.

If there is only one incompatible key, there are no keys transferred at all. Not even the compatible ones.

server $ ssh-add -l
error fetching identities for protocol 1: agent refused operation
error fetching identities for protocol 2: invalid format
The agent has no identities.

To be clear, I don't need the ed25519-sk key on the server but I need ForwardAgent to be enabled here because we're using this to access Git repos.

A workaround is to move the ed25529-sk key out of the ~/.ssh/ directory.

Anybody has an idea how to achive both of the following?

  • Keep the ed25529-sk key on my local machine in the ~/.ssh dir
  • Forward all other|compatible keys to the server
Improve this question
1
  • Have you tried adding a destination constraint when adding that key to your agent? Lack of constraint extension should error out in a different place than unexpected key format.
    – anx
    Mar 18 at 9:56

2 Answers 2

Reset to default
1

You seem to misunderstand how ForwardAgent works.

When you enable agent forwarding via SSH it actually forwards your local $SSH_AUTH_SOCK UNIX socket to the remote machine through the secure tunnel. This means that ssh-add -l on the remote machine talks to the same ssh-agent process as the one your local ssh-add -l does. As such it cannot filter anything because it's just a "dumb" RemoteForward with a few extras (creating the remote directory to place the socket in and setting the appropriate environment variable).

You either need to spawn a separate ssh-agent to be forwarded or authenticate differently to your git repositories.

Improve this answer
3
  • The entire point of the [email protected] extension was to make the agent less dumb so it can filter on different connections.
    – anx
    Mar 18 at 10:04
  • 1
    @anx, that extension landed in OpenSSH 8.9 which Debian stable does not have.
    – Ginnungagap
    Mar 19 at 8:25
  • The extension makes the agent less dumb, but it doesn't look like it will solve this particular problem. See openssh.com/agent-restrict.html for the complete story.
    – PFudd
    Mar 31 at 21:07
0

I managed to get past this problem by using the command

ssh-agent ssh -A myhost

When used this way, a new SSH agent is started, then only the key for accessing myhost was added to the agent, which was the one I needed on my CentOS 7 machine.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .