1

I have a server in my home and I am using dynamic dns and has been so for over 10 years without issues. Logging in using ssh from outside has been no problem but I did disable the port on my router few months ago as I don't use it that much.

So here is my issue. I can log in from behind the router on the internal network using ssh and 192.168.1.xxx but when I try logging in using the domain name of my server in which it will then try through the external ip it says: "Unable to negotiate with 36.xxx.xx.xx port 22: no matching key exchange method found. Their offer: diffie-hellman-group1-sha"

In fact it should say that there was a timout failure because the port is disabled on the router.

I have tried to log in from the outside using ubuntu to confirm this and it then correctly says: "ssh: connect to host xxxx.com port 22: Connection timed out" From inside using Mac connecting to external IP it gets me all the way to the password prompt and then when I fill that in it says it was rejected??

From inside using debian connecting to the external IP it warns about possible man in the middle attack.

Why would it be listening on blocked 22 port and offering connections when I try log in using the external IP from behind the router and then rejects the login attempts but from the outside it gives my timout error as it should? Is the router being compromised?

Improve this question
7
  • 1
    To confirm; you're on one machine on your local network, trying to SSH to your external IP address and getting an error? This isn't unusual, depending on your router and configuration. Sometimes they just don't like internal addresses accessing the external IP address.
    – Stephen Harris
    Aug 27, 2016 at 2:04
  • Correct, but why would it be offering a connection all the way to the password prompt?
    – Zorro
    Aug 27, 2016 at 2:09
  • 3
    Given the routing, it's possible you're being directed to an ssh daemon on the router itself.
    – Stephen Harris
    Aug 27, 2016 at 2:22
  • Stephen said what I would have commented. You should try it on another connection to confirm the behavior.
    – Julie Pelletier
    Aug 27, 2016 at 2:31
  • That makes sense, I have checked and the Host key is the same for the domain name and two different ip addresses, one is current and the other is likely older, I am on dynamic connection so that explains this part. I will still do some more checking. On a sidenote, it seems then that Linux Mint Sarah does not have diffie-hellman-group1-sha encryption the router is offering but macosx and debian both do.
    – Zorro
    Aug 27, 2016 at 2:33

1 Answer 1

Reset to default
0

To summarize, you've observed three different behaviors when connecting from inside your network:

  • From machine A, you can't even establish an SSH connection because the client and the server don't support matching protocol options.
  • From machine D, the client rejects the connection because of a host key mismatch.
  • From machine M, the SSH connection is established but then user authentication fails.

All of this indicates that you aren't reaching the host that you thought you were reaching. As several people have already remarked in comments, when you access your external IP address from inside the network, you're in fact reaching your router. (More precisely, you're reaching your NAT appliance — for a home or small office network it's just one box doing routing, NAT, and possibly being a modem as well.) Furthermore:

  • The fact that you can't establish a connection from A suggests that the server you're reaching only supports a small subset of the available options (common on routers) and that it hasn't been updated in a while (again, common on routers) — diffie-hellman-group1-sha1 deprecated.
  • The fact that D detects a host key mismatch clearly shows that this isn't the host you were looking for.
  • M has no problem connecting because it still supports the deprecated protocol and you'd never connected to your desired server from that client so it didn't see any mismatch. You should remove the corresponding public key from the known_hosts file (ssh-keygen -R 36.xxx.xx.xx) or else you'll get an error if you try to connect to your desired server.

When you attempt to connect to your external IP address from the inside of your network, what happens depends on how the NAT appliance is configured. It's common that it sees a connection request to one of its IP addresses, and treats that as a connection to itself. That depends how NAT is configured; typically it's configured by interface, so incoming connection requests coming from the outside get translated according to the incoming redirection rules but connection requests coming from the inside are only translated if they actually go outside, not when they end at the NAT appliance.

It's common for home routers to offer an SSH interface, and there's no particular reason to disable it. Even the deprecated protocol is no big reason to worry: the attack against it is only “within theoretical range” — best avoided but not immediately broken. The fact that the software is old is cause for concern however; it might have other unpatched security vulnerabilities. Make sure that your router isn't listening to anything on its outside interface at a protocol level above TCP (i.e. let it do NAT but make sure that SSH, web interfaces etc. are restricted to internal IP addresses). And if you have wifi or if you don't trust your physical network, tighten internal connections as well.

Improve this answer

You must log in to answer this question.

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