Debugging SSH Key Authentication Failures: Fixing “Permission denied (publickey)” Errors


24 views

When copying SSH private keys between machines, several subtle issues can prevent successful authentication. The debug output shows clear symptoms of key file parsing problems:

debug3: Not a RSA1 key file /home/kevin/.ssh/kev_rsa.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: missing keytype
debug3: key_read: missing whitespace

The most frequent issues when transferring private keys include:

  • Line ending conversion (CRLF vs LF)
  • File permissions being too open
  • Missing or corrupted key headers/footers
  • Hidden special characters from copy-paste

First, check the basic structure of your private key file:

# Check file permissions
ls -l ~/.ssh/kev_rsa

# Expected permissions:
-rw------- 1 kevin kevin 1675 Feb 15 09:23 /home/kevin/.ssh/kev_rsa

# Verify key format
file ~/.ssh/kev_rsa

If the key was copied via clipboard, try regenerating it properly:

# On the original machine (machine #1)
cat ~/.ssh/kev_rsa | ssh machine2 "cat > ~/.ssh/kev_rsa"

# Alternatively, use rsync to preserve formatting
rsync -avz -e ssh ~/.ssh/kev_rsa machine2:~/.ssh/

Use this command to test with maximum verbosity:

ssh -vvv -i ~/.ssh/kev_rsa \
-o PreferredAuthentications=publickey \
-o PubkeyAuthentication=yes \
user@192.168.1.244 -p 22312

If troubleshooting proves difficult, generate a new key pair:

# Generate new RSA key (4096-bit recommended)
ssh-keygen -t rsa -b 4096 -f ~/.ssh/new_rsa_key

# Copy public key to remote server
ssh-copy-id -i ~/.ssh/new_rsa_key.pub -p 22312 user@192.168.1.244

Remember to update any automation scripts or CI/CD pipelines that might be using the old key.

You've carefully copied your private key from Machine #1 to Machine #2, but SSH stubbornly refuses to authenticate. The key works perfectly on the original machine, but fails with cryptic errors on the second one. Let's examine the critical error messages:

debug3: Not a RSA1 key file /home/kevin/.ssh/kev_rsa.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: missing keytype
debug3: key_read: missing whitespace

When transferring SSH keys between systems, several things can go wrong:

  • Line ending conversion (CRLF vs LF)
  • File permission issues
  • Incomplete copy-paste operations
  • Hidden characters introduced during transfer

First, let's check if your key file is structurally sound. Run these commands:

# Check key file permissions
ls -l /home/kevin/.ssh/kev_rsa

# Verify key format
file /home/kevin/.ssh/kev_rsa

# Test key parsing
ssh-keygen -l -f /home/kevin/.ssh/kev_rsa

If the verification fails, try these solutions:

# Fix permissions (private keys should be 600)
chmod 600 /home/kevin/.ssh/kev_rsa

# Convert DOS line endings if present
dos2unix /home/kevin/.ssh/kev_rsa

# Reformat the key file
ssh-keygen -p -f /home/kevin/.ssh/kev_rsa

Instead of copy-pasting, consider these more reliable transfer methods:

# SCP between machines
scp -P 22 user@machine1:/path/to/key /home/kevin/.ssh/kev_rsa

# Using SSH agent forwarding
ssh -A user@machine2

For deeper investigation, use this command:

ssh -vvv -i /path/to/key user@host -p port 2>&1 | tee ssh_debug.log

Look for these key indicators in the output:

  • Key file parsing sequence
  • Authentication method attempts
  • Server response patterns

If troubleshooting proves fruitless, generate new keys:

ssh-keygen -t rsa -b 4096 -C "machine2_key" -f ~/.ssh/new_rsa
ssh-copy-id -i ~/.ssh/new_rsa.pub user@host -p 22312