I'm running OpenSSH 4.5p1 / OpenSSL 0.9.8e, installed as part of Cygwin 1.5.24(0.156/4/2) on a PC running WinXP Pro SP2. I can't get ssh-agent / ssh-add to work. I get the following errors when I try to add an identity via ssh-add: Error reading response length from authentication socket. Error writing to authentication socket. As best I can tell, I invoked ssh-agent properly; the subshell from which I'm trying to run ssh-add does have the proper SSH_AUTH_SOCK and SSH_AGENT_PID values, and the socket is readable/writable by me. Ssh-add and ssh-agent work perfectly for me on an older Cygwin installation (OpenSSH 3.9p1 / OpenSSL 0.9.7e / Cygwin 1.5.12(0.116/4/2).
I'm having the same problem. The ssh-agent/ssh-add worked fine until a few days ago. I didn't update any Cygwin packages in the meantime and haven't rebooted my PC for a while now (maybe that could fix it?). But the bug exists. $ env | grep SSH SSH_AGENT_PID=3244 SSH_AUTH_SOCK=/tmp/ssh-wA0SC8jY0Y/agent.3372 Content of file: /tmp/ssh-wA0SC8jY0Y/agent.3372 !<socket >2436 s 4E6A720D-ED8DF735-4D2422B5-0FA6178C From TCPView I see that process ssh-agent:3244 is listening on UDP port 2437 (not 2436!) Could this be the problem, that the port number is off by one? Here some output from TCP Spy that could be useful: (?) the next process to start and make a socket call will be spyed process attached, command line='C:\cygwin\bin\ssh-agent.exe' socket (708) created [family=AF_INET, type=SOCK_STREAM, protocol=IPPROTO_IP, dwFlags=WSA_FLAG_OVERLAPPED] socket (708) bound [name=127.0.0.1] socket (708) determined its local name [name=127.0.0.1:2436] socket (708) established for listening [backlog=128] socket (708) set one of its options [level=SOL_SOCKET, optname=SO_LINGER, l_onoff=1, l_linger=240] socket (708) closed process detached the next process to start and make a socket call will be spyed process attached, command line='C:\cygwin\bin\ssh-add.exe "/cygdrive/c/Documents and Settings/ueltschit/.ssh/id_dsa"' socket (704) created [family=AF_INET, type=SOCK_STREAM, protocol=IPPROTO_IP, dwFlags=WSA_FLAG_OVERLAPPED] socket (704) enabled its nonblocking mode socket (704) connecting synchronously without blocking [name=127.0.0.1:2436] socket (704) could not connect - WSAEWOULDBLOCK (A non-blocking socket operation could not be completed immediately) socket (676) created [family=AF_INET, type=SOCK_DGRAM, protocol=IPPROTO_UDP, dwFlags=WSA_FLAG_OVERLAPPED] socket (676) bound [name=127.0.0.1] socket (676) determined its local name [name=127.0.0.1:2442] socket (676) sending a datagram synchronously [len=1, to=127.0.0.1:2442] socket (676) sent a datagram that is 1 bytes 0000 00 . socket (676) receiving a datagram synchronously from its default address [len=1] socket (676) received a datagram that is 1 bytes 0000 00 . socket (704) specified an event object to be associated with the supplied set of network events and enabled its nonblocking mode [hEventObject=0, lEvent==0] socket (704) disabled its nonblocking mode socket (704) specified an event object to be associated with the supplied set of network events and enabled its nonblocking mode [hEventObject=280, lEvent=FD_WRITE|FD_CLOSE] socket (704) sending data synchronously without blocking [len=4] socket (704) sent 4 bytes of data 0000 00 00 02 06 .... socket (704) specified an event object to be associated with the supplied set of network events and enabled its nonblocking mode [hEventObject=0, lEvent==0] socket (704) disabled its nonblocking mode socket (704) specified an event object to be associated with the supplied set of network events and enabled its nonblocking mode [hEventObject=280, lEvent=FD_WRITE|FD_CLOSE] socket (704) sending data synchronously without blocking [len=518] socket (704) sent 518 bytes of data
BTW, I'm running OpenSSH 4.6p1-1 and OpenSSL 0.9.8e-3. I also have OpenSSL097 0.9.7l-1 installed. Could this cause a problem?
I suspect this is a cygwin-internal thing. ssh-agent uses Unix domain sockets, which Windows doesn't have and I suspect cygwin fakes it. I don't know if it uses UDP ports to emulate them (it might, but it seems odd to me). So: is this still an issues, and if so, what exact versions of the cygwin DLL do you have, and does updating cygwin and rebooting make a difference?
almost two years with no followup = no bug
Move resolved bugs to CLOSED after 5.7 release