When SSH agent forwarding fails, you'll notice that while your initial connection works (thanks to public key authentication), subsequent hops from the intermediate server fail and fall back to password authentication. The verbose output shows:

debug1: Trying private key: /home/pupeno/.ssh/id_rsa
debug1: Trying private key: /home/pupeno/.ssh/id_dsa
debug1: Trying private key: /home/pupeno/.ssh/id_ecdsa
debug1: Next authentication method: password

1. Local SSH Configuration: Your ~/.ssh/config looks correct, but let's enhance it:

Host *
  ForwardAgent yes
  AddKeysToAgent yes
  IdentityFile ~/.ssh/id_rsa
  IdentitiesOnly yes

Host b1
  HostName b1.yourdomain.com
  User pupeno
  ForwardAgent yes

2. Remote Server Checks: On your Ubuntu VM (b1), verify:

# Check if SSH_AUTH_SOCK is set
echo $SSH_AUTH_SOCK

# Verify agent connection
ssh-add -L

SSH Agent Not Running Locally: Ensure your local agent is active before connecting:

# For MacOS (modern versions)
eval "$(ssh-agent -s)"
ssh-add -K ~/.ssh/id_rsa

Permission Issues: The SSH agent socket must be accessible:

# On the intermediate server (b1)
ls -la $(echo $SSH_AUTH_SOCK)
# Should show socket is writable by your user

Add these flags to your SSH command for deeper insights:

ssh -vvv -A pupeno@b1

Look for these critical lines in the output:

debug2: auth_methods: publickey,password
debug3: preferred publickey
debug3: authmethod_lookup publickey
debug3: remaining preferred:
debug3: authmethod_is_enabled publickey

While troubleshooting, be aware that agent forwarding can expose your keys. Consider these alternatives:

# Option 1: ProxyJump (SSH 7.3+)
ssh -J pupeno@b1 target_host

# Option 2: Temporary key deployment
ssh-copy-id -i ~/.ssh/temp_key pupeno@b1

When everything works, you should see:

# From your local machine
ssh -T pupeno@b1 "ssh -T pupeno@b1"
# Should return successfully without password prompt

---

When SSH agent forwarding isn't working as expected between your MacOSX host and Ubuntu 12.04 VM (b1), we're typically dealing with one of these scenarios:

# Example of failing forward attempt
ssh -v pupeno@b1
# Output shows:
# debug1: Trying private key: /home/pupeno/.ssh/id_rsa
# debug1: Next authentication method: password

Let's examine both client and server configurations. Your current ~/.ssh/config shows:

Host *
  ForwardAgent yes
Host b1
  ForwardAgent yes

But we need to verify these additional critical components:

• SSH daemon configuration on the VM (/etc/ssh/sshd_config)
• Agent forwarding chain integrity
• Key permissions and environment variables

First, validate your agent is properly loaded:

# On your MacOSX host:
ssh-add -l
# Should show your loaded keys
# If empty, run:
eval "$(ssh-agent)"
ssh-add ~/.ssh/id_rsa

Then test forwarding functionality:

ssh -A pupeno@b1
# Then on b1:
ssh-add -l
# Should mirror your host's keys

The Ubuntu 12.04 VM needs these settings in /etc/ssh/sshd_config:

AllowAgentForwarding yes
AllowTcpForwarding yes

After modifying, restart the SSH service:

sudo service ssh restart

Check these critical variables on both systems:

echo $SSH_AUTH_SOCK
# Should show active socket path
env | grep SSH
# Verify all required variables are set

For persistent issues, try this comprehensive test sequence:

# On host:
ssh -vvv -A pupeno@b1
# On b1:
SSH_AUTH_SOCK=$SSH_AUTH_SOCK ssh -vvv pupeno@b1

This will reveal exactly where the forwarding chain breaks.

If traditional forwarding remains problematic, consider:

1. ProxyCommand approach:

Host b1
  ProxyCommand ssh -q -W %h:%p gateway.example.com
  ForwardAgent yes

2. Persistent master connection:

Host b1
  ControlMaster auto
  ControlPath ~/.ssh/control:%h:%p:%r
  ControlPersist 10m