A protocol 1 server key is generated when sshd starts up even if only protocol 2 is allowed and hence that key will never be used.
when does this happen? i don't see this with version 3.5 (or 2.5.1)
I have tested this on 3.1p1 and was able to apply the diff to 3.5p1 without an error but wasn't able to test it yet. Just for clarification I am starting an instance of sshd for each connection. (Using inetd on one set of systems and tcpserver on another.) So that the extra key generation is once per connection, not server startup. It isn't that big of a slowdown, but it is an unnecessary one. I have a copy of the diffs I used to fix the problem at: http://wolff.to/bruno/sshd.c.diff This should illustrate what I am complaining about.
I can't replicate this with CVS -current, either in inet or normal mode. Please reopen if you can.
The problem still exists in 3.6.1, but upon rereading what I posted, I see I didn't describe the problem accurately. The problem occurs when running sshd with the -i option with both protocol 1 and protocol 2 enabled. If someone connects using protocol 2, the protocol 1 ephemeral key is still generated. You can see this by running sshd with the -ddd option. The ephemeral key generation is skipped if protocol 1 is disabled. But when the -i option is used even if protocol 1 is enabled if the current connection uses protocol 2 the generated ephemeral key will never be used. Hence not generating it under those conditions seems like a good idea.
Took a quick look at this. I can confirm that when running in inetd ("-i -o Protocol=1,2") the SSHv1 ephemeral keys are still generated for v2 connects, and that with the patch it's not. The patch, however, seems to break SSHv1 connections in inetd mode: sh /usr/src/regress/usr.bin/ssh/test-exec.sh /usr/src/regress/usr.bin/ssh/obj /usr/src/regress/usr.bin/ssh/proxy-connect.sh Connection closed by UNKNOWN ssh proxyconnect protocol 1 failed Connection closed by UNKNOWN ssh proxyconnect protocol 1 failed bad SSH_CONNECTION
Thanks for looking at this and letting me know about the version 1 problem with the patch. I will want to fix this on some machines where people might be using version 1 still.
Created attachment 1429 [details] Generate ephemeral key in inetd mode only for protocol 1 connections I took another look at this and I think I now know why the original patch broke protocol 1 (although the patch is now a dead link, so I can't check). I think the generation of the ephemeral key was moved to after the privsep split, which would mean that the key was generated in the pre-auth privsep slave and not in the monitor where it's needed). The attached patch fixes this and speeds up "ssh -2 server true" from around 680 ms to 490 ms on a 1.7GHz Celeron. It passes the regress tests, which it also speeds up by about 5% (there's lots of sleeps in the test suite, so the speedup is not as significant).
The patch has been committed and will be in the 4.8 release (at long last :-). Thanks for the report.
Fix shipped in 4.9/4.9p1 release.