I recently set myself up with a VPS and have been hardening it to the greatest extent of my limited knowledge!

I was configuring OpenSSH to use certificate based authentication when something did not sit well with me. This could well be down to me missing a configuration option along the way, but if not, it is surely quite concerning:

When adding a key to the remote host, I used something resembling ssh-copy-id username@remote-host to copy it there. When doing this, it prompted me for the password for username@remote-host, which I duly provided.

When I went in to work the next day, I did the same from a machine in work, just to act as a failsafe and then turned off password authentication. However, from a third machine, I was still able to upload a key while only needing to know the username and password.

If this is how it works, surely an attacker will only need to compromise the password, even if cert based authentication is enabled - thus negating its use?!

I have to be missing something, right?

(Don't worry, I have two factor set up on my VPS using Google Authenticator now!)

  • Did you restart sshd? – Digital Chris Nov 20 '14 at 17:11
  • 1
    It's not clear what you're asking here. Apparently you thought that you'd disabled password authentication, then found that you hadn't. (If you're having trouble with that part, you can ask on Unix & Linux; be sure to say exactly what you did (what commands you ran, what files you edited, etc.).) Are you asking if it's better to turn off password authentication? Or if it's better to use key-based authentification (I assume that's what you're calling “certificate-based authentication”, it's what you get when you use ssh-copy-id)? – Gilles 'SO- stop being evil' Nov 20 '14 at 18:56

Ensure that /etc/sshd_config contains the following line:

PasswordAuthentication no

You likely have that line commented out, which allows you to fall back to password authentication. Be sure to restart sshd after you change your config.

If you want to install a key from a new computer, you can temporarily comment out that line, install your key after authenticating by password, and then re-disable password authentication.

I also recommend disabling root login:

PermitRootLogin no

(If you only allow public-key authentication, this won't matter as much if the root user doesn't have an ~/.ssh/authorized_keys file, but it is still good to have in case you change your config later.)

|improve this answer|||||

You can always connect with the username and password. Pushing a key does not prevent the password from working; the key offers an additional method to open a session on the target server.

If you want to "deactivate" password-based authentication, you can replace your password with a huge random one that you do not remember.

|improve this answer|||||
  • Pushing a key doesn't prevent a password from working, but when @Richard "turned off password authentication" I assume he meant PasswordAuthentication no in sshd_config like help.ubuntu.com/community/SSH/OpenSSH/…. – Digital Chris Nov 20 '14 at 17:13
  • Or, better, you can replace the password entry in /etc/shadow with an *. Also, sshd doesn't accept blank passwords by default, as PermitEmptyPasswords is "no" per default. Best is to do PasswordAuthentication no. – user10008 Nov 20 '14 at 17:46
  • @user10008 - Disabling password entry in /etc/shadow is probably not desirable, as typically you may want the ability login to the machine via password when you are physically present (without requiring any of the standard tricks like booting into single user mode or mounting the hard drive from a live cd/usb and editing /etc/shadow ). You would also have to replace the password entry for every user to have the equivalent to PasswordAuthentication no. – dr jimbob Nov 20 '14 at 18:29
  • 1
    @drjimbob therefore I said best is PasswordAuthentication no. Wanted to say that there are better practices than replacing passwords with huge random ones that are discarded. – user10008 Nov 20 '14 at 18:45
  • @user10008 - My mistake. I thought "or better" was responding to DigitalChris not to TomLeek. My bad. – dr jimbob Nov 20 '14 at 19:28

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.