Challenge, Easy,  on  Linux

SSH 101: Replace Password-Based Root Access with a Key-Based Admin Login

Ivan Velichko
by  Ivan Velichko

A new server has just been handed over to you. Right now the only way to access it is using the root account with a seed password. Leaving a server in this state is obviously too risky - shared root credentials can leak, and password-guessing bots can eventually brute force the weak password. So you will need to do the typical first-day SSH access hardening of a fresh box.

You have two machines:

  • workstation - your local machine, where you do all the work.
  • server-01 (203.0.113.20) - the remote server, which you can reach only over SSH.

The server currently accepts root logins with the password iximiuz-labs:

ssh root@server-01

Your tasks:

  1. Create a dedicated admin user named ops on the server with working sudo access.
  2. Generate a new SSH key pair on the workstation, saved as ~/.ssh/ops_ed25519 (and ~/.ssh/ops_ed25519.pub).
  3. Authorize that key on the server so you can log in as the ops user without a password.
  4. Disable password authentication in the server's SSH daemon.
  5. Disable direct root login over SSH.
  6. Retire the seed root password once the hardening is done (lock the account completely or change the password to a strong one).

Make sure you can log in as ops with your key and run sudo as ops before you turn off password auth, disable root login, and retire the root password - otherwise you risk locking yourself out of the server with no way back to root.

Hint: Create the user and grant sudo

Log in as root over SSH (using the provided password), then create a normal user and add it to the group that grants sudo rights on Debian/Ubuntu (the sudo group). The adduser and usermod commands are what you need.

Hint: Make sure the new user can actually use sudo

A fresh user has no password, so group membership alone will not let ops run sudo. Decide how ops should authenticate for sudo: drop a passwordless rule into /etc/sudoers.d/ (using visudo, so a typo cannot lock you out), or set a login password for ops with passwd.

Hint: Generate a key and authorize it

Use ssh-keygen on workstation to create a new key pair. Its -f option controls the output file name - make it land at ~/.ssh/ops_ed25519.

To let ops log in with that key, the matching public key has to end up in ops's ~/.ssh/authorized_keys on the server.

Hint: Disable password and root login

The SSH daemon's behavior is controlled by sshd_config. The two settings you care about are PasswordAuthentication and PermitRootLogin. Set both to no, then reload the daemon for the change to take effect.

On Ubuntu you can drop a small config override file into /etc/ssh/sshd_config.d/ instead of editing the main sshd config at /etc/ssh/sshd_config. Validate your change, and apply it with systemctl reload ssh.

Do this last, and only after you've confirmed key-based login as ops works.

Hint: Retire the seed root password

Now that you log in as ops with a key and sudo to root, the seed root password serves no purpose and is just a liability. The common practice is to lock the root account's password with passwd -l root (equivalently usermod -L root), so it can no longer be used to authenticate. If you prefer to keep a usable root password, rotate it to a new strong secret with passwd root instead. Do not leave it blank.

How to Author Challenges on iximiuz Labs

Instead of providing a subpar online editing experience, iximiuz Labs offers a helper CLI tool called labctl, allowing you to use your favorite text editor (or a full-featured IDE) to write content from the comfort of your local machine.

Install labctl CLI

curl -sf https://labs.iximiuz.com/cli/install.sh | sh

This will download and install the latest version of the labctl CLI. You only need to do this once per workstation.

Authorize labctl

labctl auth login

This will open a browser window asking you to authorize labctl to access your account. You need to do it after a fresh install of labctl and repeat it whenever the auth session expires.

Pull challenge content

labctl content pull challenge ssh-harden-new-server

This will create a local copy of the challenge content in a directory named ssh-harden-new-server. You only need to do this once per challenge.

Stream your changes

labctl content push -fw challenge ssh-harden-new-server

Run this command in a separate terminal to continuously upload your changes to the server while editing the challenge in your favorite text editor or IDE.

You can also use labctl to create, list, and delete your content. Learn more about the available commands: labctl content --help

Start challenge