Kerberised OpenSSH?

Hi,

What would it take to kerberise ssh on Interix? eg apply Simon Wilkinsons GSSAPI patches to OpenSSH.

It would be great to be able to ssh into our Windows server using existing kerberos tickets. I've got it working great between Debian machines using tickets from Active Directory.

I have a sinking feeling it would be a lot more work than just applying the patches and rebuilding. Would that be an accurate description? Not being a programmer, would it also need MIT or Heimdal libraries ported as well? Or could it use existing APIs (doubtful?) from Windows?

Thanks for any light shed on the subject :)

Yes, it is more than a few simple patches to get it working.
It will also be a lot of support too based on some experience.
There is a commercial version coming that is kerberos'd with many
other enhancements in the near future.

Thanks Rodney, I suspected that might be the case. Oh well.

I'll keep an eye out for the up and coming version :)

Cheers

Hi all,

does Kerberos authentication work in between with sshd?
This might be an alternative for host keys / public keys to allow passwordless login.

How could one setup a session with Kerberos in Interix? I assume that this must be some alternative for the setuser() system call, which doesn't accept a password, but a Kerberos ticket instead. If my assumption is  correct: Which system calls / library functions are available in Interix for this?

Just to note: the older posts are from about 3 years ago. At that time I spent a lot of time working on Kerberos. Or rather I should say I wasted a lot of time. Months in fact. That's why nothing appeared. I'll unravel it as I answer the questions.

To answer mkoeppe's questions:
- yes, you can on most systems allow for a kerberos-based authentication from an ssh client to an ssh server.
- you cannot do it with Interix though, at least not to a Windows AD centric machine. The problem is not Interix in itself.
- there are no available system API's for this

A brief, simplified explanation of Kerberos is needed to frame the explanation.
Kerberos works with tickets. When you first get authorization for the first machine that you login to that is part of the kerberos domain, the kerberos server provides a ticket to that machine. If you want to login from the first machine to a second machine (by whatever means) the ticket gets passed to the second machine. The second machine then checks with the kerberos server that it's valid. If it's valid then the connection is authorized.

Sounds all straight-forward enough so far. This is where the marketing folks get all happy and say the whole thing is solved. BUT this is also where the marketing folks' eyes glaze over as you explain why it won't work with Windows. For these tickets to get passed around there has to be a pre-established trust between the kerberos domain server and the machines. This means that the server has a list of the machines and for each machine a key. Each of the machines has a matching key. When machine and server communicate the use of these keys (challenge/response) keeps the trust flowing. The communications protocol between machines is sound enough that it doesn't really matter which operating system (OS) is running on the client and server. So Unix machines can be setup to be in the domain of a Windows kerberos server (read AD) quite successfully.

For Interix the problem arises on the "client" machine. See there already is the Windows/Win32 side that has gotten and established a key with the server. If the server were a Unix/Linux machine then an authorized person could learn what the key is for lawful, honest purposes. However, AD and the Windows/Win32 side keep the key a secret from everyone. There are no special API's to call or files to read to get this key. 100% nothing. I have this from the guy's at MS who wrote the Windows kerberos code.

Now if I build an Interix application to use kerberos, and I did do that, I can make kerberos work 100% correct within a kerberos domain running on a Unix system (BSD or Linux for example). I can do this because the key can be placed in the right file on Interix. But there is this dual personality: Win32 and Interix on the same machine. AD will only have the key setting with Win32 and then it's all a secret. It won't/can't be shared to the Interix side. The machine has a specific identity for kerberos/AD -- there cannot be multiple keys per machine. The Interix side doesn't have the key so we're screwed.

It sets up a strange set of workable situations. Interix can run kerberos as long as it's in the domain of the Unix/Linux kerberos server, or a Windows AD server as long as the Win32 side hasn't been listed.

Hi Rodney,
This description was really helpful.

Question: Is this still the case for modern SUA shipped with Vista? Maybe the new SUA provides GSSAPI (hopefully)?

Hey Harri -- glad it was helpful.

> Question: Is this still the case for modern SUA shipped with Vista? Maybe the new SUA provides GSSAPI (hopefully)?

This situation is still the same. No changes to the subsystem have been done to provide the Unix Kerberos API's through the subsystem. I'm thinking of this in the same manner that sockets are done to WinSock.
You can write a mixed-mode program that can call to the Win32 API. But that means it's all Win32 API's for kerberos which means code changes if you have an existing application.

IMHO supporting this mixed-mode would not be reasonable. SFU/SUA is intended to provide compatibility. Maybe it would help to file a bug report against SUA, pointing to GSSAPI (which seems to be an IETF standard).

Just an idea.

Hi Rodney,

I'm still not fully familiar with Kerberos, so I currently can't test, but might the following program receive the missing client side key? It at least receives the decoded value from
HKLM\Security\Policy\Secrets\$MACHINE.ACC
and according to the MS KB article, this might be the missing key:
http://support.microsoft.com/?scid=kb%3Ben-us%3B175468&x=11&y=16


#define _ALL_SOURCE
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
#include <errno.h>
#include <interix/security.h>

extern int errno;

int main(int argc, char** argv) {
    char key[] = "$MACHINE.ACC";
    char pass[1024];
    int ret;

    ret = getsecret( key, pass, sizeof( pass ) );
    if ( ret < 0 ) {
        printf( "'getsecret' for '%s' failed (%i - %s)\n", key, errno, strerror( errno ) )
        exit( 1 );
    }

    printf( "len of password: %d\n", ret );
    printf( "wc password read: %s\n", pass );

    ret = wcstombs( pass, ( wchar_t * ) pass, ret );
    if ( !ret || errno ) {
        printf( "'wcstombs' failed (%i - %s)\n", errno, strerror( errno ) );
        exit( 1 );
    }

    printf( "password read: %s\n", pass );
}

Thanks for the suggestion.

What's in "$MACHINE.ACC" is the machine's password. Since the machine has an account with Kerberos, like a user account does, there is a password. This is not the key however.

This password can be used to ask AD for the keytab (key table) which is a file that has the key in it. The Win32 command "ktpass", run on the AD server,with the right options which include this password, will generate the keytab file which can be copied to the "Unix" host (Interix in this case). The keytab will go stale when the Win32 side does the automatic password update at it's regular interval. So then you can then do a fresh generation and copy again, OR you can set the registry entry so that the automatic machine password update won't happen.

That could be enough to make kerberos viably usable from Interix (SFU/SUA). It's been 3+ years since I left it and details from then are getting foggy. Heimdal's has had more than a few updates since then I'm sure!