2

Over the last week, my SSH connection to an Amazon EC2 instance keeps getting disconnected with

Write failed: Broken pipe

Reading through a few sites, I assumed it was due to no timeouts being set so I created a ~/.ssh/config file as follows based on 

### Stop timing out connections
ServerAliveInterval 120  
ServerAliveCountMax 20  

TCPKeepAlive yes

### SSH Connection pooling for faster additional connections to a machine
ControlMaster auto  
ControlPath /tmp/ssh_mux_%h_%p_%r

Host *  
  ControlMaster auto  
  ControlPath ~/.ssh/control/%r@%h:%p  
  ControlPersist 3600  

### Make it so ssh-ing from one server to another passes keys around automagically
Host *
ForwardAgent yes

### Get rid of SSH connection delays
GSSAPIAuthentication no

### Use less encryption on servers I cant get to off-network
Host 10.* 172.* 192.168.*  
Ciphers blowfish-cbc

These settings didn't seem to have an effect, yet I realized that when I'm not at home, the connection stays idle like it has for the last year. I've ssh'ed into the instance on two separate networks other than my home Wifi, so I'm guessing there is something that happened at home in the last two week to change how the SSH connection behaves.

Using Wireshark or otherwise how can I follow/diagnose what/where the problem for broken SSH pipes occurs on my home network?

Using

  • Mac OS 10.7.5
  • OpenSSH_5.6p1, OpenSSL 0.9.8r 8 Feb 2011
  • Amazon EC2 AMI t1.micro
Improve this question

2 Answers 2

Reset to default
1

Check for local keep alive settings on your mac. These were mine...:

sysctl -a | grep tcp.keep
net.inet.tcp.keepidle: 3600
net.inet.tcp.keepintvl: 150
net.inet.tcp.keepinit: 75000
net.inet.tcp.keepcnt: 8

I needed to change the keepintvl setting to some higher value:

sudo sysctl -w net.inet.tcp.keepintvl=7500

Then the ssh "write failed: Broken pipe" error messages vanished.

Improve this answer
0

You don't state what OS is running on your EC2 instance. Let's assume it's a variant of linux.

The first thing you should do is increase the amount of logging your SSHD provides. You have two ways of doing this. You could either change the options so that SSHD always starts with the debug flags, or you could start up another instance on a non-standard port. Either way, the secret to getting debug output is to use -d's. From the man page on an Mint (Ubuntu variant) server

-d Debug mode. The server sends verbose debug output to standard error, and does not put itself in the background. The server also will not fork and will only process one connection. This option is only intended for debugging for the server. Multiple -d options increase the debugging level. Maximum is 3.

From your client, you can use the verbose options for ssh TO the server, such as ssh -vvv [email protected] -p port you used for your sshd.

One more thing I would suggest is to get rid of most of the items in your config file, just to make sure you're not adding to the problem.

None of these things are answers, but they could get you closer to one.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .