When examining the debug output from SSH authentication attempts, we can see the client successfully completes the key exchange (kex) process but fails at the publickey authentication stage:

Authentications that can continue: publickey,keyboard-interactive
Next authentication method: publickey
Trying private key: /xxx/.ssh/id_rsa
Authentications that can continue: publickey,keyboard-interactive

The debug log reveals the client tries multiple key files but ultimately falls back to keyboard-interactive (password) authentication. Several factors could cause this behavior:

• Incorrect permissions on ~/.ssh directory (should be 700)
• Incorrect permissions on authorized_keys file (should be 600)
• Key formatting issues during transfer
• SSH daemon configuration restrictions

In proprietary Linux environments where standard tools like ssh-copy-id aren't available, manual key transfer often introduces formatting issues:

# Bad formatting (line breaks in middle of key)
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC
+JKlLdc8ByzjgTl8I4Jk example@server

Versus correct single-line format:

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC+JKlLdc8ByzjgTl8I4Jk example@server

Verify these settings in /etc/ssh/sshd_config on ServerB:

PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
PasswordAuthentication no  # For enforcing key-based auth
ChallengeResponseAuthentication no

When working with limited environments, use this careful copy-paste method:

1. Open the public key file on ServerA
2. Copy first line up to last 2 characters
3. Paste into ServerB's authorized_keys
4. Manually type remaining characters including the beginning of next line
5. Repeat for subsequent lines

After fixing, test with verbose output:

ssh -vvv user@serverB

Successful authentication should show:

debug1: Authentication succeeded (publickey).

---

When examining the debug output from your SSH connection attempt, we can see the authentication sequence clearly:

debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Trying private key: /XXXX/.ssh/identity
debug1: Trying public key: /xxx/.ssh/id_rsa
debug1: Authentications that can continue: publickey,keyboard-interactive

This indicates that while the client is attempting public key authentication, the server ultimately falls back to keyboard-interactive (password) authentication.

Based on your scenario between SunOS and custom Linux systems, these are the most likely culprits:

1. SSH daemon configuration: The sshd_config might not have proper settings for public key authentication
2. Key file formatting: Line breaks in the authorized_keys file can break the key
3. File permissions: While you mentioned 700 for .ssh, individual key files need specific permissions
4. SELinux context: On some custom Linux systems, security contexts might interfere

On ServerB (the custom Linux system), verify these settings in /etc/ssh/sshd_config:

PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
PasswordAuthentication no  # Optional but recommended for security

After making changes, restart the SSH daemon:

sudo systemctl restart sshd
# Or for older systems:
sudo service ssh restart

On ServerA (SunOS), the proper way to generate keys is:

ssh-keygen -t rsa -b 4096 -C "user@ServerA"
# For newer systems consider:
ssh-keygen -t ed25519 -C "user@ServerA"

Since you can't use ssh-copy-id on this custom system, here's the exact manual process:

# On ServerA:
cat ~/.ssh/id_rsa.pub | ssh user@ServerB "mkdir -p ~/.ssh && \
  chmod 700 ~/.ssh && \
  cat >> ~/.ssh/authorized_keys && \
  chmod 600 ~/.ssh/authorized_keys"

When pasting manually, be extremely careful with line breaks. As you discovered, a multi-line key in authorized_keys will fail. The solution is to ensure the entire key is on a single line:

# Bad (will fail):
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQD...
...continuedOnNextLine...
...continuedFurther

# Good (single line):
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQD...continuedOnSameLine...continuedFurther

After setup, verify with:

ssh -v -i ~/.ssh/id_rsa user@ServerB

Check these permission requirements:

# On ServerB:
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chmod 644 ~/.ssh/known_hosts

If your custom Linux uses SELinux:

restorecon -Rv ~/.ssh
ls -lZ ~/.ssh  # Verify context matches home directory