Dear Damien and Darren, I recently ran into a really weird and spooky ssh problem. My brain is going to mad trying to explain that it is a hardware issue since on two machines, one of which is a Celeon 2.8 Ghz with 1 GB RAM, another is a Xeon 4 CPU box with 3 Gig RAM and I guess 3 Ghz or something, both of which are running FreeBSD 6.1 with latest version of OpenSSH bundled with it. The version string is SSH-2.0-OpenSSH_4.2p1 FreeBSD-2005090 I did a ssh -vvv to them and the problem occurs in kex. And it is absolutely random. Here is some sample output. 1) debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS Write failed: Broken pipe 2) debug2: set_newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent Read from socket failed: Connection reset by peer 3) debug1: Local version string SSH-2.0-OpenSSH_3.8.1p1 Debian-8.sarge.4 debug1: SSH2_MSG_KEXINIT sent Read from socket failed: Connection reset by peer At the same time sometimes I am able to connect. I tried this from my Debian, FreeBSD and OpenBSD boxes with different SSH versions. I looked at the code and I can see certain fatal() calls in the kex code which I believe is shared bet server and client. What is causing the server to die? What is the real issue? Thanks. regards, Girish -- Whenever people agree with me I always feel I am wrong. - Oscar Wilde
Dear Damien and Darren, I recently ran into a really weird and spooky ssh problem. My brain is going to mad trying to explain that it is a hardware issue since on two machines, one of which is a Celeon 2.8 Ghz with 1 GB RAM, another is a Xeon 4 CPU box with 3 Gig RAM and I guess 3 Ghz or something, both of which are running FreeBSD 6.1 with latest version of OpenSSH bundled with it. The version string is SSH-2.0-OpenSSH_4.2p1 FreeBSD-2005090 I did a ssh -vvv to them and the problem occurs in kex. And it is absolutely random. Here is some sample output. 1) debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS Write failed: Broken pipe 2) debug2: set_newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent Read from socket failed: Connection reset by peer 3) debug1: Local version string SSH-2.0-OpenSSH_3.8.1p1 Debian-8.sarge.4 debug1: SSH2_MSG_KEXINIT sent Read from socket failed: Connection reset by peer At the same time sometimes I am able to connect. I tried this from my Debian, FreeBSD and OpenBSD boxes with different SSH versions. I looked at the code and I can see certain fatal() calls in the kex code which I believe is shared bet server and client. What is causing the server to die? What is the real issue? Thanks. regards, Girish -- Whenever people agree with me I always feel I am wrong. - Oscar Wilde _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Girish Venkatachalam wrote:> Dear Damien and Darren, > > I recently ran into a really weird and spooky ssh problem. My brain > is going to mad trying to explain that it is a hardware issue since on two > machines, one of which is a Celeon 2.8 Ghz with 1 GB RAM, another is a > Xeon 4 CPU box with 3 Gig RAM and I guess 3 Ghz or something, both of > which are running FreeBSD 6.1 with latest version of OpenSSH bundled > with it. The version string is > SSH-2.0-OpenSSH_4.2p1 FreeBSD-2005090 > > I did a ssh -vvv to them and the problem occurs in kex. And it is > absolutely random. Here is some sample output. > > 1) debug1: SSH2_MSG_NEWKEYS sent > debug1: expecting SSH2_MSG_NEWKEYS > Write failed: Broken pipeIt's not clear from you're describing the client(s) or server(s) above, but the server in this case doesn't happen to be an UltraSPARC does it? If so, what version of OpenSSL does it have? -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
On Tue, Sep 19, 2006 at 02:21:33PM +1000, Darren Tucker wrote:
|Girish Venkatachalam wrote:
|>Dear Damien and Darren,
|>
|>I recently ran into a really weird and spooky ssh problem. My brain
|>is going to mad trying to explain that it is a hardware issue since on two
|>machines, one of which is a Celeon 2.8 Ghz with 1 GB RAM, another is a
|>Xeon 4 CPU box with 3 Gig RAM and I guess 3 Ghz or something, both of
|>which are running FreeBSD 6.1 with latest version of OpenSSH bundled
|>with it. The version string is
|>SSH-2.0-OpenSSH_4.2p1 FreeBSD-2005090
|>
|>I did a ssh -vvv to them and the problem occurs in kex. And it is
|>absolutely random. Here is some sample output.
|>
|>1) debug1: SSH2_MSG_NEWKEYS sent
|>debug1: expecting SSH2_MSG_NEWKEYS
|>Write failed: Broken pipe
|
|It's not clear from you're describing the client(s) or server(s) above,
|but the server in this case doesn't happen to be an UltraSPARC does it?
| If so, what version of OpenSSL does it have?
|
Sorry Darren for the confusion. Both machines running FreeBSD are the servers
and the sshd on the server side is dying. I have mentioned above the
architectures, none of them are UltraSparc.
Is there something wrong with /dev/*random?
I have tried connecting from FreeBSD itself, OpenBSD and Debian GNU/linux asssh
clients. And all of them have problems at different times. And these clients of
course are running at my home and they are old crappy i386 boxes. I dont think
there is any problem with the client part.
I would have loved u to actually take a look at it urself but the machines do
not actually belong to me and that is the reason I am not able to make them
available to you. However if you insist I can give you the IPs and you can try
connecting.
What could be the problem? Any clues? Please tell me if this is fixable at all.
I wonder what more I can do. :-)
Oh OpenSSL was my first suspicion.
ldd /usr/bin/ssh
/usr/bin/ssh:
libcrypto.so.4 => /lib/libcrypto.so.4 (0x280a7000)
libutil.so.5 => /lib/libutil.so.5 (0x28199000)
libz.so.3 => /lib/libz.so.3 (0x281a5000)
libcrypt.so.3 => /lib/libcrypt.so.3 (0x281b5000)
libc.so.6 => /lib/libc.so.6 (0x281cd000)
I assure you my fullest cooperation in clearing this up.
regards,
Girish
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev at mindrot.org
http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Girish Venkatachalam wrote: [...]> Sorry Darren for the confusion. Both machines running FreeBSD are the > servers and the sshd on the server side is dying. I have mentioned > above the architectures, none of them are UltraSparc.> > Is there something wrong with /dev/*random? Dunno, but I suspect not. > I have tried connecting from FreeBSD itself, OpenBSD and Debian > GNU/linux asssh clients. And all of them have problems at different > times. And these clients of course are running at my home and they are > old crappy i386 boxes. I dont think there is any problem with the > client part. You really need to see what's happening on the server side (normally I'd suggest running the server in debug mode, but since it's intermittent you would probably need to bump up the LogLevel and grep out the relevant session from the log). Does the problem occur with a vanilla OpenSSH built from the source on openssh.com? I'm pretty sure FreeBSD make a number of changes but I don't know what they are. They should be the first point of call for problems with the binaries they supply. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
On Tue, Sep 19, 2006 at 03:02:07PM +1000, Darren Tucker wrote:
|Girish Venkatachalam wrote:
|[...]
|>Sorry Darren for the confusion. Both machines running FreeBSD are the
|>servers and the sshd on the server side is dying. I have mentioned
|>above the architectures, none of them are UltraSparc.
|>
|> Is there something wrong with /dev/*random?
|
|Dunno, but I suspect not.
|
|> I have tried connecting from FreeBSD itself, OpenBSD and Debian
|> GNU/linux asssh clients. And all of them have problems at different
|> times. And these clients of course are running at my home and they are
|> old crappy i386 boxes. I dont think there is any problem with the
|> client part.
|
|You really need to see what's happening on the server side (normally
I'd
|suggest running the server in debug mode, but since it's intermittent
|you would probably need to bump up the LogLevel and grep out the
|relevant session from the log).
|
|Does the problem occur with a vanilla OpenSSH built from the source on
|openssh.com? I'm pretty sure FreeBSD make a number of changes but I
|don't know what they are. They should be the first point of call for
|problems with the binaries they supply.
In that case let us just move on. I could not run sshd in debug mode since I
tried something and ended up killing it and getting myself locked out. Since it
is not my machine I am also scared to just hack things.
You are right in the stance that FreeBSD owes an explanation. But I wouldnt
think they would diddle around with DH fields and stuff. Remote chance.
I have not tried with vanilla OpenSSH.
If nothing comes to your mind, then let us just leave it and move on.
This will be one of those unsolved Sherlock Holmes mysteries. :-)
regards,
Girish
--
Whenever people agree with me I always feel I am wrong.
- Oscar Wilde
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev at mindrot.org
http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev