Fix 'UNPROTECTED PRIVATE KEY FILE' when you SSH

The warning unprotected private key file means other accounts on your computer have access to the key file, so OpenSSH refuses to use it, and on macOS and Linux the fix is one command: chmod 600 on the key file.

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/home/you/.ssh/id_ed25519' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
Load key "/home/you/.ssh/id_ed25519": bad permissions
ubuntu@203.0.113.10: Permission denied (publickey).

The text comes from OpenSSH's authfile.c and sshconnect2.c, and the last line is how the login ends when no other key works. On Windows the fourth line has no number: the source of Win32-OpenSSH prints Permissions for 'C:\Users\you\.ssh\id_ed25519' are too open. instead. The OpenSSH source, the manuals and the Microsoft documentation cited below were checked on 12 November 2026.

The warning "unprotected private key file", line by line

The check is short. If the key file belongs to the account running ssh, OpenSSH refuses it when any permission bit is set for the group or for others. The Permissions 0644 ... are too open line shows the mode it found, and the Load key line then reports bad permissions. The ssh manual says the same thing in one sentence: "ssh will simply ignore a private key file if it is accessible by others." So the warning is not cosmetic. SSH moves on to your other keys, and if none of them is accepted you get Permission denied (publickey), which the permission denied page covers.

Modes 600 and 400 pass. Modes 640, 644 and 660 do not. A .pem extension changes nothing, because the check reads the mode and never the file name.

Fix it on macOS and Linux

ls -l ~/.ssh/id_ed25519
chmod 600 ~/.ssh/id_ed25519
chmod 700 ~/.ssh
ls -l ~/.ssh/id_ed25519

In the listing, -rw-r--r-- is read and write for you and read for the group and everyone else, which is mode 644. After the fix it reads -rw-------. The chmod manual explains numeric modes: read is 4, write is 2 and execute is 1, and the digits are for the owner, the group and others in that order. So 600 is read and write for you and nothing for anyone else. The ssh manual asks for ~/.ssh to be "read/write/execute for the user, and not accessible by others", which is 700, so I set that in the same step. Microsoft's VS Code documentation uses chmod 400 for the private key in one place and chmod 600 for any key file in another, and both pass the same check. Never use 777, because it grants the access the warning is about.

Fix it in WSL

WSL mounts your Windows drives under /mnt, so a key in your Windows Downloads folder sits at /mnt/c/Users/YOUR_WINDOWS_USER/Downloads/YOUR_KEY_FILE. Microsoft's WSL configuration documentation describes the metadata mount option as "Whether metadata is added to Windows files to support Linux system permissions" and lists it as disabled by default. A Windows Command Line post says you must remount the drive with metadata before chmod works on those files, and describes the old behavior as "a no-op". So chmod on a key under /mnt/c does nothing by default.

The simple fix is to copy the key into the Linux home directory, where permissions work as on any Linux machine:

mkdir -p ~/.ssh
cp /mnt/c/Users/YOUR_WINDOWS_USER/Downloads/YOUR_KEY_FILE ~/.ssh/
chmod 700 ~/.ssh
chmod 600 ~/.ssh/YOUR_KEY_FILE

To keep the key on the Windows drive, the documentation shows the option in /etc/wsl.conf, which applies to every drive WSL mounts automatically. Run wsl --shutdown in PowerShell afterwards, which the documentation calls a fast path that stops all running distributions:

[automount]
options = "metadata"

Fix it on Windows

The Windows OpenSSH client checks access control lists instead of mode bits. The Win32-OpenSSH wiki says private keys "need to be owned by the user and no other user should have access to user's key files." Keep the key in the .ssh folder of your user folder and strip everything but your own access with icacls. The commands follow Microsoft's OpenSSH key management guide, which uses /inheritance:r, and the icacls reference defines the other options:

Move-Item -Path "C:\Users\YOUR_WINDOWS_USER\Downloads\YOUR_KEY_FILE" -Destination "C:\Users\YOUR_WINDOWS_USER\.ssh\"
icacls "C:\Users\YOUR_WINDOWS_USER\.ssh\YOUR_KEY_FILE" /inheritance:r
icacls "C:\Users\YOUR_WINDOWS_USER\.ssh\YOUR_KEY_FILE" /grant:r "YOUR_WINDOWS_USER:R"
icacls "C:\Users\YOUR_WINDOWS_USER\.ssh\YOUR_KEY_FILE"

The first line moves a downloaded key, so create the folder first if it does not exist. The second removes inherited permissions, the third gives your account read-only access, and the last lists who can reach the file, which should now be only you. If (Get-Acl "C:\Users\YOUR_WINDOWS_USER\.ssh\YOUR_KEY_FILE").Owner names a different account, the wiki's rule about ownership applies, and icacls has a /setowner option for it.

The key DeployGPU gave you

The key DeployGPU creates at signup is offered once, for about 10 minutes, as a .pem download, and a key you generate on the SSH keys page works the same way. Your browser saves it in the Downloads folder unless you chose another place, so it starts outside ~/.ssh. Move it in and fix its permissions, then pass it with -i. On Windows, the PowerShell commands above already move the file:

mkdir -p ~/.ssh
mv ~/Downloads/YOUR_KEY_FILE ~/.ssh/
chmod 700 ~/.ssh
chmod 600 ~/.ssh/YOUR_KEY_FILE
ssh -i ~/.ssh/YOUR_KEY_FILE ubuntu@203.0.113.10

Use the user from your deployment, which is ubuntu on QuantaCloud and Hyperstack, Ubuntu with a capital U on Massed Compute and root on Verda. If the download never happened, fixing permissions cannot help, because the private half cannot be shown again. Add a new key and launch with it selected. The permission denied page covers that case.

The same check for your config file

A message that looks similar, Bad owner or permissions on /home/you/.ssh/config, is about the config file and not the key. The source in readconf.c rejects a config file that is owned by neither root nor you, or that the group or others can write to. The ssh manual asks for "read/write for the user, and not writable by others", and the fix is chmod 600 ~/.ssh/config.

When to contact support

Contact support only when the warning is gone and the login still fails with the key selected on the deployment. Email support@deploygpu.ai with the output of ssh -v -i ~/.ssh/YOUR_KEY_FILE ubuntu@203.0.113.10, the provider and the deployment ID. The contact page is the other way in, the SSH guide covers keys and config files, and host key verification failed covers the warning about a changed host key.