Encountering SSH “Permission denied, please try again.”

If you encountered issues like “Permission denied, please try again.” during SSH, there are a few steps to consider.

One possibility is that you may want to took at /var/log/secure which might give some clues to the possible causes. One could be due to lock out rules for SSH. There is one interesting writeup which could shed light into this possibility. Configure lockout rules for SSH login

Another possibility is that you may want to check on the permission on your .ssh directory which may be incorrectly set. For example, you may want to consider

  1. .ssh directory: 700 (drwx——)
  2. public key (.pub file): 644 (-rw-r–r–)
  3. private key (id_rsa): 600 (-rw——-)

Allow SSH Root Login From Selected IP Addresses

To secure your system better by allowing selected hosts to ssh into your system as root, you will need the Match keyword found in the /etc/ssh/sshd_config

For example, to allow only 192.168.x to be able to ssh into the system, you do the following. If you are using

Edit the SSH Config

% vim /etc/ssh/sshd_config

1. By IP Addresses

PermitRootLogin no
# Example of overriding settings on a per-user basis
Match Address 192.168.*,
PermitRootlogin yes

2. By Host Name

PermitRootLogin no
UseDNS yes
# Example of overriding settings on a per-user basis
Match Host *.example.com,host1.idontknow.com
PermitRootlogin yes

3. By User and IP Addresses

PermitRootLogin no
UseDNS yes
# Example of overriding settings on a per-user basis
Match User user1 Host *.example.com
PermitRootlogin yes

Restart SSH Service

% systemctl restart sshd.service


  1. Linux: Allow SSH Root Login From Specific IP
  2. How to restrict ssh logins by user and client address on CentOS/RHEL
  3. Limit access to openssh features with the Match option

SSH and X-Forwarding on CentOS 6

I encountered this error recently when trying to X forward to another remote site.

"Warning: No xauth data; using fake authentication data for X11 forwarding."


and there was no and doesn’t display picture.

These are the steps I took to trouble-shoot

  1. I checked my /etc/ssh/sshd_config and noted that the I have “X11Forwarding yes”
  2. On my .ssh/config, I have the “ForwardX11 yes”
  3. But one of my parameter /etc/ssh/sshd_config  “X11Uselocalhost yes”. Apparently,I was able to X11 Forward for hosts specify in my /etc/hosts file, but those outside my host file, I was not able to display the picture.
  4. But once I modified the  “X11Uselocalhost no”, the issue was resolved.

There was this post that a user explained quite well. (http://www.authsecu.com/nntp/comp-security-ssh/19540-comp-security-ssh-what-does-%22x11uselocalhost-no%22-do.htm)

When doing X forwarding, sshd listens on a TCP socket for connections from X clients. Normally, it will accept connections addressed to the loopback address only (, restricting it to clients on the local host. X11UseLocalhost no means it will accept connections from anywhere. 

Unable to open a connection to your SSH authentication agent

If you are unable to have open a connection to your SSH public key could not be exchanged successfully, you may want to do the following

Remember to do the following SSH Login without Password

Evaluate that the agent is up

# eval `ssh-agent -s`
Agent pid 265652

Add your SSH private key to the ssh-agent.

# ssh-add ~/.ssh/id_rsa.pub

*If you are still using “Could not open a connection to your authentication agent.”

# exec ssh-agent bash

*If You are having the issue. The default is

Permissions 0644 for 'id_rsa.pub' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
# chmod 600 id_rsa.pub


Building Public Key, SSH Private Key and Authorized Key

If you are rebuilding the ssh keys for a user who has accidentally destroyed their files inside .ssh directory

Step 1: Generate the Private Key

# ssh-keygen -t rsa

Step 2: Generate the Public Key from Private Key

# ssh-keygen -y -f ~/.ssh/id_rsa > ~/.ssh/id_rsa.pub

Step 3: Generate the Authorized Key

# cat .ssh/id_rsa.pub >> .ssh/authorized_keys

Step 4: Generate Config File

# touch ~/.ssh/config
StrictHostKeyChecking no

Reinstating user password-less access to compute nodes

There are occasionally in a cluster environment that users accidentally delete their head node SSH keys and later cannot submit their jobs to the queue or their MPI jobs cannot scale beyond 1 node. The system you will see when you turn on the verbose method

To conduct a quick test,

# ssh -v remote-host

you will see an errors similar to  such as those below:

debug1: Unspecified GSS failure.  Minor code may provide more information
Unknown code krb5 195


debug1: Miscellaneous failure
No credentials cache found

To reinstate the password-less access to compute nodes, you have to do the following. First thing first, please do backup files at your ~/.ssh/

Step 1: Regenerate the SSH keys
SSH Login without Password

Step 2: Append the public keys ~/.ssh/id_rsa.pub and put into the ~/.ssh/authorized_keys

# cd ~/.ssh/
# cat id_rsa.pub >> authorized_keys
# chmod 400 /home/myuser/.ssh/authorized_keys

Step 3: Try ssh into the compute nodes. It should be clear password-less access to all nodes.

SSH Login without Password

The SSH daemon validates SSH client access by Linux system verification via /etc/passwd, or by public/private key cryptography approach.

By using the public/private cryptography approach, we can do a SSH without password.

In my write-up it is for root-to-root connection. You can use it for user connections.

Steps 1: At the Host Machine

  1. Logon to the root home directory.
  2. Make sure the hidden .ssh directory has the permission 700. If not execute the command
    # chmod 700 .ssh
  3. Change Directory to .ssh directory by executing the command
    # cd .ssh
  4. Generate the public-private keys using the ssh-keygen command.
    # ssh-keygen -t rsa
  5. The resulting file id_rsa and id_rsa.pub rsa type public key
    # ssh-copy-id -i ~/.ssh/id_rsa.pub remote-host

    (ssh-copy-id appends the keys to the remote-host’s .ssh/authorized_key)

Step 2: At the Remote Machine,

  1. Test it out on the remote server
    # ssh remote-host


Algorithm negotiation failed for SSH Secure Shell Client

If you are using the dated SSH Secure Shell Client 3.2.9, you may have issue connect to the more updated OpenSSH Server.


If you cannot change the client (which is recommended), you will have to update the OpenSSH Server on Linux. Add this in

# vim /etc/ssh/sshd_config
# Ciphers
Ciphers aes128-cbc,aes192-cbc,aes256-cbc,blowfish-cbc,arcfour
KexAlgorithms diffie-hellman-group1-sha1

*If you are using Centrify-OpenSSH, you have to modify /etc/centrifydc/ssh/sshd_config and do the same


  1. Bug 1228013 – Server responded “Algorithm negotiation failed”