The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →The safest practical SSH baseline for a Linux VPS is staged and reversible: create a named administrator, verify public-key access in a second session, then disable password and direct-root logins, restrict forwarding, limit source networks, and keep a provider console available for recovery.
Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.
Do not paste a “secure” sshd_config over the only session you have. OpenSSH defaults, PAM behavior, service names, firewall tooling, and drop-in paths vary by distribution and release. Record the current settings, validate every change locally, and reload only after the syntax check succeeds.
As an Amazon Associate I earn from qualifying purchases.
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 matchWhat SSH hardening changes
SSH hardening reduces the number of ways an attacker can reach or abuse the daemon. It is not a single switch. Authentication policy determines how a user proves identity; account controls determine who may connect; forwarding controls determine what an authenticated session can tunnel; and network rules determine which systems can reach the listener at all.
The strongest policy for a typical administration account is a named, non-root user with a protected private key, no password or keyboard-interactive login, no direct root SSH, and access allowed only from required networks. That policy is inappropriate if a backup system, configuration manager, external identity provider, or emergency workflow depends on one of those mechanisms. Document exceptions instead of disabling a function blindly.
#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 safe change window
Inventory the current access paths
Before editing anything, write down the SSH port, the accounts that currently work, each account’s purpose, and whether any automation connects as root. Record whether the VPS uses IPv4, IPv6, or both. Identify the provider’s web console, serial console, rescue mode, or out-of-band terminal and confirm that you can reach it. Also record the provider firewall or security-group rules and the host firewall rules.
Check the installed distribution and OpenSSH version. Debian-family packages may combine a main configuration file with snippets, while Ubuntu commonly reads /etc/ssh/sshd_config.d/*.conf. The effective defaults and service unit name can change between releases, so treat examples in this article as a reviewable baseline, not a universal paste-in.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Fix the driver behind crashes, sound loss and screen glitches3Clear out junk files and repair common Windows errorsKeep a recovery route
Keep the current SSH connection open throughout the change. Have a second terminal ready for testing, and keep console access in another browser tab. A recent VPS snapshot or a tested backup helps with a failed disk or package update, but it does not replace a tested login path. Prepare an emergency administrator key that is stored securely and is not used for routine work.
Create and verify a named administrator
Use a non-root account
Create an individual account for each operator rather than sharing root. Grant only the sudo rights that the workload requires. A named account gives you an auditable username and lets you remove one person’s access without changing everyone else’s credentials.
Install the public key with correct ownership
On the client, generate a key pair with a passphrase if you do not already have one. Ed25519 keys are a common choice on current OpenSSH clients. Copy only the public key to the server; the private key must remain on the client or its hardware authenticator.
- Create the account and grant the required, narrowly scoped sudo access using your distribution’s account-management tools.
- Make the SSH directory and key file for the new account. A typical permission sequence is
sudo chmod 700 /home/<user>/.ssh,sudo chmod 600 /home/<user>/.ssh/authorized_keys, andsudo chown -R <user>:<user> /home/<user>/.ssh. - Append the public key as one uninterrupted line in
authorized_keys. Do not email or paste the private key onto the VPS. - Check the home directory and every parent directory for ownership and write permissions that would let another user alter the key. With
StrictModes yes, sshd rejects unsafe ownership or modes before authentication completes.
Test before changing policy
From a second terminal, force the intended identity so the test cannot silently use an agent-loaded key: ssh -o IdentitiesOnly=yes -i ~/.ssh/<private-key> <user>@<server>. Confirm that the session starts, that the account can perform its documented sudo tasks, and that the private-key passphrase or hardware authenticator prompt behaves as expected. Do not proceed until this independent login works.
Choose the authentication policy
Public-key-only access
Set PubkeyAuthentication yes when public keys are part of the policy. After the new key login succeeds, disable password authentication with PasswordAuthentication no. Also set KbdInteractiveAuthentication no when keyboard-interactive login is not required. PAM keyboard-interactive can provide a password-equivalent path even when the password method itself is disabled, so leaving it enabled may defeat a key-only design.
Ubuntu guidance summarizes the condition clearly: if you will always be able to log in with an SSH key, disable password authentication altogether. That condition includes a working recovery key or console procedure; it does not mean removing every way to regain access.
When to require multiple methods
Use AuthenticationMethods only when you genuinely need multi-factor or two-key authorization. A comma-separated list requires each method in sequence. For example, AuthenticationMethods publickey,password requires a public key and then a password, while AuthenticationMethods publickey,publickey requires two distinct public-key authentications. Every method named must be enabled elsewhere, and every account affected must be tested in a second session. A typo or an unavailable second factor can lock out all remote users.
Hardware-backed keys
FIDO2 authenticators keep the signing key in hardware and require a physical touch, PIN, or both, depending on the authenticator and client policy. OpenSSH supports authenticator-hosted keys through its security-key methods and the SecurityKeyProvider setting. A typical enrollment command on a compatible client is ssh-keygen -t ed25519-sk -f ~/.ssh/id_ed25519_sk; some environments instead use an ECDSA security-key type.
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.
Confirm that both the client and server OpenSSH versions support the selected method before removing a software key. Enroll at least one recovery key, store it separately, and test the recovery procedure. A hardware key improves resistance to theft of a client’s disk, but losing every enrolled authenticator without a backup leaves the account inaccessible.
Apply a reviewable sshd configuration
On systems that support it, put your site policy in a dedicated file such as /etc/ssh/sshd_config.d/60-hardening.conf. A separate drop-in is easier to review, disable, and restore than editing a distribution-managed file. The filename ordering rules of the distribution determine which setting wins when the same directive appears more than once.
This baseline suits an account that needs ordinary shell administration but no forwarding:
PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no
AllowGroups sshlogin
DisableForwarding yes
StrictModes yesCreate the sshlogin group, add only the intended accounts, and verify that your recovery account is a member before enabling AllowGroups. If you prefer an account list, use AllowUsers. Either directive changes the question from “which accounts happen to have keys?” to “which accounts are explicitly allowed to start SSH sessions?”
Block direct root SSH deliberately
PermitRootLogin no disallows root logins over SSH. This is the clearest policy when administrators can use a named account and sudo. The alternative PermitRootLogin prohibit-password blocks root password and keyboard-interactive authentication but still permits a root public key, so it is a weaker restriction.
Choose the setting after checking backup jobs, deployment tools, and recovery scripts. If a service truly needs root-level automation, prefer a dedicated service account with a forced command, a narrowly scoped sudo rule, or another mechanism that limits what the key can do. Do not leave an untracked root key in /root/.ssh/authorized_keys merely because changing it would require updating a script.
Reduce what an authenticated session can do
Disable forwarding that is not required
DisableForwarding yes disables X11, ssh-agent, TCP, and StreamLocal forwarding together. It is an efficient default for accounts that only need a shell. Developers and operators who use port forwarding, agent forwarding, graphical X11 sessions, or tunnel devices need a narrower policy instead.
When forwarding is required, configure the individual controls: AllowTcpForwarding, AllowAgentForwarding, X11Forwarding, and PermitTunnel. Grant them only to the accounts or hosts that need them, and consider per-key restrictions in authorized_keys for automation. Forwarding can turn a legitimate SSH account into a pivot through internal services, so treat it as a capability rather than a convenience.
Free tools Windows power users keep installed
One-click scans. No signup required.
Use account and key restrictions
For non-interactive keys, options such as a forced command, source-address restriction, and disabled forwarding can limit the blast radius of a stolen key. Keep the command and source range documented so an operator can distinguish an intentional restriction from a broken deployment. Review these restrictions whenever the job’s source host or command changes.
Restrict network exposure
Host firewall rules
Allow the SSH port only from the administration addresses or networks that need it. Ubuntu’s ufw syntax for a source restriction is:
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.
sudo ufw allow proto tcp from <address-or-cidr> to any port 22Replace port 22 if sshd listens elsewhere. Use a specific address for a fixed office or jump host, or a CIDR range for a managed network. Verify the resulting rules with sudo ufw status numbered and confirm both IPv4 and IPv6 behavior. A rule that works for IPv4 does not automatically protect or permit the IPv6 listener.
Recommended Free Tools
Provider firewall or security group
Apply the same source restriction at the VPS provider’s network boundary when available. The provider rule can block unwanted traffic before it reaches the operating system, while the host firewall still protects the instance if its network placement changes. Keep the provider console path outside the SSH rule so an overly narrow address list does not remove your only recovery channel.
Validate, reload, and test safely
- Run the platform-supported syntax check, commonly
sudo sshd -t. Fix every error before attempting a reload. - Inspect the effective configuration with the platform’s supported equivalent of
sudo sshd -T. Check the values that matter, including authentication methods, root login, allowed users or groups, forwarding, and the listening port. - Confirm that the account named in
AllowUsersor the group named inAllowGroupsexists and contains your tested administrator. - Reload the service rather than stopping it abruptly. The unit may be called
sshorsshd, so verify locally before running a command such assudo systemctl reload ssh. - Use the second terminal to establish a completely new connection with the intended key. Test sudo, an ordinary shell command, and any required automation.
- Only after the new login succeeds should you close the original session or remove obsolete keys and firewall exceptions.
Recovery if a change goes wrong
Configuration error
Use the provider console to run the syntax check and identify the failing file. Temporarily move the new drop-in out of the configuration directory, restore the last known-good version, or correct the directive, then reload sshd. Keep a dated copy of each policy revision so you can identify exactly what changed.
Authentication lockout
If keys are rejected, use the console to inspect the account’s home and .ssh ownership, file modes, line wrapping in authorized_keys, and the server log. If an AllowUsers or AllowGroups rule excludes the administrator, correct the list or group membership from the console before testing again.
Firewall lockout
Disable or amend the restrictive rule from the provider console. Check the source address seen by the VPS, which may differ from the address on your workstation because of a corporate gateway, VPN, or IPv6 transition. Reapply the narrow rule only after a new connection succeeds.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Key security features at a glance
| Feature | Security purpose | Operational trade-off |
|---|---|---|
PubkeyAuthentication |
Uses possession of a private key instead of password guessing and can be combined with other methods. | Lost keys require a documented recovery and rotation process. |
AuthenticationMethods |
Requires one or more authentication methods, including two distinct public keys. | Incorrect combinations can lock out users; each path must be tested separately. |
PermitRootLogin |
Controls direct root SSH; no blocks it, while prohibit-password still allows root keys. |
Root-based automation may need a service account, forced command, or sudo redesign. |
AllowUsers / AllowGroups |
Limits SSH to explicitly named accounts or groups. | Membership and emergency access must be maintained as staff changes. |
PasswordAuthentication and KbdInteractiveAuthentication |
Removes password and PAM keyboard-interactive paths when keys are the sole method. | Console, break-glass, or external-identity workflows may require an exception. |
DisableForwarding, AllowTcpForwarding, AllowAgentForwarding, X11Forwarding, PermitTunnel |
Reduces pivoting and tunneling capabilities. | Legitimate development and administration workflows may depend on forwarding. |
StrictModes |
Rejects unsafe ownership and permissions on homes and key files. | Permission mistakes appear as ordinary public-key authentication failures. |
RevokedKeys |
Rejects keys listed in a text file or OpenSSH key-revocation list. | Revocation data must remain readable and be replaced atomically. |
SecurityKeyProvider |
Enables FIDO authenticator-hosted keys for hardware-backed authentication. | Requires compatible clients, authenticators, enrollment, and a recovery key. |
| Firewall or security group | Restricts which networks can reach the SSH listener. | Overly narrow rules cut off legitimate administrators; IPv6 must be handled explicitly. |
Troubleshoot common symptoms
“Permission denied (publickey)”
- Confirm the client is using the intended private key with
IdentitiesOnly=yes. - Check that the public key line is complete and belongs to that private key.
- Correct ownership and modes on the home directory,
.ssh, andauthorized_keys. - Review the server authentication log while making one test connection; it usually identifies a rejected file, account, or policy.
Password prompts continue
Inspect the effective configuration, not just the file you edited. A later drop-in may override PasswordAuthentication, or PAM keyboard-interactive may still be enabled. Set both methods to no only when your recovery and identity workflows do not require them.
Forwarding stopped unexpectedly
Check whether DisableForwarding yes is active and whether a per-account exception is needed. Re-enable only the specific forwarding type required, then test from the account that uses it; do not restore every forwarding feature as a blanket fix.
Root still connects
Check the effective value of PermitRootLogin, the file ordering of drop-ins, and whether the connection is actually using a different host or port. A value of prohibit-password intentionally permits root public-key access; use no for a complete direct-root ban.
Operate the control after hardening
Hardening is a maintenance process. Rotate keys when an operator leaves, a device is lost, or a key may have been copied. Remove old public keys from authorized_keys and use RevokedKeys with an OpenSSH revocation list when you need centralized invalidation. Replace revocation files atomically and verify that sshd can read them.
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Repair Windows errors before they cause bigger problemsFix Now →Monitor authentication logs through the system’s journal or authentication log, looking for unexpected usernames, source addresses, failed-key bursts, and successful sessions outside the administration window. Patch the operating system and OpenSSH package through the normal change process, then rerun the syntax and second-session tests after upgrades.
Review the account allow-list, sudo rules, forwarding exceptions, firewall sources, IPv6 exposure, provider security-group rules, and console access whenever the workload or team changes. Keep the recovery key, console credentials, and configuration backups under separate access controls so compromising one workstation does not remove every path to the VPS.
Quick Recap
A staged checklist
- Record the port, users, automation, firewall rules, OpenSSH version, and provider console path.
- Confirm a tested recovery route and keep the existing SSH session open.
- Create a named administrator with narrowly scoped sudo access.
- Install its public key with ownership and permissions that satisfy
StrictModes. - Log in from a second terminal using that key.
- Place a reviewed policy in the appropriate sshd drop-in.
- Disable password and keyboard-interactive authentication only after key access is proven.
- Set
PermitRootLogin nounless a documented, tested exception is unavoidable. - Allow only required users or groups and disable unneeded forwarding.
- Restrict SSH at the host firewall and provider boundary, including IPv6.
- Run the syntax and effective-configuration checks, reload safely, and test a new connection.
- Rotate, revoke, monitor, patch, and review the policy as the VPS changes.
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.
