Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

As the title says, when I'm using wifi at my office, I'm able to copy files to and from my server using SCP, but for some reason SSH is non-responsive. It just hangs, doesn't print anything, and I can't ctrl-c to end it; I have to close the terminal window.

When I'm plugged in on the LAN, everything works fine. Any ideas how to figure out what's going on?

share|improve this question
If it helps, here is the output from my ssh -vv (IP addresses and keys redacted): pastie.org/2723594 – Dave Oct 19 '11 at 12:37
Compare the IPs you get when you connect via WiFi vs wire. Are they from the same subnet? If not, confront this with /etc/ssh/sshd_config on the SSH server. – rozcietrzewiacz Oct 19 '11 at 14:27
How does it look like on the server-side? $(which sshd) -d – Nils Oct 19 '11 at 18:42
Thanks, this helped diagnose the problem, but it seems to have been with the PTY allocation, and not an IP address issue. (See my response below.) – Dave Nov 2 '11 at 15:31
up vote 5 down vote accepted

I finally found what was causing the issue. This was due to my router blocking TCP keepalive messages when I connected wirelessly (go figure).

ssh my_server -o TCPKeepAlive=no solved all my problems. Yay!

From the documentation:

  Specifies whether the system should send TCP keepalive messages
  to the other side. If they are sent, death of the connection or
  crash of one of the machines will be properly noticed.  However,
  this means that connections will die if the route is down tem-
  porarily, and some people find it annoying.  On the other hand,
  if TCP keepalives are not sent, sessions may hang indefinitely on
  the server, leaving "ghost" users and consuming server resources.

  The default is "yes" (to send TCP keepalive messages), and the
  server will notice if the network goes down or the client host
  crashes.  This avoids infinitely hanging sessions.

  To disable TCP keepalive messages, the value should be set to
share|improve this answer

From your pastie it is clear that your public key gets accepted. I have a feeling it might have to do with PTY allocation, as I do not see this in your -vv:

debug2: PTY allocation request accepted on channel 0

Could you make 2 outputs from wired + wireless and diff them?

share|improve this answer
Sorry for the delayed response, been busy with many things. Okay, so it turns out this was exactly the problem. For some reason, SSH doesn't want to allocate a PTY when I connect over the wireless. The solution (workaround) to my problem then it seems is to run ssh my_server -T 'bash -i' which gives me an interactive shell, but doesn't fail on the PTY allocation step. – Dave Nov 2 '11 at 15:28
Out of interest, the diff between my logs showed that wireless connection froze at a point, where the wired had the following lines: debug2: channel_input_status_confirm: type 99 id 0 debug2: PTY allocation request accepted on channel 0 – Dave Nov 2 '11 at 15:30
@Dave did you ever figure the source of this issue out? Having the same thing here, 3 years later! – Scott Jun 30 '15 at 20:51

Verify /etc/ssh/sshd_config for server side and /etc/ssh/ssh_config for client side. (don't forget client side)
The only difference between wifi and ethernet are IP addresses.
If you have TX/RX error with wifi, It's can be also a problem. (rarely)

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.