Hubba's Blog

What version of SSL/TLS does my openssl support?

Mon, 23 Mar 2026 10:39:34 +0000

This one I always have to look up as I don't use openssl very often and some people say that this is the solution:

                openssl ciphers -v | awk '{print $2}' | sort -u

This is not actually correct as the second column list the minimum version for a cipher. - The way you can get it from the command line is using the help section from s_client with something like:

               openssl s_client -help 2>&1  > /dev/null | egrep "\-(ssl|tls)[^a-z]"

Now the client can also be used to explore a remote web server to see what versions it supports with:

               openssl s_client -connect {domain}:443 -servername {domain} -tls{version}

Extracting a user keytab for krb5 authentication without passwords.

Thu, 05 Mar 2026 16:15:45 +0000

WARNING - The keytab must be kept safe as it can be used as a key on other systems!

So the problem at hand is for users that do not authenticate against AD and use an SSH key for like an SFTP job or for applications that run in the background and the kerberos ticket expires they will no longer be able to access the NFS filesystem but I have the need to encrypt the filesystem. How can we keep them authenticated.

For this we use ktutil to create our own keytab (ktutil is like a shell):

Run ktutil to enter the shell

In the shell we run "addent -password -p <user>@<REALM> -k 2 -e aes256-cts-hmac-sha1-96 -f" which will prompt you for the user password.

The "-f" flag may not be required but it will make sure that the "salt" is the same as kinit will use.

We can use "list -e" to view the result and then write it to a file with "wkt <filename.keytab>"

With "q" we can gracefully exit ktutil.

You should now be able to do a "kinit -kt <path to above created keytab> <user>@<REALM>"

If that works the keytab can be placed as <user>.keytab in /var/lib/gssproxy/clients/ and gssproxy will attempt to use it when that UID accesses the filesystem. - ONLY root should be able to read that keytab!

On RHEL8 /etc/gssproxy/99-nfs-client.conf actually looks for the keytab as <numerical UID>.keytab in /var/lib/gssproxy/clients/.

Disk/Filesystem benchmarking

Tue, 30 Dec 2025 16:23:14 +0000

Note to self at the moment until I have more details on what I am actually trying to prove:

To test performance on file systems I have used the following command:

fio --name=rand --rw=randrw --bs=4k --iodepth=32 --numjobs=16 --runtime=600 --time_based --size=1G --directory=/filesystem

iozone -Rac -b test.xls is also something I am experimenting it but don't really understand the output of that yet.

Another tool that has been around for a long time is bonnie++ but I am not sure if it is still maintained

Encrypted NFS

Thu, 04 Sep 2025 17:04:57 +0100

After joining AD we can use kerberos to encrypt nfs traffic as well - Obviously the NFS server must be joined to the same AD domain.

To this we need to add a SPN on the server side (already explained in the previously mentioned blog) to the NFS server nfs/<server name>

It needs to be visible in the keytab with klist -ke.

Then we add the export to the exports file womething like:

/TEST *.localnet.lan(rw,sec=krb5:krb5i:krb5p,no_root_squash)

We only really want krb5p as that is fully encrypted.

Then we need to set the domain in /etc/idmapd.conf - It should be returned when you run "nfsidmap -d" - In my case this is localnet.lan.

Most problems are about this SPN - so my SPN is nfs/server.localnet.lan but and the server name is the same but my kerberos realm is upnor.localnet.lan so I had to add this to my /etc/krb5.conf file that is mentioned in the other blog.

    
  [domain_realm]
  .localnet.lan = UPNOR.LOCALNET.LAN
  localnet.lan = UPNOR.LOCALNET.LAN
  .upnor.localnet.lan = UPNOR.LOCALNET.LAN
  upnor.localnet.lan = UPNOR.LOCALNET.LAN

I also added allow_weak_crypto - I am not sure it is required but in the redhat manuals it does tell you to do that so for completeness my config is now:

    includedir /etc/krb5.conf.d/

[logging]
    default = FILE:/var/log/krb5libs.log
    kdc = FILE:/var/log/krb5kdc.log
    admin_server = FILE:/var/log/kadmind.log

[libdefaults]
    dns_lookup_realm = false
    dns_lookup_kdc = false
    ticket_lifetime = 24h
    renew_lifetime = 7d
    forwardable = true
    rdns = false
    pkinit_anchors = FILE:/etc/pki/tls/certs/ca-bundle.crt
    spake_preauth_groups = edwards25519
    default_realm = UPNOR.LOCALNET.LAN
    default_ccache_name = KEYRING:persistent:%{uid}
    allow_weak_crypto = true

[realms]
  UPNOR.LOCALNET.LAN = {
  kdc = 192.168.0.10
  }

[domain_realm]
  .localnet.lan = UPNOR.LOCALNET.LAN
  localnet.lan = UPNOR.LOCALNET.LAN
  .upnor.localnet.lan = UPNOR.LOCALNET.LAN
  upnor.localnet.lan = UPNOR.LOCALNET.LAN

If we have done this all correctly we should be able to mount this export with something like "mount -t nfs -o nfsvers=4,sec=krb5p,proto=tcp" - We want krb5p as that fully encrypts all traffic while krb5 and krb5i only encrypt certain parts of the protocol which may be to insecure in some environments.

It should be noted that users have to have a kerberos ticket before they can read/write files on this mount and then the normal file permissions apply - However in an export the no_root_squash is actually irrelevant as root may be able to read stuff using the host credentials but root can not write to the file system as root can not get a kerberos ticket. There are workarounds to make that work but in general they are not recommended as they make your environment less secure again.

You may want to read my article about about ssh kerberos authentication and ticket delegation.

Some of the errors that can be encountered are very misleading. - For example I have come accross "an incorrect mount option was specified" - This had nothing to do with the mount options but can mean it is an error in the client configuration. - In my case the culprit was that rpc-gssd.service actually had died and I needed to manually start it.

You may notice that the no_root_squash option does not actually work with krb5. - There are various way to enable that but none are really recommended or even work as they will lower the security of your setup. RedHat have this article on that which would not work for me. - The ony way I was able to actually make that work with my setup is add the following to my realms section on the nfs server which will enable the client host linuxdev2 which will hold the host credential to be able to access shares as root (HOSTNAME$ is the actual computer account in AD and only root can use that to perform the initial mount):

 [realms]
  UPNOR.LOCALNET.LAN = {
  kdc = 192.168.0.10
  auth_to_local_names ={
       LINUXDEV2$ = root
    }
  }

There are articles that explain how you can create a a root account kerberos realm but that then means that root will also have to authenticate with a password to perform the mount and mounts can not be performed during boot out of fstab

Enable krb5 authentication for SSH

Thu, 04 Sep 2025 14:49:15 +0100

After joining an AD it is very simple to enable kerberos authentication for SSH assuming your Windows ID and Unix ID match. - All you need to do is add the following 2 lines to /etc/ssh/sshd_config

GSSAPIAuthentication yes
GSSAPIKeyExchange yes

All you then have to do is enable these options on your ssh client and you should be able to login to your Linux systems with the credentials on the windows machine joined to the same domain.

You may also have to turn things on the client side depending on what ssh client you use so on Linux you may need the following in your .ssh/config file or in the /etc/ssh/ssh_config file if you want all users to use kerberos:

GSSAPIAuthentication yes
GSSAPIDelegateCredentials yes

The delegate part is to enable kerberos ticket forwarding so when you log into the system your ticket gets passed along so you can read your encrypted NFS directories for example.

The delegation part is however also controlled by the system administrator so in Linux to enable this you have to add "forwardable = true" to /etc/krb5.conf in the libdefaults section.

On Windows the delegation part is controlled out of the Group Policy on the computer account for the machine.

It is important to understand that authenticatin with a kerberos ticket will not issue a ticket on the target machine it must be delegated during kerberos authentication and it will also not be delegated if you are using ssh keys or other forms of authentication.

A kerberos ticket can only be optained by authenticating against kerberos with a password. - On Windows this is done during login or when you unlock your screen with your password. On Linux the same may be enabled in pam with sssd or winbind authentication so you can get pam to pass your password through to the domain when authenticating. Obviously kinit is your last resort if these methods are not viable.