Archy's Blog

Creating users is typically straightforward as the documentation for the required Ansible modules is comprehensive and easy to navigate. However, working with dictionaries instead of lists can introduce some additional complexity.  For example, let's assume the following dictionary structure is given: usergroups: group1: gid: 10001 name: group1 group2: gid: 10002 name: group2 group3: gid: 10003 name: group3 group4: gid: 10004 name: group4 users: user1: uid: 1985 name: user1 groups: - group1 - group2 sshkeys: - ssh-ed25519 AAAA0 - ssh-ed25519 AAAA1 user2: uid: 1986 name: user2 groups: - group4 - group1 sshkeys: - ecdsa-sha2-nistp384 AAAA0 Ansible provides the dict2items filter which transforms a dictionary into a list of key-value pairs. This transformation allows you to ite...

So this is a weird one that apparently existed for quite some time now. I've only noticed after the latest Upgrade to Foreman 3.9 and Katello 4.11 that the 'freeipa_register' snippet only creates RSA keys for sshd by default. However, I prefer to have all three key types generated: ed25519 ecdsa rsa However, in order to accomplish that, we'll have to modify the 'freeipa_register' privisioning snippet and add the other keys: Before: <% elsif os_major > 7 %> /usr/libexec/openssh/sshd-keygen rsa <% end -%> After: <% elsif os_major > 7 %> /usr/libexec/openssh/sshd-keygen ed25519 /usr/libexec/openssh/sshd-keygen ecdsa /usr/libexec/openssh/sshd-keygen rsa <% end -%> Now the hosts automatically installed by katello will have all three key-types present in the ipa configuration. There's another article that might be of use for regenerating sshfp records for hosts:  FreeIPA - Regenerate sshfp records ....

Managing mulltiple ssh-key pairs can be made easy by utilizing the power of ssh-agent. However, I'd like to have my ssh-sessions automatically attach to the ssh-agent or start a instance of ssh-agent if it's not already started. Starting the ssh-agent and attaching to it can be achieved by using these commands: [archy@server ~]$ ssh-agent -s > ${HOME}/.ssh/environment-$(hostname -s) [archy@server ~]$ source ${HOME}/.ssh/environment-$(hostname -s) This will create a file named 'environment-server'  in the folder ~/.ssh with all information required to attach it and then source it to attach to the running ssh-agent. Reconnecting to the running ssh-agent can be done using this command again: [archy@server ~]$ source ${HOME}/.ssh/environment-$(hostname -s) Another thing to consider is not starting multiple ssh-agents, so we'll have to check there is a instance of ssh-agent running for the current user and then determine if we should attach to the currently r...

This will likely only be interesting to you if you have your users stored centrally using some form of centralized identity management such as OpenLDAP, 389ds, or FreeIPA which again uses 389ds in the background. I'll configure SSHD to ignore each user's .ssh/authorized_keys file with the only exception being root. SSH-Keys for users will be stored in FreeIPA which can be managed using the 'freeipa.ansible_freeipa' modules and git for example. First, make sure your host is enrolled in FreeIPA [root@host ~]# ipa-client-install --mkhomedir --enable-dns-updates Now that your client is enrolled, let's try querying a user that exists in the ldap tree [root@host ~]# $ executor uid=10007(executor) gid=10007(executor) groups=10007(executor),10011(ansible-users) The ipa-client will automatically configure the 'AuthorizedKeysCommand' and 'AuthorizedKeysCommandUser' options which you could change to some self-written helper script if absolutely require...

Since the Katello-Agent has been deprecated. remote-execution is the recommended successor. The setup is fairly simple since a few arguments passed to the foreman-installer will set everything up automatically. First I'm going to create a new ssh-key pair: [archy@foreman ~]$ sudo su foreman-proxy -s /usr/bin/sh -c 'ssh-keygen -a 128 -t ecdsa -b 521 -C "foreman-proxy $(date +%F)" -f /var/lib/foreman-proxy/ssh/id_ecdsa_foreman_proxy -N "" -Z "chacha20-poly1305@openssh.com"' Next, let's enable the remote-execution plugin and the remote-execution-ssh plugin. Also I will configure the directory where the ssh-key is stored ('/var/lib/foreman-proxy/ssh') as well as the key-name ('id_ecdsa'). [archy@foreman ~]$ sudo foreman-installer --scenario katello \ --enable-foreman-plugin-remote-execution \ --enable-foreman-proxy-plugin-remote-execution-ssh \ --foreman-proxy-plugin-remote-execution-script-generate-keys \ --fore...

SSSD-KCM is a service tool for managing kerberos caches obtained from pam_sso but it can sometimes cause huge cpu-loads (90%+). I'm not sure on why exactly this happens but I think it has something to do with the secrets.ldb (/var/lib/sss/secrets/secrets.ldb) mismatching the current dyanmic-db or cache. Anyway, the solution is fairly simple and takes less than a minute. First, stop both sssd-services: [root@server ~]# systemctl stop sssd.service sssd-kcm.socket Now, make a backup of the secrets.ldb, you know just in case: [root@server ~]# cp -r /var/lib/sss/secrets /var/lib/sss/secrets.bak [root@server ~]# rm -rf /var/lib/sss/secrets Start the sssd services again: [root@server ~]# systemctl start sssd.service sssd-kcm.socket The 'sssd_kcm' process should not be causing any huge cpu loads anymore. Feel free to comment and / or suggest a topic.

I've encountered this error in a FreeIPA - AD Trust environment along with this error: "pam_sss(sshd_auth): received for user: 6 (Permission denied)" where users could log in using ssh with GSSAPIAuthentication and PubkeyAuthentication but logins with passwords were rejected. I've found that removing the dynamic-db files, clearing the cache, and restarting sssd worked for me: [root@server ~]# systemctl stop sssd.service [root@server ~]# rm -rf /var/lib/sss/db/* [root@server ~]# sss_cache -E [root@server ~]# systemctl start sssd.service I'm not really sure what exactly is causing this error but I think it might have to do with password-changes and therefore invalid caches but this is just a wild guess to the best of my knowledge. Feel free to comment and / or suggest a topic.

I prefer to use the respective config files for services in order to configure them. An example here is ssh where if you configure for example Ciphers, KexAlgorithms, and MACs in the sshd_config it most likely won't take effect. RHEL8 has switched to system-wide crypto policies which also affect sshd.  To make sshd ignore the crypto policies, uncomment the 'CRYPO_POLICY=' line in /etc/sysconfig/sshd: [archy@server ~]$ sudo sed -i 's/^#\ CRYPTO_POLICY=/CRYPTO_POLICY=/g' /etc/sysconfig/sshd Restart sshd: [archy@server ~]$ sudo systemctl restart sshd.service Check with nmap to see if the settings have been applied: [archy@server ~]$ nmap -sV -Pn -p 22 -open -script ssh2-enum-algos 127.0.0.1 Starting Nmap 7.80 ( https://nmap.org ) at 2021-01-26 19:40 CET Nmap scan report for 127.0.0.1 Host is up (0.00096s latency). PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 8.0 (protocol 2.0) | ssh2-enum-algos: | kex_algorithms: (1) | curv...

In one of my previous posts, I've mentioned locking down SSHD in terms of Algorithms, MACs, and Ciphers for the connection. This config is intended to work on larger fleets of servers and I'll not go into obscurity, meaning I will not change the SSH Port to something else.  However, these are probably the most important settings to change for a larger fleet of servers. Protocol Versions Let's start with the first setting, pinning the protocol to version 2: [archy@ansible01 ~]$ sudo vim /etc/ssh/sshd_config Protocol 2 Ciphers, Algorithms, and MACs  At the time of writing this (11/2020), the first algorithms tend to be the most secure, and the second mentioned ones tend to be focused on compatibility. If you are using an updated ssh-client, it should always pick the first. [archy@ansible01 ~]$ sudo vim /etc/ssh/sshd_config KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256 Ciphers chacha20-poly1305@openssh.com,aes256-ctr MACs hmac-s...