iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.
The safest practical SSH hardening sequence is staged: create a named administrator, install and test its public key in a second session, then disable password and direct-root logins, restrict accounts and forwarding, narrow the network source range, and keep a provider console or other recovery path open. Make one reversible change at a time; never close your known-good session until a new login has succeeded.
The settings below are a baseline for a Linux VPS, not a universal paste-in. Distribution packaging, OpenSSH release, PAM, automation, backups, IPv6, and your provider’s firewall can change the correct value. Record the installed distribution and OpenSSH version, validate the effective configuration locally, and test every authentication path you intend to keep.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →What SSH hardening protects
SSH is both a remote administration service and a potential entry point to every account that can authenticate. Hardening reduces the number of ways an attacker can reach it and limits what a stolen credential can do. The controls fall into four layers:
- Authentication: prefer possession of a cryptographic private key over a password, and add a second factor or second key when the workload justifies it.
- Authorization: allow only named users or groups, block direct root access, and grant administrative privileges through a controlled sudo policy.
- Session capabilities: turn off forwarding and tunneling features that are not required by the workload.
- Network exposure: allow the SSH listener only from the addresses or networks that actually administer the VPS.
These controls are complementary. A firewall cannot compensate for an exposed key, and disabling passwords does not stop a compromised account that still has unrestricted forwarding or sudo access.
#1 Best Overall
- POWERFUL SECURITY KEY: The Security Key C NFC is the essential physical passkey for protecting your digital life from phishing attacks. It ensures only you can access your accounts.
- WORKS WITH 1000+ ACCOUNTS: Compatible with Google, Microsoft, and Apple. A single Security Key C NFC secures 100 of your favorite accounts, including email, password managers, and more.
- FAST & CONVENIENT LOGIN: Plug in your Security Key C NFC via USB-C and tap it, or tap it against your phone (NFC) to authenticate. No batteries, no internet connection, and no extra fees required.
- TRUSTED PASSKEY TECHNOLOGY: Uses the latest passkey standards (FIDO2/WebAuthn & FIDO U2F) but does not support One-Time Passwords. For complex needs, check out the YubiKey 5 Series.
- BUILT TO LAST: Made from tough, waterproof, and crush-resistant materials. Manufactured in Sweden and programmed in the USA with the highest security standards.
Prepare a recovery plan before touching sshd
Lockouts usually happen because an administrator changes several variables at once or closes the only working session. Preparation makes each change reversible.
Record the current access model
- Write down the current SSH port, listening addresses, administrator usernames, and whether the VPS uses IPv4, IPv6, or both.
- Identify the provider’s web console, serial console, rescue environment, or equivalent out-of-band path. Sign in once so you know it works before making changes.
- Record provider security-group rules and the host firewall rules. Keep a copy of the current SSH configuration and the relevant account and sudo files.
- Confirm a tested backup or image recovery route. A backup that has never been restored is not a dependable break-glass plan.
Keep the existing SSH session open throughout the procedure. Use a separate terminal for every test so that a failed change does not destroy your only evidence or route back in.
Recommended Free Tools
Create a named administrator and install its key
Use a non-root account
Create an individual account for each operator instead of sharing root credentials. On Debian- and Ubuntu-family systems, a typical account creation sequence is:
sudo adduser adminops
sudo usermod -aG sudo adminopsThe sudo group name and administrative policy differ by distribution. Grant only the commands the operator needs when full sudo is unnecessary, and maintain a separate break-glass account under your normal identity-management controls.
Install the public key
Place the operator’s public key in /home/adminops/.ssh/authorized_keys. From a trusted workstation, an available helper is:
ssh-copy-id -i ~/.ssh/id_ed25519.pub adminops@server.exampleIf that helper is unavailable, create the directory and file on the VPS and paste the complete, unwrapped public-key line:
sudo install -d -m 700 -o adminops -g adminops /home/adminops/.ssh
sudo install -m 600 -o adminops -g adminops /dev/null /home/adminops/.ssh/authorized_keys
sudoedit /home/adminops/.ssh/authorized_keysReplace the example hostname with the VPS address you already use. The private key stays on the workstation; only its public half belongs in authorized_keys.
Check ownership and modes
OpenSSH’s StrictModes check rejects keys when the home directory, .ssh directory, or key file is writable by an inappropriate user. Verify that the account owns the path, that the directory is mode 700, and that authorized_keys is mode 600 or stricter. Also check parent-directory ownership and mandatory-access-control labels when your distribution uses them.
Prove key login works before disabling passwords
Open a second terminal and authenticate as the named user with the intended private key:
ssh -i ~/.ssh/id_ed25519 adminops@server.exampleConfirm that the session reaches the expected shell, that sudo works according to policy, and that you can read the logs and reload services. Test from the same network that will be used for normal administration and, if relevant, from the provider console. Do not proceed until this second login succeeds.
If the key is rejected, use verbose client output such as ssh -vvv in the test terminal and inspect the server’s authentication log through the existing session or console. The common causes are a wrong username, a public key copied with line breaks, incorrect ownership or permissions, an SSH agent offering a different key, or a server-side policy that excludes the account.
Use a reviewable sshd drop-in
Ubuntu and many current packages load snippets from /etc/ssh/sshd_config.d/*.conf. A dedicated file such as /etc/ssh/sshd_config.d/60-hardening.conf keeps local policy separate from the distribution file and is easy to remove during recovery. Debian packaging and older releases can differ, so confirm the include order and active file on the target VPS.
Put only settings you understand in the drop-in. A concise key-only baseline is:
Rank #2
- Ultra-Compact FIDO2 Security Key - Plug-and-stay or carry on a keychain. This USB-A hardware security key offers portable, always-on protection for desktop and mobile use. (Item Size: 0.75 X 0.74 IN x 0.25 IN)
- USB-A Hardware Key for All Devices - Works with USB-A ports on PC, Mac, Android, and other laptop/notebook device. Enables secure, cross-platform login with FIDO2.0 passkey support.
- FIDO Certified Security Key - Meets FIDO and FIDO2 standards. Works with Google, Microsoft, GitHub, Dropbox, and more. Please check service compatibility before purchase.
- Passwordless Login with Passkey - Supports passkey login via WebAuthn and CTAP2. Enjoy password-free sign-ins where supported. Not all websites or services currently support passkeys.
- Advanced Multi-Factor Authentication - Offers 200 FIDO2 passkey slots and 50 OATH-TOTP slots. Strong, flexible 2FA/MFA support across various apps and authentication platforms.
PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no
AllowGroups sshlogin
DisableForwarding yes
StrictModes yesThe baseline assumes that the sshlogin group exists and contains every account that must use SSH. If you prefer an explicit account list, use AllowUsers adminops instead. Do not enable both directives casually: OpenSSH applies them as an allow-list, so an account must satisfy every active restriction.
Free tools Windows power users keep installed
One-click scans. No signup required.
Set authentication policy deliberately
Public-key authentication
PubkeyAuthentication yes enables public-key authentication. The server verifies a signature made by the private key without receiving that private key. Protect private keys with a strong local passphrase and an appropriate workstation access policy. Document where replacement keys are stored before you remove an old one.
Disable password and keyboard-interactive paths
After the named user’s key login has passed, set PasswordAuthentication no. Ubuntu guidance recommends disabling password authentication when you will always be able to log in with an SSH key. Also set KbdInteractiveAuthentication no when keyboard-interactive authentication is not required. On PAM-enabled systems, keyboard-interactive can provide a password-equivalent path, so disabling only PasswordAuthentication may leave an unintended login method available.
Do not apply these values blindly if your environment depends on console-assisted identity, an external authentication module, one-time passwords, or a documented break-glass workflow. In that case, define the exception narrowly and test it separately from ordinary operator access.
Block direct root SSH
Set PermitRootLogin no when the named administrator and recovery route have been tested. This prevents root from logging in over SSH, even with a root public key. The weaker value PermitRootLogin prohibit-password blocks root password and keyboard-interactive authentication but still permits root public-key login. Choose it only when a specific, reviewed automation or recovery requirement justifies direct root keys.
Jobs that currently use a root key should be moved to a service account with the minimum required permissions. If a legacy job cannot be migrated immediately, constrain its key with an appropriate forced command and remove interactive access rather than retaining unrestricted root SSH.
Require multiple methods when needed
AuthenticationMethods lets you require a sequence of methods. For example, publickey,password requires a successful public key and then a password; a comma-separated list means all methods in that sequence, while alternatives can be separated according to the OpenSSH syntax. Each named method must be enabled elsewhere. Requiring two distinct public keys is another option for a controlled two-person or two-device process.
Multi-method policies are easy to misconfigure. Test every intended path in a second session before reloading, and keep a console route available in case one factor is unavailable.
Limit users and session capabilities
Allow only required accounts
AllowUsers names individual accounts; AllowGroups allows members of a maintained group such as sshlogin. These directives prevent unrelated local accounts from becoming SSH entry points. Review group membership whenever staff, automation, or incident-response roles change, and retain one documented emergency account that is tested but not used for daily work.
Disable forwarding that the workload does not need
Forwarding can turn a legitimate SSH session into a pivot through internal services. For accounts that do not require it, DisableForwarding yes disables X11, agent, TCP, and StreamLocal forwarding and tunneling features. If one function is required, leave the global setting off and control individual capabilities with:
AllowTcpForwardingfor local and remote TCP forwarding.AllowAgentForwardingfor forwarding an SSH agent.X11Forwardingfor X11 sessions.PermitTunnelfor tun device forwarding.
Use per-key restrictions in authorized_keys when a service account needs one narrowly defined action. A forwarding ban can break development tunnels, deployment tools, database administration, or bastion workflows, so test the actual workload rather than assuming it is unused.
Reduce network exposure with firewall rules
Account controls still matter when SSH is reachable from the public internet, but a firewall or provider security group can reduce the number of hosts that can even attempt a connection. Permit TCP access to the SSH port only from required addresses or networks. Ubuntu’s UFW syntax for an administrator address is:
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Repair Windows errors before they cause bigger problemsFix Now →sudo ufw allow proto tcp from 198.51.100.24 to any port 22The address above is documentation space; replace it with the fixed public address or management subnet that actually administers the VPS. If the service listens on a different port, use that port in the rule. Add an equivalent IPv6 rule when the VPS has IPv6 administration, and verify the provider security group separately from the host firewall. Do not delete the current working rule until the replacement has been tested from the intended source network.
Rank #3
- Security Key : Protect your online accounts against unauthorized access by using FIDO2 and U2F authentication with T110. It's the world's most protective security key that works with windows, Mac OS, Linux as well as Chrome, Firefox, Edge and many other major browsers.
- Certified with the new FIDO2 standard, T110 provides the benefit of fast login and strong protection against phishing, account takeover as well as many other online attactks.
- Works with : Bank of America, Github, Google, Microsoft, DUO, Twitter, Facebook, Dropbox, Apple, ebay, BINANCE, mor and more.
- Fits USB-A port : Insert the T110 security key into the USB-A port of each service and log in conveniently with one touch
- For the driver download and user guide, please visit TrustKey Solutions Home support page.
Restricting SSH to a dynamic residential address may cause outages when the address changes. In that situation, use a controlled management network, VPN, bastion, or provider console rather than repeatedly opening broad internet access.
Validate the effective configuration and reload safely
- Review the final drop-in and any later files that can override it. Check for duplicate directives and unexpected include order.
- Run the installed server’s syntax check from the existing session. On many OpenSSH installations this is
sudo sshd -t; some distributions require an explicit configuration path. - Inspect effective values with the platform-supported equivalent of
sudo sshd -T, and confirm the result for the accounts and source addresses you care about. The exact command and service name vary by distribution. - Reload the SSH service rather than stopping it abruptly. Common service managers use
sudo systemctl reload sshorsudo systemctl reload sshd; verify which unit exists locally. - Keep the original session open and make a fresh connection using the new key, account, port, and source-network rule. Test sudo and any required forwarding or automation.
- Only after the new connection succeeds should you close the old session or remove temporary recovery access.
A syntax check proves that the file parses; it does not prove that the firewall, account allow-list, PAM stack, or key permissions permit the login you need. The second-session test is the operational proof.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Use hardware-backed keys for higher-assurance access
OpenSSH supports FIDO authenticator-hosted keys through SecurityKeyProvider. A FIDO2 security key keeps the private key operation on a hardware authenticator and normally requires the device, a user-presence gesture, and sometimes a PIN. This is useful for privileged VPS administration where theft of a workstation file would otherwise be enough to authenticate.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Scan for outdated or missing drivers - takes under a minute3Clear out junk files and repair common Windows errorsConfirm that the client OpenSSH version supports the required security-key key type and that the server package supports the corresponding method. Enroll the key on the client, add its public key to the named account, and complete a second-session login test before changing the server’s authentication policy. Keep at least one separately stored recovery key or a tested console procedure; a lost or damaged sole authenticator is an administrative outage, not a security control.
Hardware-backed authentication does not replace account restrictions, firewall rules, patching, or key revocation. It protects the key material; the account can still be overprivileged if the rest of the SSH policy is broad.
Operate SSH as a continuing control
Rotate and revoke keys
Maintain an inventory showing which person or service owns each key, where it is used, and when it should expire. Add a replacement key and test it before removing the old one. For centralized invalidation, OpenSSH supports RevokedKeys pointing to a text revocation list or an OpenSSH key revocation list (KRL). Replace revocation files atomically and ensure the sshd process can read them.
Monitor authentication and configuration changes
Review successful and failed authentication events, unexpected source addresses, new keys, group membership changes, and modifications to the SSH configuration. Alert on root-login attempts even when root SSH is disabled; they can reveal scanning or a misconfigured job. Keep timestamps and host identity in your logs so an incident can be reconstructed across a fleet.
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchPatch the operating system and OpenSSH
Apply security updates through the distribution’s supported process and schedule maintenance for reboots when required. After an OpenSSH or PAM update, re-check effective defaults, include-file behavior, and authentication methods because package defaults are version-sensitive.
Review when the workload changes
Reassess forwarding, account groups, sudo rules, firewall sources, IPv6 exposure, backup jobs, and automation whenever staff, applications, networks, or provider images change. A rule that was necessary for a deployment tunnel may become an unnecessary pivot months later.
Key SSH features at a glance
| Feature | Security purpose | Operational trade-off |
|---|---|---|
PubkeyAuthentication |
Replaces password guessing with possession of a private key and can participate in multi-method policies. | Lost keys require a documented recovery and rotation process. |
AuthenticationMethods |
Requires one or more authentication methods, such as a public key followed by a password or two distinct keys. | A policy error can lock out users; test every method in a second session. |
PermitRootLogin |
Controls direct root SSH; no blocks it, while prohibit-password still permits root public-key login. |
Root-key automation may need a forced command or a service account. |
AllowUsers / AllowGroups |
Narrows SSH access to named accounts or maintained groups. | Membership and emergency access must be reviewed as staffing changes. |
PasswordAuthentication and KbdInteractiveAuthentication |
Removes password and PAM keyboard-interactive paths when keys are the sole intended method. | Console, break-glass, or external-identity workflows may require a tested exception. |
DisableForwarding, AllowTcpForwarding, AllowAgentForwarding, X11Forwarding, PermitTunnel |
Reduces pivoting and tunneling capabilities that the workload does not need. | Developers and operators may rely on forwarding for legitimate administration. |
StrictModes |
Rejects unsafe ownership or permissions on key files and home directories. | Incorrect modes can look like an authentication failure until corrected. |
RevokedKeys |
Refuses keys listed in a text file or OpenSSH KRL. | Revocation files must remain readable and be replaced atomically. |
SecurityKeyProvider |
Enables FIDO authenticator-hosted keys for hardware-backed authentication. | Requires compatible clients, authenticators, enrollment, backup keys, and recovery. |
| Firewall or provider security group | Restricts which networks can reach the SSH listener. | Overly narrow rules can cut off legitimate administration; account for IPv6 and console access. |
Troubleshoot a failed login without making the lockout worse
The key is rejected
- Confirm the username and destination address, then rerun the client with
-vvv. - Check that the public key is one complete line in the correct account’s
authorized_keys. - Verify ownership and modes on the home directory,
.ssh, andauthorized_keys;StrictModesis commonly responsible. - Inspect server logs for the exact rejection reason and check whether an allow-list, PAM rule, or key algorithm policy excludes the account.
Password login stopped unexpectedly
Check both PasswordAuthentication and KbdInteractiveAuthentication, then inspect PAM requirements. If the intended key login works, the change may be correct; if a required external-identity or break-glass path was removed, use the open session or provider console to restore the narrowly scoped exception.
The service will not reload
Use the syntax-check command before attempting another reload. Read the error path and line number, correct the drop-in, and test again. Do not stop the only running SSH service while investigating.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
The firewall blocks the administrator
Use the provider console or an existing session to inspect both host and provider rules. Check the actual source address, the configured port, and IPv4 versus IPv6. Restore the smallest rule that permits the tested management network, then remove any temporary broad rule.
Quick Recap
A practical hardening checklist
- Recovery console, backup, current port, users, firewall rules, and OpenSSH version recorded.
- Named administrator created with appropriate sudo scope.
- Public key installed with correct ownership and restrictive permissions.
- Fresh key login and sudo test completed in a second terminal.
- Drop-in reviewed, syntax-checked, and effective settings inspected.
- Password and keyboard-interactive authentication disabled only when the intended key workflow is proven.
- Direct root SSH disabled, or a documented reason exists for the weaker key-only root setting.
- SSH access limited with
AllowUsersorAllowGroups. - Unused forwarding and tunneling features disabled.
- Host firewall and provider security group restricted for both IPv4 and IPv6 where applicable.
- Configuration reloaded, then a new login tested while the old session remained open.
- Key inventory, revocation process, log monitoring, patching, and periodic review assigned to an owner.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
