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?

  • 1
    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
  • 3
    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
  • 1
    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

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
| 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?

| 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)

| improve this answer | |

This is 6 years later, but I've been struggling with a problem that seems similar, but that ultimately was not. But I provide this in the hope someone finds it useful.

I could perform scp, but not ssh. Then I realized that I could perform commands over ssh, such as ssh user@server 'ls -l'.

The problem was in the .bashrc: It contained the following lines:


Disabling unlimited history seemed to fix it.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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