Frozen connection using ssh over Amazon EC2 using ubuntu

Question

When I am connected to Amazon EC2 using the secure shell and don't type anything for a few minutes, everything freezes. I can't type anything or exit. After a few minutes I get a message from the server...

Last login: Fri Dec 6 23:21:28 2013 from pool-173-52-249-158.nycmny.east.verizon.net ubuntu@ip-172-31-31-33:~$ Write failed: Broken pipe

Some of you have had to have this problem before. If you could shed some light on the situation for a newb using the cloud.

Answer 1

Try below options:

Explore ServerAliveCountMax and ServerAliveInterval. These settings are set in /etc/ssh/ssh_config on SSH client side.

from man ssh_config:

ServerAliveCountMax
             Sets the number of server alive messages (see below) which may be sent without ssh(1) receiving any mes‐
             sages back from the server.  If this threshold is reached while server alive messages are being sent, ssh
             will disconnect from the server, terminating the session.  It is important to note that the use of server
             alive messages is very different from TCPKeepAlive (below).  The server alive messages are sent through
             the encrypted channel and therefore will not be spoofable.  The TCP keepalive option enabled by
             TCPKeepAlive is spoofable.  The server alive mechanism is valuable when the client or server depend on
             knowing when a connection has become inactive.

             The default value is 3.  If, for example, ServerAliveInterval (see below) is set to 15 and
             ServerAliveCountMax is left at the default, if the server becomes unresponsive, ssh will disconnect after
             approximately 45 seconds.  This option applies to protocol version 2 only; in protocol version 1 there is
             no mechanism to request a response from the server to the server alive messages, so disconnection is the
             responsibility of the TCP stack.

And

ServerAliveInterval
             Sets a timeout interval in seconds after which if no data has been received from the server, ssh(1) will
             send a message through the encrypted channel to request a response from the server.  The default is 0,
             indicating that these messages will not be sent to the server, or 300 if the BatchMode option is set.
             This option applies to protocol version 2 only.  ProtocolKeepAlives and SetupTimeOut are Debian-specific
             compatibility aliases for this option.

Also similar settings are available from the server side which are ClientAliveInterval and ClientAliveCountMax. These settings palced in /etc/ssh/sshd_config on Server side.

from man sshd_config:

ClientAliveCountMax
             Sets the number of client alive messages (see below) which may be sent without sshd(8) receiving any mes‐
             sages back from the client.  If this threshold is reached while client alive messages are being sent,
             sshd will disconnect the client, terminating the session.  It is important to note that the use of client
             alive messages is very different from TCPKeepAlive (below).  The client alive messages are sent through
             the encrypted channel and therefore will not be spoofable.  The TCP keepalive option enabled by
             TCPKeepAlive is spoofable.  The client alive mechanism is valuable when the client or server depend on
             knowing when a connection has become inactive.

             The default value is 3.  If ClientAliveInterval (see below) is set to 15, and ClientAliveCountMax is left
             at the default, unresponsive SSH clients will be disconnected after approximately 45 seconds.  This
             option applies to protocol version 2 only.

And

ClientAliveInterval
             Sets a timeout interval in seconds after which if no data has been received from the client, sshd(8) will
             send a message through the encrypted channel to request a response from the client.  The default is 0,
             indicating that these messages will not be sent to the client.  This option applies to protocol version 2
             only.

Answer 2

Looks like your firewall (from different locations) are dropping the sessions due to inactivity.

I would try just like @slayedbylucifer stated something like this in your ~/.ssh/config

Host *
    ServerAliveInterval 60