Home / server / Questions / 161699
Accepted
John Bachir
Asked: 2010-07-19 23:33:08 +0800 CST

How can I increase ssh security? Can I require both a key and password?

  • 772

I have a small network of servers and I would like to increase the general security. I don't have enough time/money/paranoia to set up a VPN -- what's a basic way I can increase the security of my system?

One thing could be to require that users both send their key and enter a password. This is kinda hard to google for because everything about "ssh key password" is about sshing without a password. :-)

One scheme I've always wanted to toy with is requiring that incoming connections only come from a whitelist of dyndns ip addresses. I know some security heads would vomit at the thought of the idea, but the fact of the matter is it would add very significant complexity to exploit a box.

What do you think? What else is out there?

security ssh

9 Answers

  1. Best Answer

    The login with password and key is the same as "just with key". During the key creation, you are asked to enter passphrase. If you leave it blank, you won't be asked for a password. If you fill some passphrase, you'll be asked for it everytime when you want to login.

    If you are concerned about security, consider some of these advices mentioned trillion times in this forum:

    • Disable ssh login for root
    • Allow ssh access only from defined ip addresses (iptables, hosts.allow,... )
    • Move ssh port to another port (more obscurity then security, but it works)
    • Monitor foreign login attempts and react accordingly
    • Keep your system up-to-date

    Etc, etc.

    Update: Please refer to the answer here for how to require both a public key and local system password with an OpenSSH server.

    • 8

  2. One idea I found interesting is port knocking - basically, in order to establish the ssh connection, you first have to probe on a sequence of other ports, before the ssh server will acknowledge a connect request. If the correct sequence of ports is not used, there is no response, so it effectively looks like there is no ssh server running. The sequence of ports is customizable and can be shared with your intended users; everyone else would effectively be unable to connect.

    I haven't tried this myself, but from what I've heard (which isn't much, actually) the overhead is negligible and it lowers your visibility profile tremendously.

    • 6

  3. Patches related to enabling directly in SSH and lots of relevant discussion:

    This can also be done without modification by having a password verification script combined with the use of the ForceCommand configuration option.

    Finally, though no module exists for it, if you moved the public key authentication to PAM then you would be able to require both steps to pass before PAM considered authentication successful.

    • 3

  4. Just use 

    RequiredAuthentications publickey, password

    in sshd_config if you are using sshd from ssh.com. This feature is not available in OpenSSH.

    • 2

  5. You could also use one-time passwords to increase security. This would allow users to login from an insecure terminal, which may have a keylogger, if they previously generated the next password. Also there are password generators that can be installed even on older Java MIDP phones, that you carry with you all the time.

    • 1

  6. I would recommend that you never ever run a sshd, rdp or such management services with no IP restriction. In fact, I would suggest limiting access to such services to administrators connecting over VPN.

    • 1

  7. Regarding your original question about requiring both a key and a password, if you're running RHEL or CentOS 6.3 this is now posible. The RHEL 6.3 release notes describe it, it's a matter of adding this to your sshd_config

    RequiredAuthentications2 publickey,password
    • 1

  8. I strongly agree with 3molo. OpenSSH is the default SSH server of Linux and Unix. There is no reason for us to change it, especially for security. VPN should be the best solution, which can encrypt our traffic and provide the 2-step password authorization.

    • 0

  9. Not sure why no one has mentioned it but - you should make sure to generate the keys longer than default 1024 bits which is no longer considered secure.

    • 0