How to Fix SSH Permission denied Error on macOS: Causes and Solutions

What the SSH Permission denied Error Means

When attempting to connect to a remote server via SSH on macOS, you see the message:

Permission denied (publickey,password).

This error means the server rejected your authentication attempt. SSH tried several methods (first public key, then password), but none succeeded. As a result, access is denied.

The SSH Permission denied error is not specific to macOS—it occurs on any platform. However, macOS has its own nuances: key file locations, Keychain integration, agent settings. This article focuses specifically on solving the problem in a macOS environment.

Common Causes

The Permission denied error is usually caused by one of the following:

1. Incorrect permissions on your SSH key files on your Mac. The private key (e.g., ~/.ssh/id_rsa) must be readable only by the owner (permissions 600). If permissions are more open (e.g., 644), SSH will refuse to use the key for security reasons.
2. Missing public key on the server. Your public key (id_rsa.pub) was not added to the ~/.ssh/authorized_keys file on the remote server, or was added incorrectly (e.g., with line breaks).
3. SSH agent is not running or does not have keys loaded. On macOS, the agent (ssh-agent) usually starts automatically, but sometimes keys are not loaded into the session, especially after a reboot.
4. Incorrect path to the private key when connecting. If the key is in a non-standard location or has a different name, you need to specify it explicitly with the -i option.
5. Key-based authentication is disabled on the server. In the SSH server configuration (/etc/ssh/sshd_config), PubkeyAuthentication may be set to no or PasswordAuthentication may be set to no (and password authentication is disabled).
6. Incorrect username. You are trying to log in as a user who does not have access or the username is specified incorrectly.
7. Two-factor authentication or other restrictions (e.g., AllowUsers in the server config).

Solutions

Method 1: Check SSH Key File Permissions

On macOS, permissions on SSH key files must be strictly limited. Open Terminal and run:

# Check permissions on the .ssh folder
ls -ld ~/.ssh
# Expected output: drwx------  or drwxr-xr-x (but 700 is better)

# Check permissions on the private key (e.g., id_rsa)
ls -l ~/.ssh/id_rsa
# Expected output: -rw-------  (600)

# If permissions are different, fix them:
chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_rsa
# If you have multiple keys, fix each private key.

⚠️ Important: Do not set permissions 777 or 644 on private keys—SSH will refuse to use them.

After fixing permissions, try connecting again.

Method 2: Add Your Public Key to the Server

Ensure your public key is present in authorized_keys on the server.

1. On your Mac, copy the contents of your public key:

cat ~/.ssh/id_rsa.pub

Copy the entire output (starts with ssh-rsa ...).

2. On the server (if you already have access, e.g., via password) open or create the file:

mkdir -p ~/.ssh
chmod 700 ~/.ssh
nano ~/.ssh/authorized_keys

Paste the copied line at the end of the file. Save (Ctrl+X, then Y, Enter).

3. Set correct permissions:

chmod 600 ~/.ssh/authorized_keys

4. Try connecting again.

💡 Tip: If you do not have access to the server, ask the administrator to add your public key.

Method 3: Start and Configure the SSH Agent

macOS uses ssh-agent to store keys in memory. Check if the agent is running and if keys are loaded:

# Check if the agent is running
echo $SSH_AUTH_SOCK
# If output is empty, the agent is not running in the current session.

# Start the agent manually
eval "$(ssh-agent -s)"
# Output should be: Agent pid 12345

# Add the key (if not loaded)
ssh-add ~/.ssh/id_rsa
# If the key is password-protected, enter the passphrase.

# Check the list of loaded keys
ssh-add -l
# Should show the fingerprint of your key.

If you are using an SSH key with a passphrase, to avoid entering it every time, add the key to macOS Keychain:

ssh-add -K ~/.ssh/id_rsa

The -K (capital K) flag saves the passphrase in Keychain, and the key will be loaded automatically at login.

After loading the key, try connecting again.

Method 4: Specify the Key Explicitly When Connecting

If your key has a non-standard name or is located elsewhere, specify it explicitly:

ssh -i ~/.ssh/your_key user@host

For example:

ssh -i ~/.ssh/id_ed25519 user@example.com

You can also add a setting to your local SSH config (~/.ssh/config) to avoid specifying the key each time:

Host myserver
    HostName example.com
    User username
    IdentityFile ~/.ssh/id_ed25519

After this, simply run ssh myserver.

Method 5: Check the SSH Server Configuration

If you have access to the server (e.g., via console or another account), check its settings:

1. Open the configuration file:

sudo nano /etc/ssh/sshd_config

2. Ensure the following parameters are set:

PubkeyAuthentication yes
PasswordAuthentication yes   # if you want to allow password (not recommended)
AuthorizedKeysFile .ssh/authorized_keys

3. Also check if there are any restrictions for your user (the AllowUsers or DenyUsers directives).
4. After making changes, restart the SSH daemon:

sudo systemsetup -setremotelogin on   # for macOS Server
# or
sudo launchctl unload /System/Library/LaunchDaemons/ssh.plist
sudo launchctl load -w /System/Library/LaunchDaemons/ssh.plist

On standard macOS (not Server), SSH is managed via systemsetup or launchctl.

Method 6: Temporarily Disable Key Authentication for Diagnosis

To understand exactly what the problem is (key or password), try connecting with key authentication disabled:

ssh -o PubkeyAuthentication=no user@host

If password-based connection succeeds, the issue is with the keys (permissions, missing on server, agent). If this also results in Permission denied, password authentication may be disabled on the server (PasswordAuthentication no) or your password is incorrect.

You can also enable verbose logging for SSH to see what is happening:

ssh -vvv user@host

Look for lines like Offering public key and Authentication failed in the output. This helps pinpoint the problem.

Prevention

To avoid the SSH Permission denied error in the future:

1. Always maintain correct permissions on ~/.ssh and your key files. After generating a key (ssh-keygen), the system usually sets correct permissions, but they can get messed up when copying files.
2. Add public keys to the server immediately after generation. Use ssh-copy-id user@host (if installed) or copy manually.
3. Use the SSH agent and Keychain for automatic key loading. On macOS this works out of the box, but after a system update or account change, you may need to restart the agent.
4. Store private keys in a secure location and never share them with third parties.
5. Regularly check server configuration after updates, especially if you are an administrator.
6. Use the ~/.ssh/config file to manage multiple servers and keys. This reduces the chance of specifying the wrong key.
7. If using a passphrase on your key, ensure it is strong enough, and consider using hardware tokens (e.g., YubiKey) for two-factor authentication.

Following these recommendations will minimize the risk of access errors when working with SSH on macOS.