Here's the exact behavior I'm observing when attempting X2GO connection:

1. Immediate fallback to username/password prompt
2. "No public key matched" error when enabling auto-login
3. Confirmed working SSH access with same credentials
4. Working password authentication when enabled on server

First, let's verify the keychain status:

# Check SSH agent key loading
$ ssh-add -l
1024 b9:3d:e5:ef:48:ea:fc:c6:6e:45:89:b5:35:e7:58:39 server.com_dsa (DSA)

# Test raw SSH connection
$ ssh -v -i ~/.ssh/server.com_dsa user@host
... (successful connection logs)

Common pitfalls in X2GO client settings:

• Key path must be absolute (not ~/.ssh/ expansion)
• DSA keys require explicit permission settings
• Session preferences must match server-side auth methods

Example correct configuration:

<session>
  <name>RemoteDesktop</name>
  <keyfile>/home/user/.ssh/server.com_dsa</keyfile>
  <autologin>1</autologin>
  <auth>pubkey</auth>
</session>

Check the auth log during connection attempts:

$ tail -f /var/log/auth.log
... sshd[pid]: Found matching DSA key: b9:3d:e5:ef:48:ea:fc:c6:6e:45:89:b5:35:e7:58:39
... x2golistsessions: Authentication tried for user with public key but failed

Modern systems often disable DSA by default. Verify sshd_config:

# /etc/ssh/sshd_config must contain:
PubkeyAuthentication yes
HostKeyAlgorithms ssh-rsa,ssh-dss

If DSA proves problematic:

1. Generate new ED25519 key pair:

   ssh-keygen -t ed25519 -f ~/.ssh/x2go_ed25519

2. Convert existing DSA to RSA:

   ssh-keygen -p -f ~/.ssh/server.com_dsa -m pem

Required permission structure:

$ chmod 700 ~/.ssh
$ chmod 600 ~/.ssh/server.com_dsa
$ chmod 644 ~/.ssh/server.com_dsa.pub
$ chmod 755 ~

---

When attempting X2Go remote desktop connections using DSA keys, many users encounter immediate fallback to password authentication despite properly configured SSH access. The server consistently responds with:

No public key matched
Access denied. Authentication that can continue: publickey

While both protocols use OpenSSH underneath, X2Go implements additional security layers that affect key authentication:

• X2Go requires keys to be in specific formats
• Agent forwarding behaves differently in GUI sessions
• Key permissions are validated more strictly

First, confirm your key is properly loaded in ssh-agent:

ssh-add -l
# Expected output showing your key fingerprint:
# 2048 SHA256:AbCdEfGh... /home/user/.ssh/id_rsa (RSA)

Then verify the remote server accepts your key for SSH:

ssh -v -i ~/.ssh/id_dsa user@server.com
# Look for:
# debug1: Authentication succeeded (publickey)

1. Key Format Conversion

Convert legacy DSA keys to RSA and update permissions:

ssh-keygen -p -f ~/.ssh/id_dsa -m PEM
chmod 600 ~/.ssh/id_dsa

2. X2Go Client Configuration

In the session preferences:

• Check "Use SSH agent" if available
• Explicitly browse to select the private key file
• Disable "Try auto login" and manually specify the key

3. Server-Side Adjustments

Edit /etc/ssh/sshd_config to ensure these settings:

PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
PasswordAuthentication no

Then restart sshd:

sudo systemctl restart sshd

Enable detailed logging on the server:

tail -f /var/log/auth.log

And on the client side:

x2goclient --debug

If problems persist, consider these workarounds:

# Create new ED25519 key pair
ssh-keygen -t ed25519 -C "x2go_access"

# Temporary password fallback
sudo sed -i 's/PasswordAuthentication no/PasswordAuthentication yes/' /etc/ssh/sshd_config