The verbose SSH output shows a puzzling sequence where the client offers public keys but doesn't properly attempt private key authentication:

debug1: Offering RSA public key: /home/martin/.ssh/id_rsa
debug1: Authentications that can continue: publickey
debug1: Trying private key: /home/martin/.ssh/id_dsa
debug1: Trying private key: /home/martin/.ssh/id_ecdsa
debug1: Trying private key: /home/martin/.ssh/id_ed25519

The listing shows correct permissions for the key files:

total 20
drwx------  2 martin martin 4096 feb 26 09:44 .
drwxr-xr-x 41 martin martin 4096 feb 26 09:37 ..
-rw-------  1 martin martin 1766 feb 25 16:31 id_rsa
-rw-r--r--  1 martin martin  409 feb 25 16:31 id_rsa.pub
-rw-r--r--  1 martin martin  540 feb 26 09:46 known_hosts

The most frequent causes for this behavior include:

# 1. Verify the key is actually added to ssh-agent
ssh-add -l

# 2. Force specific key usage with -i parameter
ssh -i ~/.ssh/id_rsa user@host -v

# 3. Check server-side authorized_keys permissions
# On remote server:
chmod 600 ~/.ssh/authorized_keys
chmod 700 ~/.ssh

A proper ~/.ssh/config entry should look like:

Host myserver
    HostName server.example.com
    User myusername
    IdentityFile ~/.ssh/id_rsa
    IdentitiesOnly yes  # Crucial to limit key attempts

For deeper investigation:

# Increase verbosity for more details
ssh -vvv user@host

# Test key authentication separately
ssh-keygen -y -f ~/.ssh/id_rsa | ssh user@host "cat >> ~/.ssh/authorized_keys"

# Verify the key type is supported
ssh -Q key

On the remote server, verify these settings in /etc/ssh/sshd_config:

PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
PasswordAuthentication no  # To ensure key auth is enforced

---

When examining SSH authentication failures, the debug output reveals the exact sequence of attempts. In your case, the critical lines are:

debug1: Offering RSA public key: /home/martin/.ssh/id_rsa
debug1: Authentications that can continue: publickey

This indicates the client is offering the key but the server is rejecting it. Let's break down the troubleshooting process.

Your ls -la output shows correct permissions (600 for private key, 644 for public):

-rw------- 1 martin martin 1766 feb 25 16:31 id_rsa
-rw-r--r-- 1 martin martin 409 feb 25 16:31 id_rsa.pub

However, let's verify the parent directory permissions too:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_rsa
chmod 644 ~/.ssh/id_rsa.pub

Even with correct local setup, server-side problems can prevent authentication. Verify:

1. The public key exists in ~/.ssh/authorized_keys on the server
2. The authorized_keys file permissions are 600
3. SSH daemon configuration allows public key auth (PubkeyAuthentication yes)

Check server auth logs for more details:

tail -f /var/log/auth.log
# Or on RHEL/CentOS:
tail -f /var/log/secure

Try these SSH client commands to force specific behavior:

# Explicitly specify key file
ssh -v -i ~/.ssh/id_rsa user@host

# Skip other auth methods
ssh -v -o PreferredAuthentications=publickey user@host

# Combine both approaches
ssh -v -i ~/.ssh/id_rsa -o PreferredAuthentications=publickey user@host

Create or modify ~/.ssh/config with these settings:

Host target-server
    HostName example.com
    User martin
    IdentityFile ~/.ssh/id_rsa
    PreferredAuthentications publickey
    IdentitiesOnly yes

The IdentitiesOnly yes directive prevents SSH from trying other keys.

Modern SSH servers may reject older key formats. Check your key type:

ssh-keygen -lf ~/.ssh/id_rsa.pub

If you need to upgrade to a more secure format:

ssh-keygen -p -f ~/.ssh/id_rsa -m PEM

Generate a new test key pair to isolate the issue:

ssh-keygen -t ed25519 -f ~/.ssh/test_key -N ""
ssh-copy-id -i ~/.ssh/test_key user@host
ssh -v -i ~/.ssh/test_key user@host

This helps determine if the issue is specific to your existing key.