Leave a reply

Part 0: Multi-Master Kerberos Server with OpenLDAP Backend – Installer

Some months ago, I started to play around with OpenLDAP and Kerberos. At the beginning of my LDAP adventure, I often messed up my installation, so I ended up reinstalling everything and had to start again from scratch.

To make my life a little bit easier, I wrote a simple bash script to do the package installing in order to make the necessary changes to the config files only to the last ‘save’ point. Over the time, I added a lot of stuff and features and so the script started to accumulate. In retrospect, if I started again from the beginning, I would now use something more appropriated than bash.

Anyway, the script installs a “Multi-Master Kerberos Server with a LDAP Backend”.

Please follow the steps to try out the script on a current ubuntu or debian system (ubuntu 16.04 or debian 8). I would recommend to use a fresh system in a virtual machine.

There are some more things I will explain in further posts, once I will have the time which I do not have currently. Soooo, if you have specific questions about the script or ideas for improvement, please leave me a comment.

Disclaimer: Feel free to use this script at your own charge, I cannot be held responsible for what YOU do on YOUR administered system.

  1. Download the two files:
  2. Use md5 to check the data integrity of the downloaded file:
    user@yourbox:~$ md5sum -c LDAPX-0.1.3.tar.gz.md5
  3. Extract the file with tar:
    user@yourbox:~$ tar -zxvf LDAPX-0.1.3.tar.gz
  4. Change in the directory LDAPX:
    user@yourbox:~$ cd LDAPX
  5. Add the fully qualified domain name of the server(s) to the variable ‘LDAPMASTER‘ in ‘conf/LDAPX.conf‘. (Only necessary if you want more then one master server.)
    • Optional step: Change the password of the ldap admin (LDAPADMINPW), the gpg password file (GPGPWFILEPW) and the gpg user password file (GPGPWUSERFILEPW)
      (Leave it blank to enter them during the installation)
  6. Optional step: In the file ‘conf/LDAPX.tls.conf’ change the values of LOCALITY/STATE/COUNTRYCODE/
  7. Become root with the command:
    user@yourbox:~$ sudo su
  8. Important: Add the fully qualified domain name of the server(s) to ‘/etc/hosts‘.
  9. Make the two scripts executable with:
    root@yourbox:/home/user/LDAPX# chmod +x installLDAPX.sh
    root@yourbox:/home/user/LDAPX# chmod +x setupLDAPX.sh
  10. Run the script:
    root@yourbox:/home/user/LDAPX# ./installLDAPX.sh
  11. Start the installation process with the menu item ‘Install first master server’
  12. You can find some more information in the file: ‘backup/LDAPX.info
  13. Test the setup:
    • kinit
      1. Use kinit to request a kerberos ticket:
        root@yourbox:/home/user/LDAPX# kinit doejo
      2. The default password for user doejo is ‘winter2014#’
      3. Use klist to list your cached Kerberos ticket.
    • ssh
      1. ssh to yourbox with:
        ssh doejo@yourbox
      2. Use your new password or ‘winter2014#’ if you did not change it above.
      3. Use klist to list your cached Kerberos ticket.
      4. Try to become root with doejo@yourbox:~# sudo su -

Leave a reply

SSH key exchange between two linux systems

If you work with several different *nix hosts, you will often have to jump from one to another and you have to enter your passwords all over again. Well, there is an easy way to avoid this and at the same time to add some more security to the setup. To be honest, there is more than just one way, but right now we are going to look at the public key authentication method to make a ssh login without password possible. We will create a pair of rsa keys as a normal user and transfer the public key to one of our boxes. At the end we will look at the difference between a normal and root user and what we need to establish a ssh login without password for root.
Suggestion before we start: It is possible to secure the private key with a password. This adds more security but the trade-off is that you need to enter the key password before log-on.

Example: To demonstrate how to use the above mentioned, we create a pair of keys for the user myuser on the host0815 to establish a ssh login without a password to host host5180. The user myuser exists on both host systems. The standard ssh port 22 is used by default, if you want to use another port you can change it with the ‘-p‘ switch (e.g. if the ssh daemon listens on port 2222 use: ssh p 2222 myuser@host5180). Remember, if you operate on a remote computer which is not easy to reach, I would recommend to always run a second ssh connection in another terminal session.

  1. In order to create the ssh keys, login to host0815 and create the ‘~/.ssh’ directory with the command mkdir -p ~/.ssh and with the command chmod 700 ~/.ssh, we restrict the access to the directory to only your user myuser. After this, execute the ssh-keygen command ssh-keygen -t rsa -b 2048. With the ‘–b’ switch it is possible to specify the number of bits in the key (e.g. –b 4096). You can enter a password to secure your key or just press enter twice to leave the key “unprotected”. ssh can either use “RSA” (Rivest-Shamir-Adleman) or “DSA” (“Digital Signature Algorithm”) keys. RSA is often considered the recommended choice for new keys and it is selected by default (OpenSSH 7.0 and greater disable the DSA public key algorithm).
  2. Copy the newly created ssh public key to host5180:
    myuser@host0815:/# ssh-copy-id myuser@host5180
    After entering  the password of myuser@host5180, the key is written to

    The operation has worked if the following message is displayed: “Number of key(s) added: 1”.
  3. Finally, test if everything works like expected:
    • Try to login with your key to host5180.
      myuser@host0815:/# ssh myuser@host5180
    • If you are prompted for a password (and you didn’t protect the key with a password) then the key exchange didn’t work out and you need to check the previous steps (1-3). If you find yourself on the command prompt of host5180 you managed to established a public key based connection.

Additional hint: If you want to be able to login from host5180 to host0815 in the same way, you have to repeat the steps 1-3 with the two hosts exchanged of course.

Now that everything is set up, we can consider disabling the “normal” password-based authentication. This has some advantages and disadvantages.


  1. Leave the normal login just like it is.
    • Advantage:
      • You can log in with both the private key and your normal password. This is especially helpful if you work on a computer without your private key e.g. from your friends PC.
    • Disadvantage:
      • From a security point of view, this adds one more possibility for the bad guys to break into your computer, if they gets hold of your private key.
  2. Disable the password enabled login!
    • Advantage:
      • This closes the door for brute force attacks against your users passwords.
    • Disadvantage:
      • You can only login from remote if you have your private key with you.
      • This obviously doesn’t remove the possibility that your key gets stolen and the thief can break into your computer.

At the end there is a trade-off between comfort and safety. For maximum safety, we turn off the password based login and secure our private key with a strong password. Keys without a password are for the utmost comfort since they offer the possibility to jump from one computer to another without entering a password.
But the decision on safety or comfort has the administrator to take for the system he is responsible of.

SSH key exchange between two linux boxes for the root user.

For the root user, you will need a few more steps especially on a stock Ubuntu system, because the root user is disabled and root is not allowed to log in via ssh. Again we use the two hosts host0815 and host5180 for the example.

Important: Open a second ssh connection and keep it open until you know everything works!

  1. Login with your normal user to host0815 and become root with the following command:
    myuser@host0815:/# sudo su –
  2. Create the ssh key pair:
  3. Now we copy the newly generated ssh key to host5180. As already mentioned, there is a specialty for the root user: the password based ssh login on many linux systems is disabled by default for root.
    So we will look at how to activate it temporarily to be able to copy our public key to host5180.

    1. Login with your normal user to host5180 and use sudo to become root with the following command:
      myuser@host5180:/# sudo su –
    2. Activate the root user by setting a password with the command passwd:
    3. Open the config file “/etc/ssh/sshd_config” with your editor of choice and search for “PermitRootLogin without-password”, comment the line out by adding ‘#’ in front of it and add “PermitRootLogin yes” in the line below:

      This will enable the root ssh login with the password we have just set up.
    4. Save the file and restart the ssh daemon. Check that your second ssh connection is still open!
      root@host5180:/# systemctl restart sshd.service
      root@host5180:/# service sshd restart
    5. Now go back to host0815 and test if root can login to host5180:
      root@host0815:/# ssh root@host5180 date
      After entering the root password date and time should be displayed as a result. If this didn’t work out check the the previous steps (3.1-3.5).

    After this little excursion we can now copy the public key to host5180:
    root@host0815:/# ssh-copy-id root@host5180
    In my opinion, this is the easiest/best way to copy the public key to a host but of course there are other ways to do this, for example use a USB stick, scp, etc.

  4. Test if everything works:

    1. Try to login with your shiny new key to host5180:
      root@host0815:/# ssh root@host5180
    2. If you are prompted for a password the key exchange didn’t work out and you have to re-check the previous steps (1-4).
  5. Finally change the “PermitRootLogin yes” back to “PermitRootLogin without-password” in the config file ‘/etc/ssh/sshd_config’ and restart the ssh daemon (see 3.4).
  6. Disable the root user again if you like:

Step 5 and 6 are not necessary but recommended.

Additional hint:

It is possible to change single settings only for individual users, e.g.:

  • Prohibits ssh access for the user user0815
  • Disables password authentication for user myuser
  • For all other users, the password authentication is maintained.


Leave a reply

Cannot contact any KDC for requested…

If you get this error message while you try to change your Kerberos password and your running server system is virtualized, you may have an entropy shortage issue which will lead to a timeout.
Linux operating systems serve random numbers using special files, /dev/random and /dev/urandom. The pool of random bits of these files will exhaust very fast in virtualized systems without hardware entropy from keyboard, mouse or actuality hardware entropy generators.
One possible solution is to install the haveged entropy deamon. This daemon will provide you with unpredictable random numbers.

For ubuntu or debian: use the following command to install the daemon.

apt-get install haveged

After the daemon is running you can issue the kinit command again. To get some more debug information write it to stdout with KRB5_TRACE=/dev/stdout in front of kinit.

KRB5_TRACE=/dev/stdout kinit username