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.

Automate pushing of ssh-copy-id to multiple servers

This is a follow-up of the writeup of  Tools to automate ssh-copy-id to remote servers. The Server OS used is CentOS 6.2. If you are automating scripts, you may have to modify the default settings SSH first.

I think you probably would have encounter the yes/no question below when trying to ssh into a remote server.

The authenticity of host 'yourserver.com.sg (192.168.1.1)' can't be established.
RSA key fingerprint is 8d:e7:92:ef:86:1a:fb:4a:01:00:6a:fc:8c:23:ed:15.
Are you sure you want to continue connecting (yes/no)?

To rectify the issue, you can do at server levels /etc/ssh/ssh_config

# vim /etc/ssh/ssh_config
#  StrictHostKeyChecking ask
StrictHostKeyChecking no

Alternatively, you can Or at local account level at ~/.ssh/config

$ vim ~/.ssh/config

Add the following lines

StrictHostKeyChecking no
UserKnownHostsFile=/dev/null

You may want to revert back to the default settings of StrictHostKeyChecking after you have push your keys if you have configure of /etc/ssh/ssh_config or remove the 2 lines above if you are doing with the local account

Next you can use a simple bash scripts. I’m not comfortable in using the password in text. So make sure only you can view the file.

for i in 'cat my_hosts_list'    
    do
       sshpass -p 'server_password' ssh-copy-id admin@${i}
    done

Speeding up SSH connections

Suggestion 1: Resolving SLOW Login by turning off reverse DNS Lookup for OpenSSH

If you are facing slow login times, it might be due to reverse DNS is not responding quick enough. This system can show up on your log file

# tail -50 /var/log/secure

You will notice that there is a time lag from accepting the key to opening a session

Sep  6 10:15:42 santol-h00 sshd[4268]:
Accepted password for root from 192.168.1.191 port 51109 ssh2

Sep  6 10:15:52 santol-h00 sshd[4268]: pam_unix(sshd:session):
session opened for user root by (uid=0)

To fix the issue, you should modify the /etc/ssh/sshd_config file

# vim /etc/ssh/sshd_config

At /etc/ssh/sshd_config, change UseDNS  no

#ShowPatchLevel no
UseDNS no
#PidFile /var/run/sshd.pid

Restart the ssh service

# service sshd restart

Feel the login speed 🙂


Suggestion 2: Speeding up multiple ssh connections with ControlMaster

I’m assuming you are using OpenSSH 4.

If you are make multiple connections to the same server, you can enables the sharing of multiple sessions over a single network connections. In other words, the additional sessions will try to reuse the master instance’s connection rather than initiating new ones.

Step 1: Create a config file in your ~/.ssh directory. Make sure the permission is readable and writable by the owner only ie permission of 600

Step 2: Add the following lines

Host *
   ControlMaster auto
   ControlPath ~/.ssh/master-%r@%h:%p

ControlMaster auto Tries to start a master if there is no existing connection
or it will use an existing master connection.

ControlPath is the location socket for the ssh processes to communicate among
themselves. The %r, %h and %p are replaced with your user name, the host to which
you’re connecting and the port number—only ssh sessions from the same user to
the same host on the same port can or should share a TCP connection,
so each group of multiplexed ssh processes needs a separate socket.

Step 3a: To test the configuration, start an ssh session and keep it connected, you should see something like

...........
debug1: setting up multiplex master socket
debug1: channel 0: new [client-session]
...........

Step 3b: Launch another ssh connection to a the same server with the same userid

....................
debug1: auto-mux: Trying existing master
...................

Much of the materials come from  Speed Up Multiple SSH Connections to the Same Server (Linux Journal).


Suggestion 3: Speeding and Compressing X forwarding Traffic

To run the an X application over SSH connection, you can use the

$ ssh -X user@computername.com

Do note that for the remote Server shich you are connecting to must have X forwarding enabled. To configure, go to /etc/ssh/ssh_config/

X11Forwarding yes

If the SSH is setup with trusted X11 Forwarding ie in the /etc/ssh/ssh_config file,

ForwardX11Trusted yes

You can compress and speed up the X forwarded connection

$ ssh -Y -C user@computername.com
  • -Y to enable trusted X11 forwarding. Trusted X11 forwardings are not subjected to the X11 SECURITY extension controls. So it will boost speed.
  • -C to compress the data

Suggestion 4: Tuning TCP/IP and Patching SSH with HPN-SSH

Good read-up to tune your SSH connections.

  1. High Performance Data Transfers on TCP/IP
  1. High Performance SSH/SCP – HPN-SSH

Recommended /etc/sshd_config parameters for OpenSSH

There are a few settings at /etc/ssh/sshd_config we can set to improve security, performance and user experience. Many of this information comes from SSH The Secure Shell, 2nd Edition from O’Reilly

1. Using SSH-2 Protocol and disable SSH-1 protocol altogether

Protocol 2

2. Ensure that the HostKey and PidFile are located on a machine’s local disk and not over the NFS mount. The default setting should be in the machine local file like those below

HostKey /etc/ssh/ssh_host_key
PidFile /var/run/sshd.pid

3. File and directory permissions

The StrictModes value requires users to protect their SSH-related files and directories or else they will not authenticate.The default values is yes

StrictModes yes

4. Enable KeepAlive messages

Keepalive messages are enabled so that the connections to clients that have crashed or unreachable will terminate rather than be an orphaned process which require manual intervention by sysadmin to eliminate it.

Port 22 
ListenAddress 0.0.0.0
TcpKeepAlive yes

5. Disable Reverse DNS lookup

UseDNS no

6. Select a shorter grace login time

The default grace login is 2 minute which you might want to change. The value here is 30 seconds

LoginGraceTime 30

7. Authentication

The default setting are fine unless you wish to use Public-Key Authentication and wish to disabled Kerberos, Interactive and GSSAPIAuthentication

PubkeyAuthentication yes
PasswordAuthentication no
PermitEmptyPasswords no
RSAAuthentication yes
RhostsRSAAuthentication no
HostbasedAuthentication no
KerberosAuthentication no
ChallengeResponseAuthentication yes
GSSAPIAuthentication no
IgnoreRhosts yes

8. Access Control

If you wish to allow only selected users or groups to use ssh, you would like to use

AllowGroups users
AllowUsers me_only
DenyGroups black_list
DenyUsers hacker_id

For more information, see How do I permit specific users SSH access?
9. Securing TCP port forwarding and X forwarding

AllowTcpForwarding yes
X11Forwarding yes