Apache Ranger and MIT Kerberos Enablement - Big Data security

---- In Progress ----

Kerberos:

Kerberos is an authentication protocol that can provide secure network login or SSO for various services over a non-secure network. Kerberos works with the concept of tickets which are encrypted and can help reduce the amount of times passwords need to be sent over the network.  These tickets are issued throughout the Kerberos realm by a centralized key distribution center (KDC).   Furthermore, Kerberos requires mutual authentication of both parties (user and server); this prevents a malicious service from masquerading as an authorized service and stealing information fro m the user.

Kerberos is a Single Sign-On (SSO) technology. This means that the user only has to authenticate once against the KDC to acquire as many tickets as required by the user in the course of his session. Kerberos is application agnostic. Kerberos is not tied to any particular application, and has been implemented for all common network services (ssh, HTTP, FTP, SMTP, IMAP, etc).


  • MIT Kerberos, an implementation of Kerberos, will be used to authenticate users.  User account names and passwords will be defined in the Kerberos database. When they type in their login name and password, their input will be verified against the Kerberos database.  Kerberos will only hold this "account information", name/password pairs called principals (along with their expiration time and related options).  When users authenticate with their credentials (username/password pair), Kerberos issues them a ticket that they use to access all kinds of services without having to retype their login name and/or password. In fact, to be precise, each service requires it's own ticket, but the initial ticket issued by Kerberos is a Ticket-granting Ticket (TGT) which is automatically used to produce further tickets for individual services.  Note also that with Kerberos, thanks to the design of the protocol, passwords never go over the wire.

  • The "glue layer":

    • Linux-PAM, an implementation of PAM (Pluggable Authentication Modules), will be used to tune the behavior of individual programs' functions related to authentication and authorization.

  • To configure debconf to a know state run
      sudo dpkg-reconfigure debconf

           When asked, answer interface=Dialog and priority=low.

  • To monitor the log file you can open a new terminal and run the following command, The command will keep printing log messages to the screen as they arrive
     cd /var/log; sudo tail -F daemon.log sulog user.log auth.log debug kern.log syslog dmesg messages kerberos/{krb5kdc,kadmin,krb5lib}.log

  • On our machine the hostname is thx2-03 the thx2-03.linaro.org is our Kerberos server, SSH server and the client connecting to them will all be on the same machine. To differenciate between client and servers roles, the connecting client is thx2-03.linaro.org , the SSH server is thx2-03.linaro.org (same as client, because SSH service is a client to Kerberos and needs to authenticate to it to prove its identity to the connecting user) and the server is linaro.linaro.org The following addition will be made to /etc/hosts to completely support this scheme. Note that the client machine's hostname parts (thx2-03 in our example) must come before "linaro" in order for things to work on the same machine as we are showing:  10.101.16.67 linaro.linaro.org linaro thx2-03.linaro.org thx2-03 hadoop.linaro.org hadoop
  • Install and configure sudo. It will allow you to carry out system administrator tasks from your normal user account. All the examples requiring root privileges will use sudo so you will be able to copy-paste them to your shell:

    su -c 'aptitude install sudo'
    su -c 'echo "$USERNAME ALL=(ALL) NOPASSWD: ALL" >> /etc/sudoers'




KERBEROS INSTALLATION:


Kerberos server installation basically consists of just two packages — the KDC (Key Distribution Center), which takes care of handling authentication requests and issuing Kerberos tickets, and kadmind (Kerberos master server), which allows
remote administration access to the Kerberos database and carrying out of administrative tasks.

sudo apt-get install krb5-{admin-server,kdc}

During installation, Kerberos' Debconf interface will ask you a few questions. Here's the list of questions and realistic answers to them:

Default Kerberos version 5 realm? LINARO.ORG 
# (Your Internet domain name in uppercase - a standard for naming Kerberos realms) Kerberos4 compatibility mode to use? none
# (No krb4 compatibility needed in our setup) What are the Kerberos servers for your realm? linaro.linaro.org
# (Make sure your DNS resolves linaro.linaro.org to
# the NETWORK IP of the server, NOT 127.0.0.1!). If you do not use
# the DNS server, adjust an entry in /etc/hosts like this:
#
# 127.0.0.1 localhost.localdomain localhost
# 192.168.7.12 linaro.linaro.org node1 linaro.linaro.org What is the administrative server for your realm? linaro.linaro.org # (Make sure your DNS resolves linaro.linaro.org to
# the NETWORK IP of the server, NOT 127.0.0.1!). If not, same hint as above.

Once we do the above, both the admin-server (kadmind) and the KDC will try to start. Kadmind will fail since we haven't created any realms yet.

To actually create the realm, invoke krb5_newrealm. The command will ask about the master password (write it down since it's very important but also very rarely used) and create the realm using the name as defined in the Debconf step (LINARO.ORG).


linaro@thx2-03:~$ sudo apt-get install krb5-{admin-server,kdc}

electing previously unselected package krb5-user.
Preparing to unpack .../08-krb5-user_1.15-1+deb9u1_arm64.deb ...
Unpacking krb5-user (1.15-1+deb9u1) ...
Selecting previously unselected package krb5-kdc.
Preparing to unpack .../09-krb5-kdc_1.15-1+deb9u1_arm64.deb ...
Unpacking krb5-kdc (1.15-1+deb9u1) ...
Selecting previously unselected package krb5-admin-server.
Preparing to unpack .../10-krb5-admin-server_1.15-1+deb9u1_arm64.deb ...
Unpacking krb5-admin-server (1.15-1+deb9u1) ...
Setting up libev4 (1:4.22-1+b1) ...
Setting up libgssrpc4:arm64 (1.15-1+deb9u1) ...
Processing triggers for libc-bin (2.24-11+deb9u4) ...
Processing triggers for systemd (241-3~bpo9+1) ...
Setting up libkdb5-8:arm64 (1.15-1+deb9u1) ...
Processing triggers for man-db (2.7.6.1-2) ...
Setting up libkadm5clnt-mit11:arm64 (1.15-1+deb9u1) ...
Setting up krb5-config (2.6) ...
Setting up libkadm5srv-mit11:arm64 (1.15-1+deb9u1) ...
Setting up krb5-user (1.15-1+deb9u1) ...
Setting up libverto-libev1:arm64 (0.2.4-2.1) ...
Setting up libverto1:arm64 (0.2.4-2.1) ...
Setting up krb5-kdc (1.15-1+deb9u1) ...
Job for krb5-kdc.service failed because the control process exited with error code.
See "systemctl status krb5-kdc.service" and "journalctl -xe" for details.
invoke-rc.d: initscript krb5-kdc, action "start" failed.
● krb5-kdc.service - Kerberos 5 Key Distribution Center
Loaded: loaded (/lib/systemd/system/krb5-kdc.service; disabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Thu 2019-06-06 10:34:52 GMT; 11ms ago
Process: 161714 ExecStart=/usr/sbin/krb5kdc -P /var/run/krb5-kdc.pid $DAEMON_ARGS (code=exited, status=1/FAILURE)

Jun 06 10:34:52 thx2-03 systemd[1]: Starting Kerberos 5 Key Distribution Center...
Jun 06 10:34:52 thx2-03 krb5kdc[161714]: Cannot open DB2 database '/var/lib/krb5kdc/principal': No such file or directory - while initializing database f
or realm LINARO.ORG
Jun 06 10:34:52 thx2-03 krb5kdc[161714]: krb5kdc: cannot initialize realm LINARO.ORG - see log file for details
Jun 06 10:34:52 thx2-03 systemd[1]: krb5-kdc.service: Control process exited, code=exited, status=1/FAILURE
Jun 06 10:34:52 thx2-03 systemd[1]: krb5-kdc.service: Failed with result 'exit-code'.
Jun 06 10:34:52 thx2-03 systemd[1]: Failed to start Kerberos 5 Key Distribution Center.
Created symlink /etc/systemd/system/multi-user.target.wants/krb5-kdc.service → /lib/systemd/system/krb5-kdc.service.
Setting up krb5-admin-server (1.15-1+deb9u1) ...
Created symlink /etc/systemd/system/multi-user.target.wants/krb5-admin-server.service → /lib/systemd/system/krb5-admin-server.service.
Processing triggers for libc-bin (2.24-11+deb9u4) ...
Processing triggers for systemd (241-3~bpo9+1) ...

linaro@thx2-03:~$


linaro@thx2-03:~$ sudo krb5_newrealm
This script should be run on the master KDC/admin server to initialize
a Kerberos realm. It will ask you to type in a master key password.
This password will be used to generate a key that is stored in
/etc/krb5kdc/stash. You should try to remember this password, but it
is much more important that it be a strong password than that it be
remembered. However, if you lose the password and /etc/krb5kdc/stash,
you cannot decrypt your Kerberos database.
Loading random data
Initializing database '/var/lib/krb5kdc/principal' for realm 'LINARO.ORG',
master key name 'K/M@LINARO.ORG'
You will be prompted for the database Master Password.
It is important that you NOT FORGET this password.
Enter KDC database master key:
Re-enter KDC database master key to verify:


Now that your realm is set up you may wish to create an administrative
principal using the addprinc subcommand of the kadmin.local program.
Then, this principal can be added to /etc/krb5kdc/kadm5.acl so that
you can use the kadmin program on other computers. Kerberos admin
principals usually belong to a single user and end in /admin. For
example, if jruser is a Kerberos administrator, then in addition to
the normal jruser principal, a jruser/admin principal should be
created.

Don't forget to set up DNS information so your clients can find your
KDC and admin servers. Doing so is documented in the administration
guide.
linaro@thx2-03:~$


We now need to tune the Kerberos config file, /etc/krb5.conf. It is split into sections. Look for [realms] and notice the listed famous realms in there that don't belong to your configuration (i.e. LINARO.ORG).  Then search further below for [domain_realm] and add your realm definitions:

.linaro.org = LINARO.ORG 
linaro.org = LINARO.ORG

Then, at the end of the file add this logging section:

[logging]
kdc = FILE:/var/log/kerberos/krb5kdc.log
admin_server = FILE:/var/log/kerberos/kadmin.log
default = FILE:/var/log/kerberos/krb5lib.log

To create the logging directory and set up permissions, run:

sudo mkdir /var/log/kerberos
sudo touch /var/log/kerberos/{krb5kdc,kadmin,krb5lib}.log
sudo chmod -R 750  /var/log/kerberos

To apply changes to the Kerberos server, run:

sudo invoke-rc.d krb5-admin-server restart
sudo invoke-rc.d krb5-kdc restart


The following are the logs on a real system

linaro@thx2-03:~$ sudo vim /etc/krb5.conf
linaro@thx2-03:~$ sudo mkdir /var/log/kerberos
linaro@thx2-03:~$ sudo touch /var/log/kerberos/{krb5kdc,kadmin,krb5lib}.log
linaro@thx2-03:~$ sudo chmod -R 750 /var/log/kerberos
linaro@thx2-03:~$ sudo invoke-rc.d krb5-admin-server restart
linaro@thx2-03:~$ sudo invoke-rc.d krb5-kdc restart
linaro@thx2-03:~$ sudo invoke-rc.d krb5-kdc status
● krb5-kdc.service - Kerberos 5 Key Distribution Center
Loaded: loaded (/lib/systemd/system/krb5-kdc.service; enabled; vendor preset: enabled)
Active: active (running) since Thu 2019-06-06 10:41:45 GMT; 15s ago
Process: 161965 ExecStart=/usr/sbin/krb5kdc -P /var/run/krb5-kdc.pid $DAEMON_ARGS (code=exited, status=0/SUCCESS)
Main PID: 161966 (krb5kdc)
Tasks: 1 (limit: 34406)
CGroup: /system.slice/krb5-kdc.service
└─161966 /usr/sbin/krb5kdc -P /var/run/krb5-kdc.pid

Jun 06 10:41:45 thx2-03 krb5kdc[161965]: Setting up UDP socket for address ::.88
Jun 06 10:41:45 thx2-03 krb5kdc[161965]: setsockopt(11,IPV6_V6ONLY,1) worked
Jun 06 10:41:45 thx2-03 krb5kdc[161965]: Setting pktinfo on socket ::.88
Jun 06 10:41:45 thx2-03 krb5kdc[161965]: Setting up TCP socket for address 0.0.0.0.88
Jun 06 10:41:45 thx2-03 krb5kdc[161965]: Setting up TCP socket for address ::.88
Jun 06 10:41:45 thx2-03 krb5kdc[161965]: setsockopt(13,IPV6_V6ONLY,1) worked
Jun 06 10:41:45 thx2-03 systemd[1]: krb5-kdc.service: Can't open PID file /run/krb5-kdc.pid (yet?) after start: No such file or directory
Jun 06 10:41:45 thx2-03 krb5kdc[161965]: set up 6 sockets
Jun 06 10:41:45 thx2-03 krb5kdc[161966]: commencing operation
Jun 06 10:41:45 thx2-03 systemd[1]: Started Kerberos 5 Key Distribution Center.
linaro@thx2-03:~$

Initial Test

It's already the time to test the installation. We assume that both the admin server and the KDC can be restarted with no errors. (Again, you are watching the log files, right?).  To just quickly test the installation, we will use the kadmin.local database administration program.   Start kadmin.local, then type listprincs. That command should print out the list of principals (user, host and/or service accounts). The whole session should look like this:


linaro@thx2-03:~$ sudo kadmin.local
Authenticating as principal root/admin@LINARO.ORG with password.
kadmin.local: listprincs
K/M@LINARO.ORG
kadmin/admin@LINARO.ORG
kadmin/changepw@LINARO.ORG
kadmin/thx2-03.linaro.org@LINARO.ORG
kiprop/thx2-03.linaro.org@LINARO.ORG
krbtgt/LINARO.ORG@LINARO.ORG
kadmin.local: quit
linaro@thx2-03:~$

Access Rights

Take a look at the /etc/krb5kdc/kadm5.acl file. It defines user access rights in Kerberos. For users with no special privileges, no action is required. To admin users, however, we want to grant all privileges. To do this, make sure the following line is present in the file and enabled (that is, without the comment '#' character at the beginning):

*/admin *

Also, a word or two on principal names is in order here. In the test step above, you might have noticed principal names like kadmin/admin@LINARO.ORG. The general naming syntax for principals is SPEC@REALM, where SPEC, by convention, consists of components separated by "/". In the case of user names, the first component identifies the user name, and the second component, when present, identifies user role. This is a nice separation of privileges; System administrators will authenticate to Kerberos like any other user during off-hours (for example, as NAME). Only when the duty calls will they authenticate as NAME/admin and obtain administrative privileges on the Kerberos database.

Knowing all this, let's create principal root/admin.

Make sure to restart the admin server to apply /etc/krb5kdc/kadm5.acl changes:

sudo invoke-rc.d krb5-admin-server restart

linaro@thx2-03:~$ sudo vim /etc/krb5kdc/kadm5.acl
linaro@thx2-03:~$ sudo vim /etc/hosts
linaro@thx2-03:~$ sudo invoke-rc.d krb5-admin-server restart
linaro@thx2-03:~$ sudo invoke-rc.d krb5-kdc restart
linaro@thx2-03:~$ sudo invoke-rc.d krb5-kdc status
● krb5-kdc.service - Kerberos 5 Key Distribution Center
Loaded: loaded (/lib/systemd/system/krb5-kdc.service; enabled; vendor preset: enabled)
Active: active (running) since Thu 2019-06-06 10:48:13 GMT; 6s ago
Process: 162151 ExecStart=/usr/sbin/krb5kdc -P /var/run/krb5-kdc.pid $DAEMON_ARGS (code=exited, status=0/SUCCESS)
Main PID: 162152 (krb5kdc)
Tasks: 1 (limit: 34406)
CGroup: /system.slice/krb5-kdc.service
└─162152 /usr/sbin/krb5kdc -P /var/run/krb5-kdc.pid

Jun 06 10:48:13 thx2-03 krb5kdc[162151]: Setting up UDP socket for address ::.88
Jun 06 10:48:13 thx2-03 krb5kdc[162151]: setsockopt(11,IPV6_V6ONLY,1) worked
Jun 06 10:48:13 thx2-03 krb5kdc[162151]: Setting pktinfo on socket ::.88
Jun 06 10:48:13 thx2-03 krb5kdc[162151]: Setting up TCP socket for address 0.0.0.0.88
Jun 06 10:48:13 thx2-03 krb5kdc[162151]: Setting up TCP socket for address ::.88
Jun 06 10:48:13 thx2-03 systemd[1]: krb5-kdc.service: Can't open PID file /run/krb5-kdc.pid (yet?) after start: No such file or directory
Jun 06 10:48:13 thx2-03 krb5kdc[162151]: setsockopt(13,IPV6_V6ONLY,1) worked
Jun 06 10:48:13 thx2-03 krb5kdc[162151]: set up 6 sockets
Jun 06 10:48:13 thx2-03 krb5kdc[162152]: commencing operation
Jun 06 10:48:13 thx2-03 systemd[1]: Started Kerberos 5 Key Distribution Center.
linaro@thx2-03:~$


Kerberose Policies

Kerberos "policies" offer an elegant way to sort principals into a kind of categories and to automatically apply corresponding defaults onto newly created principals.

Let's create four basic policies: for admins, hosts, services and users. In this example, each policy will define minimum password strength (measured in number of character classes present in the password, from 1 to 5), but a few other options can be set — run addpol (the supported abbreviation of add_policy) if you're curious.

linaro@thx2-03:~$ sudo kadmin.local
Authenticating as principal root/admin@LINARO.ORG with password.
kadmin.local: add_policy -minlength 8 -minclasses 3 admin
kadmin.local: add_policy -minlength 8 -minclasses 4 host
kadmin.local: add_policy -minlength 8 -minclasses 4 service
kadmin.local: add_policy -minlength 8 -minclasses 2 user
kadmin.local: quit
linaro@thx2-03:~$

Creating first privileged principal


As you might have noticed, the kadmin.local command identified us as the principal admin/admin. Still, that principal does not actually exist in the database so we might as well create it now. Once the principal is actually there, we'll be able to connect to the administrative server using kadmin from any machine within the Kerberos realm, and not just by using kadmin.local on the Kerberos server.

Creating a principal based on your regular identity (such as USERNAME/admin) is preferred over creating one called admin/admin, and you are welcome to do so in your setup.

linaro@thx2-03:~$ sudo kadmin.local
Authenticating as principal root/admin@LINARO.ORG with password.
kadmin.local: addprinc -policy admin admin/admin
Enter password for principal "admin/admin@LINARO.ORG":
Re-enter password for principal "admin/admin@LINARO.ORG":
add_principal: Password is too short while creating "admin/admin@LINARO.ORG".
kadmin.local: quit
linaro@thx2-03:~$

Kadmin Test

Now that the admin/admin principal exists in the Kerberos database, we should be able to use kadmin just as we used kadmin.local. The only exception, of course, is that kadmin will prompt for a password to connect to the Kerberos admin server.

Double-check that all the permissions are granted to admin roles in the /etc/krb5kdc/kadm5.acl (as explained in the section called “Access rights”), and that the admin server has been restarted to read the new configuration; then proceed to test kadmin connection:

linaro@thx2-03:~$ sudo kadmin.local
Authenticating as principal root/admin@LINARO.ORG with password.
kadmin.local: listprincs
K/M@LINARO.ORG
kadmin/admin@LINARO.ORG
kadmin/changepw@LINARO.ORG
kadmin/thx2-03.linaro.org@LINARO.ORG
kiprop/thx2-03.linaro.org@LINARO.ORG
krbtgt/LINARO.ORG@LINARO.ORG
kadmin.local: addprinc -policy admin admin/admin

Enter password for principal "admin/admin@LINARO.ORG":
Re-enter password for principal "admin/admin@LINARO.ORG":
Principal "admin/admin@LINARO.ORG" created.
kadmin.local: listprincs
K/M@LINARO.ORG
admin/admin@LINARO.ORG
kadmin/admin@LINARO.ORG
kadmin/changepw@LINARO.ORG
kadmin/thx2-03.linaro.org@LINARO.ORG
kiprop/thx2-03.linaro.org@LINARO.ORG
krbtgt/LINARO.ORG@LINARO.ORG
kadmin.local: quit
linaro@thx2-03:~$


Creating first unprivileged principle

Let's add a principal that will correspond to your regular, unprivileged user account. In our example, the username will be called "jirky". We've essentially performed this procedure for the admin/admin principal above, but we'll repeat it here for your regular user account, using a different policy, and replacing nbhat with your username.


linaro@thx2-03:~$
linaro@thx2-03:~$ sudo kadmin -p admin/admin
Authenticating as principal admin/admin with password.
Password for admin/admin@LINARO.ORG:
kadmin: addprinc -policy user nbhat
Enter password for principal "nbhat@LINARO.ORG":
Re-enter password for principal "nbhat@LINARO.ORG":
add_principal: Password is too short while creating "nbhat@LINARO.ORG".
kadmin: addprinc -policy user nbhat
Enter password for principal "nbhat@LINARO.ORG":
Re-enter password for principal "nbhat@LINARO.ORG":
Principal "nbhat@LINARO.ORG" created.
kadmin: quit
linaro@thx2-03:~$

Obtaining Kerberose Ticket

As hinted in the introduction, each user is expected to type in the password once, to obtain the initial TGT (Ticket-granting Ticket). Obtained tickets are saved to a so-called ticket cache, which is most commonly a file named /tmp/krb5cc_*, stored on the user's workstation.

Let's run the klist command to inspect our ticket cache (run this command under your regular, non-privileged username). As one might guess, since we did not obtain any tickets yet, the cache will be empty:

klist -f klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_0)

Let's use kinit now to obtain the ticket, and then re-inspect the ticket cache. If the command seemingly "hangs" and does nothing, wait a few seconds — DNS misconfiguration may be causing a delay.

kinit nbhat Password for nbhat@LINARO.ORG: PASSWORD

linaro@thx2-03:~$ klist -f
klist: No credentials cache found (filename: /tmp/krb5cc_1000)
linaro@thx2-03:~$ kinit nbhat
Password for nbhat@LINARO.ORG:
linaro@thx2-03:~$ klist -f
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: nbhat@LINARO.ORG

Valid starting Expires Service principal
06/06/2019 11:26:58 06/06/2019 21:26:58 krbtgt/LINARO.ORG@LINARO.ORG
renew until 06/07/2019 11:26:53, Flags: FPRIA
linaro@thx2-03:~$ kdestroy
linaro@thx2-03:~$

Installing Kerberized services

To actually use Kerberos, we need to install or configure versions of standard services that support Kerberos.

Each service may support Kerberos authentication either by having native Kerberos support, or by delegating the authentication work to the PAM subsystem (and since all relevant services support PAM, this means it is possible to Kerberize all network services).

Let's install openssh-server as our first and possibly the most important service.

sudo apt install openssh-server

To successfully connect to a certain service, the service must have a corresponding principal in the Kerberos database. This is because the Kerberos server acts as a trusted 3rd party and performs mutual authentication of both users and services as explained in the section called “The role of Kerberos within a network”.

The generic service name for telnet, rsh, ssh and related protocols is "host", so let's create the necessary principal with a randomly-generated password.

Please note that since Kerberos is based on the principle of shared secrets (as opposed to e.g. public-private key), the principal's key will need to exist in two places — one is obviously in the Kerberos database, and the other is in a file somewhere on the host where the service is running (e.g. in /etc/ on the SSH server machine).

In our example, since we are configuring the Kerberos and SSH server on the same machine, this will be the same host. In all other cases when these services are not on the same host, the procedure is exactly the same — you use kadmin on the client machine to connect to the Kerberos server, and then you call ktadd which will export the key to the local filesystem.

Note

Traditionally, the default behavior of ktadd is such that it changes the principal's key to a random value before exporting it to a file. You can verify this by checking the principal's "kvno" value which will increase by 1 every time you call ktadd on the principal. This is done due to an assumption that the key should always exist in only two places (in the Kerberos database and exported into a file on the client), so whenever you call ktadd to export a key, it is a good time to change it to a fresh value for added security.

In any case, to prevent key randomization, use ktadd ... -norandkey as we show in our example. The -norandkey option is available from the kadmin.local shell. If your are using kadmin instead, the option -norandkey is available there with package krb5-user version 1.15 and above (check with dpkg -l krb5-user). Also, it requires that the admin user has "extract-keys" privilege. This privilege must be granted to principals in /etc/krb5kdc/kadm5.acl explicitly as it is not included in "*". If you want to do this, your entry might look like either of these (they are identical):

*/admin *e

*/admin admcilspe

linaro@thx2-03:~$ sudo kadmin.local
Authenticating as principal root/admin@LINARO.ORG with password.
kadmin.local: listprincs
K/M@LINARO.ORG
admin/admin@LINARO.ORG
kadmin/admin@LINARO.ORG
kadmin/changepw@LINARO.ORG
kadmin/thx2-03.linaro.org@LINARO.ORG
kiprop/thx2-03.linaro.org@LINARO.ORG
krbtgt/LINARO.ORG@LINARO.ORG
nbhat@LINARO.ORG
kadmin.local: addprinc -policy service -randkey host/thx2-03.linaro.org
Principal "host/thx2-03.linaro.org@LINARO.ORG" created.
kadmin.local: ktadd -k /etc/krb5.keytab -norandkey host/thx2-03.linaro.org
Entry for principal host/thx2-03.linaro.org with kvno 1, encryption type aes256-cts-hmac-sha1-96 added to keytab WRFILE:/etc/krb5.keytab.
Entry for principal host/thx2-03.linaro.org with kvno 1, encryption type aes128-cts-hmac-sha1-96 added to keytab WRFILE:/etc/krb5.keytab.
kadmin.local: quit
linaro@thx2-03:~$ sudo vim /etc/ssh/sshd_config
linaro@thx2-03:~$ sudo invoke-rc.d ssh restart

Now let's open the file /etc/ssh/sshd_config and modify or add the following lines:

GSSAPIAuthentication yes
GSSAPICleanupCredentials yes
GSSAPIKeyExchange yes
UsePAM yes


And to apply changes to the SSH server, run:

sudo invoke-rc.d ssh restart

Installing kerberized clients


Let's install the client side of the show:

sudo apt install openssh-client

As we have taken care of all the pre-requisites, we can try connecting:

(Just make sure that the user you are connecting as actually exists on the machine. If you went with our example of linaro, make sure "linaro" is a valid, existing system user.)

Then obtain Kerberos ticket (you can do this step as any user):

kinit nbhat Password for nbhat@LINARO.ORG: PASSWORD

linaro@thx2-03:~$ sudo apt install openssh-client
Reading package lists... Done
Building dependency tree
Reading state information... Done
openssh-client is already the newest version (1:7.4p1-10+deb9u6).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
linaro@thx2-03:~$ kinit nbhat
Password for nbhat@LINARO.ORG:

linaro@thx2-03:~$ ls /home/
hadoop linaro
linaro@thx2-03:~$ ssh hadoop@thx2-03.linaro.org
hadoop@thx2-03.linaro.org's password:
Permission denied, please try again.
hadoop@thx2-03.linaro.org's password:
Linux thx2-03 4.16.0-290-arm64 #1 SMP Debian 4.16.13.linaro.290-1 (2018-06-06) aarch64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Thu Jun 6 07:41:53 2019 from 172.16.101.6
hadoop@thx2-03:~$

linaro@thx2-03:~$ ssh linaro@thx2-03.linaro.org
linaro@thx2-03.linaro.org's password:
Linux thx2-03 4.16.0-290-arm64 #1 SMP Debian 4.16.13.linaro.290-1 (2018-06-06) aarch64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Fri Jun 7 08:48:21 2019 from 172.16.101.6
linaro@thx2-03:~$

linaro@thx2-03:~$ exit
logout
Connection to thx2-03.linaro.org closed.
linaro@thx2-03:~$


Reference: 

http://web.mit.edu/kerberos/

https://debian-administration.org/article/570/MIT_Kerberos_installation_on_Debian

https://www.rootusers.com/how-to-configure-linux-to-authenticate-using-kerberos

http://research.imb.uq.edu.au/~l.rathbone/ldap/kerberos.shtml