ssh/connection reset by peer (not timeout issue)

[arri]

hi,

i'm sorry if missed similair posts, but all i found so far were issues related to timeouts or bad routers.
also, i realise it's not completely mac-related, although the clients i'm using are all macs (leopard, tiger)

my problem is that although nothing changed in my network setup, i'm lately suffering from dropping ssh-connections which are randomly being reset by the server(?).

it's got nothing to do with time-outs either on client or server side. it's all configured to never timeout, and it sometimes happens that several connections drop all at once, while i'm actually transfering files (scp) and monitoring remote log-files etc..

the only significant changes are my isp merged with another (bigger) company, and the bill now shows another name, and i suddenly have a new ip-address.
the first seems like the only logical explaination for these problems.i already mailed them about this, but they state nothing has changed on the technical side.

as for the ip-address, i don't see why that would cause this kind of probelms.
to make sure, i generated new keys, cleaned-out known_hosts etc.. to no avail.

anyone some ideas what it might be?

thanks
arri

 

[Satcomer]

Is your ISP packet shaping Bit Torrent users? I ask because the Windows only program that does this is flawed and blocks ssh ports also when it detects those packets.

 

[macbri]

You might try enabling debugging in both the server and client:

On the server, run sshd on a different port:

sudo /usr/sbin/sshd -dddp 2022 2>&1 |tee /tmp/sshd.log

Then on your client connect with

ssh -vvvp 2022 server 2>&1 |tee /tmp/ssh.log

-or-

scp -vvvp 2022 server:/file /tmp/file 2>&1 |tee /tmp/scp.log

Might give some clues, even if just a debug string which happens when the connection is shut down, which might turn up something else on a web search....

 

[arri]

satcomer, i never noticed any block whatsoever, i'd actually be surprised(..)

macbri, thanks for the suggestion. you're right..
i was just still denying, and blaming the isp

 

[arri]

to round-up:

the timeout-issue magically dissapeared before i got a chance to test with debugging/verbose flags on ssh/sshd.

i like to believe my isp actually took appropriate action after they received my complaint
(prob. not)