On Tue, 19 May 2020, Alex Wilson wrote: > I know this is pretty left-field, but I'm working on a custom ssh-agent > implementation and looking at ways to detect forwarded agent connections, with > the hope to have a "confirm" mode which can apply just to those (or those, > plus non-whitelisted local processes). > > I realise this has been discussed a bit before, but I have thought up a method > which seems to be working in my tests so far (which isn't one I've seen > discussed really?), and wanted to ask if anyone can see an obvious problem > with it. > > The SSH client makes multiple connections to the agent's UNIX socket when it's > forwarding -- the first one seems to always be for the client itself (even > with public key auth disabled), and then subsequent connections are made 1:1 > with remote client connections that are being forwarded. > > My agent implementation already knows how to look up the PID of the connected > process (via SO_PEERCRED, getpeerucred, etc) and find its executable name and > basic info (via procfs, kvm_getprocs etc) on the handful of OS that I care > about, so this is what I'm thinking of doing: > > 1. Track connections per process by pid + process start time (so if the PID > is re-used, the start time should be different and we'll treat it as new) > 2. If the calling process' exec binary path ends with "ssh" and this > connection is NOT the first connection from that process, then prompt for > confirmation. > 3. Otherwise, allow it. > > Obviously this won't work if somebody renames the "ssh" binary -- but the > threat I'm trying to mitigate here is somebody forwarding from a trusted local > machine to a remote machine which they conditionally trust (e.g. trust it in > the absence of exploits), and there's not an easy way that I know of to rename > the local ssh binary from the remote machine. That would probably work, though I have been toying with trying some changes to ssh-agent that could make this easier: 1) Make ssh-agent listen on two sockets instead of one, say SSH_AUTH_SOCK and SSH_AUTH_SOCK_FORWARD. 2) Make ssh _use_ $SSH_AUTH_SOCK, but _forward_ $SSH_AUTH_SOCK_FORWARD (this is already possible given the recent change to ForwardAgent) 3) Define some extensions to the agent protocol that allow adding keys to ssh-agent for local use only (i.e. not forwarding). This would let users add keys for local use, keys for remote use w/ confirmation, etc. What do you think? -d _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
