Is your SSH private key downloadable from your own website?

Most exposed-file problems leak a secret you then have to use to get somewhere: a database password, an API key, a config value. A leaked SSH private key skips that step. It is the login. Whoever downloads it can connect to your server as you, run commands, read everything, and change anything, with no password to crack because the key is the password.

So the question is unsettlingly direct. If a stranger types yoursite.com/id_rsa or yoursite.com/.ssh/id_rsa, do they get a file back that starts with -----BEGIN OPENSSH PRIVATE KEY-----?

Why a private key ends up in a web root

It shouldn't be anywhere near one, which is exactly why this leak surprises people. It happens through the same deploy accidents that expose every other file that doesn't belong.

A developer generates a deploy key in the project directory "just to get CI working" and it gets committed. A git pull or rsync onto the server brings the whole home directory's .ssh/ along with the code. A backup script writes keys into a folder that turns out to be web-served. A Dockerfile copies the build context wholesale and the key rides in the image. The file is small, it's text, and once it's sitting next to your static assets the web server serves it like any other file. The matching .htpasswd problem is the same shape: that file holds the username and a password hash for HTTP basic auth, and a public one hands an attacker the hashes to crack offline at their leisure.

What it buys an attacker

Direct, authenticated access to whatever that key opens. The blast radius depends on where the key is trusted, and people are usually too generous with that.

If it's a server login key, they SSH in as that user, and if that user has sudo, they own the box: your data, your other secrets, your running services. If it's a deploy key for a Git host, they can pull your private source and, if it's writable, push code that ships to production. If it's a key trusted across several machines, which deploy keys often are, one download is access to all of them. There's no brute force here and no alert. A successful key-based login looks exactly like you logging in, because as far as the server is concerned, it is you.

The fix, and how to confirm it

Two parts, and order matters because the first is urgent. If a key was ever public, rotate it now: generate a new keypair, replace the public key in authorized_keys on every host that trusted the old one, and delete the old key. A private key that was downloadable is compromised permanently, and pulling the file doesn't un-leak it.

Then make sure no key is in a deployable path again.

# the key sits in the project, gets deployed and served
./.ssh/id_rsa
./deploy_key
# both downloadable at yoursite.com/...

Keys also shouldn't live in the project directory at all. They belong in the user's ~/.ssh on the machine that needs them, with 600 permissions, and CI should use the platform's secret store, not a committed file. For the .htpasswd case, move the file outside the web root and point your server config at the absolute path.

Whether your site serves a real private key or a basic-auth password file is something a stranger checks by requesting the path, and we check it the same way. SurfaceCheckr requests the known key and credential paths from outside and inspects each response for the actual signature, the BEGIN ... PRIVATE KEY body for a key, the user:hash format for an .htpasswd, so a soft-404 that 200s everything doesn't get mistaken for a real hit. It reads just enough to confirm the file is the genuine article and flags it. That's a ten-second check on the single worst file you could leave in a web root, and the only way to catch it is to send the request a stranger would send.