How to disable CBC Mode Ciphers in RHEL 8 or Rocky Linux 8

This writeup is reference from The Geek Diary

Edit /etc/sysconfig/sshd and uncomment CRYPTO_POLICY line:

CRYPTO_POLICY=

Edit /etc/ssh/sshd_config file. Add Ciphers, MACs and KexAlgorithms have been added

KexAlgorithms curve25519-sha256@libssh.org,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com

After making changes to the configuration file, you may want to do a sanity check on the configuration file

# sshd -t

Restart sshd services

# systemctl restart sshd

To test if weak CBC Ciphers are enabled

$ ssh -vv -oCiphers=3des-cbc,aes128-cbc,aes192-cbc,aes256-cbc [youruserid@IP of your Server]

References:

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

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