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
Powerriegel
  • 385
  • 1
  • 6
  • 16
  • 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 '23 at 09:56

2 Answers2

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.

Ginnungagap
  • 2,595
  • 10
  • 13
  • The entire point of the `session-bind@openssh.com` extension was to make the agent less dumb so it *can* filter on different connections. – anx Mar 18 '23 at 10:04
  • 1
    @anx, that extension landed in OpenSSH 8.9 which Debian stable does not have. – Ginnungagap Mar 19 '23 at 08:25
  • The extension makes the agent less dumb, but it doesn't look like it will solve this particular problem. See https://www.openssh.com/agent-restrict.html for the complete story. – PFudd Mar 31 '23 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.

Per Johansson
  • 126
  • 3