Bug 3106

Summary: Please allow ssh to use one agent to authenticate, but forward agent connections to another one
Product: Portable OpenSSH Reporter: András Korn <korn-mindrot.org>
Component: sshAssignee: Assigned to nobody <unassigned-bugs>
Status: CLOSED DUPLICATE    
Severity: enhancement    
Priority: P5    
Version: 8.1p1   
Hardware: All   
OS: All   

Description András Korn 2019-12-21 09:25:25 AEDT
Background: forwarding connections to ssh-agent is risky; if a server you ssh into is compromised (or if its administrator is malicious), someone could abuse your forwarded agent to authenticate as you.

One mitigation is to use `ssh-add -c` when adding keys to the agent, which causes the agent to prompt the user each time a key would need to be used.

Problem: for people who use ssh a lot, `ssh-add -c` is very inconvenient; it would be nice if we could be prompted only when a *remote* client tries to use our key, not for local clients. Unfortunately, ssh-agent can't differentiate between local and remote clients.

Proposal: have the user run two agents; one for local clients, one for remote ones. Keys would be added to the 2nd agent with `ssh-add -c`, but without `-c` to the 1st one. ssh clients started locally would use the local agent to authenticate; however, they would forward agent connections from remote servers to the 2nd agent.

The ForwardAgent ssh_config directive could be extended to support specifying a path to a socket in addition to the "yes" and "no" keywords, in the same way IdentityAgent does. IdentityAgent would point to the local agent socket (which doesn't prompt for key usage), and ForwardAgent would point to the other agent socket (which would require user confirmation when a remote client wishes to use a private key).
Comment 1 András Korn 2019-12-21 09:31:43 AEDT
Ah, I just found https://bugzilla.mindrot.org/attachment.cgi?id=3087&action=diff in https://bugzilla.mindrot.org/show_bug.cgi?id=1937, which seems to implement something similar.
Comment 2 András Korn 2019-12-21 09:36:03 AEDT
Ah, also found #2216, which is the same request. Sorry about the noise.

*** This bug has been marked as a duplicate of bug 2216 ***
Comment 3 Damien Miller 2021-04-23 15:10:46 AEST
closing resolved bugs as of 8.6p1 release