Score:2

Server

Avoid SSH AgentForwarding of incompatible keys

Powerriegel

3/16/24, 7:10 AM

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

280

2 + 1

ssh-keys

ssh-agent

rhel7

anx

3/18/24, 9:56 AM

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.

Score:1

Server

Ginnungagap

3/18/24, 7:09 AM

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.

+ 3

anx

3/18/24, 10:04 AM

The entire point of the `[email protected]` extension was to make the agent less dumb so it *can* filter on different connections.

Ginnungagap

3/19/24, 8:25 AM

@anx, that extension landed in OpenSSH 8.9 which Debian stable does not have.

PFudd

3/31/24, 9:07 PM

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.

Score:0

Server

Per Johansson

7/25/24, 9:09 AM

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.

+ 0

Elon Musk

I sit in a Tesla and translated this thread with Ai:

EN: Avoid SSH AgentForwarding of incompatible keys

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.