Request for help: How do I get tickets to these workstations?

Oliver Loch o.loch at
Tue Jun 5 04:43:51 EDT 2012


Am 05.06.2012 um 08:37 schrieb Jan-Piet Mens:

>>> +----+        +---------+        +--------+
>>> |    +-- SSH ->  semi    +-- SSH ->  trusted|
>>> | PC |        | trusted |        |        |
>>> +----+        +---------+        +---^----+
>>>                                      |
>>>                                  +---+----+
>>>                                  |  KDC   |
>>>                                  |        |
>>>                                  +--------+
>> I am assuming that the KDC is behind a firewall, and the PC cannot contact the KDC?
> Correct. The "semi-trusted" host can contact the KDC; the PC cannot.
>> Otherwise KfW and PuTTY with GSSAPI delegation as Oliver pointed out should work.
> Yes, I understand that, and thank you both. 
>>> Users now hop onto the semi-trusted system and invoke `kinit', but they
>>> have to do this for each and every SSH session.
>> And you are not using pam_krb5 on the bastion host either, as the user is doing
>> kinit.
> How would using pam_krb5 on the bastion host help? Surely, each SSH
> connection to the bastion host from the PC would re-prompt for
> credentials, because the PC doesn't have a TGT. 

When the user logs in, the pam_krb5 module generates a kerberos ticket which is forwardable.

All you need is to set this on the semi trusted host:

In /etc/krb5.conf

        forwardable = true
        pam = {
                default_realm = this_one_only_if_necessary

Then you can add to /etc/pam.d/sshd 

auth	sufficient your=options_here
account	required your=options_here
session	required your=options_here

And you have to enable PAM support in /etc/ssh/sshd_config

UsePAM yes

This should give you the following sshd_config(5):

UsePAM Enables  the  Pluggable Authentication Module interface.  If set
              to ``yes'' this will enable PAM  authentication  using  Challen‐
              geResponseAuthentication  and PasswordAuthentication in addition
              to PAM account and session module processing for all authentica‐
              tion types.

So when the user logs in the generates a ticket for the user. The point in this is, that only password based authentication can be done then, as the password is needed to request the kerberos tickets. The host also needs a keytab in /etc/krb5.keytab or whatever you set KRB5_KTNAME in sshd's environment to, that should contain the principals $hostname and host/$hostname.

Btw: Putting the KDC into the public would make things way easier :)

>> From a security point of view that is not much different then opening
>> up port 88 of the KDC in your firewall.
> I don't think this is an option at the moment.
> While we're at it: are there organizations who have Internet-facing KDCs
> or would that be complete madness? 

The whole Kerberos thing is made for exactly this. So putting the KDC to the public is not any problem at all. It's made for this. 

Kadmind is a different story.

But you could also put a "KDC-Slave" server to the public that can only hand out tickets and is only able to serve the things you send to it via kprop.

Maybe that could be the solution.

> Regards,
>        -JP
> ________________________________________________
> Kerberos mailing list           Kerberos at



More information about the Kerberos mailing list