{"id":168,"date":"2026-05-28T09:30:06","date_gmt":"2026-05-28T09:30:06","guid":{"rendered":"https:\/\/blog.offshorekaka.in\/?p=168"},"modified":"2026-08-27T05:43:54","modified_gmt":"2026-08-27T05:43:54","slug":"ssh-hardening-for-offshore-vps","status":"publish","type":"post","link":"https:\/\/offshorekaka.in\/blog\/ssh-hardening-for-offshore-vps\/","title":{"rendered":"SSH Hardening for Offshore VPS Servers"},"content":{"rendered":"
\n

Server Security<\/span><\/p>\n

What this guide does<\/h2>\n

By the end of it you will log in to your offshore VPS<\/a> with a key file instead of a password, and password logins and direct root logins will be switched off. Bots that spend all day guessing passwords on port 22 will have nothing left to guess.<\/p>\n

One rule matters more than everything else here. Do not close the terminal you are already logged in with.<\/strong> Open a second window to test. We have watched people lock themselves out of a brand new server in under five minutes by skipping that.<\/p>\n

\n
Level<\/strong>You need to be comfortable running commands.<\/span><\/div>\n
Time<\/strong>About 10 minutes.<\/span><\/div>\n
You need<\/strong>Root or sudo, and your provider panel login.<\/span><\/div>\n<\/div>\n<\/div>\n
On this page<\/strong>Check what you have now<\/a>The four steps<\/a>Useful commands<\/a>If you get locked out<\/a>Testing<\/a>FAQ<\/a><\/div>\n

Check what you have now<\/h2>\n

Before changing anything, ask the server what it is actually doing. Reading the config file is not enough, because a setting can be overridden further down the file or by a drop-in in \/etc\/ssh\/sshd_config.d\/<\/code>. This command prints the settings that are really in force:<\/p>\n

sshd -T | grep -Ei '^(port|permitrootlogin|passwordauthentication|pubkeyauthentication|maxauthtries) '<\/code><\/pre>\n
\"Terminal
A fresh VPS almost always looks like this. Password login on, root login on.<\/figcaption><\/figure>\n
That is a default install, and it is what every scanner on the internet is hoping to find. Write these values down before you change them, so you know exactly what to put back if you need to.<\/p>\n
Take a snapshot if your panel offers one.<\/strong> A snapshot takes a minute and turns a lockout from a bad afternoon into a two minute rollback.<\/p>\n
The four steps<\/h2>\n
Step 1: Make a key pair on your own computer<\/h3>\n
The key pair has two halves. The private half stays on your laptop and never moves. The public half gets copied to the server. Run this on your computer, not on the VPS:<\/p>\n
ssh-keygen -t ed25519 -C \"laptop-to-vps\"<\/code><\/pre>\n
Press Enter to accept the default location. Use a passphrase if the laptop is ever out of your sight. Ed25519 is the right choice in 2026: the keys are short, they are fast, and they are supported everywhere. Only fall back to ssh-keygen -t rsa -b 4096<\/code> if you are dealing with something genuinely ancient.<\/p>\n
Now push the public half up:<\/p>\n
ssh-copy-id youruser@your-server-ip<\/code><\/pre>\n
Test before moving on.<\/strong> Run ssh youruser@your-server-ip<\/code>. If it logs you in without asking for a password, the key works. If it still asks for a password, stop here and fix that first. Everything after this step assumes key login is working.<\/p>\n
Step 2: Turn off password login and root login<\/h3>\n
Open \/etc\/ssh\/sshd_config<\/code> and set these three lines. If a line is already there with a #<\/code> in front of it, delete the #<\/code> rather than adding a second copy lower down.<\/p>\n
PasswordAuthentication no\nPermitRootLogin no\nPubkeyAuthentication yes<\/code><\/pre>\n
On Ubuntu 22.04 and newer, check \/etc\/ssh\/sshd_config.d\/<\/code> as well. Cloud images often drop a file in there that sets PasswordAuthentication yes<\/code>, and because those files are read first, they win. This is the single most common reason people follow a hardening guide, restart SSH, and find passwords still work.<\/p>\n
Step 3: Move SSH off port 22 (optional)<\/h3>\n
Changing the port does not make SSH stronger. What it does is drop the noise in your logs by roughly 95 percent, because the bulk of automated scanning only tries port 22. That alone makes real attacks easier to spot.<\/p>\n
Port 2222<\/code><\/pre>\n
Open the new port in the firewall before you restart SSH.<\/strong> Not after. If you restart first, the service moves to a port your firewall is dropping and you are locked out. Our firewall setup guide<\/a> covers the rules in more detail.<\/p>\n
Step 4: Restart and test in a second window<\/h3>\n
sshd -t && systemctl restart ssh<\/code><\/pre>\n
The sshd -t<\/code> part checks the config for syntax errors and only restarts if it passes. A typo in sshd_config<\/code> stops the service from coming back up at all, and that is a lockout you cannot talk your way out of.<\/p>\n
Now open a new<\/strong> terminal, leaving the first one connected, and log in there. Confirm the settings took:<\/p>\n
\"Terminal
What the same command should print once the two doors are shut.<\/figcaption><\/figure>\n
Only when that second login works should you close the first one.<\/p>\n
Useful commands<\/h2>\n
Confirm the port SSH is really listening on<\/h3>\n
ss -tulpn | grep ssh<\/code><\/pre>\n
Allow the new port in UFW<\/h3>\n
ufw allow 2222\/tcp\nufw reload<\/code><\/pre>\n
Read recent login attempts<\/h3>\n
tail -n 50 \/var\/log\/auth.log<\/code><\/pre>\n
On AlmaLinux, Rocky and CentOS the file is \/var\/log\/secure<\/code> instead. Look for Accepted publickey<\/code> lines, which are your own successful logins, and Failed password<\/code> lines, which are the bots. After this guide the failed lines should stop appearing entirely, because passwords are no longer an option.<\/p>\n
Fix key permissions when the key is refused<\/h3>\n
SSH ignores a key file that other users on the box can read. If your key is not being accepted and you are certain it is the right one, this is almost always why:<\/p>\n
chmod 700 ~\/.ssh\nchmod 600 ~\/.ssh\/authorized_keys<\/code><\/pre>\n
If you get locked out<\/h2>\n
Every VPS panel worth using has a web console, sometimes called VNC or noVNC. It talks to the server the way a physical monitor and keyboard would, so it keeps working when SSH is dead. That is your way back in.<\/p>\n
From the console, log in as root, set PasswordAuthentication yes<\/code> again, restart SSH, and you are back where you started. If you changed the port and cannot connect, either reopen the old port in the firewall or set the port back to 22.<\/p>\n
The thing that turns a small mistake into a big one is changing several things at once. Change one setting, restart, test, then move to the next.<\/p>\n
How to test when you are done<\/h2>\n
    \n
  1. Log in from a new terminal using your key.<\/li>\n
  2. Add -p 2222<\/code> if you changed the port.<\/li>\n
  3. Try ssh root@your-server-ip<\/code>. It should be refused.<\/li>\n
  4. Force a password attempt with ssh -o PubkeyAuthentication=no youruser@your-server-ip<\/code>. It should also be refused.<\/li>\n
  5. Run sshd -T | grep -i passwordauth<\/code> and confirm it reads no<\/code>.<\/li>\n
  6. Check the auth log for clean Accepted publickey<\/code> lines.<\/li>\n<\/ol>\n
    When it does not work<\/h2>\n\n\n\n\n\n\n\n\n
    What you see<\/th>\nWhy<\/th>\nFix<\/th>\n<\/tr>\n<\/thead>\n
    Password login still works after the restart<\/td>\nA file in \/etc\/ssh\/sshd_config.d\/<\/code> is overriding your change<\/td>\nEdit that file too, or delete the line from it, then restart<\/td>\n<\/tr>\n
    Key refused, password prompt appears<\/td>\nWrong username, or permissions on ~\/.ssh<\/code><\/td>\nCheck the username, then run the two chmod commands above<\/td>\n<\/tr>\n
    SSH does not come back after restart<\/td>\nSyntax error in the config<\/td>\nUse the panel console and run sshd -t<\/code> to see the exact line number<\/td>\n<\/tr>\n
    Cannot connect after a port change<\/td>\nFirewall is still only allowing 22<\/td>\nAllow the new port, then connect with -p<\/code><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
    Checklist<\/h2>\n