A friend told me a few months ago about an audit where he discovered root logins were enabled via SSH. This obviously ended up on the report, but when questioned the admin told him that he had set up SSHD to allow root login attempts, but not actually check them, and just claiming the password is wrong, as a kind of honeypot.

How is this possible? A read of the docs of sshd shows no obvious way to do such a thing.


It is easy to construct a password hash that does not match any password. One of many ways to achieve this would be to store a hash value along with a different salt from the one it was computed from. A password hash constructed that way would never match an actual password unless you constructed a collision in the underlying hash.

Regardless of the method used to construct such a password hash, the outcome is the same. The account will appear to have a password (to any program with access to check this), but regardless of which password is entered, it would be rejected.

Whether this approach is a good idea is a different matter. I would rather have sshd simply refuse password logins completely.

  • 3
    +1 for just having sshd refuse pw logins. Unless one is in the security business, it's not even worth mucking about with honeypots. – EEAA Jan 4 '15 at 21:02
  • 3
    @EEAA Some high profile targets might have good reasons to deploy honeypots even though they aren't themselves in the security business. But we could say that honeypots are only for security professionals (who would never want to use a production system as a honeypot). – kasperd Jan 4 '15 at 21:26
  • @kasperd Yup, that's a great way to articulate it. – EEAA Jan 4 '15 at 21:27
  • Could you be a bit more specific? Can you salt the root password via SSH but not when accessing directly or from an inner network? If so, then how? Thanks a lot! – Dropout Jan 5 '15 at 9:28
  • 1
    @Dropout If the password was 12345, then $1$aaaaaaaa$3dvZZNzeA4AiIzZnIRH/B/ and $1$bbbbbbbb$yEBCjcsKE5rfe5idQt8LA0 would both be valid hashes. However $1$aaaaaaaa$yEBCjcsKE5rfe5idQt8LA0 would not be valid, and short of a hash collision it would not be valid for any other password either. – kasperd Jan 5 '15 at 10:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy