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 required.
[root@host ~]# grep -i -e '^authorizedkeyscommand' /etc/ssh/sshd_config
AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys
AuthorizedKeysCommandUser nobody
Since the client is enrolled, we can disable the local .ssh/authorized_keys for all users except root and restart the ssh daemon to make changes take effect.
[root@host ~]# sed -i 's/^AuthorizedKeysFile\ \.ssh\/authorized_keys/AuthorizedKeysFile\ \/dev\/null/g' /etc/ssh/sshd_config
[root@host ~]# echo -e 'Match user root\n\tAuthorizedKeysFile .ssh/authorized_keys' >> /etc/ssh/sshd_config
[root@host ~]# systemctl restart sshd.service
Now that sshd is restarted and the config changes are live, create a ssh-key for a user and test it out.
NOTE: this will not set a password for the key which is not recommended for production use. I will only do this for demonstration purposes.
[root@host ~]# ssh-keygen -a 64 -t ecdsa -b 521 -f userkey -C "$(date +%F)" -N ""
[root@host ~]# ipa user-mod executor --sshpubkey "$(cat userkey.pub)"
Check using the helper program that sshd is going to use for fetching keys if everything has been applied as expected. As I left the default, I will test using 'sss_ssh_authorizedkeys'
[root@host ~]# sss_ssh_authorizedkeys executor
ecdsa-sha2-nistp521 AAAAE00...
As you can see, the key-data is stored centrally and we should be able to log in as the executor user, assuming the required hbac rules are in place allowing sshd.
[root@host ~]# ssh -i userkey executor@$(hostname -f)
[executor@host ~]$
You can also check what key has been used by having a look at the '/var/log/secure' file filtering for the user
[root@host ~]# sudo grep -i -A 1 -e 'publickey' /var/log/secure | grep -i -e 'executor'
Edits to any local .ssh/authorized_keys file will be ignored (except root) and keys will be pulled from a centrally managed user directory.
Feel free to comment and / or suggest a topic.
Comments
Post a Comment