This guide shows you how to remove an SSH key from an existing BinaryLane Ubuntu VPS and re-enable password authentication without losing access.


These steps apply to BinaryLane Ubuntu 24.04 LTS and Ubuntu 26.04 LTS VPSs. Complete them in order: configure and test password access before removing any SSH key.


Warning: Removing your only working SSH key before password access is confirmed can lock you out of the VPS. Keep your current SSH or mPanel console session open until every verification step has passed.


Before you begin


Prerequisites: 

  • The public IP address of your VPS.
  • A working SSH session or access through the mPanel web console.
  • Access as root, or an account with sudo privileges.

Replace YOUR_SERVER_IP with your VPS's public IP address. If you use an account other than root, replace root with that username where appropriate.

The VPS operating system and SSH configuration are customer-managed. These steps change authentication settings and should be completed during a period when you can use the mPanel console if SSH access fails.


TABLE OF CONTENTS



1. Set a password for the login account


If you intend to sign in as root and do not know a working root password, set one before changing SSH access:

sudo passwd root


Enter the new password twice. Use a long, unique password generated by a password manager.

Check whether the account has a password hash:

sudo passwd --status root


The second field should be P, for example:

root P 2026-09-18 0 99999 7 -1


P means a password hash is present. L means the account is locked, while NP means no password is set.


Using a non-root account: Set its password with sudo passwd YOUR_USERNAME. You do not need to enable root password login, so omit the PermitRootLogin yes line in the next section.

 


2. Enable password authentication


Ubuntu loads additional OpenSSH server settings from /etc/ssh/sshd_config.d/*.conf. OpenSSH uses the first value it obtains for each setting, and included files are processed in lexical filename order.

BinaryLane Ubuntu images include 10-binarylane.conf. On a VPS deployed for key-based root access, the effective PermitRootLogin setting may be without-password or prohibit-password. These values are equivalent and prevent root password login even when PasswordAuthentication is set to yes.

Check the effective configuration:

sudo sshd -T | grep -Ei '^(permitrootlogin|passwordauthentication|kbdinteractiveauthentication) '


Create a custom drop-in file


A filename beginning with 01- is read before 10-binarylane.conf:

sudo nano /etc/ssh/sshd_config.d/01-enable-password-auth.conf


To enable password access for root, add:

PermitRootLogin yes
PasswordAuthentication yes


For a non-root account, add only:

PasswordAuthentication yes


Press Ctrl+O, Enter, then Ctrl+X to save and exit.


Check and apply the configuration


Check the complete SSH configuration for syntax errors:

sudo sshd -t


No output means the syntax check passed. If an error appears, correct it before continuing.

Confirm the effective settings:

sudo sshd -T | grep -Ei '^(permitrootlogin|passwordauthentication) '


For root password access, the output should include:

permitrootlogin yes
passwordauthentication yes


Apply the change:

sudo systemctl restart ssh


Restarting the SSH service does not normally disconnect established sessions.


3. Test password access


Leave the original session open. From a second terminal, connect with public-key authentication disabled:

ssh -o PubkeyAuthentication=no -o PreferredAuthentications=password,keyboard-interactive root@YOUR_SERVER_IP


Enter the account password. Do not continue unless this login succeeds.


Stop if the login fails: Return to the original session and review the account password, the output of sudo sshd -T and any syntax errors. Removing the key before password access works can lock you out.



4. Remove the SSH key


Authorised keys are stored in ~/.ssh/authorized_keys, with one key per line. Display their fingerprints:

ssh-keygen -lf ~/.ssh/authorized_keys


Identify the key by its fingerprint and comment. If you are unsure which entry belongs to the key, stop and compare its fingerprint with the public key on the relevant computer.


Back up the file while preserving its ownership and permissions:

cp -a ~/.ssh/authorized_keys ~/.ssh/authorized_keys.before-removal

Remove one key


Open the file:

nano ~/.ssh/authorized_keys


Delete the complete line for the key you want to remove. A long key may wrap visually in Nano, but each key remains one logical line beginning with a type such as ssh-ed25519 or ssh-rsa.

Press Ctrl+O, Enter, then Ctrl+X to save and exit.

Remove every key for this account


Warning: The following command immediately removes key-based access for the current account. Run it only after the password-login test has succeeded.


Empty the file without deleting it:


: > ~/.ssh/authorized_keys


Keeping the file in place preserves its existing ownership and permissions.

Confirm which keys remain


cat ~/.ssh/authorized_keys


An empty result means that no keys remain for the current account. On an empty file, ssh-keygen -lf may report that it is not a public key file; this is expected.

SSH keys are configured per account. To locate authorised-key files for other accounts:

sudo find /root /home -type f -path '*/.ssh/authorized_keys' -print

 


5. Verify the result


From a new terminal, test the removed key without allowing SSH to fall back to a password:

ssh -o IdentitiesOnly=yes -o PreferredAuthentications=publickey -o PasswordAuthentication=no -o KbdInteractiveAuthentication=no -i ~/.ssh/id_ed25519 root@YOUR_SERVER_IP


The connection should fail with Permission denied.

Then test password access again:

ssh -o PubkeyAuthentication=no -o PreferredAuthentications=password,keyboard-interactive root@YOUR_SERVER_IP


Once both tests give the expected result, you can close the original session. Keep ~/.ssh/authorized_keys.before-removal until you are satisfied that access is stable, then remove it if it is no longer required:

rm ~/.ssh/authorized_keys.before-removal

 


Undo the password-authentication change


Before disabling password access again, install and test a working SSH key. Then disable the custom drop-in file and restart SSH:

sudo mv /etc/ssh/sshd_config.d/01-enable-password-auth.conf /etc/ssh/sshd_config.d/01-enable-password-auth.conf.disabled
sudo sshd -t && sudo systemctl restart ssh


Confirm the effective settings with sudo sshd -T, then test the key from a second terminal before closing your original session.


Things to know


  • Password authentication on a public SSH service increases exposure to automated login attempts. Use a long, unique password and consider restricting SSH access with the BinaryLane External Firewall.
  • Removing a key from one account or VPS does not revoke that key anywhere else it is installed.
  • Keep the private key until all verification steps have passed.
  • If a private key may have been copied or compromised, remove it from every account and VPS where it was authorised.
  • If you are already locked out, use the recovery environment described in Boot a Linux VPS into Finnix recovery mode.



If you require assistance, feel free to submit a support ticket at our helpdesk here: Submit a ticket | BinaryLane