Request for help: How do I get tickets to these workstations?
Oliver Loch
o.loch at gmx.net
Tue Jun 5 04:43:51 EDT 2012
Hi,
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
[appdefaults]
forwardable = true
pam = {
default_realm = this_one_only_if_necessary
}
Then you can add pam_krb5.so to /etc/pam.d/sshd
auth sufficient pam_krb5.so your=options_here
account required pam_krb5.so your=options_here
session required pam_krb5.so 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 pam_krb5.so 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 mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
KR,
Oliver
More information about the Kerberos
mailing list