NOTE: This setup was tested only in Ubuntu 18.04 x64

INTRO

The objective is to perform a SSH login and authenticate to a local Microsoft AD. There are many ways out there to do this, but most involving joining the Domain, I did not want that, The best options were:

  • Kerberos
  • RADIUS
  • SAML with shibboleth

In the past I have used Open pbis to join the domain and then performs the remote authentication, the big issue is that PBIS does not encrypt traffic and works only with regular LDAP port 389.

I ended up using an official Ubuntu documentation that provides a very very dangerous setup!

Somewhere it tell us to run: ‘auth-client-config -a -p kerberos_example’ opsss now any user was able to login without entering a password and ‘su -‘ Luckly I found a great post about the

problem here: https://www.claudiokuenzler.com/blog/874/local-users-becoming-root-using-su-without-password-authentication-wrong-config

After few weeks of testing and retesting I was able to make it work using
SSH → PAM → Kerberos (port 88) → Active Directory

Important thing to consider:

  • Users must be pre created local with same name as of the AD.
  • You will need to reach the Domain Controller on port 88 (TCP/UDP)

The setup involves quite a lot of configuration steps, I am working on having a simple script to configure it all, but I think its very important to document and understand it first
let’s try to go one by one…

PRE-REQUSITES

apt install -y libpam-krb5 libpam-ccreds auth-client-config krb5-user

1) CREATE LOCAL USER AND GROUPS

Lets use the group called ict and it is important to keep the UID over 5000 (will be used as a filter later on).
IMPORTANT: The <USER> must be exatcly the same name of a valid AD user account!

groupadd -g 5000 ict
useradd -u 5001 -g ict -G sudo -s /bin/bash -m -c “AD Login via Kerberos” -d /home/USERNAME -p ‘!!’ USERNAME

SUDOER
Also adding the users of the group ict to sudoers, There are 2 options one to request the password for sudo and one without, select what is best for you.

echo “%ict ALL=(ALL:ALL) ALL” > /etc/sudoers.d/domain_kerberos
echo “%ict ALL=(ALL) NOPASSWD:ALL” > /etc/sudoers.d/domain_kerberos
chmod 0440 /etc/sudoers.d/domain_kerberos
visudo -c

2) SSH

This are very standard configurations if in any part of the setup you think to have done something wrong just disable PAM by doing ‘UsePAM no’ There is a nice setup where you can request a Key and AD password!

Very simple just change to: ‘authenticationmethods publickey password’

/etc/ssh/sshd_config

UsePAM yes
KbdInteractiveAuthentication yes
Match Group ict
AuthenticationMethods password

INTRO PAM
PAM is Pluggable Authentication Modules. When a program needs to authenticate a user, PAM provides a library containing the functions for the proper authentication scheme.
Because this library is loaded dynamically, changing authentication schemes can be done by simply editing a configuration file.
The config files are located in “/etc/pam.d/” take a look at them. Since PAM is not as famous as SSH I will intro to how it is configured:PAM configuration tokens

3) PAM

Now that we understand the basics of PAM let’s configure it! I choose to keep it all ssh in one single file, it will be used for ssh, but we must configure also common-auth that is used by sudo or su. Please backup your origin config before editing

/etc/pam.d/ssh

auth required pam_env.so
auth sufficient pam_unix.so nullok try_first_pass
auth sufficient pam_krb5.so try_first_pass
auth required pam_deny.so
account required pam_unix.so broken_shadow
account sufficient pam_succeed_if.so uid < 5000 quiet
account [default=bad success=ok user_unknown=ignore] pam_krb5.so
account required pam_permit.so

password sufficient pam_unix.so md5 shadow nullok try_first_pass use_authtok
password sufficient pam_krb5.so use_authtok minimum_uid=5000 try_first_pass
password required pam_deny.so

session optional pam_keyinit.so revoke
session required pam_limits.so
session required pam_mkhomedir.so umask=0022 skel=/etc/skel
session optional pam_krb5.so debug
session required pam_unix.so debug

For the sudo and us we must add only this line
/etc/pam.d/common-auth

auth [sucess=1 default=ignore] pam_krb5.so try_first_pass

INTRO KERBEROS

Kerberos is a computer-network authentication protocol that works on the basis of tickets to allow nodes communicating over a non-secure network to prove their identity to one another in a secure manner.

The Keytab File – All Kerberos server machines need a keytab file, called /etc/krb5.keytab, to authenticate to the KDC. The keytab file is an encrypted, local, on-disk copy of the host’s key. So a kerberos client has no need for it.

4) KERBEROS

For Kerberos to work we require a valid ticket as a Preauthentication so we have to run: set the kerberos ticket cache location and create a renewable ticket (10 hours lifetime + renewable for 7 days)

echo “export KRB5CCNAME=/tmp/my_krbtkt” >> /etc/profile source /etc/profile kinit -r7d -l10h

CRONTAB

Add to crontab to auto renew the ticket

echo “0 */6 * * * kinit -R -c /tmp/my_krbtkt” >> /var/spool/cron/crontabs/root

/etc/krb5.conf

[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log
[libdefaults]
default_realm = example.local
dns_lookup_realm = false Keytab (not needed)
dns_lookup_kdc = true
ticket_lifetime = 24h
default_tgs_enctypes = AES256-CTS AES128-CTS RC4-HMAC DES-CBC-MD5 DES-CBC-CRC
default_tkt_enctypes = AES256-CTS AES128-CTS RC4-HMAC DES-CBC-MD5 DES-CBC-CRC
preferred_enctypes = AES256-CTS AES128-CTS RC4-HMAC DES-CBC-MD5 DES-CBC-CRC
forwardable = yes
[realms]
example.local = {
kdc = example.local:88 
default_domain = example.local
}
[domain_realm]
.example.local = example.local
example.local = example.local
[appdefaults]
pam = {
debug = true
ticket_lifetime = 36000
renew_lifetime = 36000
forwardable = true
krb4_convert = false 
}

Troubleshooting:

First place to look is your /var/log/auth.log

Error:
kinit: krb5_get_init_creds: unable to reach any KDC in realm
Solution:
it is a must to reach UDP and TCP port 88 for Kerberos to work correctly
test it by doing:
nc -vz -t 10.10.8.3 88
nc -vz -u 10.10.8.3 88
I found a problem where kinit thru UDP would not work so changing the parametr
kdc = tcp/10.1.8.30:88 would work for kinit command
but then it would not work for SSH !
Going back to the kdc = 10.10.8.3:88 made it work!
TIP: tcpdump is a good help

Error:
parse_name failed: Configuration file does not specify default realm
Solution:
Add default_realm in libdefaults

Error:
krb5_get_init_creds_password: Preauthentication failed
Causes:
did you create a Kerberos account for your machine? Did you add it to your local keytab?Either the password for the relevant account in the Active Directory has changed since the keytab file was created or The system clock is off by about 5 minutes from that of the Active Directory

References:

Problem as described here: (EVIL kerberos-example https://www.claudiokuenzler.com/log/874/local-users-becoming-root-using-su-without-password-authentication-wrong-config

Good simple How to
http://tldp.org/HOWTO/User-Authentication-HOWTO/x115.html
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/managing_smart_cards/pam_configuration_files

About Kerberos https://en.m.wikipedia.org/wiki/Kerberos_(protocol)
Keytab (not needed) https://blogs.technet.microsoft.com/pie/2018/01/03/all-you-need-to-know-about-keytab-files/
Troubleshooting help https://unix.stackexchange.com/questions/12021/automatic-kerberos-ticket-initialization-on-login
https://docs.oracle.com/cd/E19253-01/816-4557/trouble-6/index.html
http://web.mit.edu/kerberos/krb5-1.5/krb5-1.5/doc/krb5-install/The-Keytab-File.html

Tags: , , , , ,

2 thoughts on “Configure Kerberos for SSH

  1. PowerBroker binding is not in clear text ( or plain password ) but use SASL/GSSAPI for AD over LDAP as transport security.

  2. Well done.
    You should not need to join domain if you configure NSS with NSS_LDAP.
    As AD is, basically, an LDAP server, you can use it as you reference repository to manage accounts.

Leave a Reply

Your email address will not be published. Required fields are marked *