Permission Denied (Publickey, GSSAPI-Keyex, GSSAPI-With-MIC): Causes, and Fixes
Marketing Team
Last Updated: Jul 16, 2026
Total View: 92
SSH Access Denied During Deployment?
If you’re getting “Permission denied (publickey,gssapi-keyex,gssapi-with-mic)”, your SSH authentication or key configuration may be incorrect. Resolve the issue to restore secure server access quickly.
- SSH key verification
- Public key configuration
- Server access troubleshooting
- Secure authentication setup
The error “Permission denied (publickey,gssapi-keyex,gssapi-with-mic)” usually appears when an SSH client reaches a remote Linux server but cannot complete authentication. The network connection may be working correctly, yet the server rejects every authentication method offered by the client.
This issue commonly occurs while connecting to cloud servers, virtual machines, Git repositories, deployment environments, and remote Linux systems. It may be caused by an incorrect username, a missing private key, invalid file permissions, an unregistered public key, or a server-side SSH configuration problem.
Although the message looks complicated, it mainly means that password authentication was either unavailable or not accepted, and the configured key-based or GSSAPI authentication methods failed. A structured troubleshooting process can help identify the exact cause without weakening server security.
What Does “Permission Denied (Publickey, GSSAPI-Keyex, GSSAPI-With-MIC)” Mean?
This message indicates that the SSH connection reached the destination server, but authentication was unsuccessful. The terms inside the brackets show the authentication methods the server was willing to accept.
A typical error looks like this:
user@server: Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
The server may accept SSH public keys and Kerberos-based GSSAPI authentication, but the client either did not provide valid credentials or the server could not verify them. As a result, the SSH session closes before granting shell access.
What Do Publickey, GSSAPI-Keyex, and GSSAPI-With-MIC Mean?
The authentication methods listed in the error message describe how the SSH server expected the client to prove its identity. Understanding them helps you focus on the relevant configuration instead of troubleshooting unrelated network settings.
In most cloud and development environments, publickey is the important method. The two GSSAPI methods are more common in enterprise networks that use centralized Kerberos authentication.
Publickey Authentication
Public-key authentication uses a matching pair of cryptographic keys. The private key remains on the client device, while the corresponding public key is stored on the remote server.
During login, the client proves it owns the private key without sending that private key over the network. If the public key is missing, damaged, placed under the wrong account, or paired with a different private key, authentication fails.
GSSAPI-Keyex
GSSAPI-Keyex uses the Generic Security Services Application Program Interface during SSH key exchange. It is commonly associated with Kerberos-based enterprise authentication systems.
Most individual Linux servers and cloud virtual machines do not rely on this method. If you are not using Kerberos or centralized domain authentication, its failure is usually expected and not the main problem.
GSSAPI-With-MIC
GSSAPI-with-MIC also uses Kerberos or another GSSAPI-supported identity system. The MIC component helps verify message integrity during authentication.
This method is common in corporate networks where users authenticate through centralized identity systems. For standard SSH key authentication, you can generally focus on fixing the publickey failure.
Why Does This SSH Permission Denied Error Occur?
This error can result from problems on either the client or server side. The SSH service may be running normally, but the user, key, permissions, or authentication configuration may not match.
Before making changes, determine whether the issue affects one account, one computer, or every connection to the server. That distinction helps separate local key problems from server-wide SSH configuration failures.
Incorrect SSH Username
One of the most common causes is using the wrong remote username. Cloud images and Linux distributions often use different default account names.
For example:
ssh root@203.0.113.10
may fail when the correct account is:
ssh ubuntu@203.0.113.10
Common default usernames include:
| Platform or Image | Common Username |
|---|---|
| Ubuntu | ubuntu |
| Amazon Linux | ec2-user |
| Debian | debian |
| CentOS | centos |
| Fedora | fedora |
| Oracle Linux | opc |
| Azure Ubuntu VM | Username selected during setup |
Even a valid key fails when it is offered for the wrong user because each account has its own authorized_keys file.
Wrong Private Key
The client may be using a private key that does not match the public key installed on the server. This often happens when several .pem, .key, or OpenSSH key files exist on the same computer.
SSH may also offer a default key automatically instead of the one required by the server. Specifying the identity file explicitly helps confirm which key should be used.
ssh -i ~/.ssh/my-server-key ubuntu@203.0.113.10
Public Key Is Missing From the Server
For key-based authentication to work, the server must contain the matching public key in the target user’s SSH configuration.
The usual file is:
~/.ssh/authorized_keys
If the key was deleted, added under another user, broken across multiple lines, or copied incorrectly, the server cannot authenticate the client.
Incorrect Private Key Permissions
SSH protects private keys by refusing to use files that are accessible by other users. If the private key permissions are too open, the client may ignore the key completely.
For example, the following permissions are usually appropriate on Linux and macOS:
chmod 600 ~/.ssh/my-server-key
Some providers supply .pem files and recommend:
chmod 400 server-key.pem
The key should remain readable only by its owner.
Incorrect Server-Side SSH Permissions
OpenSSH also checks the permissions of the user’s home directory, .ssh directory, and authorized_keys file. If they are writable by unauthorized users, the server may ignore the public key for security reasons.
Common permissions are:
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
The ownership must also match the target user:
chown -R username:username ~/.ssh
SSH Agent Is Not Loading the Key
The private key may exist locally but not be loaded into the running SSH agent. When the client does not explicitly specify a key, it often relies on the agent to supply one.
Check loaded keys with:
ssh-add -l
Add the required key using:
ssh-add ~/.ssh/id_ed25519
If the agent is not running, start it before adding the key.
Password Authentication Is Disabled
Many cloud servers disable password authentication by default to reduce brute-force attacks. In that situation, SSH accepts only public keys or another approved enterprise authentication mechanism.
If no valid public key is available, the server returns:
Permission denied (publickey,gssapi-keyex,gssapi-with-mic)
Enabling password authentication may be possible, but it should not be the first solution. Restoring valid key-based access is generally safer.
Root Login Is Disabled
Some servers prevent direct SSH login as root, even when the correct key exists. Instead, users must log in through a standard account and then elevate privileges.
For example:
ssh ubuntu@203.0.113.10
After login:
sudo -i
Trying root@server on such systems produces an authentication failure.
Step-by-Step Process to Fix the SSH Authentication Error
The safest troubleshooting approach starts with client-side checks and then moves to server-side configuration. This avoids unnecessary SSH daemon changes and reduces the risk of locking yourself out.
Run the following steps in order and test the connection after each meaningful change.
Step 1: Confirm the Hostname and Username
Verify that the IP address or hostname points to the correct machine. Then confirm the expected Linux account with your hosting provider, server administrator, or deployment documentation.
Use the correct structure:
ssh username@server-ip
For an Ubuntu cloud server:
ssh ubuntu@203.0.113.10
For Amazon Linux:
ssh ec2-user@203.0.113.10
Step 2: Specify the Private Key Explicitly
Do not assume SSH is selecting the correct key automatically. Pass the key path using -i.
ssh -i ~/.ssh/project-server.pem ubuntu@203.0.113.10
On Windows PowerShell:
ssh -i C:\Users\YourName\.ssh\project-server.pem ubuntu@203.0.113.10
If this works, the problem was likely related to default key selection or SSH agent configuration.
Step 3: Fix Private Key Permissions
On Linux or macOS, restrict access to the private key:
chmod 600 ~/.ssh/project-server.pem
Or:
chmod 400 ~/.ssh/project-server.pem
Then retry:
ssh -i ~/.ssh/project-server.pem ubuntu@203.0.113.10
If SSH previously displayed an “unprotected private key file” warning, correcting these permissions is essential.
Step 4: Run SSH in Verbose Mode
Verbose output reveals which keys are being offered and why authentication fails.
Start with:
ssh -v -i ~/.ssh/project-server.pem ubuntu@203.0.113.10
For more detail:
ssh -vvv -i ~/.ssh/project-server.pem ubuntu@203.0.113.10
Look for lines such as:
- Offering a public key
- The server accepts key
- Authentications that can continue
- No more authentication methods to try
If the key is never offered, the client configuration is the likely problem. If it is offered but rejected, the public key or server-side permissions may be incorrect.
Step 5: Check the SSH Agent
List the keys currently loaded:
ssh-add -l
If no identities are available, start the agent:
eval "$(ssh-agent -s)"
Then add the correct key:
ssh-add ~/.ssh/project-server.pem
Retry the connection without -i only after confirming the correct key appears in the agent.
Step 6: Verify the Public Key on the Server
This step requires another access method, such as a cloud serial console, provider recovery console, another administrator account, or direct virtual machine access.
Check:
cat ~/.ssh/authorized_keys
The matching public key must appear as one complete line. To derive a public key from a private key for comparison, run locally:
ssh-keygen -y -f ~/.ssh/project-server.pem
Copy the resulting public key into the target user’s file:
nano ~/.ssh/authorized_keys
Do not paste the private key into authorized_keys.
Step 7: Correct Server-Side Ownership and Permissions
Log in through a recovery method and run:
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
Confirm ownership:
ls -ld ~ ~/.ssh
ls -l ~/.ssh/authorized_keys
Fix it when necessary:
sudo chown -R username:username /home/username/.ssh
For example:
sudo chown -R ubuntu:ubuntu /home/ubuntu/.ssh
Step 8: Review SSH Server Configuration
Open the SSH daemon configuration:
sudo nano /etc/ssh/sshd_config
Review settings such as:
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
Depending on the server’s security policy, you may also see:
PasswordAuthentication no
PermitRootLogin no
After making a valid change, check the configuration before restarting:
sudo sshd -t
Then restart the service:
sudo systemctl restart ssh
On some distributions:
sudo systemctl restart sshd
Keep the recovery session open until a new SSH connection has been tested successfully.
How to Fix the Error on AWS EC2?
AWS EC2 instances commonly use key pairs and distribution-specific usernames. A wrong username or missing .pem file is therefore a frequent source of authentication failures.
For an Ubuntu instance:
ssh -i my-key.pem ubuntu@ec2-public-ip
For Amazon Linux:
ssh -i my-key.pem ec2-user@ec2-public-ip
Also verify that the key belongs to the instance’s original key pair. AWS does not automatically replace a lost private key because the private component is not stored for later download.
If the key is lost, recovery may require AWS Systems Manager Session Manager, EC2 Instance Connect, an attached root volume, or another provider-supported access method.
How to Fix the Error on GitHub or GitLab?
The same public-key error can occur while pushing or cloning over SSH.
Test GitHub authentication with:
ssh -T git@github.com
Test GitLab with:
ssh -T git@gitlab.com
Check available keys:
ls -la ~/.ssh
Generate a new key when needed:
ssh-keygen -t ed25519 -C "you@example.com"
Start the agent and add it:
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519
Display the public key:
cat ~/.ssh/id_ed25519.pub
Add that public key to the SSH key settings of the appropriate Git hosting account.
Common Mistakes to Avoid
SSH authentication errors are often made worse by rushed troubleshooting. Avoid changing several settings at once because doing so makes it difficult to identify the actual fix.
You should also avoid weakening the entire server’s security merely to restore one user’s access.
Enabling Password Authentication Immediately
Turning on password authentication may appear convenient, but it can expose the server to password-guessing attacks.
First, verify the username, key path, public key, file permissions, and SSH configuration. Key-based authentication is generally the preferred approach for internet-facing servers.
Copying the Private Key to the Server
The server needs the public key, not the private key. The private key should remain protected on the client device.
Uploading or emailing private keys creates a serious security risk. If a private key has been exposed, revoke it and generate a new pair.
Editing SSH Configuration Without Validation
A syntax error in sshd_config can prevent SSH from restarting. Always run:
sudo sshd -t
Before restarting the SSH service.
Maintain an active recovery session while testing configuration changes.
Using Too Many Agent Keys
SSH servers may stop authentication after too many failed key attempts. This can happen when an agent contains many unrelated identities.
Use:
ssh -o IdentitiesOnly=yes -i ~/.ssh/correct-key user@serverThis limits the attempt to the intended key.
How Does Moon Technolabs Help With Linux, Cloud, and DevOps Management?
Moon Technolabs helps businesses build and maintain secure Linux servers, cloud environments, deployment pipelines, and DevOps infrastructure. Our teams troubleshoot SSH authentication failures, configure secure remote access, manage cloud identities, automate deployments, and strengthen infrastructure security.
From AWS, Azure, and Google Cloud environments to containerized applications and CI/CD systems, Moon Technolabs focuses on reliable access management, least-privilege security, monitoring, automation, and production stability. This helps organizations reduce downtime while maintaining secure and scalable infrastructure.
Conclusion
The “Permission denied (publickey,gssapi-keyex,gssapi-with-mic)” error means the SSH server was reachable, but none of the permitted authentication methods succeeded. In most standard Linux and cloud environments, the real issue is related to public-key authentication rather than GSSAPI.
The most effective troubleshooting process is to confirm the username, specify the correct private key, fix key permissions, run SSH in verbose mode, verify the public key in authorized_keys, and correct server-side ownership and SSH configuration. Password authentication should not be enabled casually as a shortcut.
By maintaining separate SSH keys, using secure file permissions, documenting server usernames, and preserving reliable recovery access, teams can prevent authentication failures and manage remote infrastructure more safely.
Jayanti Katariya is the CEO of Moon Technolabs, a fast-growing IT solutions provider, with 18+ years of experience in the industry. Passionate about developing creative apps from a young age, he pursued an engineering degree to further this interest. Under his leadership, Moon Technolabs has helped numerous brands establish their online presence and he has also launched an invoicing software that assists businesses to streamline their financial operations.
Get in Touch With Us
Submitting the form below will ensure a prompt response from us.
