Victor's room

Overview & Root Cause Summary: The error Permission denied (publickey) (or Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password)) occurs during an SSH session or Git command when the destination server requires public key authentication, but fails to validate the cryptographic credentials presented by the client. This typically stems from the private key not being loaded into the local ssh-agent, overly permissive permissions on local or remote .ssh directories, missing keys in the server’s authorized_keys, or OpenSSH 8.8+ disabling deprecated SHA-1 RSA signatures.

Understanding the Root Causes

• Private Key Not Loaded in ssh-agent: The local SSH agent is either not running or has not registered the specific private key file (e.g., custom named keys like ~/.ssh/id_ed25519_work).
• Insecure File Permissions (StrictModes Enforcement): OpenSSH strictly mandates secure permissions. If ~/.ssh is not 700 or private keys / authorized_keys are not 600, the SSH daemon or client automatically ignores them.
• Missing Public Key on Target Host / Git Service: The corresponding public key has not been appended to the server’s ~/.ssh/authorized_keys or uploaded to GitHub/GitLab user settings.
• OpenSSH 8.8+ RSA Signature Deprecation (ssh-rsa SHA-1): Modern versions of OpenSSH disable the legacy ssh-rsa algorithm by default due to security vulnerabilities, rejecting older RSA 2048/4096-bit keys.

Step 1: Quick Fix (Load Key into ssh-agent & Specify Identity)

Ensure the background SSH agent is running and register your private key.

# 1. Start the SSH agent in your current shell:
eval "$(ssh-agent -s)"

# 2. Check currently loaded keys:
ssh-add -l

# 3. Add your private key to the agent:
ssh-add ~/.ssh/id_ed25519
# (Or for RSA keys):
ssh-add ~/.ssh/id_rsa

# 4. Alternatively, explicitly pass the identity file when connecting:
ssh -i ~/.ssh/id_ed25519 user@remote-host.com

Step 2: Correct Client & Server File Permissions (chmod 700/600)

Reset strict POSIX permissions across both local client and remote server SSH directories.

# --- On your Local Machine (Client) ---
# Set directory permissions:
chmod 700 ~/.ssh

# Set private key permissions (read/write only for owner):
chmod 600 ~/.ssh/id_ed25519 ~/.ssh/id_rsa 2>/dev/null

# Set public key and config permissions:
chmod 644 ~/.ssh/*.pub ~/.ssh/known_hosts ~/.ssh/config 2>/dev/null

# --- On the Remote Server ---
# Ensure correct ownership and permissions for the target user:
sudo chown -R $USER:$USER ~/.ssh
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Step 3: Resolve OpenSSH 8.8+ Legacy RSA Rejection (SHA-1 Deprecation)

If connecting to older servers with existing RSA keys on newer OpenSSH clients, configure modern signature algorithms or upgrade to ED25519.

# Best Practice: Generate a modern, secure ED25519 key pair:
ssh-keygen -t ed25519 -C "your_email@example.com"
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@remote-host.com

# Temporary Compatibility Workaround:
# Add RSA SHA-2 support to your local ~/.ssh/config:
nano ~/.ssh/config

# Add the following configuration block:
Host remote-host.com
    HostkeyAlgorithms +ssh-rsa
    PubkeyAcceptedAlgorithms +ssh-rsa

Verification & Testing Steps

Validate SSH authentication and run verbose debugging to trace the exact key exchange process.

# 1. Test Git authentication against GitHub:
ssh -v -T git@github.com
# Expected output: "Hi <username>! You've successfully authenticated..."

# 2. Test connection to a remote Linux server with verbose diagnostics:
ssh -vvv user@remote-host.com

# 3. In the debug output, confirm:
# "Offering public key: /home/user/.ssh/id_ed25519"
# "Server accepts key: pkalg ssh-ed25519"
# "Authentication succeeded (publickey)."

Summary Comparison Table