cPanel SSH Key Setup Tutorial (2026): Disable Password Logins for WHM, cPanel Users, and SFTP

Passwords are still the easiest way into hosting servers. If your cPanel box allows SSH password auth, one leaked credential can turn into a full WHM compromise.

This cPanel SSH key setup tutorial shows how to move WHM/root and cPanel users to SSH keys. You’ll then disable password logins without locking yourself out.

The steps apply to cPanel & WHM on AlmaLinux/Rocky Linux/CentOS Stream. Roll this out in a safe order. Add keys first, test from a second session, then turn off passwords.

Keep a rollback plan ready before you touch sshd.

What you’ll set up (and what you should not change yet)

You’re going to:

• Create an SSH key pair on your admin machine
• Install the public key for root (or an admin user) and for selected cPanel accounts
• Harden sshd to disable password authentication
• Verify SFTP/scp still work for customers who use SSH keys

You’re not going to change the SSH port in this guide. That’s a separate change, and it has different ways to fail.

If you want that next, follow our SSH port change tutorial.

Prerequisites and safe-work checklist

• cPanel/WHM server access over SSH as root (or sudo-capable admin)
• A second active SSH session kept open while you test changes
• Out-of-band/console access (IPMI/KVM) for dedicated servers, or provider console for VPS
• A place to store private keys securely (1Password, Bitwarden, or your OS keychain)

If this is a brand-new server, do the SSH work before you onboard users.

On production hosting nodes, schedule a maintenance window. Warn anyone still using password-based SFTP.

Need a clean baseline server first? A managed VPS hosting plan from HostMyCode fits well if you want hardened defaults and help if an SSH change goes wrong.

Step 1: Confirm your current SSH authentication settings

On the server, check what sshd is actually allowing:

sshd -T | egrep -i 'passwordauthentication|pubkeyauthentication|permitrootlogin|authenticationmethods'

On older installs you’ll often see PasswordAuthentication yes. The target end state is:

• PubkeyAuthentication yes
• PasswordAuthentication no
• PermitRootLogin prohibit-password (or without-password on older sshd)

Also confirm the running SSH port (usually 22):

ss -tulpn | awk '$1 ~ /tcp/ && $5 ~ /:22$/ {print}'

Step 2: Generate a strong SSH key on your admin machine

Generate the key on your workstation (not the server). Use Ed25519 and set a passphrase.

You won’t type the passphrase often. It also prevents a stolen key file from turning into instant access.

ssh-keygen -t ed25519 -a 64 -f ~/.ssh/hostmycode-cpanel-admin

This creates:

• ~/.ssh/hostmycode-cpanel-admin (private key, keep secret)
• ~/.ssh/hostmycode-cpanel-admin.pub (public key, safe to share)

If you already have keys, don’t reuse one personal key across every server you manage.

Use per-environment keys and rotate them.

If you’re planning a rotation, see our SSH key rotation tutorial.

Step 3: Install the key for root (or your admin user) the safe way

From your workstation, push the public key with ssh-copy-id:

ssh-copy-id -i ~/.ssh/hostmycode-cpanel-admin.pub root@YOUR_SERVER_IP

If root SSH is disabled on your build, use your admin user instead:

ssh-copy-id -i ~/.ssh/hostmycode-cpanel-admin.pub admin@YOUR_SERVER_IP

Now force a key-based login test:

ssh -i ~/.ssh/hostmycode-cpanel-admin root@YOUR_SERVER_IP

Don’t close your original SSH session.

Open a second session for this test. If the key login fails, you can fix it without a rescue console.

Step 4: Lock down permissions (this is where most key setups fail)

On the server, fix permissions for the target user (example shows root):

chmod 700 /root/.ssh
chmod 600 /root/.ssh/authorized_keys
chown -R root:root /root/.ssh

For a non-root user:

chmod 700 /home/USERNAME/.ssh
chmod 600 /home/USERNAME/.ssh/authorized_keys
chown -R USERNAME:USERNAME /home/USERNAME/.ssh

If SELinux is enforcing (common on AlmaLinux/Rocky), restore contexts:

getenforce
restorecon -Rv /root/.ssh /home/USERNAME/.ssh

Step 5: Enable SSH keys for cPanel users (SFTP/scp workflows)

Many hosting customers still sign in to SFTP with passwords. Before you disable passwords globally, decide what you’re enforcing.

Also decide who needs a transition window:

• Hosting/reseller nodes: move customers to SFTP with per-user SSH keys.
• Business VPS: move your team first, then disable passwords.

To add a key for a cPanel user (example: exampleuser), switch to that user and create authorized_keys:

su - exampleuser
mkdir -p ~/.ssh
chmod 700 ~/.ssh
cat >> ~/.ssh/authorized_keys <<'EOF'
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... your-public-key ... comment
EOF
chmod 600 ~/.ssh/authorized_keys
exit

Test SFTP key auth from your workstation:

sftp -i ~/.ssh/hostmycode-cpanel-admin exampleuser@YOUR_SERVER_IP

If you need tighter file access controls, chrooted SFTP is the next layer.

Use our VPS SFTP setup guide tutorial as a pattern. Then adapt it to your cPanel filesystem layout.

Step 6: Update sshd_config for key-only access (with a rollback path)

On cPanel servers, sshd config is typically in /etc/ssh/sshd_config. It may also pull in snippets from /etc/ssh/sshd_config.d/.

Start by backing up your config:

cp -a /etc/ssh/sshd_config /etc/ssh/sshd_config.bak.$(date +%F)
ls -la /etc/ssh/sshd_config*

Edit /etc/ssh/sshd_config and set (or verify) these lines.

If the same setting appears in an included file, keep one authoritative value. This avoids confusion later.

# Allow SSH keys
PubkeyAuthentication yes

# Disable password-based SSH
PasswordAuthentication no
KbdInteractiveAuthentication no
ChallengeResponseAuthentication no

# Root can log in, but only with keys
PermitRootLogin prohibit-password

# Reduce brute-force noise
MaxAuthTries 3
LoginGraceTime 20

# Optional: don’t use DNS lookups during login
UseDNS no

Reseller/shared hosting note: if you have a few legacy users who can’t switch immediately, do a staged cutover with Match User blocks.

Example (temporary):

PasswordAuthentication no

Match User legacyuser1,legacyuser2
  PasswordAuthentication yes

Keep the exception list small. Give it an expiration date.

“Temporary” password access has a habit of sticking around.

Step 7: Validate sshd config before restarting (avoid self-inflicted outages)

Run a syntax check first:

sshd -t

No output means sshd accepts the config. If you get an error, fix it before you restart anything.

Restart sshd and check service health:

systemctl restart sshd
systemctl status sshd --no-pager

Then test from a fresh terminal on your workstation:

ssh -i ~/.ssh/hostmycode-cpanel-admin root@YOUR_SERVER_IP

Finally, confirm password logins are rejected:

ssh root@YOUR_SERVER_IP

You should see Permission denied (publickey) (or similar).

Step 8: Make sure WHM/cPanel operations still work

SSH key auth doesn’t affect WHM/cPanel web logins. Still, validate the admin workflows you rely on:

• Log into WHM normally over HTTPS
• Run an update check: /usr/local/cpanel/scripts/upcp --check
• Verify you can open a terminal in WHM (if enabled) and it connects

If you already restrict WHM access with IP allowlisting, keep it.

Key-only SSH cuts risk, but WHM remains a high-value target.

Step 9: Common failures and quick fixes

Key works for root but not for a cPanel user

• Wrong permissions: the user’s ~/.ssh must be 700, authorized_keys must be 600.
• Wrong ownership: chown -R user:user ~/.ssh
• SELinux context: run restorecon -Rv /home/user/.ssh
• Key pasted with line breaks: the public key must be a single line.

Password auth still works after you disabled it

Something is overriding your setting. Confirm the effective values:

sshd -T | egrep -i 'passwordauthentication|kbdinteractiveauthentication'

If it still shows yes, look for duplicates in the main file and includes:

grep -R --line-number -E 'PasswordAuthentication|KbdInteractiveAuthentication' /etc/ssh/sshd_config /etc/ssh/sshd_config.d/* 2>/dev/null

You locked yourself out (rollback plan)

If you still have one SSH session open, revert immediately:

cp -a /etc/ssh/sshd_config.bak.YYYY-MM-DD /etc/ssh/sshd_config
systemctl restart sshd

If SSH is completely gone, use console access (VPS provider console or dedicated server IPMI/KVM). Apply the same rollback there.

Hardening extras that pair well with key-only SSH

Once keys are working, harden in small steps. Change one thing, test it, then move on.

• Firewall rules: allow SSH only from your office/VPN IP range. Start with our VPS firewall setup guide tutorial concepts, then apply them with your distro’s firewall (firewalld on Alma/Rocky is common).
• Jump host: keep port 22 private and access through a bastion. Use SSH jump host setup guide tutorial.
• Monitoring: alert on spikes in SSH failures and unexpected root logins. For a lightweight stack, see VPS monitoring setup tutorial.

Operational checklist for hosting teams and resellers

• Document which users have SSH access and why.
• Require per-person keys (no shared “team key”).
• Store public keys in version control or a password manager note.
• Remove keys immediately on offboarding.
• Quarterly: verify PasswordAuthentication no stayed that way after updates.
• Keep console access tested. “We have it” isn’t the same as “we used it this year.”

Summary: key-based SSH is the cleanest win for cPanel security

On any server that hosts multiple sites or resold accounts, disabling SSH passwords removes a whole category of brute-force and credential-stuffing risk.

Add keys, test them, then flip the switch. Keep a backup of sshd_config, and keep one active session open while you work.

Running cPanel on a server that’s outgrowing shared resources? Start with a HostMyCode VPS for full root control, or use managed VPS hosting if you want an expert handling hardening and recovery.

FAQ

Will disabling SSH passwords break WHM or cPanel logins?

No. WHM/cPanel web logins are separate from SSH. This change only affects SSH, SFTP, and scp authentication.

Can I disable root SSH and use a sudo user instead?

Yes, and many teams prefer it. Create an admin user, add your key, confirm sudo works, then set PermitRootLogin no. Keep console access ready before you change it.

Do cPanel users need shell access for SFTP with keys?

They need SSH access. In WHM you can set a user to “Normal Shell” or “Jailed Shell” depending on your policy. SFTP uses SSH, so completely disabling shell access can block it.

How do I handle legacy users who only know password SFTP?

Give them a deadline and provide a key setup template. If you must, use a short-lived Match User exception while they transition, then remove it.

What’s the fastest way to verify passwords are really off?

Run sshd -T | grep -i passwordauthentication on the server, then try a password login from a new terminal. You want an immediate rejection.