When attempting to SSH into host2 from an intermediate server (host1), you might encounter the frustrating error:

Permission denied (publickey,gssapi-with-mic,password)

This typically indicates that while the SSH connection is established, the server rejects all authentication methods you've attempted. Let's break down what's happening under the hood.

The verbose SSH output reveals several critical points:

debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Next authentication method: gssapi-with-mic
...
debug1: Next authentication method: publickey
...
debug1: Next authentication method: password
...
debug1: No more authentication methods to try.

The server is configured to accept three authentication methods, but none succeed:

1. GSSAPI authentication fails due to missing credentials cache
2. Public key authentication fails as no valid keys are presented
3. Password authentication fails (even with correct credentials)

The root cause often lies in the server's sshd_config:

# Common restrictive settings that could cause this:
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM no
GSSAPIAuthentication yes
PubkeyAuthentication yes

Even when password authentication is technically enabled, other factors like PAM modules or account restrictions might block access.

When you don't control the server configuration, try these approaches:

1. Force Password Authentication

Explicitly request password authentication (though this may not work if disabled server-side):

ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no host2

2. Check for Hidden Configuration

Your local SSH config might be interfering. Create a minimal config:

Host host2
    HostName 192.*.*.*
    User ff
    GSSAPIAuthentication no
    PreferredAuthentications password

3. Verify Credentials Through Alternative Methods

If possible, test credentials through other services (like web login) to confirm they're valid.

If none of these work, you'll need to:

1. Request SSH key access from the administrators
2. Ask them to temporarily enable password authentication
3. Get them to verify your account status in PAM/system auth

Remember that many corporate environments intentionally disable password authentication for security reasons, so SSH keys may be your only option.

If you can get key-based authentication approved:

# On host1:
ssh-keygen -t rsa -b 4096 -f ~/.ssh/host2_key
cat ~/.ssh/host2_key.pub | ssh ff@host1 "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

# In your SSH config:
Host host2
    IdentityFile ~/.ssh/host2_key
    IdentitiesOnly yes

This creates a dedicated key pair and configures SSH to use it exclusively for host2.

---

When encountering the "Permission denied (publickey,gssapi-with-mic,password)" error, we're seeing a classic case where the SSH client successfully connected to the server but failed all available authentication methods. Let's break down what's happening in the debug output:

debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Next authentication method: gssapi-with-mic
debug1: Next authentication method: publickey
debug1: Next authentication method: password

Based on the debug output, here are the most likely scenarios:

• The server has PasswordAuthentication set to no in sshd_config
• The user account might be locked or the password incorrect
• Public key authentication is required but no keys are present
• GSSAPI is configured but not properly set up client-side

Since you don't have access to the server's configuration, here are client-side approaches:

1. Force password authentication attempt (though the debug shows it was already tried):

ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no user@host2

2. Check if any SSH keys are being offered:

ssh -v -o IdentitiesOnly=yes -i ~/.ssh/id_rsa user@host2

3. Modify your SSH config temporarily:

Host host2
    HostName host2.example.com
    User yourusername
    GSSAPIAuthentication no
    PreferredAuthentications keyboard-interactive,password
    PubkeyAuthentication no

If none of these work, you'll need to contact the server administrators. Provide them with:

• The complete debug output (ssh -vvv is even better)
• Your public key if they need to authorize it
• Information about what authentication methods should be available to you

For reference, here's what a properly configured client setup might look like for password authentication:

# ~/.ssh/config
Host jump-host
    HostName host1.example.com
    User yourusername
    
Host target-host
    HostName host2.example.com
    User projectuser
    ProxyCommand ssh -W %h:%p jump-host
    PreferredAuthentications password
    PubkeyAuthentication no
    GSSAPIAuthentication no

This configuration explicitly tells SSH to only attempt password authentication when connecting to host2 through the jump host.