I am trying to ssh into my server at work (CentOS) from my laptop (Ubuntu). When I am at home, I do it by running the following script on the server (I start it while I am physically at work):

ssh -R (port #):localhost:22 (name@home ip)

I do this because it doesn't accept connections from external IPs. Then, I can ssh into the specified port on my laptop, and it works fine.

However, when I am actually at work, I cant ssh to the server. The other people in my office can. They do this very simple command (only works while they are at work, since they need an IP from inside the system):

ssh (username)@(work ip)

And they are automatically logged in. When I do that, I get no response; no public key denial, no wrong username, no response at all. Eventually it times out. But I know the server has ssh running, because everyone else can do it.

Additionally, if I do this on my laptop, while at work:

ping (work ip)

I do get response packets, with no loss, almost no lag. But ssh doesn't work.

I can ssh to other places from my laptop, both while I am at home and at work. So my laptop is properly configured to ssh to things, it just doesn't reach the work server for some reason. I talked to the guy who set it up and he insists there is no whitelist; the only security from internal IPs (and I am physically on site, so I have an internal IP, so there should be no need to do the ssh -r like I do at home) is the private/public RSA key system, and I know the keys must be already set up, because it works when I do the ssh -R from home. Plus, if the keys were not set up, I would get a public key denial, instead of no response at all, right?

If I do ssh -vv, this is the last line before it times out:

debug1: Connecting to ccny6 [WORK IP] port 22.

I see other people have posted similar questions, but the responses they seem to generally be "is the server running the ssh service" etc, which I know it is as other people can ssh to do (as can I if I'm using the ssh -r tunnel), so none of those responses did me much good, unfortunately.

Summary: I can ssh to a server from OFF site via a ssh tunnel, but can't ssh to it while I am right next to it using direct ssh, even though I can ping it, and others can ssh to it.

  • Have you tried connecting with another user but the same laptop? If yes, is there still the timeout issue? – ADDB May 23 '17 at 20:18
  • Yes, still a timeout. I can also leave no username and do ssh (workip) (as one person the lab does, and it automatically puts it in his user becuase of his rsa key) and there is a timeout that way too. – iammax May 23 '17 at 20:19
  • ...oops, I forgot to take part out, idiot me... But nobody can get in from an external IP anyway. – iammax May 23 '17 at 20:32
  • I was actually only interested in whether the IP was resolving correctly – steeldriver May 23 '17 at 21:15
  • 1
    telnet <ssh_server_ip> 22 # will tell if the server is even responding. If it is, you will need to set log reporting to debug, probably on both ends, to see what's blocking the connection. The remote ssh script is bypassing some suspects, like firewalls, IPCHAINS (or whatever), and a few other things. A wild but educated guess would be that your work IP is not in AllowUsers or is in DenyUsers or you are other wise blacklisted or not on a needed allow list. – jones0610 May 23 '17 at 22:41

Based on our lengthy conversation it seems quite likely that this is not a Ubuntu problem. And, in fact, the problem you describe seems to be on the server side and not anything to do with your laptop. Therefore, my "solution" would be to ping various IPs in your subnet until you find one that does not respond. Then, change your laptop to use that IP as a static IP. Test to see if you can now connect to the server via ssh. I'll bet a diet coke this will work. Then, go back to your old IP settings and present your findings to your uncooperative IT guys, who should thank you for doing their job for them.

  • Small update: We figured it out: the log-on I was using to get onthe wifi was turned into a student account by IT when it was created for some reason. This was causing the ssh request I was sending to the server to be killed. We went to IT and fought with them for a week to turn my account into a faculty account. They did and the problem was solved. We discovered this when my co-worker tried on my laptop but didn't know my wifi password so used his own; IT certainly refused to tell us this was their policy even when we asked afterwards. We never thought it would be something like this... – iammax Jun 21 '17 at 17:55
  • I love it when my answer is correct :) – jones0610 Jun 21 '17 at 20:17
  • Well, you were right that it wasn't a Ubuntu problem... but it wasn't really an IP problem either, lol! Still, thanks for helping me diagnose... – iammax Jun 21 '17 at 20:23

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.