On Wed, Jan 14, 2004 at 09:01:40PM +1300, Volker Kuhlmann wrote: > Well, for *&*@&#*($ ADSL 90 seconds timeout, it's impossible to do any > work without some countermeasure.
Where are the connections being dropped? I suspect the problem will be with your ADSL router/gateway and what sound like extremely aggressive timeouts for TCP state entries. Nothing to do with ADSL... > > No matter what option you do use, think long and hard about the > > risks of leaving ssh sessions open and unwatched for extended > > periods of time, > Can you quantify the risk a bit more? It's afterall supposed to be a > secure sonnection. Waht if you copy some file which takes 12 hours? Have a read of [0] and [1]. These don't directly cover ssh session hijacking (though Dug Song's sshmitm is mentioned in passing). The ssh protocol is only secure for certain definitions of secure. Look at the design of the ssh protocol versus SSL and IPsec. You'll see they've each solved different security problems (and, of course, at different levels of abstraction). For example, ssh doesn't try as hard to protect your session from timing attacks as SSL can[2]. If you want to keep sessions open for 12 hours (as in your example about long file transfers), ssh is not the best way to do this... but it's better than using plain FTP. [0] http://www.seifried.org/security/cryptography/20011108-end-of-ssl-ssh.html [1] http://www.seifried.org/security/cryptography/20011108-sslssh-followup.html [2] Assuming the SSL-enabled application takes advantage SSL traffic generation Cheers, -mjg -- Matthew Gregan |/ /| [EMAIL PROTECTED]
