I have changed the SSH default port (by updating the Port attribute in the /etc/ssh/sshd_config file). But what I would like to do is still make it appear as if everything is working as expected if someone was to try and connect to SSH over port 22.

Currently, after changing the SSH port and attempting to login over port 22, SSH returns:

ssh: connect to host server_ip port 22: Connection refused

Is there a way to return the normal output "enter password", but configure SSH to never accept logins from port 22?

My idea is, if someone is going to try and brute force my server, first port they will try is 22. But if I could spoof things and make it appear that SSH is working on port 22, they would be wasting their time and would never get access.

Tried searching online for this but it's bringing back unwanted results.



It's possible to run 2 different SSH servers on 2 different ports, one refusing all connections while appearing in working order, while the other works fine.

Why one would do that though is beyond me. Investing in a defense featuring IPS, IDS, firewall, the lot, seems to be the prudent approach, given enough funds.

If you just want to refuse access to script kiddies, disable password logins and stick with public key logins.

Rate limiting and fail2ban is a good enough deterrent IMO for the bots.


You can also run Kippo https://github.com/desaster/kippo as an SSH honeypot, which simulates succesful login and you can log everything the user tries to do while "in" the server.

  • Great minds think alike :-) – HTTP500 Jan 25 '15 at 15:06
  • 1
    +1 I wouldn't add this to a production system though. It should be run separate. – fuero Jan 25 '15 at 15:20
  • 2
    I agree with @fuero that a honeypot doesn't belong on a production system. A lot can be done to protect a honeypot against attacks such as running it in a sandbox. But regardless of how much you do, having the honeypot still means there is more code on the system in which vulnerabilities can exist. A closed port is always going to be harder to compromise than a port with something listening on it. – kasperd Jan 25 '15 at 15:53

It sounds maybe like you want to run a SSH honeypot. There are lots to choose from depending upon the level of interaction you want. Kippo is a popular one.

But unless you have a good reason for doing so, I agree with fuero that you should just use something like fail2ban or DenyHosts.

  • I found this relevant quote in the Kippo FAQ: "By running kippo, you're virtually mooning the attackers. Just like in real life, doing something like that, you better know really well how to defend yourself!" – kasperd Jan 25 '15 at 16:12

If you run a separate SSH server on port 22, you could set it to not allow any users to login by using the AllowUsers option in the sshd configuration file. The man page says:

        This keyword can be followed by a list of user name patterns,
         separated by spaces.  If specified, login is allowed only for
         user names that match one of the patterns.  Only user names are
         valid; a numerical user ID is not recognized.  By default,
         login is allowed for all users.  If the pattern takes the form
         USER@HOST then USER and HOST are separately checked, restrict-
         ing logins to particular users from particular hosts.

You can set a username that doesn't exist, and allow it to only connect from localhost. The SSHD will still be available on the port, but whatever username an attacker tries to use won't be allowed to login.

You can also combine it with requiring public key login and disallow passwords, for added security.

However, as kasberd says, a closed port is always going to be harder to compromise than a port with something listening on it. You would still be vulnerable to bugs in the sshd server software that might allow an attacker entry despite these measures.

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.