openssh unix dev - Aug 2014 - SSH completely locks up if you have a NOT PERFECT con

This is a SSH BUG !

The problem is programmers who say things like this: "disconnection is the
responsibility of the TCP stack" or "TCP layer 1 should take care of
that".

TCP will close and SSH doesn't seem to notice, I am really tired of it
getting stuck. I kill it and immediately re-connect and all is OK, so how did
TCP save me? IT DOESN'T - layer 1 2 3 4 5 whatever failed because YOU
didn't do your part!

Programmers: Ap level stuff knows when to time out not TCP, so you need to send
a RST to the TCP stack so it will try to re-establish the connection or
something!!! A few missing packets and you are screwed! I AM REALLY TIRED OF BAD
PROGRAMMING assuming that some other layer is going to do everything for you.
It's not a perfect connection world.

Network session stability is responsibility of layer 4 - That's why
these things are split in layers, so you don't have to reimplement all
functionalities (badly) on every layer. Read about OSI layers.
OpenSSH does not implement the TCP stack and the magical settings you
ask for are not provided by the OS.
Forward your bug to Linux, FreeBSD, Microsoft or to the dev team of
whatever OS you didn't even bother to mention.

Or use mosh, which is designed to continue working even when changing IP
addresses.

I would change my tone if you expect more than a patronizing answer like
this one.

Aris
Le 28/08/14 18:20, Anonymous a ?crit :
> This is a SSH BUG !
>
> The problem is programmers who say things like this: "disconnection is
the responsibility of the TCP stack" or "TCP layer 1 should take care
of that".
>
> TCP will close and SSH doesn't seem to notice, I am really tired of it
getting stuck. I kill it and immediately re-connect and all is OK, so how did
TCP save me? IT DOESN'T - layer 1 2 3 4 5 whatever failed because YOU
didn't do your part!
>
> Programmers: Ap level stuff knows when to time out not TCP, so you need to
send a RST to the TCP stack so it will try to re-establish the connection or
something!!! A few missing packets and you are screwed! I AM REALLY TIRED OF BAD
PROGRAMMING assuming that some other layer is going to do everything for you.
It's not a perfect connection world.
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>

On 8/28/2014 9:20 AM, Anonymous wrote:
> This is a SSH BUG !
It sounds like your main problem is with the specification of TCP, not 
SSH.  TCP/IP was developed with a few overarching assumptions:

1) Your own (source interface) IP#s and possibly the server's didn't 
change "often".  I am pretty sure its original designers didn't
develop
TCP in an environment "featuring" bouncing IP#s from flaky WiFi
spots'
DHCP implementations issuing you a new IP# all the time when your link 
resumes.

2) The route path to your server was reasonably stable, and fairly 
static.  Most of the transient path-'outages' are usually due to some 
leg's BGP changes or flakiness.  Occasionally, connections get 
half-broken, even if both sides don't notice any especial "outage"
to
the Internet-at-large.

Projects with security as their first priority generally don't have the 
mandate, let alone resources to try to work around all of the problems 
caused by the "modern flaky reality" of Internet connectivity.

TCP's always had a problem of detecting half-broken connections on the 
server side when the normal "idle" state of the server is awaiting for
input from the client.  With TCP - unless you enable KEEPALIVES or build 
in a "HEARTBEAT" into your protocol, you generally don't know the
link's
dead until you try to send data to your endpoint.

If you really do want "auto-closure" of half-disconnected connections,
there are many options open to you, ranging from a mix of enabling TCP 
keep-alives with semi-shortish timeout intervals (note, this isn't 
protected by any crypto or MAC of any kind), to enabling an "SSH inband 
'ping'" to more securely implement a "heartbeat" type of
functionality.

Read the manuals, educate yourself about your kernel's TCP stack tuning 
knobs (if you can even get at those on your system), but don't shriek 
like a lunatic to every software project that inherits the limitations 
of underlying protocols and demand that they redress the accumulated 
shortcomings of decades of ad-hoc and often chaotic "progress" that
have
exposed the cracks in a 30+ year old networking specification.

Not an SSH Bug, but a USER Bug.

=R=