Bug 1017651 - Logging in using SSH keys does not create a kerberos ticket
Logging in using SSH keys does not create a kerberos ticket
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: ipa (Show other bugs)
6.4
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Martin Kosek
Namita Soman
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-10-10 05:51 EDT by Maxim Egorushkin
Modified: 2016-03-21 20:06 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-10-29 09:53:46 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Maxim Egorushkin 2013-10-10 05:51:50 EDT
Description of problem:
Logging into a machine enrolled as an IPA client does not automatically create a kerberos ticket.

Version-Release number of selected component (if applicable):
ipa-server-3.0.0-26.el6_4.4.x86_64
ipa-client-3.0.0-26.el6_4.4.x86_64

How reproducible:
Always.

Steps to Reproduce:
[max@otlonlin050:~] $ ssh linux01
[max@linux01 ~]$ klist

Actual results:
[max@linux01 ~]$ klist
klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_1637600006)

Expected results:
$ klist
Ticket cache: FILE:/tmp/krb5cc_1637600006
Default principal: max@XYZ.COM

Valid starting     Expires            Service principal
10/10/13 09:46:12  10/11/13 09:46:09  krbtgt/XYZ.COM@XYZ.COM

Additional info:
I have to manually invoke kinit and provide my password after the ssh login.

All ssh users are authenticated using IPA. From sshd_config:

    AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys
Comment 2 Martin Kosek 2013-10-10 06:50:58 EDT
CC-ing Jakub from SSSD team to advise.
Comment 3 Jakub Hrozek 2013-10-10 07:29:41 EDT
How do you log in, with GSSAPI or password? Can you attach the lines (if any) that the login attempt generates in /var/log/secure ?
Comment 4 Maxim Egorushkin 2013-10-10 08:18:24 EDT
I registered my public rsa key in IPA gui, so that I login without a password.

From /var/log/secure:

Oct 10 12:16:35 linux01.xyz.com sshd[11426]: Accepted publickey for max from a.b.c.d port 60833 ssh2
Oct 10 12:16:35 linux01.xyz.com sshd[11426]: pam_unix(sshd:session): session opened for user max by (uid=0)
Comment 5 Dmitri Pal 2013-10-10 13:29:00 EDT
So you are logging in with SSH keys and expecting a kerebros ticket?
Kerberos does not support authentication with SSH keys. 
I think your expectation is wrong. Sorry.

The whole point of Kerberos is to authenticate on the client system and then use SSO to access the target server. In this case one can have a ticket forwarded if needed. SSH keys are not used then.

But may be instead of just CLOSE INVALID we should turn it around and ask what are you trying to accomplish?
Comment 6 Jakub Hrozek 2013-10-10 13:48:02 EDT
Dmitri is right, the login should trigger a PAM conversation in order to generate a TGT from SSSD.
Comment 7 Jakub Hrozek 2013-10-10 13:48:39 EDT
btw if you want to login without a password, you can configure GSSAPI authentication in sshd_config.
Comment 8 Maxim Egorushkin 2013-10-10 14:09:38 EDT
My use case is the following:

We have a few servers in a datacenter, all configured as IPA clients. I log into one of these servers as prod user (a user that runs production applications on all servers). I would like to invoke rsync (using ssh as transport) to copy files from this server to all other servers. When I invoke rsync it asks me for a password for each server. If I invoke kinit prior to rsync, rsync does not require a password.

On https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/logging-in.html it says:

> If SSSD or pam_krb5 is configured on the IdM client machine, then when a user logs into the machine, a ticket is created which can be used for machine services which require authentication, such as sudo.

I thought that means when I ssh into one of the servers as a user authenticated by IPA it creates a kerberos ticket for me, so that I can access all other servers as the same user with no password (single sing-on?). Is that not what that quote mean?
Comment 9 Dmitri Pal 2013-10-10 16:34:20 EDT
You need to login in the first one using password and then the ticket is created and you can SSO between other servers. If you login in the initial server with SSH the ticket is not created and you have to do kinit and then things work. I suspect that this is what you are experiencing.

Where are you logging from in the first place? Windows system or Linux laptop?
If it is a Linux system then you can potentially join this Linux system into IdM and then once you log into your Linux laptop you can SSO into different other systems managed by IdM.
If your initial system is a Windows system then you still can accomplish SSO but with a bit more complexity. Your Windows system is probably a part of some AD domain so if you establish trust between AD domain and IdM your AD users coming from Windows systems would be able to SSH into different hosts. 
One caveat is that if you want to chain your logins and still enjoy SSO you need to configure Kerberos to send TGT around so that you can re-use it moving to the next system in the chain. It is not recommended though because TGT forwarding weakens security. But it is convenient so it is a trade off that you need to make.
Comment 10 Maxim Egorushkin 2013-10-10 18:45:34 EDT
(In reply to Dmitri Pal from comment #9)
> You need to login in the first one using password and then the ticket is
> created and you can SSO between other servers. If you login in the initial
> server with SSH the ticket is not created and you have to do kinit and then
> things work. I suspect that this is what you are experiencing.

You are right. I log in over ssh using a private key.

> Where are you logging from in the first place? Windows system or Linux
> laptop?

I log in from a Fedora 18 from the office, but none of the office machines are part of the IPA "domain".

I was expecting that a kerberos ticket gets created upon a ssh login into one of the IPA clients.

From your detailed comments I gather this is not how IPA has been designed to work. 

IPA knows my public ssh key, why would I still have to invoke kinit and enter a password though, doesn't it feel like some sort of a disconnect and duplication?
Comment 11 Maxim Egorushkin 2013-10-10 18:50:34 EDT
(In reply to Maxim Yegorushkin from comment #10)
> (In reply to Dmitri Pal from comment #9)
> > You need to login in the first one using password and then the ticket is
> > created and you can SSO between other servers. If you login in the initial
> > server with SSH the ticket is not created and you have to do kinit and then
> > things work. I suspect that this is what you are experiencing.
> 
> You are right. I log in over ssh using a private key.
> 
> IPA knows my public ssh key, why would I still have to invoke kinit and
> enter a password though, doesn't it feel like some sort of a disconnect and
> duplication?

That /usr/bin/sss_ssh_authorizedkeys command technically could create a kerberos key for me, could not it?
Comment 12 Dmitri Pal 2013-10-10 23:18:03 EDT
Kerberos key is a symmetric key that is stored on both sides. What you are suggesting is that we use SSH keys as kerberos keys. 

Such functionality is not implemented by the Kerberos protocol.

I suspect it is technically possible but it would be a major undertaking and would take years to implement because it would require standardization work first.

Frankly we hear about this as a requirement for the first time (in 6 years of life of IPA). I agree that it might be a valid use case but it is very rare.

What prevents you from enrolling your F18 office machines with IPA or using password authentication for SSHing into the machines from the office? In both cases the SSO would work as you expect. You are sort of trying to bridge two technologies that are currently not connected.
Comment 13 Maxim Egorushkin 2013-10-11 06:03:00 EDT
(In reply to Dmitri Pal from comment #12)
> Kerberos key is a symmetric key that is stored on both sides. What you are
> suggesting is that we use SSH keys as kerberos keys.

Exactly. SSH keys may be more secure than passwords due to their length.

> Such functionality is not implemented by the Kerberos protocol.

I gather the only way to get a kerberos ticket is to enter a plain text password into kinit, is that right?

> I suspect it is technically possible but it would be a major undertaking and
> would take years to implement because it would require standardization work
> first.
> 
> Frankly we hear about this as a requirement for the first time (in 6 years
> of life of IPA). I agree that it might be a valid use case but it is very
> rare.

Fair enough.

I guess I will have to put kinit invocation into my .bash_profile to work around this limitation.

> What prevents you from enrolling your F18 office machines with IPA or using
> password authentication for SSHing into the machines from the office? In
> both cases the SSO would work as you expect. You are sort of trying to
> bridge two technologies that are currently not connected.

On my desktops I use user max, to deploy changes to production I use user prod. However, user prod accepts a ssh private key of user max. As I have to switch the user anyway, having my desktop enrolled into IPA does not seem to improve things, or am I missing something?
Comment 14 Dmitri Pal 2013-10-11 18:24:09 EDT
First of all you can eliminate SSH keys by using Kerberos keys instead.
You can issue a kerberos key in a keytab it will be very similar to SSH keys but your passwords and keys will be managed in a coherent way and will be connected to each other. 

What is not clear is when the transition from max to prod happens?
Do you already SSH from you desktop as prod or you ssh as max and then use prod once you got into the first system?

Anyways passwords can be very long and complex and stored in the keytabs. You can create a user with a long and strong random password that is effectively a key.
You can store the key in the keytab. You can use keytab to kinit.

So in your scenario instead of using password you can:

1) Create a service principal 'prod'
2) Get keytab for it using ipa-getkeytab (the result is the equivalent of your SSH key)
3) Place this keytab on the systems you log in and then manage production from
4) Add kinit with this keytab to you bash profile

This way you do not need SSH keys any more and you use Kerberos for everything.

You can also have this keytab just in the office on your office machine and kinit on the office machine as prod and then ssh as prod rather than max.

The security of the system is as strong as the weakest link.
If to get to a strong key you have a weak password things are not good so you need to have a good password for max in the first place. But if you have a good password in the first place you can log as max on in the office system and ssh using kerberos SSO where you need to and do the whole management as max.

There are probably some policies that would prevent you from doing this and force you to use two different accounts though it is strictly not required.

Also you might look at use of .k5login file that allows you to translate from a kerberos principal to local user. May be you would be able to configure things in such a way that one kerberos principal would map to different users on different systems. Just wanted to mention that this is possible and you might consider this as an option.
Comment 15 Maxim Egorushkin 2013-10-13 13:02:15 EDT
(In reply to Dmitri Pal from comment #14)
> First of all you can eliminate SSH keys by using Kerberos keys instead.
> You can issue a kerberos key in a keytab it will be very similar to SSH keys
> but your passwords and keys will be managed in a coherent way and will be
> connected to each other.

I would not mind using Kerberos keys instead, however, there is a use case when production management staff need to login from hosts that are not enrolled in the Kerberos domain for various reasons and only have ssh available (I do that from my girlfriend's iPad when on holiday).

> What is not clear is when the transition from max to prod happens?
> Do you already SSH from you desktop as prod or you ssh as max and then use
> prod once you got into the first system?

Local user max initiates a ssh connection to IPA user prod on a remote machine like so:

    [max@otlonlin050:~] $ id
    uid=1000(max) gid=1000(max) groups=1000(max),7(lp),10(wheel),39(video),100(users)
    [max@otlonlin050:~] $ ssh prod@hlinux01
    [prod@hlinux01:~] $ id
    uid=1637600016(prod) gid=1637600016(prod) groups=1637600016(prod)

> Anyways passwords can be very long and complex and stored in the keytabs.
> You can create a user with a long and strong random password that is
> effectively a key.

You are right, I concede passwords can be as long and secure as ssh public/private keys.

> You can store the key in the keytab. You can use keytab to kinit.
> 
> So in your scenario instead of using password you can:
> 
> 1) Create a service principal 'prod'
> 2) Get keytab for it using ipa-getkeytab (the result is the equivalent of
> your SSH key)
> 3) Place this keytab on the systems you log in and then manage production
> from
> 4) Add kinit with this keytab to you bash profile

This sounds like a solution for my use cases provided service principal prod can  rsync to other servers. Probably sss_ssh_authorizedkeys on other servers ought to accept service principal prod as a valid user for this to work, or rsync being able to accept Kerberos principals in some other way. I am not sure what the differences between service and user principals are.

> This way you do not need SSH keys any more and you use Kerberos for
> everything.

I still need to be able to login using ssh password or public/private key only and get that kerberos ticket automatically. 

> You can also have this keytab just in the office on your office machine and
> kinit on the office machine as prod and then ssh as prod rather than max.

Can I kinit as both simultaneously?

[]

> Also you might look at use of .k5login file that allows you to translate
> from a kerberos principal to local user. May be you would be able to
> configure things in such a way that one kerberos principal would map to
> different users on different systems. Just wanted to mention that this is
> possible and you might consider this as an option.

This is an interesting option. When it translates to the local user does it also generate the kerberos ticket for that local user?
Comment 16 Maxim Egorushkin 2013-10-14 05:50:41 EDT
(In reply to Dmitri Pal from comment #14)

[]

> You can store the key in the keytab. You can use keytab to kinit.
> 
> So in your scenario instead of using password you can:
> 
> 1) Create a service principal 'prod'
> 2) Get keytab for it using ipa-getkeytab (the result is the equivalent of
> your SSH key)
> 3) Place this keytab on the systems you log in and then manage production
> from
> 4) Add kinit with this keytab to you bash profile
> 
> This way you do not need SSH keys any more and you use Kerberos for
> everything.

This method works for me. Thank you for your detailed and insightful comments.
Comment 18 Martin Kosek 2013-10-15 07:26:16 EDT
Thanks to Dmitri and Maxim for great discussion. Are all questions now resolved, can we close this bug?
Comment 19 Maxim Egorushkin 2013-10-15 08:34:48 EDT
(In reply to Martin Kosek from comment #18)
> Thanks to Dmitri and Maxim for great discussion. Are all questions now
> resolved, can we close this bug?

kinit in .bash_profile works for me. I can live with that.

On the other hand, IPA ties together Kerberos, LDAP, OpenSSH and other bits. Kerberos authentication automatically works for ssh, but not the other way around. So, it feels like this is a missing feature of IPA.
Comment 20 Martin Kosek 2013-10-18 07:49:57 EDT
Potentially, yes. But as Dmitri already pointed out in Comment 12, this is a quite rare request which is also hard to fulfill - it won't be something we would focus soon.

Theoretically, I am thinking that this could be make to work with pkinit (when it's support is added to FreeIPA), I found several old-ish discussions of people who wanted ti achieve the same use case as you, e.g.:

http://www.mail-archive.com/kerberos@mit.edu/msg12285.html

I plan to clone this RFE to FreeIPA upstream Trac, but for the time being it will most probably end in Deferred milestone.
Comment 21 Martin Kosek 2013-10-25 05:16:12 EDT
Upstream ticket:
https://fedorahosted.org/freeipa/ticket/4000
Comment 22 Martin Kosek 2013-10-29 09:53:46 EDT
Upstream ticket was closed as WONTFIX with following explanation from Simo Sorce:

~~~~
This is an unsolvable problem.

The issue is that with SSH keys you are completely deferring authentication to the target machine and the KDC is not involved in any way. In order to release a TGT for a user the KDC needs proof of knowledge of the user's long term secret. The target machine does not have that knowledge, because the user logged in via SSH keys not username/password, so it has no way to ask the KDC for a user TGT.

If it is desired to have a kerberos TGT on the target machine but log in without providing the password then the only option is to use GSSAPI authentication with SSH and the -K switch to forward the user TGT from the client machine to the target machine.
~~~~

Closing the downstream Bugzilla as well.
Comment 23 steverweber 2016-03-21 20:06:53 EDT
I understand this issue is dated/closed and marked wontfix

However getting this to work would solve many issues we battle at a university with a large collection of mixed environments.

Moving are servers to use nfs4 sec=krb and automount for user home is ideal... however if users cant use ssh keys to login it's a no go.
 
@bnordgren had added a message to the thread:
https://fedorahosted.org/freeipa/ticket/4000

seems this feature could be worked out.

Note You need to log in before you can comment on or make changes to this bug.