Why Your SSH Hardening Changes Aren't Working on BinaryLane

The Problem

You've added SSH keys, edited /etc/ssh/sshd_config to disable password authentication, restarted SSH — and you think you're secure. But password authentication is still enabled.

Your changes are being silently overridden.

BinaryLane uses a drop-in configuration file at /etc/ssh/sshd_config.d/10-binarylane.conf to manage security-critical SSH settings. Drop-in files in sshd_config.d/ take precedence over settings in the main sshd_config — so any changes you make directly to sshd_config for options that also appear in 10-binarylane.conf will have no effect.

What BinaryLane Sets When Your Server Is Deployed

The settings in 10-binarylane.conf depend on whether an SSH key was selected when the server was deployed or rebuilt:

• Deployed with an SSH key (including a key set as Default For Future Installations): PermitRootLogin without-password and PasswordAuthentication yes. Root must log in over SSH with the key, so the root password emailed when the server was created is refused over SSH. Password authentication itself is not switched off.
• Deployed without an SSH key: PermitRootLogin yes and PasswordAuthentication yes. Root can log in over SSH with the password.

These are SSH settings only. The root password is real and still works on the Rescue Console in mPanel, whichever way the server was deployed. Standard images have no separate sudo user, so if you lose the SSH key, the Rescue Console is how you get back in.

To allow root password logins over SSH on a server deployed with a key, set PermitRootLogin yes in your own drop-in file (Option 1 below), or deploy the server without an SSH key selected. To remove a key and re-enable password logins, see Remove an SSH key and re-enable password logins on an Ubuntu VPS.

How to Check If You're Affected

Run this command to see your effective SSH configuration:

sshd -T | grep passwordauthentication

If this shows passwordauthentication yes after you've tried to disable it in sshd_config, you're affected.

You can also check what BinaryLane's drop-in file is setting:

cat /etc/ssh/sshd_config.d/10-binarylane.conf

How to Fix It

Option 1: Create your own drop-in file (Recommended)

Create a custom drop-in config with a lower number than BinaryLane's (lower = loaded first = first match wins):

sudo nano /etc/ssh/sshd_config.d/01-custom.conf

Add your desired settings:

PasswordAuthentication no
PermitRootLogin prohibit-password
X11Forwarding no

Then restart SSH:

sudo systemctl restart sshd

Option 2: Edit the BinaryLane config directly

sudo nano /etc/ssh/sshd_config.d/10-binarylane.conf

Modify the settings there and restart SSH:

sudo systemctl restart sshd

Verify Your Changes

Always confirm your changes are actually effective after making them:

sshd -T | grep -E 'passwordauthentication|permitrootlogin|x11forwarding'

Expected output if hardening is applied correctly:

passwordauthentication no
permitrootlogin prohibit-password
x11forwarding no

Why It Works This Way

OpenSSH loads sshd_config.d/*.conf files in alphabetical order, and the first match wins — once a setting is seen, later files cannot override it. BinaryLane uses this mechanism to configure security defaults based on how your server was provisioned (with SSH keys vs password). That's why your drop-in file needs a lower number than 10-binarylane.conf to take priority.

Avoid the Problem Entirely

When creating a new BinaryLane server, select an SSH key. Root logins over SSH then accept the key only (PermitRootLogin without-password), with no manual hardening needed. PasswordAuthentication stays yes for any other users you create; to switch it off as well, add PasswordAuthentication no to your own drop-in file as in Option 1.

You can add SSH keys to your account under Account → SSH Keys in the BinaryLane panel, then select them during server creation.

Key Takeaway