Tim, I'm not an expert on ssh. IMHO this kind of behaviour is typical of a memory leak or the application running out of resources in some way. So this may be a track worth pursuing before having to delve in to the more complex world of decoding packets. As you can establish a second tunnel alongside the slow tunnel and this works it is not an OS resource issue. It may be that instance of the ssh application (either your client or the instance of the daemon to which you connect) has run out of resources. My first reaction would be to update the software at each end to the latest revision. Second have a look for this specific issue with the software being used. It may be a known issue and that a specific parameter setting may resolve this. If this makes no difference then try the more difficult decoding route. I suspect that the software has its own commands/tools to help with this. For example, Cisco has "debug" commands to help with troubleshooting, such as debug ip ssh (http://www.cisco.com/en/US/tech/tk583/tk617/technologies_tech_note09186a00800949e2.shtml#debugandshowcommands). You may spot increasing number of errors as the link is used, or at least be able to work out which packets belong to which type of ssh traffic. On 22 March 2010 17:32, Timothy O'Keefe <timothy.okeefe@xxxxxxxxx> wrote: > > Hi all, > > First time poster, long time OpenSSH user :) > > The Situation: > > Users within our net require access to a website (http/80) that is > being hosted on another, trusted net. Admins on this other trusted net > are not necessarily as trusting as we are, though they do provide a > ssh gateway. So, one fairly easy solution that was decided upon was to > simply allow users access to this website via a "permanent" SSH tunnel > (-f) > > ssh -Nf -L 9100:webserver.trusted.com:80 user@xxxxxxxxxxxxxxxxx > > The Problem: > > After a while -- say a few days/weeks -- of having this tunnel > established, transactions through this tunnel slow down to a crawl. To > the point where requests will typically timeout. Establishing a brand > new tunnel alongside the slowing tunnel seems to work fine. I don't > see anything particularly wrong with the endpoint systems other than > that sshd on the ssh gateway is consuming about 1.4 MB of virtual > memory. While this does not pose any threat to the machine per se, it > does seem a bit strange to me. > > I'm curious as to what might be happening here, and what -- if > anything -- we can do about it. I've heard from a number of folks that > ssh tunnels for this purpose are a "bad idea" and that we might > consider a connectionless OpenVPN based solution. This is 100% fine, > however no one has been able to explain _why_ the tunnel slows down > which happens to be precisely what interests me. Can someone provide > me with any insights? > > The ssh gateway system is CentOS 4.7 w/ OpenSSH 3.9p1 and the client > is Ubuntu 8.04 w/ OpenSSH 4.7p1. > > Thanks in advance, > Tim
