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, 2011 at 6:46

9 Answers 9


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? Jul 19, 2010 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. Jul 19, 2010 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. Jul 19, 2010 at 8:50
  • 1
    200_success -- so is it possible to require both a key and a password? Jul 19, 2010 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.. Aug 14, 2013 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. Jul 19, 2010 at 8:29
  • I use this at all sites that I ssh into, and it's very effective imho.
    – Sirex
    Jul 13, 2011 at 6:56
  • Isn't this the same thing as having a password that is 4 characters longer? Jan 11, 2012 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, 2012 at 8:41
  • well then 8 or 12 characters longer :-D Feb 17, 2012 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 Jan 11, 2012 at 20:25
  • Do you know which sshd implementations support this? Jan 11, 2012 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 Jan 13, 2012 at 23:20
  • Similar functionality is supported in OpenSSH as of version 6.2: serverfault.com/a/562899 Mar 29, 2014 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. Jul 26, 2012 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.

You must log in to answer this question.

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