Long time open source user, first time bug reporter - let me know if I can do better etc! We use an agent account to run an ssh-agent. Process accounts belong to an agent group and we use unix group permissions to control access to the agent socket. This means we have one shared agent process per server that is easy to monitor etc. I think this approach is outlined in the O'Reilly book. ssh-agent now checks uid and euid and this disables the use of group permissions to control access to the socket, the process account now can't use the ssh-agent provided by the agent account. e.g., as 'agent' ssh-agent -c | head -2 > agent-info.c source agent-info.c source agent-info.c ssh-add .ssh/process-account-key chmod -R 770 agent.agent /tmp/ssh-socket-dir as 'process account' source /home/agent/agent-info.c try and ssh somewhere: ssh -i .ssh/process-account-key process@server Error reading response length from authentication socket. The disabling of use of group permissions is caused by L912-918 of ssh-agent.c I commented this code out, rebuilt and the agent account now works as we require. if ((euid != 0) && (getuid() != euid)) { error("uid mismatch: " "peer euid %u != uid %u", (u_int) euid, (u_int) getuid()); close(sock); break; } A command line flag to disable the use of group permissions (ie the default being that ssh-agent doesn't check euid), or removing the code would be good. Cheers, Geoff
Created attachment 1311 [details] Add -P option to ssh-agent to disable strict identity check This patch implements a -P option to ssh-agent to deactivate the strict user identity check.
Created attachment 2046 [details] Alternate but incredibly similar patch implementing option as -U The only advantage of my patch I can see is that I also patched the man page. :) I'd like to see some version of this go into the main release of the code, in any case.
I have a use-case for disabling this check as well. I have a system where I'd like to give certain users time-limited access to the use of certain SSH private keys without actually exposing the keys. I have the idea of using ssh-agent to do this. The agent would run as a "keyholder" user, and group permissions on the UNIX-domain socket would allow read-write by both that account and the actual ssh user. The current policy enforced by ssh-agent prevents this. This is very sensible in general, but breaks my particular case, and Geoff's as well. Thanks!