timeout in locking authority file /home/user1/.Xauthority

If you are encountering delays in entering your linux account and instead notice

/usr/bin/xauth: timeout in locking authority file /home/user1/.Xauthority

The Issue is that xauth is trying to open a lock files.

To resolve the issues, first list the file to check whether it exists

% ls -l .Xauthority*
% rm -fr .Xauthority-*

Log off and Log on again.

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.*,172.21.1.1
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

References:

  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 (127.0.0.1), 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

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: UNPROTECTED PRIVATE KEY FILE! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
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 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

OR

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

References

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.

SSH

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

References:

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

Helping users to SSH without password into the Compute Nodes manually

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

OR

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

Auto 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.