cPanel SSH Access Manager: Setup Guide and Key Auth Fixes

You've got SSH enabled on your shared hosting account, but every login still asks for a password — and your deploy script or CI pipeline needs key-based auth to run unattended. cPanel's SSH Access Manager handles exactly this, but the UI is easy to misuse: generate a key in the wrong place, forget to authorize it, or paste a key type your server's OpenSSH build doesn't accept, and you're stuck staring at "Server refused our key" with no obvious reason why.

What SSH Access Manager Actually Does

It lives under cPanel → Security → SSH Access, and it's a thin UI over standard OpenSSH public-key authentication scoped to your one hosting account — not WHM, not root, not a VPS-wide setting. Three things happen here, and they're easy to mix up:

• Generate a Key creates a fresh key pair on the server and drops the public half into ~/.ssh/authorized_keys automatically.
• Import Key lets you upload a public key you already generated locally (with ssh-keygen or PuTTYgen), but it does not authorize it for login until you explicitly click Authorize afterward.
• Manage Keys shows every key on the account and whether its status is Authorized or Not Authorized — this status flag is the single most common thing people miss.

None of this replaces the account's SSH access being turned on in the first place. If SSH itself isn't enabled for the account (a WHM-level flag on shared/reseller plans), you won't see the SSH Access icon in cPanel at all, and no amount of key wrangling will fix that — that needs your host to flip it on for the package or account.

Symptom: "Server Refused Our Key" or Falls Back to Password Prompt

You import or generate a key, plug it into PuTTY, FileZilla, WinSCP, or your deploy tool, and connection still asks for a password (or rejects the key outright). The cause is almost always one of these, roughly in order of how often we see them on tickets:

1. The key was imported but never authorized

Importing a public key just stores it against the account. It has no login power until it shows Authorized in Manage Keys. Go to SSH Access → Manage Keys, find the key, and click Manage → Authorize. This is the #1 cause of "I added my key and it still doesn't work."

2. Wrong half of the key pair was uploaded

Import Key wants the public key (id_rsa.pub / id_ed25519.pub), not the private key. If you pasted the private key by mistake, the import will either fail or produce a key that can never authenticate anything — the private key never leaves your machine.

3. Key type isn't supported by that server's OpenSSH build

Older cPanel/CentOS 7 stacks sometimes ship an OpenSSH version that's fussy about newer ed25519 keys, especially if the key was generated with non-default parameters. RSA at 4096 bits is the safest universal choice if you hit unexplained rejection with a modern key type. Check the server's version with:

ssh -V

Anything from OpenSSH 6.5+ handles ed25519 fine, so this is rarely the real cause on current infrastructure — but it's worth ruling out before you chase something else.

4. Client is pointed at the wrong private key or wrong port

Shared hosting SSH commonly runs on port 2222, not the default 22. If your SFTP client or ssh command doesn't specify -p 2222, it'll either time out or hit the wrong service. Double-check your account's SSH port in cPanel → SSH Access → Manage SSH Keys page header, or in your welcome email from your host.

ssh -p 2222 -i ~/.ssh/id_ed25519 username@yourdomain.com

5. Permissions on the private key are too open

This one bites people on the client side, especially on Linux/macOS. OpenSSH refuses to use a private key file that's readable by other users:

chmod 600 ~/.ssh/id_ed25519

If you see UNPROTECTED PRIVATE KEY FILE in verbose output, that's the fix.

Setting It Up Correctly, Start to Finish

1. Log in to cPanel → Security → SSH Access.
2. Click Manage SSH Keys, then either Generate a New Key (server creates both halves, you download the private key immediately — it's shown only once) or Import Key if you already have a local key pair.
3. If you generated on-server: save the private key file it hands you right away. cPanel does not store a copy for you to re-download later.
4. Go back to Manage Keys, find your key in the list, and click Manage next to it.
5. Click Authorize. The status should flip to Authorized.
6. Test the connection from your terminal or SFTP client using the private key and the correct port before wiring it into any automated deploy step.

For diagnosing a stubborn failure, connect with verbose output so you can see exactly where it's failing — "connection refused," "permission denied (publickey)," and "connection timed out" all point to different problems:

ssh -v -p 2222 -i ~/.ssh/id_ed25519 username@yourdomain.com

Quick Reference: Error to Likely Cause

Using the Key With Deploy Tools

Once a key authorizes cleanly over plain ssh, it'll work the same way for anything layered on top of SSH — SFTP in FileZilla/WinSCP, cPanel's own Git Version Control feature, rsync-based deploy scripts, or a CI pipeline pulling code onto the server. Point all of them at the same private key file and the same port; there's nothing extra to configure on the cPanel side once the key shows Authorized.

Prevention

• Keep a copy of the private key somewhere safe the moment you generate it on-server — there's no second download.
• Use one key per machine or CI system, not one shared key everywhere, so you can revoke a single compromised key without breaking every integration.
• Check Manage Keys after any import — don't assume authorization happened automatically.
• Document the account's SSH port alongside its credentials so the next person (or you, in six months) doesn't waste twenty minutes on a timeout that was really a wrong port.