I’m setting up a new home server running Manjaro Minimal (no GUI), so my primary means of interacting with it will the via SSH. On my last machine, I did the following to secure my SSH connections:
Changed default port away from 22;
Used 64 character account password;
Installed and enabled Google Authenticator support–to SSH in, a 6 character one time password is needed; and
Activated firewall.
One thing I’ve not done that I know everyone says to do: Set up automated authentication via a public/private key pair.
I understand all the technical reasons why this is more secure than a one time password setup, but my biggest concern has always been that anyone with physical access to an unlocked device with the public key stored on it would be able to SSH in to the server.
I make sure to leave my screen locked on my main work machine when I’m not at my desk, but the whole idea that someone who manages to get their hands on my unlocked client computer will be able to gain access to my server via SSH without any sort of second factor authentication seems inherently insecure.
My Google Authenticator-compatible password manager, where I keep my verification code generator for my servers, is protected by a complex password with letters, numbers and symbols, or more preferably face recognition on my phone or unlock via my watch, which only works when it’s on my wrist.
What am I missing? Does the public/private key recommendation assume I’m storing my client/public key on an external (USB ?) device that’s only connected to the client computer when I’m sitting in front of it?
Put another way: I’ve got the instructions to turn on public/private key authentication. What’s the best practice for actually using it well?
You’ve summed it up very well. In the end, whether a public/private key pair would be more secure than passwords is only a matter of opinion. The internet is rife with systems that got “broken into” because someone used authentication keys for logging in from their laptop and their laptop got stolen.
In the end, I personally feel that a strong password ─ which doesn’t mean that it needs to be excruciatingly long; just that it would be hard to guess and difficult to crack with brute force ─ with a sufficiently powerful encryption should suffice.
That, and preventing any kind of direct root logins, i.e. disallow direct root logins in /etc/ssh/sshd_config and comment out all entries in /etc/securetty. Also make sure that the server requires the use of su for root access, or at the very least sudo with the target password as a requirement, not the user’s password.
I appreciate your thoughtful response. Your approach certainly sounds more manageable (IMHO) than inviting a new easy-to-lose dongle into my life–I say this as someone who loses his keys fairly often. I always find them again, but still.
Do you think it’s better or worse vs. a strong password to have login via Google Authenticator or the like enabled? Better/worse from a security perspective, that is. I’ve actually gotten locked out of a machine when it hard crashed during a Google Authenticator authentication attempt and the authenticator on the server got out of sync with the time server, or something. It just never worked again. I had to boot from another drive and edit the config files to fix it.
I’ve been able to memorize a 21 character password that’s a combination real words, fake words, numbers, and symbols. I feel like that has to be good enough. I’ve got a 64 character random password that 1Password generated for my newest little Pi server, but I hate it because I have NO IDEA what it is and never could memorize it. I much prefer the string of words-and-numbers approach.
I will implement your suggestions immediately w/r/t the root login.
I wouldn’t trust Google for anything, especially if it’s privacy-/security-related.
The thing is, spaces are legitimate characters in a password, so I think the best approach would be to use a passphrase ─ i.e. a sentence or part of a sentence ─ that only holds meaning to you. You don’t have to embed any numbers or symbols, although you could always do that if you’re comfortable with it.
I always forget this, and I think it’s 'cause I was using Macs and Windows machines for decades before I started working with Linux, and spaces very much were not an option there. I’ve always done.passphrases.like.this. Do you think the spaces are more secure than using spaces, or is it about the same?
Yeah, I’m honestly surprised there’s not some sort of self-hosted replacement for whatever it is the Google Authenticator servers actually do. There probably is.
Random question: is it possible to make the Manjaro password prompts actually show stars or dots or something when entering a password? I’ve got a wonky keyboard and sometimes it randomly dies, and actually knowing that input is happening would occasionally be useful.
I think you meant “dots” in one instance of the word in that sentence.
Well, you can use any character as the word delimiter. A space is just a character like any other. I was only suggesting spaces for the sake of being able to remember your password.
For the sudo prompt, yes. Not for the login prompt ─ at least, when we’re talking of tty logins.
You can combine a key pair with a OTP. In this case you would need the private key and a OTP (depending on the setup, you also need the user password, which might be a little bit to much.).
Also a private key should be encrypted, you would need to unlock the key before it can be used. For convenience reason, the key is usually unlocked after you locked in, but it does not have to be like this.
What’s the real benefit of this, from your POV, on a personal home server? At least, compared to implementing the security measures @Aragorn described, which don’t involve the certificate and seem easier to do?
I agree that public-private key encryption and authentication is objectively more secure, but the question I’m having now is more: under what circumstances are just using a strong password and locking down SSH/the root account as described above not enough?
I didn’t read the entire thread, but for login/password on servers I use fail2ban, so it bans IP in iptables from failed login attempts (depending on the number of failed attempts during the time span you have configured).
Also something I never did but read about, was the “port knocking” to unlock access to SSH. It seems to be another good layer of protection on top of other measures.
//EDIT: on my side I fear the public/private keys, not if someone steal them, but if I LOSE them
Yes there are a lot of tricks (other port, knocking, banning). I did a lot of them.
At home my network has NO access from outside, so the danger is not the same as with a public server. But as basic security i did:
disable password - logon completely (only public key)
disable root-login (even with key) completely (but i am able to use sudo when i am logged in)
all keys i do use are protected with a passphrase
i do change my keys after 2 years
i do have more then 1 key that is able to log in
i do have more then 1 user who is allowed to sudo (this is a must on remote servers)
i do habe physical access
if a key where stolen, i would replace it with a new one (one step in authorized-keys on the server) even when the passphrase would protect the key
Wehter you use a sort of ssh-agent is up to you. As standard ssh will ask you every time for the passphrase. When the session ends, there is no danger of finding the decrypted password in memory. While the session persists the biggest risk is the session itself.
A good ssh-agent won´t store the decrypted key unencrypted in memory . Most ssh-agents are configurable to your needs and wishes (like disable key after X min).
Out there it is dangerous: IPs can be faked, distributed attacks are the norm today, portscanning is easy, dictionary attacks are normal. mostly on easy to guess usernames (root,me,system,lightdm,user1 …). So with password-login you have to have a really good one
You have to watch out for your logfiles. There you will detect if someone tries, and how hard he tries.
I have seen logs with thousands of tries. Never using the same IP, never using the same “name”. This has been 10 years ago !
I require a private-public keypair in order to automate rsync and backup tasks in the background. It will fail if it requires a passphrase input (since it runs in the background as a service.)
It assumes that wherever the key is stored, it’s secured and only accessible by the authorized user (you). This can be on a laptop, desktop, external drive, etc. If you use full-disk encryption, then once the laptop powers off, the burglar has no access to anything on the drive, including the private key.
Install a pad filled with thermite along the bottom of your laptop with a magnetically-activated relay ignition switch. If someone attempts to leave with your laptop, the thermite will immediately ignite upon leaving the magnet’s range.
→ Automation ← 