openssh-clients-5.1p1-3.fc10.i386 openssh-5.1p1-3.fc10.i386 SSH into a Juniper SSG140 Firewall, give password then wait for ~10 seconds... $ ssh -v -l netscreen 192.168.1.1 OpenSSH_5.1p1, OpenSSL 0.9.8g 19 Oct 2007 debug1: Reading configuration data /home/mwatts/.ssh/config debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug1: Connecting to 192.168.1.1 [192.168.1.1] port 22. debug1: Connection established. debug1: identity file /home/mwatts/.ssh/identity type -1 debug1: identity file /home/mwatts/.ssh/id_rsa type 1 debug1: identity file /home/mwatts/.ssh/id_dsa type 2 debug1: Remote protocol version 2.0, remote software version NetScreen debug1: no match: NetScreen debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_5.1 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client 3des-cbc hmac-sha1 none debug1: kex: client->server 3des-cbc hmac-sha1 none debug1: sending SSH2_MSG_KEXDH_INIT debug1: expecting SSH2_MSG_KEXDH_REPLY Warning: Permanently added '192.168.1.1' (DSA) to the list of known hosts. debug1: ssh_dss_verify: signature correct debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: password debug1: Next authentication method: password netscreen.1.1's password: debug1: Authentication succeeded (password). debug1: channel 0: new [client-session] debug1: Entering interactive session. debug1: Requesting authentication agent forwarding. debug1: Sending environment. debug1: Sending env LANG = en_GB.UTF-8 Remote Management Console netscreen(M)-> buffer_get_ret: trying to get more bytes 4 than in buffer 0 buffer_get_int: buffer error
This problem "goes away" with Fedora 11 - openssh-clients-5.2p1-1.fc11.i586 so backporting this version to F10 would probably do it.
This message is a reminder that Fedora 10 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 10. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '10'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 10's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 10 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Re-opening, its back again on Fedora 12. $ rpm -q openssh-clients openssh-clients-5.2p1-31.fc12.i686 $ ssh netscreen@ssg-140 netscreen@ssg-140's password: Remote Management Console ssg-140-> buffer_get_ret: trying to get more bytes 4 than in buffer 0 buffer_get_int: buffer error
can you test the latest version openssh from f-13? there is openssh-5.4p1 which has rewritten the transport layer and message multiplex.
OK, I still see the same issue with openssh-clients-5.4p1-1.fc13.i686.rpm However, I think it may be related to the following section I have in my users ~/.ssh/config file: Host * ServerAliveCountMax 4 ServerAliveInterval 15 As another user (root in this case) I do _not_ see the disconnect, so I think I've actually found a bug in ScreenOS on Juniper firewalls, not a bug in SSH itself. As a result, I'm closing this again.