SCP works, but SSH doesn't (over wifi)

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?

edited Dec 20 '18 at 0:23

Rui F Ribeiro

39k1479130

asked Oct 19 '11 at 12:25

Dave

17117

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

add a comment |

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

edited Dec 20 '18 at 0:23

Rui F Ribeiro

39k1479130

asked Oct 19 '11 at 12:25

Dave

17117

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

add a comment |

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

edited Dec 20 '18 at 0:23

Rui F Ribeiro

39k1479130

asked Oct 19 '11 at 12:25

Dave

17117

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

linux ssh scp wifi

edited Dec 20 '18 at 0:23

Rui F Ribeiro

39k1479130

asked Oct 19 '11 at 12:25

Dave

17117

edited Dec 20 '18 at 0:23

Rui F Ribeiro

39k1479130

asked Oct 19 '11 at 12:25

Dave

17117

edited Dec 20 '18 at 0:23

Rui F Ribeiro

39k1479130

edited Dec 20 '18 at 0:23

Rui F Ribeiro

39k1479130

edited Dec 20 '18 at 0:23

Rui F Ribeiro

39k1479130

asked Oct 19 '11 at 12:25

Dave

17117

asked Oct 19 '11 at 12:25

Dave

17117

asked Oct 19 '11 at 12:25

Dave

17117

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

add a comment |

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

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

add a comment |

4 Answers
4

active

oldest

votes

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:

TCPKeepAlive

  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

  "no".

edited Nov 8 '11 at 13:47

answered Nov 8 '11 at 13:36

Dave

17117

add a comment |

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?

answered Oct 19 '11 at 15:42

Ole Tange

12k1451105

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

add a comment |

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)

answered Oct 19 '11 at 19:37

boup

add a comment |

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:

HISTSIZE=-1

HISTFILESIZE=-1

Disabling unlimited history seemed to fix it.

answered May 19 '17 at 16:48

Toon

add a comment |

Your Answer

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});

}
});

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f22929%2fscp-works-but-ssh-doesnt-over-wifi%23new-answer', 'question_page');
}
);

Post as a guest

Name

Required, but never shown

4 Answers
4

active

oldest

votes

4 Answers
4

active

oldest

votes

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:

TCPKeepAlive

  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

  "no".

edited Nov 8 '11 at 13:47

answered Nov 8 '11 at 13:36

Dave

17117

add a comment |

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:

TCPKeepAlive

  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

  "no".

edited Nov 8 '11 at 13:47

answered Nov 8 '11 at 13:36

Dave

17117

add a comment |

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:

TCPKeepAlive

  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

  "no".

edited Nov 8 '11 at 13:47

answered Nov 8 '11 at 13:36

Dave

17117

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:

TCPKeepAlive

  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

  "no".

edited Nov 8 '11 at 13:47

answered Nov 8 '11 at 13:36

Dave

17117

edited Nov 8 '11 at 13:47

answered Nov 8 '11 at 13:36

Dave

17117

answered Nov 8 '11 at 13:36

Dave

17117

answered Nov 8 '11 at 13:36

Dave

17117

add a comment |

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?

answered Oct 19 '11 at 15:42

Ole Tange

12k1451105

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

add a comment |

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?

answered Oct 19 '11 at 15:42

Ole Tange

12k1451105

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

add a comment |

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?

answered Oct 19 '11 at 15:42

Ole Tange

12k1451105

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?

answered Oct 19 '11 at 15:42

Ole Tange

12k1451105

answered Oct 19 '11 at 15:42

Ole Tange

12k1451105

answered Oct 19 '11 at 15:42

Ole Tange

12k1451105

answered Oct 19 '11 at 15:42

Ole Tange

12k1451105

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

add a comment |

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

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

add a comment |

answered Oct 19 '11 at 19:37

boup

add a comment |

answered Oct 19 '11 at 19:37

boup

add a comment |

answered Oct 19 '11 at 19:37

boup

answered Oct 19 '11 at 19:37

boup

answered Oct 19 '11 at 19:37

boup

answered Oct 19 '11 at 19:37

boup

answered Oct 19 '11 at 19:37

boup

add a comment |

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:

HISTSIZE=-1

HISTFILESIZE=-1

Disabling unlimited history seemed to fix it.

answered May 19 '17 at 16:48

Toon

add a comment |

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:

HISTSIZE=-1

HISTFILESIZE=-1

Disabling unlimited history seemed to fix it.

answered May 19 '17 at 16:48

Toon

add a comment |

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:

HISTSIZE=-1

HISTFILESIZE=-1

Disabling unlimited history seemed to fix it.

answered May 19 '17 at 16:48

Toon

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:

HISTSIZE=-1

HISTFILESIZE=-1

Disabling unlimited history seemed to fix it.

answered May 19 '17 at 16:48

Toon

answered May 19 '17 at 16:48

Toon

answered May 19 '17 at 16:48

Toon

answered May 19 '17 at 16:48

Toon

add a comment |

draft saved

draft discarded

Thanks for contributing an answer to Unix & Linux Stack Exchange!

Please be sure to answer the question. Provide details and share your research!

But avoid …

Asking for help, clarification, or responding to other answers.

Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.

Some of your past answers have not been well-received, and you're in danger of being blocked from answering.

Please pay close attention to the following guidance:

Please be sure to answer the question. Provide details and share your research!

But avoid …

Asking for help, clarification, or responding to other answers.

Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Name

Required, but never shown

Name

Required, but never shown

This page is only for reference, If you need detailed information, please check here

搜尋此網誌

Cfrtjryk