When running a public web server (e.g., with Apache), I've heard it's recommended to bind SSH to a second IP address, different from the one Apache is listening to.

But for me it seems like this is only a matter of obfuscation - once an attacker knows the second IP address, the situation would be the same as with a single IP address.

Am I right? Or are there any other benefits of using a second IP address except for obfuscation?

  • 2
    Unless you're talking about a honeypot I dont see the benefit
    – Purefan
    Feb 2, 2016 at 11:37
  • Look into port knocking. It is not as good as running ssh over an isolated network, but it is better than plain ssh when it comes to 0days
    – Navin
    Feb 3, 2016 at 16:11

5 Answers 5


Unless that IP address belongs to a dedicated management network which implements additional security, it is a waste of resources.

Both IPs are, obviously, ending up on the same server. This means that, unless they come in through different networks (i.e. a management network that implements additional protection), there will be no difference locally between a connection to SSH going on one IP or the other: you can firewall these exactly in the same way (if you want) and it doesn't make any more or less obvious in the logs.

The only thing you're "hiding" is the relation between the SSH server and the web server and, unless you have very poor procedure for picking up account names, then it shouldn't matter.

If you're using a dedicated management network, however, it's a different matter: such a network could require all connections to go though a secure authentication phase and impose extra limitation on the conneting party (for instance, you can require them to be physically connected to the network, or go through a VPN requiring 2FA and making sure your client is "clean").

  • Hi @Stephane (+1) - could you explain why? For future onlookers, it would help if you could explain the idea behind the strategy, and then explain why that idea is flawed.
    – smeeb
    Feb 2, 2016 at 11:36
  • 5
    Could you explain your comment "unless you have very poor procedure for picking up account names"?
    – gardenhead
    Feb 2, 2016 at 18:12
  • 2
    If the account you use to connect to the SSH server is the name of the web site, putting both on the same IP address reveals that fact. It's not really a big issue since that shouldn't (in theory) weaken security
    – Stephane
    Feb 3, 2016 at 7:49

You are basically correct. It is obfuscation. Obfuscation is not without value, but you should not rely on it.

The first answer is correct, BTW, that it is good practice to host management services such as SSH on a separate network (i.e., not the internet).

  • An obscure port, port knocking and ssh on a separate IP all provide some obfuscation benefits. Obfuscation mainly has value in avoiding untargeted (automated scan) attacks. Moving ssh to another IP offers the least benefit in this regard since it will still be found on the default port by a range scan. Moving the port will be a bit more effective since fewer scans will cover a wide range of ports or these scans will hit fewer hosts per unit time. Port knocking will be most effective against untargeted attacks since scans would have to cover many ports and in a particular order to work.
    – Bell
    Feb 3, 2016 at 17:30
  • Well, there is one more benefit, which is that an attacker doesn't know that SSH service on IP x gives access to the server of, for example, web site y. When sshd and httpd are seen on the same IP, it's obviously the same machine. When the IP's differ, the attacker targeting site y won't know that the SSH daemon listening on IP x gives access to the same server.
    – Mark Koek
    Feb 4, 2016 at 11:51

It is a bit like moving SSH to a different port. You just hide something (poorly) and that shouldn't be something to rely the security of a system on. It might throw off the attackers that really don't know what they are doing (and they will not get into ssh anyway if it is setup properly) but is useless otherwise.


With fwknop deployed, anyone using nmap to look for SSHD can't even tell that it is listening - it makes no difference if they want to run a password cracker against SSHD or even if they have a 0-day exploit.

I have some notes here for using fwknop. I can also ssh into containers behind NAT with no port open externally.


I suppose a good question would be why do you even have SSH open to the WAN, anyway? ... As others have mentioned, administering via a private network is the Holy Grail.

The best approximation (and the reason I even bother to answer here) for a WAN connection is an IP wrapper or firewall ruleset that only allows SSH from a particular IP address. One such strategy is a dedicated SSH server that uses only key-based authentication (if necessary, from any IP address), and a WWW server that only accepts inbound SSH from said server's IP address. When an attacker has to guess, and then spoof, an IP address to get in, you have added a good layer of protection. That might be one application for your 2nd IP address ...

You must log in to answer this question.

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