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?

  • You can also restrict the list of users that are allowed to connect using AllowUsers or DenyUsers directives. More details on this post. – Fred Jul 13 '11 at 6:46

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.

  • Thanks for all your tips, will look into those. if key and password are both required, then if an exploiter figures out a password (like if the user uses it elsewhere that is insecure), they can't get in without the key, and if the exploiter steals the key from the user's machine, they can't get in without knowing the password… right? – John Bachir Jul 19 '10 at 7:48
  • 12
    It's not the same. If you require just the key, the server can't enforce any password strength policy on the key. A careless user could have an unencrypted private key lying around on the client that leaves your server vulnerable if the key is stolen. – 200_success Jul 19 '10 at 8:01
  • mkudlacek -- I didn't know about hosts.allow before -- googling around, it seems like my dyndns whitelist idea isn't so silly after all, I think I'll try that out. – John Bachir Jul 19 '10 at 8:50
  • 1
    200_success -- so is it possible to require both a key and a password? – John Bachir Jul 19 '10 at 8:51
  • I also use the DenyHosts application to help lock out people who keep trying to get in, and failing. A nice little pro-active automated way of blacklisting people.. – James T Snell Aug 14 '13 at 17:13

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.

  • I'd go with this if you just want to "increase general security" but you should probably try to solve particular security problems instead. – Stefan Thyberg Jul 19 '10 at 8:29
  • I use this at all sites that I ssh into, and it's very effective imho. – Sirex Jul 13 '11 at 6:56
  • Isn't this the same thing as having a password that is 4 characters longer? – John Bachir Jan 11 '12 at 21:10
  • not really. There's 65536 ports, and 26 letters. Also you have have the knock sequence any length, and you can limit retries using standard firewalling techniques. Its not security per se, but it's nice to have. – Sirex Feb 17 '12 at 8:41
  • well then 8 or 12 characters longer :-D – John Bachir Feb 17 '12 at 23:36

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.


Just use

RequiredAuthentications publickey, password

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

  • RequiredAuthentications is definitely non standard extension to OpenSSH – Hubert Kario Jan 11 '12 at 20:25
  • Do you know which sshd implementations support this? – John Bachir Jan 11 '12 at 21:08
  • Tectia SSH server does support it. BTW: use @nameOfUser when replying to their comments, this way they will be notified about the reply – Hubert Kario Jan 13 '12 at 23:20
  • Similar functionality is supported in OpenSSH as of version 6.2: serverfault.com/a/562899 – Søren Løvborg Mar 29 '14 at 20:13

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.

  • Yes, on my personal server I use a Yubikey token in addition to my password. The token generates a one-time password. Both are required to authenticate. Alternatively, I allow bypassing of the password/otp pair if you authenticate with an SSH key. The Yubikey is cheap and there's plenty of software to integrate it with Pam, Linux's extensible authentication system. – Martijn Heemels Jul 26 '12 at 23:25

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.


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

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.


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.

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.