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


2 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