SSH

by

Using Mac Terminal App to SSH X-Forward

If you are using a MacOS and you are planning to do a X-forwarding, you may notice an error like this. In the Pix, below, after SSH, I wanted to X-forward Firefox Browser from Rocky Linux 8

ssh -X user1@192.168.0.1

There are a few settings we need to do. Let’s fix the “Locale not supported by C library. Using the fallback ‘C’ locale”

Issue 1 – Locale not support by C library. Using the fallback ‘C’ locale

To fix it, go to Top-Left-Hand Corner of your Mac-Desktop to look for the Terminal App,

  1. Click “Settings” (Pix 1)
  2. Click the Profiles Icons (Pix 2)
  3. Uncheck the “Set locale environment variable on startup” (Pix 2)

Close and Quit Terminal App and come in again. You should fix the first problem.

Issue 2 – Install XQuartz

X11 used to be included with macOS. Apple no longer includes X11 with macOS. That is why you see an error like this “Error: no DISPLAY environment variable specified.”

You have to download the XQuartz App which is an open-source effort to develop a version of the X.Org X Window System that runs on macOS. Downloading and Installing is very straight-forward and easy. I’ve captured selected screen-shots….

After installing, you may want to let is run in the background

Log-Off from Your Mac Completely to allow the settings to reinitate

Issue 3 – Fixing the libGL error: failed to load driver: swrast on Rocky Linux 8

You may find an issue similar to the one in the earlier blog. That is how you may want to fix it.

by

SSL connection error For Delinea MFA with DirectControl 

Muco of the Troubleshooting comes from the Knowledgebase Article is derived from KB-8958: MFA with DirectControl fails with SSL connection error and Preparing a Linux Client Server for Centrify and 2FA for CentOS-7

Problem :

When attempting to log in with a user that requires MFA the following error is presented:

$ ssh user@192.168.0.1
SSL Connection Error

Cause:

The error is likely due to a certificate problem. A required certificate may be missing or the permission may not be set correctly

How to check:

# /usr/share/centrifydc/bin/adcdiag
VERSION   : Verify that DirectControl version supports MFA               : Pass
JOINSTATE : Verify that DirectControl is in connected mode               : Pass
ZONECHK   : Verify that MFA is supported in the zone                     : Pass
SSHDCFG   : Verify that SSHD enables ChallengeResponseAuthentication     : Warning
          : Cannot read sshd configuration file. Probably you are not
          : using Delinea openssh. SSH login for MFA users will fail if
          : option ChallengeResponseAuthentication is not set to yes.
          : Please check and ensure ChallengeResponseAuthentication is
          : set to yes in sshd configuration file.
CDCCFG    : Verify that MFA options in centrifydc.conf are correct       : Pass
PROXYCFG  : Verify that HTTP proxy configuration is set properly         : Pass
CLDINST   : Verify that trusted Identity Platform instance is specified  : Pass
          : Successfully connected to Identity Platform and certificate
          : has been verified OK.
CNTRCFG   : Verify that Connectors are configured correctly              : Pass
CURCNTR   : Verify that DirectControl has selected a workable Connector  : Pass
CLOUDROLE : Verify that this machine has permissions to perform Identity
          : Platform authentication                                      : Pass
......
......
......

Check the Logs at /var/centrify/tmp…. You may notice some errors like 

.....
.....
ERROR:
Not a trusted connector or no valid connector certificate installed locally.
SUGGESTIONS:
1. Verify that the IWA root CA certificate is installed in the system. Please refer to KB-7393 on how to configure the root CA certificate in the system.
2. Please collect connector log if you need Delinea support.
.....
.....

Resolution:

Check whether the Certificates have been added at

  •  /etc/pki/ca-trust/source/anchors/ 
  • /var/centrify/net/certs

Check the SSH Settings at

# vim /etc/ssh/sshd_config
# To disable tunneled clear text passwords, change to no here!
#PasswordAuthentication yes
#PermitEmptyPasswords no
PasswordAuthentication no


# Change to no to disable s/key passwords
#ChallengeResponseAuthentication yes
ChallengeResponseAuthentication yes

Restart the SSHD Services

# systemctl restart sshd.service

Restart the Centrifydc services

# /usr/share/centrifydc/bin/centrifydc restart

Active Directory Flush and Reload

# adflush -f
# adreload
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

How to disable vulnerable ciphers and encryption modes in Rocky Linux 8 to mitigate Terrapin Attack (CVE-2023-48795)

For more information on the Terrapin Attack (CVE-2023-48795), do take a look at Terrapin Attack (CVE-2023-48795): SSH Protocol Impacted.

As mentioned, in the blog entry, Terrapin Attack (CVE-2023-48795): SSH Protocol Impacted, the attack is possible only if you use vulnerable ciphers and encryption modes: ChaCha20-Poly1305, CTR-EtM, CBC-EtM. Note that the cyphers and the encryption modes themselves are not vulnerable, but their input (sequence number) can be manipulated by the attacker.

The mitigation is similar to How to disable CBC Mode Ciphers in RHEL 8 or Rocky Linux 8 except that you have to remove the “chacha20-poly1305@openssh.com” besides the CBC Mode Ciphers.

Step 1: 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 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 and  ChaCha20-Poly1305 are enabled

$ ssh -vv -oCiphers=chacha20-poly1305@openssh.com,3des-cbc,aes128-cbc,aes192-cbc,aes256-cbc IP-Address-of-your-Server

You should receive a similar message

Unable to negotiate with 172.21.33.11 port 22: no matching cipher found. Their offer: aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr

To verify that the Terrapin Attack Vulnerability is mitigated, take a look at Vulnerability Scanner. Pre-built binaries for all major platforms and the source code are available on GitHub.

./Terrapin_Scanner_Linux_amd64 -connect XXX.XXX.XXX.XXX

If you are not vulnerable, you may have an output like this.

References:

  1. Terrapin Attack (CVE-2023-48795): SSH Protocol Impacted
  2. Terrapin Attack
  3. Terrapin (CVE-2023-48795): New Attack Impacts the SSH Protocol
  4. SSH protocol flaw – Terrapin Attack CVE-2023-48795: All you need to know
by

Terrapin Attack (CVE-2023-48795): SSH Protocol Impacted

What is Terrapin Attack (CVE-2023-48795)?

Researchers from Ruhr University announced the discovery of new vulnerabilities impacting the SSH Protocol. Detailed Information of the Terrapin Attack can be found at Terrapin Attack.

According to FOSSA Terrapin (CVE-2023-48795): New Attack Impacts the SSH Protocol

Terrapin is a man-in-the-middle attack; the flaw allows an attacker to corrupt data being transmitted. This can result in a loss of information or bypass critical security controls such as keystroke timing protections or SHA-2 cryptographic hash requirements, allowing the threat actor to downgrade to SHA-1. Doing so opens up the possibility of other attacks on downstream applications, components, or environments that use SSH. ​​These associated vulnerabilities have been assigned CVE-2023-46445 (Rogue Extension Negotiation Attack in AsyncSSH) and CVE-2023-46446 (Rogue Session Attack in AsyncSSH).

Terrapin (CVE-2023-48795): New Attack Impacts the SSH Protocol

How do I know that I am vulnerable?

The attack is possible only if you use vulnerable ciphers and encryption modes: ChaCha20-Poly1305, CTR-EtM, CBC-EtM. Note that the cyphers and the encryption modes themselves are not vulnerable, but their input (sequence number) can be manipulated by the attacker.

How do I mitigate the attack?

To mitigate the attack, either you upgrade OpenSSH to their latest version 9.6 or disable the affected ciphers and encryption modes.

Vulnerability Impacts

According to FOSSA Terrapin (CVE-2023-48795): New Attack Impacts the SSH Protocol, their assessment of the Attack are:

  • Limited Impacts: Terrapin can delete consecutive portions of encrypted messages, which in isolation will typically result in a stuck connection. Some of the most serious impacts identified are in downstream applications implementing SSH, such as AsyncSSH. An attacker may be able to disable certain keylogging obfuscation features, enabling them to conduct a keylogging attack; or, worst case, a threat actor can sign a victim’s client into another account without the victim noticing, enabling phishing attacks.
  • Difficult to Expliot: An active man-in-the-middle attacker and specific encryption modes are prerequisites for the exploit. Intercepting SSH traffic requires a detailed understanding of a target’s environment, limiting real-world applicability.

How do I check?

You may want to explore the vulnerablilty tool published by the Ruhr University Researchers:

For more information, do take look at Vulnerability Scanner. Pre-built binaries for all major platforms and the source code are available on GitHub.

Usage is very simple, after downloading the relevant binary, just use the command

./Terrapin_Scanner_Linux_amd64 -connect XXX.XXX.XXX.XXX

If you are not vulnerable, you may have a output something like this.

If you are vulnerable, the scanner will flag as expected.

References:

  1. Terrapin Attack
  2. Terrapin (CVE-2023-48795): New Attack Impacts the SSH Protocol
  3. SSH protocol flaw – Terrapin Attack CVE-2023-48795: All you need to know
by

Git clone fatal: Could not read from remote repository.

If you have an error 

git clone git@github.com:kittycooldew/ansible_cluster.git
fatal: Could not read from remote repository.

If you encounter an SSH authentication issue, do add your key to the SSH keychain:

ssh-add ~/.ssh/id_rsa

If you encounter an error such as this

Could not open a connection to your authentication agent.

Start the process and add key to SSH Keychain

eval `ssh-agent -s`
ssh-add ~/.ssh/id_rsa

Try the git clone again. It should work

References:

by

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]

You should receive a aimilar message message 

Unable to negotiate with 172.21.33.13 port 22: no matching cipher found. Their offer: chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr

References:

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——-)