Platform: Compaq Tru64 UNIX V5.1A (Rev. 1885) When building: openssh-4.0p1 against openssl-0.9.7f and zlib-1.2.2 The sftp client hangs when attempting to log into the remote host. e.g. ---snip--- # sftp -vvv root@css-ps Connecting to css-ps OpenSSH_4.0p1, OpenSSL 0.9.7f 22 Mar 2005 debug1: Reading configuration data /usr/local/ssh/etc/ssh_config debug3: Seeding PRNG from /usr/local/ssh/libexec/ssh-rand-helper ---snip--- I had the same problem when building: openssh-3.9p1 against openssl-0.9.7f and zlib-1.2.2 When I built: openssh-4.0p1 against openssl-0.9.7e and zlib-1.2.2 I do not have this problem. So it appears that some change between openssl-0.9.7e and openssl-0.9.7f has broken the sftp client. For more info, please see secure-shell mailing list: http://marc.theaimsgroup.com/?l=secure-shell&m=111167722024411&w=2 http://marc.theaimsgroup.com/?l=secure-shell&m=111210986628577&w=2
Could you please run ssh-rand-helper on its own in debug mode and attach the output using "Create New Attachment"? ie $ /usr/local/ssh/libexec/ssh-rand-helper -vvv
BTW does it hang with regular ssh commands too or is it specific to sftp?
Created attachment 859 [details] results of ssh-rand-help -vvv This is the current output of ssh-rand-helper. Here's the weird thing. I rebuilt openssh-4.0p1 with the lastest openssl and zlib and sftp works. (i.e. now I cannot reproduce the problem.) Now there's no reason why the rebuild would change anything. It must have something to do with the ssh-rand-help command. I tested this when I was having the problem though and ssh-rand-helper appeared to run fine from the command line. (See: http://marc.theaimsgroup.com/?l=secure-shell&m=111167722024411&w=2 for my test.) Is there any difference in running from command line and the way sftp runs ssh-rand-helper.
(In reply to comment #2) > BTW does it hang with regular ssh commands too or is it specific to sftp? Specific to sftp.
Created attachment 860 [details] sftp wait() changeset from 4.0 I don't think this is it, but it's the only thing I could come up with that might have an effect anything like what you're reporting. It also doesn't explain why it only occurs with openssl-0.9.7f or why it apparently stopped after a recompile. If you manage to reproduce it again, try reverting this patch (patch -R) and retesting.
One other thing: do you have prngd or egd?
(In reply to comment #5) > Created an attachment (id=860) [edit] > sftp wait() changeset from 4.0 > I don't think this is it, but it's the only thing I could come up with that > might have an effect anything like what you're reporting. It also doesn't > explain why it only occurs with openssl-0.9.7f or why it apparently stopped > after a recompile. > If you manage to reproduce it again, try reverting this patch (patch -R) and > retesting. I'll do this when the problem comes up again. We have a number of Tru64 boxes running OpenSSH so I dare say we haven't seen the last of this problem. (In reply to comment #6) > One other thing: do you have prngd or egd? No.
Is it dependant on the version of the server you're connecting to?
(In reply to comment #8) > Is it dependant on the version of the server you're connecting to? No. I've tried sftp'ing to various different ssh servers. Linux, Tru64, FreeBSD with OpenSSH and Tru64 with commercial ssh.
(In reply to comment #5) > Created an attachment (id=860) [edit] > sftp wait() changeset from 4.0 > I don't think this is it, but it's the only thing I could come up with that > might have an effect anything like what you're reporting. It also doesn't > explain why it only occurs with openssl-0.9.7f or why it apparently stopped > after a recompile. > If you manage to reproduce it again, try reverting this patch (patch -R) and > retesting. When I try: # patch -R < openssh-sftp-sigchld.patch.txt I get: Hmm... I can't seem to find a patch in there anywhere.
Created attachment 869 [details] results of ssh-rand-help -vvv (2) Problem is back in the same machine as before. I've included debug output of ssh-rand-helper and it all looks OK. I couldn't get the patch you posted to apply but I think we've ruled out ss-rand-helper as the problem.
(In reply to comment #10) > Hmm... I can't seem to find a patch in there anywhere. It's a unified diff, some patch program don't understand them. If you have GNU patch available then try that, otherwise I can recreate the diff in another format. (Alternatively you could apply by hand, it's only a couple of lines if you ignore the scp.c part).
(In reply to comment #12) > (In reply to comment #10) > > Hmm... I can't seem to find a patch in there anywhere. > It's a unified diff, some patch program don't understand them. If you have GNU > patch available then try that, otherwise I can recreate the diff in another > format. (Alternatively you could apply by hand, it's only a couple of lines if > you ignore the scp.c part). Yeah Tru64(Sucks)UNIX diff/patch utilities don't support unified diffs, it turns out. So I applied by hand e.g. commented out the call to waitpid but the problem is still there.
If you are still experiencing this bug, could you please try to truss or strace (or whatever the Tru64 equivalent is) the sshd and ssh-rand-helper processes, and attach the results? Alternately, you could use a debugger or insert a bunch of printf("still here"); statements into entropy.c:seed_rng() to see where it chokes.
Hi Damien, Casting my mind back I believe I worked around the issue by editing: /usr/local/ssh/etc/ssh_prng_cmds And commenting out: ---snip--- #"netstat -an" /usr/sbin/netstat 0.05 #"netstat -in" /usr/sbin/netstat 0.05 #"netstat -rn" /usr/sbin/netstat 0.02 #"netstat -pn" undef 0.02 #"netstat -ia" /usr/sbin/netstat 0.05 #"netstat -s" /usr/sbin/netstat 0.02 #"netstat -is" /usr/sbin/netstat 0.07 #"arp -a -n" /sbin/arp 0.02 ---snip--- It seems these commands were taking a long time to complete and delaying the PRNG seed by the sftp client. From memory, it was *not* DNS resolution (netstat -n) that was causing the delay in netstat. It must have been some other issue. I don't recall any more details I could give you. Let me know if you need any more detail and I'll see what I can dig up. Thanks, Paul
Created attachment 1431 [details] Make ssh-rand-helper close all fds above STDERR Random thought: I wonder if some commands are making unwarranted assumptions about the descriptors they inherit? The down side of this is one systems that don't have a native closefrom or equivalent is that the equivalent close calls are going to be relatively slow (but only required once).
Can't replicate this and can't diagnose without a truss or similar; ssh-rand-helper includes subcommand timeout logic that should avoid this. Please reopen if it recurs and you can trace it.
As I said a few years ago, we can't diagnose this without more information. Please reopen this bug if the problem is still occurring and you are able to provide it.
Close all resolved bugs after 7.3p1 release