Using SSH Keys with Kerberos

Question

In the below, is it possible to create foo_bars without moving/taking ownership of foos, or cloning it. I need to be able to use foos after creating foo_bars.

struct Foo<'a> {
    bar: &'a str,
}

fn main() {
    let foos = vec![Foo { bar: "one" }, Foo { bar: "two" }, Foo { bar: "three" }];
    let foo_bars: Vec<&str> = foos.into_iter().map(|foo| foo.bar).collect();
    println!("{}", foo_bars[1]); // should print 'two'
    println!("{}", foos[0].bar); // should print 'one'
}

Solution 1

PuTTY 0.61 or newer can use Kerberos/GSSAPI tickets (instead of public-key authentication) to authenticate to an SSH server. To enable this, go in PuTTY's configuration menu to "Connection | SSH | Auth | GSSAPI" and make sure "Attempt GSSAPI authentication" is enabled. (The Linux OpenSSH client equivalent is "ssh -K".)

There are two ways in which PuTTY can obtain the required Kerberos ticket-granting ticket:

1. PuTTY has access to any ticket that Windows obtained from its Active Directory domain server when you logged into a Windows machine that is in a domain. In that case, there is no need to do anything special to get a ticket.

2. Alternatively (e.g. on a Windows machine not in a domain), PuTTY also has access to any tickets that you got by running the "MIT Kerberos Ticket Manager" GUI tool that comes with the "MIT Kerberos for Windows" package from http://web.mit.edu/kerberos/dist/). Just use that to obtain your Kerberos ticket before you start PuTTY. If "MIT Kerberos Ticket Manager" is running, it will prompt you automatically for your Kerberos password if PuTTY needs one. It is therefore a good idea to add a shortcut to "MIT Kerberos Ticket Manager" to your Startup folder.

On the sshd server side:

• Obtain from your KDC and install in /etc/krb5.keytab a server keytab.

• In /etc/ssh/sshd_config make sure you have GSSAPIAuthentication yes to enable Kerberos authentication.

Make sure that krb5.conf is set up correctly on both sides, such that the GSSAPI libraries used by putty and sshd both find the same realm and contact the same KDC (unless your realm and KCD are already properly advertised via DNS, in which case nothing needs to be added to krb5.conf).

Solution 2

First off, a clarification. Kerberos and SSH Keys are two mutually exclusive authentication methods for SSH. You don't use Kerberos with SSH Keys. You use Kerberos instead of SSH Keys. Both allow for "passwordless" SSH logon. A bit of reading on the Kerberos protocol may be in order.

With Kerberos, you need to obtain a TGT that proves you are who you say you are before you try to connect to your endpoint. If you're on Windows joined to an Active Directory domain, you automatically get a Kerberos TGT for the Active Directory realm on login. But a lot of organizations don't bother configuring their Linux hosts to use the Active Directory Kerberos realm. If you do, life is much easier. If you don't, it means that Windows needs to be configured to know about your other Kerberos realm and how to request a ticket. It's also an extra step for your users because they'll need to abandon their AD TGT and request a TGT for your other realm.

You also have the option to use a trust between the Kerberos realms such that (for example) AD users can authenticate to resources in the other Kerberos realm.

A Kerberos keytab file is just a file representation of your Kerberos account password. So when requesting your initial TGT, you wouldn't need to enter your password if you had a valid keytab file. But this is also generally outside the scope of your SSH client.

Once you have a valid TGT, you need to make sure your SSH client is configured to use GSSAPI. PuTTY supports this out of the box and I'm sure most others do as well.

Assuming everything is configured properly, it should "just work". But there are a lot of configuration mishaps that can happen along the way. There are also a lot of third party products that can make things easier, but I will refrain from mentioning anything specific.

Comments

[Michael Hampton]

Why are people trying to manage Linux systems from Windows desktops? Things are much smoother with Linux desktops, and somewhat smoother with OS X desktops.

[Mark O'Reilly]

The problem I'm currently having is getting from PuTTY into my server without having to use a password. In the PuTTY configuration it asks for a private key file, but my keytab does not work with this. I need a way for PuTTY to use my Kerberos keytab so that I can get access.

[Ryan Bolger]

The private key setting in PuTTY is only for SSH Keys, not Kerberos. But don't worry about keytabs just yet. Is your machine joined to an Active Directory? If so, run the klist command in a cmd prompt to see your current ticket list. One of the entries should have a Server entry that starts with 'krbtgt' and ends with your realm name. Does that realm match the realm that your Linux boxes are in? If your machine is not joined to Active Directory, you're going to need to configure Windows to recognize the Kerberos realm that your Linux boxes are in. That might warrant a separate question.

[D. Müller]

I'm just trying to get this also working. I need to ssh from Windows to my Linux Realm. Can you explain what you mean with the step "Obtain from your KDC and install in /etc/krb5.keytab a server keytab.", what do I have to do? Seems that a simple "addprinc user" and "xst -k user.keytab user" wouldn't be enough here, as I doesn't want to work. See also stackoverflow.com/questions/41763536/… Thank you

[Markus Kuhn]

D. Müller: Does in your "Linux realm" Kerberized "ssh -K" already work well between Linux machines? My answer was mainly aimed at users who have "ssh -K" already working well under Linux, and just need help with getting that to work as well from PuTTY clients under Windows. The "On the sshd server side:" part was mainly aimed to clarify what should already be in place on the Linux server, and was not meant as detailed instructions on how to set up an SSH Linux server in an MIT Kerberos realm.