[Samba] How do I get an ssh client to authenticate with samba4's kerberos GSSAPI? [Solved]
Quinn Plattel
qiet72 at gmail.com
Mon Jul 23 07:13:17 MDT 2012
Hi,
I have now managed to succeed in doing passwordless ssh logins via
kerberos/samba4 without the "GSSAPIStrictAcceptorCheck" trick or hacking
the krb5.keytab file.
My samba4 setup is actually a bit special compared to a normal samba4 setup
in that I am running samba4 on top of a corosync/pacemaker high
availability cluster. It does complicate things a bit in that samba4 is
running on a machine with more than one hostname and ip address. I wanted
samba4 to run on a virtual ip/hostname using corosync. Whenever a node
become the primary node in a cluster, it automatically allocates a virtual
ip by doing an ip alias. So for example, eth0 would have a normal ip fx
10.0.0.1, but when this machine became the active node, it would also have
a eth0:0 with ip fx, 10.0.0.10 and samba4/bind9/whatever services would
bind only to that virtual ip address. Unfortunately, some services such as
sshd queries the hostname of the name and that usually does not match the
virtual hostname - hence we get "Wrong principal in request". The solution
was to make the active node temporarily have the same hostname as the
virtual hostname.
So anyways, here are the required items for passwordless ssh to work with
kerberos:
- on the machine where sshd runs, make sure the command "hostname -f"
returns the correct fully qualified domain name that you want to connect to
via ssh
- on the machine where sshd runs, make sure you have a valid krb5.keytab
file in /etc/ - (sshd looks for it)
- on the machine where sshd runs, make sure you have host/<fully qualified
domain name> exported to the /etc/krb5.keytab "samba-tool domain
exportkeytab /etc/krb5.keytab --principal=host/cofil01.mydomain.net"
Note: You don't need to have an existing krb5.keytab for "samba-tool domain
exportkeytab" to work. So a minimal sshd working keytab would have this
using "klist -ke /etc/krb5.keytab":
Keytab name: FILE:krb5.keytab
KVNO Principal
----
--------------------------------------------------------------------------
1 host/cofil01.mydomain.net @ MYDOMAIN.NET (des-cbc-crc)
1 host/cofil01.mydomain.net @ MYDOMAIN.NET (des-cbc-md5)
1 host/cofil01.mydomain.net @ MYDOMAIN.NET (arcfour-hmac)
Remember to do a kinit <user> before doing a "ssh -l <user> <server>" if
you are not using a Single Sign On solution.
Hope this helps other people with there kerberos hacking! :-)
br,
Quinn
On Thu, Jul 19, 2012 at 9:34 PM, Ritter, Marcel - RRZE <
marcel.ritter at rrze.fau.de> wrote:
> Hi Quinn,
>
> Maybe I can help with this:
>
> "That's it. Now I just have to see if I can get a "host/
> server.mydomain.net"
> principal into the samba domain somehow."
>
> I just tried to get rid of the "GSSAPIStrictAcceptorCheck no" option myself
> on the Samba 4 DC - while still using GSSAPI based ssh login.
>
> Doing this involves a very, very dirty hack:
>
> 1. Copy samba 4 secrets.keytab to /etc/krb5.keytab
> (this one contains upper case HOST/ principals).
> 2. Principal names are stored as strings in the keytab,
> so let's use sed to turn upper into lower case
> (yes I know, this is very, very dirty - but it's just a
> prove of what I suspected):
> sed -i s+HOST+host+g /etc/krb5.keytab
> 3. Remove the "GSSAPIStrictAcceptorCheck no" option from
> sshd_config and restart sshd.
> 4. Try to log in using ssh
> -> works for me (and I hope for everyone else).
>
> Somehow MS AD and therefore Samba 4 seem to treat
> principals case insensitive, while standard kerberos
> implementations are case sensitive.
> BTW: klist reports a host/... principal (lower case),
> after trying a GSSAPI ssh login - so this is the
> principal sent by ssh to the server, that looks
> for a match in krb5.keytab - and fails because
> by default we only have HOST/... principal there.
>
> I guess the easiest way would be to store principals
> in lower case only during a provision run of samba4.
>
> This may however cause other problems - I guess some
> samba core developer needs to have a look at this.
>
> But the only principal I ever encountered, that needed to be
> upper case was the HTTP/ one ...
>
> Hope this helps,
> Marcel
>
>
> -----Ursprüngliche Nachricht-----
> Von: samba-bounces at lists.samba.org [mailto:samba-bounces at lists.samba.org]
> Im Auftrag von Quinn Plattel
> Gesendet: Donnerstag, 19. Juli 2012 16:23
> An: samba
> Betreff: Re: [Samba] How do I get an ssh client to authenticate with
> samba4's kerberos GSSAPI? [Solved]
>
> Hi,
>
> Using the following tutorials:
> https://help.ubuntu.com/community/SingleSignOn
> https://help.ubuntu.com/community/Kerberos
>
> I have now managed to get passwordless ssh logins via kerberos working
> (without using the /etc/ssh/sshd_config parameter
> "GSSAPIStrictAcceptorCheck no") on a normal kerberos server setup. I
> learned from this that ssh requires "host/server.mydomain.net @
> MYDOMAIN.NET"
> in the principal database and also exported to a keytab located on the
> server which sshd is running in the location /etc/krb5.keytab.
> On the client, /etc/ssh/ssh_config requires at least "GSSAPIAuthentication
> yes". sshd requires at least "KerberosAuthentication yes" and
> "GSSAPIAuthentication yes" in the /etc/ssh/sshd_config.
>
> On a real kerberos server, you use the following commands in the kadmin
> tool to add the necessary principals for ssh to work properly:
> addprinc user # Adds
> a valid user to the kerberos principal database
> addprinc -randkey host/server.mydomain.net # Adds a host
> principal to the principal database
> ktadd -k /etc/krb5.keytab host/server.mydomain.net # exports the
> principals host/server.mydomain.net to the /etc/krb5.keytab
>
> Restart sshd to be sure it picks up the updated /etc/krb5.keytab file. On
> the client side, "kinit user", then ssh -l user <server>
>
> That's it. Now I just have to see if I can get a "host/
> server.mydomain.net"
> principal into the samba domain somehow.
>
> Note: once I get single-sign-on to work, then it should not be necessary
> to do a kinit first.
>
> br,
> Quinn
>
> On Mon, Jul 16, 2012 at 2:34 PM, Quinn Plattel <qiet72 at gmail.com> wrote:
>
> >
> > I think I take this back. This more a workaround than a solution.
> > The workaround makes sshd use any principal found in the database, but
> > a proper kerberos setup would look for the client's hostname principal
> only.
> > The search goes on for a proper samba4 kerberos setup. :-)
> >
> > br,
> > Quinn
> >
> >
> > On Tue, Jul 10, 2012 at 4:07 PM, Quinn Plattel <qiet72 at gmail.com> wrote:
> >
> >> Hi,
> >>
> >> I solved my ssh GSSAPI problem. There were a lot of solutions on
> >> google referring to a proper fqdn in the /etc/hosts file and having
> >> the fqdn's/principals in the kerberos server's keytab file but I
> >> found out that my problem was that the samba4/kerberos server was
> >> running on a multi-homed machine and that the ssh server kerberos
> >> authentication needed the following parameter in order for it to work
> on multi-homed machines:
> >>
> >> GSSAPIStrictAcceptorCheck no
> >>
> >> The default is yes, using "no" will, according to the manpage
> >> "clients may authenticate against any service key stored in the
> >> machine's default store."
> >>
> >> I hope this helps others that have similar setups as I do.
> >>
> >> Thank you all for your input.
> >>
> >> br,
> >> Quinn
> >>
> >>
> >>
> >>
> >
> >
> > --
> > Best regards/Med venlig hilsen,
> > Quinn Plattel
> >
>
>
>
> --
> Best regards/Med venlig hilsen,
> Quinn Plattel
> --
> To unsubscribe from this list go to the following URL and read the
> instructions: https://lists.samba.org/mailman/options/samba
>
--
Best regards/Med venlig hilsen,
Quinn Plattel
More information about the samba
mailing list