Ditch password logins for good. Generate a key pair with PuTTYgen on Windows, install the public key on your Ubuntu VPS, and optionally lock the door on password authentication entirely.
PuTTYgen is a key generator included with the PuTTY suite. If you don't have it yet, download it from putty.org — grab the full MSI installer so you get PuTTY, PuTTYgen, and Pageant in one shot.
After generating, you'll save two things: the private key (stays on your Windows machine) and you'll copy the public key text (goes on the server). Don't mix them up.
id_ed25519.ppk. PuTTY uses the .ppk format.
C:\Users\YourUsername\.ssh\ — create the .ssh folder if it doesn't exist. This is the conventional location.
.ppk file, upload it anywhere, or put it in a synced folder (Dropbox, OneDrive, etc.). The public key is the one that goes on servers — it's safe to share freely.
The server needs to know your public key before it will trust your private key for login.
You'll add it to a special file called authorized_keys in your home directory.
First, log in to your VPS the old-fashioned way (password) one last time.
Once logged in, run the following commands. The first two create the
~/.ssh directory if it doesn't exist and set correct permissions.
The third line is where you paste your public key.
mkdir -p ~/.ssh
chmod 700 ~/.ssh
Now add your public key. Replace the placeholder below with the full public key text
you copied from PuTTYgen (the line starting with ssh-ed25519 AAAA... or ssh-rsa AAAA...):
echo "YOUR_PUBLIC_KEY_HERE" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys
~/.ssh or authorized_keys is world-readable, SSH will silently refuse to use the key and fall back to password auth (or just deny access).
You can verify the key was added correctly by running:
cat ~/.ssh/authorized_keys
You should see your public key printed as a single long line starting with
ssh-ed25519 or ssh-rsa.
Now tell PuTTY where your private key lives so it presents it automatically when connecting.
.ppk file.
.ppk. Any PuTTY session will pick it up automatically.
Before disabling password auth, verify the key actually works. Open PuTTY, load the saved session, and click Open. You should connect without being asked for a password (or only asked for your key passphrase, if you set one).
If the login fails, common causes are:
authorized_keys correctly — check with cat ~/.ssh/authorized_keyschmod commands from Step 3.ppk file — double-check the path in Connection → SSH → Authauthorized_keys file is per-user
Once key login works, disabling password auth closes the door on brute-force attacks entirely.
A server exposed to the internet with passwords enabled will be hammered constantly by bots —
you can watch it happen in /var/log/auth.log. Keys eliminate that attack surface.
Open the SSH daemon config file:
sudo nano /etc/ssh/sshd_config
Find the following lines (use Ctrl+W in nano to search) and set them as shown.
If a line is commented out (starts with #), uncomment it by removing the #:
# Disable password-based logins
PasswordAuthentication no
# Ensure public key auth is on (usually already yes)
PubkeyAuthentication yes
# Optional but recommended: disable root login entirely
PermitRootLogin no
Save the file with Ctrl+O, then Enter, then exit with Ctrl+X.
Restart the SSH service to apply changes:
sudo systemctl restart ssh
To confirm password authentication is truly disabled, you can check the running SSH config:
sudo sshd -T | grep passwordauthentication
The output should be passwordauthentication no. If it still shows
yes, check for an override in /etc/ssh/sshd_config.d/ —
Ubuntu 22+ sometimes has a separate file in that directory that can override the main config.
# Check for override files
grep -r "PasswordAuthentication" /etc/ssh/sshd_config.d/
authorized_keys. Brute-force password attacks are no longer a threat.
By default, Ubuntu asks for your password every time you run a sudo command.
Since you've already secured server access behind SSH keys, you may want to remove this extra
friction — especially useful for scripting or frequent admin work. This is done by editing the
sudoers file via visudo, which validates the syntax before saving
(preventing you from accidentally locking yourself out of sudo).
visudo locks the file and checks for syntax errors before writing. Editing /etc/sudoers directly with nano or vim risks a broken sudoers file that locks you out of all administrative commands.
Open the sudoers file:
sudo visudo
This opens the sudoers file in your default terminal editor (usually nano).
Choose one of the two approaches below depending on how broadly you want to apply the change.
Type your username into the field below, then copy the generated line and add it at the very end of the sudoers file (scroll down past all existing content).
username ALL=(ALL:ALL) NOPASSWD: ALL
Find the existing line that starts with %sudo and modify it so it reads exactly as below.
This removes the password requirement for every user in the sudo group,
so only use this if all sudo-group members on the server should have passwordless access.
# Change FROM this:
%sudo ALL=(ALL:ALL) ALL
%sudo ALL=(ALL:ALL) NOPASSWD: ALL
Save and exit: Ctrl+O → Enter → Ctrl+X.
visudo will validate the syntax before writing — if there's an error it will warn you
and give you the option to re-edit rather than saving a broken file.
Test immediately in a new terminal window without closing your current session:
sudo whoami
If it prints root without prompting for a password, you're all set.
systemctl restarts only: username ALL=(ALL) NOPASSWD: /bin/systemctl. This gives convenience without full blanket access.