SSH

by

SSH Error – Receive Packet Type 51 on Rocky Linux 8

If you are having SSH issues and if you turned on high verbosity and the following output is generated

# ssh -vvv XXX.XXX.XXX.XXX
.....
.....
debug1: Offering public key: debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
.....
.....
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
user1@192.168.0.1: Permission denied (publickey,gssapi-with-mic,password)

According to SSH protocol (RFC 4252), these are the general authentication message codes

SSH_MSG_USERAUTH_REQUEST            50
SSH_MSG_USERAUTH_FAILURE            51
SSH_MSG_USERAUTH_SUCCESS            52
SSH_MSG_USERAUTH_BANNER             53

It means that the authentiation methods mentioned in the “Permission Denied” was not accepted. What are some of the common issues.

Type 1 (Most Common Mistake): Permission Errors on the .ssh Folder and files inside .ssh

Type 2: Incorrect Configuration Settings on the /etc/ssh/sshd_config
(Assuming you are using Password Authentication) Inside /etc/ssh/sshd_config, you should have something like

PermitRootLogin no
.....
PasswordAuthentication yes
.....
ChallengeResponseAuthentication no
.....
GSSAPIAuthentication yes
GSSAPICleanupCredentials no
.....
UsePAM yes

Type 2: Incorrect Configuration Settings on the /etc/ssh/ssh_config
In Rocky Linux 8, everything should be commented except the last line “Include /etc/ssh/ssh_config.d/*.conf”

References:

  1. How to Fix SSH Failed Permission Denied (publickey,gssapi-keyex,gssapi-with-mic)
  2. ssh receive packet: type 51
by

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——-)
  4. authorized_keys: 600 (-rw——-)

by

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
by

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. 

by

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

 

by

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
by

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.

by

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