How to properly setup SSH Key Authentication - If you are logging into your server with root, you are doing it wrong!

in sysadmin •  8 months ago

If you are running a witness, full node, web server, or any Linux box the very first thing you should do is to stop using root to login, and set up SSH key authentication and disable root logins.

This process is surprisingly easy once you have done it a few times, but this guide will make it absolutely painless even for the non-admin types. The post looks overwhelming, but it isn't a long process, I can do it inside of five minutes on new servers.

When you first get a Linux server you will most likely receive a root password and sign in with that. Continuing to log in using this account is very insecure and not recommend. Not only does this allow anyone who breaks your password access to everything on your system, it means you are doing every command with full admin access even when you don't need it.

These steps are what I do with every server I own or work with. All my servers are Debian based (mostly all Ubuntu at this point) so these commands will be for Ubuntu. They should be the same for most versions of Linux except for the Update Packages section, which will use yum on RedHat flavors like CentOS.

To properly secure a new (or current) server, you want to do these steps, all of which I will cover in detail below.

  • Change root password
  • Update Packages
  • Create New User
  • Add new user to sudo group
  • Create SSH Key
  • Install SSH Key for new user
  • Test SSH Key authentication
  • Disable root login & password authentication

Change Root Password

The first thing you should do is change your root password. Most service providers will give you a short 8-16 character password to get you started. This is also usually displayed in clear text in their control panel.

You are going to want to change this password immediately, I recommend a secure password like this:

jsEwnxFr3Dj]%&-K}i_}zU:R,oz=3=86a7A*.jD9tz8Aq*Y7-fM%FkQw_.:UWM#n

As ridiculous as it looks, you will never need this password except in extreme emergencies. Using a good password manager will make this an easy process. Going forward you will only need your custom user password to do anything as root, so this password won't typically be used. Be sure to keep this password safe.

To change your password in Linux just issue the following command and follow the prompts.

passwd

Update Packages

This is the only thing I recommend doing before the next steps, but even this can be done later. I like to do it first just to get it over with and make sure I am dealing with an up to date system. Each provider will provide the server in different states.

The first step is to download an updated list of packages. You do this with the sudo apt update command.

This will update the operating systems package manager (apt or apt-get) has the most current list of packages that can be installed.

This does not upgrade any packages, it just updates the database that tells apt what packages can be installed.

We next want to tell apt to update all packages that are installed.

To upgrade all packages to the latest version and resolve any dependencies properly, you use sudo apt dist-upgrade.

You may already be familiar with apt upgrade and not apt dist-upgrade.

You can see the difference here:

tl;dr Unless you are using advanced apt features like freezing versions and running personal package archives (PPA) then you should use apt dist-upgrade to resolve all dependencies automatically.

Create New User

Now that we know the system is up to date, you need to create a user account of yourself. Logging in as root is insecure as it exposes root to the public but it also means you will use root for every task regardless if you require it.

Create a user is very easy, let's make a user hoban

sudo adduser hoban

It will ask you for a password, for this password you want something long, complex, but something you can remember as you will type it everytime you want to do something as root.

I like to have a Full Name but I don't fill in the rest of the options, just hit enter and then Y to confirm.

From this point on, you will only login as this user, but don't logout yet. Let's do one more thing, and then we will switch users.

Add new user to sudo group

Now that we have a new user, we are going to want to give that user sudo access. To do this, you add the user to do the sudo group.

usermod -aG sudo hoban

You will not receive any feedback from this command unless you did something wrong.

If you don't know what sudo is, sudo allows you to run commands as an unprivledged user with root power while properly logging who executed the command. This last feature is critical for multi-admin systems.

Basically, if you want to do something that requires root permissions, prefix the command with sudo.

You will notice I used sudo above, even though I was root. I did this for two reasons. To prevent any issues if you were doing the commands on an account other than root, but also to get you in the mindset of using it.

At this point, login to SSH again using your new credentials. You can test to make sure you got everything correct at this point by doing the following command:

sudo apt update

You will be promopted for your password and then should see the package list update. If you get a permission denied after doing the password correctly, make sure you have executed sudo usermod -aG sudo hoban, replacing hoban with whatever user you created. You will need to do this as root, and relogin as your user when adding a group.

Create SSH Key

At this point, we want to create our SSH key pair, this is a public and private key you will use as a what you have type of security. Using a passphrase on your key is optional, but I highly recommend using a passphrase. Once you use an SSH key for authentication, that is all that is required to get into any server you add your key to. Without a passphrase, they don't need to know anything, they only need access to your private key.

A good SSH client like SecureCRT or using SSHAgent will make using a passphrase less painful.

I highly recommend using ed25519 algorithm for your SSH key, most system support this algorithm but keep in mind some older software will not. If you use an SSH client on your mobile phone or some older clients, you want to confirm support. I would opt to upgrade your software over resorting to using the current standard RSA key.

The difference between rsa and ed25519 is minor but significant. rsa uses elliptical curves that many believe have been compromised by the NSA. ed25519 uses new algorithms that are much more secure. You can read the differences in detail here if you have the stomach for it.

There is two popular ways to create an SSH key. Using your SSH Client (Putty, SecureCRT, or whatever you use) or using ssh-keygen on Linux. If you use Linux, you will need to download the private key off the server and delete it. This is not as secure as doing it all on your private workstation.

If you have local Linux/Mac machine, you can run the following command to make an ssh key using ed25519.

ssh-keygen -t ed25519

You will be prompted where to save the files, and if you want a passphrase (Yes, yes you do!). By default this will create two files, id_ed25519 and id_25519.pub. The first is your private key, and is what you use on your workstation to confirm your identity, the second is what you put on any server that you want to be able to login into.

It is safe to share your public SSH key, but your private ssh key you shoudl treat like your Bitcoin private key.

PuttyGen is the easiest way to create an SSH Key on Windows. Make sure you choose ed25519 and follow the prompts and save the public and private key some where safe.

You will need to configure your SSH client to point to your private key, and you will need to install your public key on your server [next step].

Install SSH Key for new user

To install your public key on your server involves a couple of steps. First login as your personal user account, you will not need root for any of these commands, so do not use sudo as we are only changing your local user files.

make sure you are in your home folder

cd ~

make .ssh directory

mkdir .ssh

lock down permissions on .ssh

chmod 700 .ssh

add your key

vim .ssh/authorized_keys
Paste the one-line of text from your public key file and hit escape to go into command mode then write & exit.

Hit escape
:wq # Write & Exit

Change permission of your public key

chmod 644 .ssh/authorized_keys

At this point, you should be all set. If you did everything correctly you should be able to login with just your SSH key and passphrase.

Test SSH Key authentication

Add your private key to your SSH client, and make sure you disable password authentication and only leave public key authentication enabled.

For the most popular SSH client (Putty) you will want to add your private key here:

Once you have confirmed you can log in via your SSH key and hopefully a passphrase, you will want to disable root login and password authentication.

Disable root login & password authentication


WARNING DO NOT DO THIS STEP UNTIL YOU HAVE CONFIRMED YOU CAN LOGIN WITH YOUR SSH KEY


You will lose access to your server if you have not first confirmed you can log in with only your SSH Key and passphrase.

If you have confirmed you can log in, we will now edit the SSH server files to prevent anyone from being able to log in as root or with a password.

sudo vim /etc/ssh/sshd_config

Look for the two lines:

PermitRootLogin yes
PasswordAuthentication yes

You want to make both of these no, and his escape :wq to save and exit. You will then need to restart the ssh daemon with the following command.

sudo systemctl restart ssh

It will warn you of losing connections if things are not set up properly. Hit yes, and do not log out!.

Immediately open a new SSH connection and confirm you can log in before closing this session. This is your only last ditch effort to save yourself if you didn't do all the steps properly.

That's it, the post was really long, but the actual steps are quite quick and easy.




Authors get paid when people like you upvote their post.
If you enjoyed what you read here, create your account today and start earning FREE STEEM!
Sort Order:  

When I did this with @ginabot's server after your recommendation, i had to search each step on Google...
It went alright but to have a comprehensive tutorial like this in hand can speed up my next server setup for sure :)
Thank you!

Super helpful post! One quick thing, the command to generate the SSH key has a typo, you put 'ad25519' instead of 'ed25519'.

·

Thanks! I can't tell you how much I hate editing / writing posts on Steemit, it is so laggy and Grammarly makes it virtually impossible to read due to some quirky stuff going on with their forms. Only site I have ever had problems with it.

·
·

Atom, emacs, and vim have preview modes for markdown that include checkers. I like to use external editors because then it gives me an excuse to use git to version control my posts.

Next evolution is to post to steemit directly from git (See https://github.com/r351574nc3/docker-git-steem-bot)

·
·
·

VS Code, Sublime Text, and other GUI editors have the ability to use git directly in the editor.

Thanks for this great tutorial, and the heavy detail for the technically illiterate...like myself.

As ridiculous as it looks, you will never need this password except in extreme emergencies. Using a good password manager will make this an easy process.

Sorry if I missed this somewhere...what password manager do you recommend?

This assumes sudo is the group that gives sudo access. This isn't the case on every linux distribution. Some use wheel or admin

To ensure use of sudo group do the following after step 2 Update Packages

  1. visudo
  2. Add %sudo ALL=(ALL:ALL) ALL
·

These steps are what I do with every server I own or work with. All my servers are Debian based (mostly all Ubuntu at this point) so these commands will be for Ubuntu.

·
·

That's not necessary, I was pointing information that would be useful for users of other distributions.

I think a safer approach would be:

  1. Change root password
  2. Update Packages
  3. Admin Account Setup
    1. Create New User
    2. Add new user to sudo group
    3. Test login and sudo
    4. Disable root login
    5. Test ssh configuration with sshd -T
  4. SSH Key Setup
    1. Create SSH Key
    2. Install SSH Key for new user
    3. Test SSH Key authentication
    4. Disable password authentication
    5. Test ssh configuration with sshd -T
  5. Restart sshd

This breaks up Disable root login & password authentication into separate steps because it is safer. Instead of a kill switch at the end, vulnerabilities are removed in a sequence. First, a user is created and login to the user with sudo is tested and verified working. Then root logins are disabled. Next, key setup is handled along with disabling password logins.

·

I do the process in less than five minutes. If I can log in via the SSH key, I don't have to worry about the password authentication, nor do I care about it as it is being disabled.

The entire time I have failbacks:

  • root login is still enabled until the final step
  • initial root login session is still connected
  • I have tested user login with key and sudo command functionality

I see no problems doing it all at once, especially since it's done very quickly and the final test will verify everything and nothing is locked down until that is completed.

·
·

I do the process in less than five minutes.

I'm glad you can. I was making the suggestion for others that want to attempt this that find it's an easier to troubleshoot process. It's a miniscule change since this process is unchanged with the exception of disabling root sooner. It's literally one extra step and not a big one.

·
·
·

I agree, I just don't think the password is an issue if you are not locking things down until you verify SSH Key. The password auth is a moot point. Especially when keeping the original session open (which will persist even if you locked yourself out as long as you don't disconnect).

·
·
·
·

I guess it's just a separation of concerns.

  1. Setup Admin Account
  2. Setup Auth Key

This way if users have problems, they are isolated to what they're working. For example, if there's an issue disabling root, it can be caught early before moving on to key setup. Users aren't left wondering what went wrong.

IMHO, due to the separation of concerns, having a continuous login isn't necessary. Once sudo is setup, root login is disabled, and ssh with pw login is still working, then it's safe to have a new session and the user is able to make changes that require root access as they need.

At this point, the rest of the instructions are only related the pub/priv key auth. We are confident sudo is setup correctly with an admin account. Any problems from this point forward will be related to key setup alone.

The key to managing the setup in discrete pieces lies in disabling root sooner.

Especially when keeping the original session open (which will persist even if you locked yourself out as long as you don't disconnect).

IMHO, this is only helpful at step 1. However, once the admin account is setup, the user can connect/reconnect and execute commands as logged in as root. At some point sshd -T needs to be run to test the configruation. A typo will easily ruin your day. In one case, you run into it sooner and can assume it's not a problem with key setup. In the other case, it could be a problem with either admin user setup or key setup.

Loading...

Nice tutorial. I can add the following points:

  • U can use ssh-copy-id to install authorized keys easily
  • For public servers u might want to change the default sshd port (e.g. 2222). Otherwise u might get lots of connection tries and big log files.

Thanks. J

·

Old habits die hard :) Especially since most are going from Windows->Linux

I didn't want to get into much detail on changing ports and fail2ban as it is a bit more work. Most users who change ports with fail2ban fail to properly configure it for the new port and it just sits there protecting a port not even being used.

I'm a newish Linux user with mint, which, as I understand doesn't let you use the root account. Although the main account can do root commands with sudo.. but I still don't quite understand the distinction and if, I shouldn't use that main account still. Any advice would be appreciated

·

Most "workstation" Linux builds create a regular user during the install because it is so important not to use root as your main account.

·

sudo just gives you temporary root permissions. You can think of the sudo command as a temporary switch user command. The su command in linux allows you to switch user so sudo is like "switch user, do as". Try it yourself, with your main account type the whoami command and it should return your username. Then type sudo whoami and and it should return root. This just tells you that what ever command you run after sudo you run with root permissions.

·
·

yeah, but confusing why sudo accepts my account password, and mint doesn't even let you log into root with su.... so I'm feeling like I'm secure because mint doesn't let me use root, but wondering if I'm less secure than I think.... :-(

·
·
·

@inquiringtimes I'm not as familiar with Mint as others, but I think it's just a flavor of Debian (to which Ubuntu is as well). You can log in to your root account by typing sudo su on the command line. Because your main account is a part of the sudoers group you have the ability to use sudo. If you're a former windows junkie who has seen the light like I was, then it's similar to right-clicking on a program and saying "run as Administrator". As long as you are using your main account and you have a secure password I think you're probably fine.

·
·
·
·

I was just stuck with windows until I installed linux without doing a dual boot... ONLY LINUX. Yes, mint is ubuntu\debian flavoured.

I got a new computer recently, I'm going to up my security in a number of ways on the new one... I love how simple linux is to use compared to 15 years ago.... the first time I tried to install linux was a nightmare... hehe. now I only am forced to learn commandline stuff occasionally, which gives me a gradual learning process on the deeper workings.

·
·
·

sudo asks for your permission to validate access, this is so if you login as your user, walk away and someone comes up and tries to use sudo rm -rf they need authentication.

·
·
·
·

DISCLAIMER if a person approaches just after the user walks away (tailgating), sudo will not require a password.

To force behavior of sudo to require a password:

  1. sudo visudo
  2. add Defaults env_reset,timestamp_timeout=0
·
·
·
·
·

Or lock your session when you leave like a good sysadmin ;)

·
·
·
·
·
·

LOL. It was your point, not mine.

·
·
·
·
·
·
·

Ahh, I see what you saying now, been a while since I wrote the post. :)

Wow!!!. , i like your post. i wait for your next post , carry on . all the best

Very good Tutorial, im still following to get TOP News....

Wow. Great post.

I knew you were watching my computer! Thanks for the advice, I will be using this.

A great primer, resteeming.

If you are running a witness, full node, web server, or any Linux box the very first thing you should do is to stop using root to login, and set up SSH key authentication and disable root logins.

This summarises and anybody expecially network admins should take it serious.
It's sometimes to hear of boxes getting owned and compromised because of mistakes like this.

Thanks for sharing this as it'll go a long in helping a lot of persons to be security conscious when it comes to network security. You're so apt and your research and write up is spot on.

Happy Steeming

Thank you for sharing this.

great tutorial @themarkymark! I love SSH Public Key Authentication. It's the first thing I do when setting up a new linux system. I did it so many times I just have a bash script that modifies all the ssh settings and installs my public key.

I've never seen the distinction between ed25519 and rsa, I'm going to have to do some more reading on that. I've always just used a high key length rsa algorithm for my keys. Thanks for bringing that to my attention, I now know what I'm spending my weekend reading about!

Very thorough and technical. I will be referring to this as a resource. Thanks @themarkymark

Very well put. I think I put pull it off. I'm not sure when I'll going to try it.

Top notch tutorial, @themarkymark! I will need this very soon.

hi @themarkymark i will send 1sbd to @upmyvote, what percent will upvote in my post. @ipromote weak

·

You got $1.35 for your $0.50 bid. I wouldn't call it weak, it's much smaller than my other bots but also has a lower minimum.

Nice post. Should actually implement this to our linux machines at work. You can never be safe enough.

Very useful information you shared.

Isn't the root user locked by default in Ubuntu?

·

not on most VPS/Dedicated servers.

·
·

Right, I have set up dozens on my own, and used Mittwald lately, must have escaped my attention then, but now that you mention it, I remember that Hetzner had root logins, I still get goosebumps from that time when I was told to leave it that way :) Thanks.

·
·
·

I wrote this because I notice a lot of witnesses use root with password.

Very informative post. Its a great help and knowledge sharing. Thanks for sharing this post.

awww crap - more sysadmin work to learn - i bookmarked this one - now to fire up a dummy vm and make sure I can do it - then move on to production server ;)