CC-ing Jakub from SSSD team to advise.

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 ?

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)

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?

Dmitri is right, the login should trigger a PAM conversation in order to generate a TGT from SSSD.

btw if you want to login without a password, you can configure GSSAPI authentication in sshd_config.

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?

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.

(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?

(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?

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.

(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?

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.

(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?

(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.

Thanks to Dmitri and Maxim for great discussion. Are all questions now resolved, can we close this bug?

(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.

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.

Upstream ticket:
https://fedorahosted.org/freeipa/ticket/4000

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.

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.

Hello.

It's 2019 now, and we also still need this feature, on both RHEL 6 and RHEL 7 systems.

If the SSH-RSA public key is enrolled in the directory, there is a tie in with the identity provider, and the identity provider can know that the user and authentication are happening over a trusted path, and issue the TGT.  

In our use case, the SSH RSA public key is enrolled as the posix attribute "userCertificate" on the user object in Active Directory.  
At the system level, sss_ssh_authorized_keys can retrieve this object for ssh authentication at authentication time.  
It seems feasible that pam or another mechanism could be made to retrieve a tgt from the identity provider when the identity provider looks up and returns the userCertificate attribute for the authenticating user.

The theory here is that the bind itself to the identity provider is done via kerberos, so the machine itself is already authenticated, via it's trusted keytab which contains the computer account principle. The user must already exist in the domain, and they SSH key is retrieved from the identity provider, again, over a secure channel, and provided back to the authenticating client.

This is a requirement for us when doing certificate based PKI smart card SSH login, and when using NFS version 4.0, 4.1, and 4.2 with KRB5i or KRB5p auto mounted home directories.
SSSD supports retrieving an SSH rsa key from an x.509 certificate enrolled as the userCertificate attribute on the user object in Active Directory.  When the key is returned via this end to end secure path, a TGT should be able to be issued.

If one is willing to trust the security of smart cards, then IDM / IPA should be configured to accept that same trust, and issue the kerberos ticket.

Thanks,
Chris.

+1 for adding this

A very simple solution could be to force users to login using a password if they don't have a ticket available. If a ticket is already available, allow public key login. I think sss_ssh_authorizedkeys should be able to implement this.

I would urge hardly against any solution which allows acquiring tickets by an ssh key.

Please look at the attack vectors in this incident:
https://csirt.egi.eu/academic-data-centers-abused-for-crypto-currency-mining/

Spreading of this attack worked mainly by abusing ssh keys with empty passphrases. Users are often much too lazy.

(In reply to Klaus Steinberger from comment #27)
> I would urge hardly against any solution which allows acquiring tickets by
> an ssh key.
> 
> Please look at the attack vectors in this incident:
> https://csirt.egi.eu/academic-data-centers-abused-for-crypto-currency-mining/
> 
> Spreading of this attack worked mainly by abusing ssh keys with empty
> passphrases. Users are often much too lazy.

What is exactly your argument? Is it that ssh private keys can be stolen, but a kerberos keytab with no password cannot be?

A kerberos keytab is much more under system control than a ssh private key. Usually you will not give out keytabs to users or just for special purpose. 
Also you can restrict keytabs fine grained to services.

SSH private keys are completly under user control, and there is now way to forge them to use Passphrases.

The Incident I refer hit most HPC and Supercomputer Centers worldwide. Spreading around was by private ssh keys with empty passphrase

(In reply to Klaus Steinberger from comment #29)
> A kerberos keytab is much more under system control than a ssh private key.
> Usually you will not give out keytabs to users or just for special purpose. 
> Also you can restrict keytabs fine grained to services.
> 
> SSH private keys are completly under user control, and there is now way to
> forge them to use Passphrases.
> 
> The Incident I refer hit most HPC and Supercomputer Centers worldwide.
> Spreading around was by private ssh keys with empty passphrase

ssh keys can also be managed by IPA. IPA can grant kerberos keytabs to particular ssh keys. I don't see a fundamental reason why using an ssh key should be less secure than having to type a (kerberos) password.

the problem are the lazy and  advice resistant users !

(In reply to Klaus Steinberger from comment #31)
> the problem are the lazy and  advice resistant users !

Users are always lazy. IMO, the problem was security practices in the affected organisations and people in charge of those, not the users or ssh keys.

Would a toggle option (off by default) satisfy the security concerns (whether superficial or not) that are preventing this from being developed? That way organizations can decide if they want to enable it?

Has anyone considered that SSH key can also be one from an X.509 certificate stored on a smartcard or TPM (version 2)?

I'm running this since years, regardless whether Windows OS (using pagent from PuTTY-CAC) or Linux ("ssh-add -s /usr/lib64/opensc-pkcs11.so" or "ssh-add -s /usr/lib64/pkcs11/libtpm2_pkcs11.so").

Then I can login using that key with *onetime* PIN entry until ssh-agent is locked or card is pulled or system is rebooted (TPM).

Server side one can use "pam_ssh_agent_auth" with a managed public key list for particular actions like

/etc/pam.d/su:auth      sufficient      pam_ssh_agent_auth.so file=/root/.ssh/authorized_keys
/etc/pam.d/sudo:auth       sufficient   pam_ssh_agent_auth.so file=/root/.ssh/authorized_keys

As IPA has also the SSH public keys stored, it should be also able to verify a key from an ssh-agent which finally ends up in a trust chain towards smartcard or TPM.

Created also a Jira ticket for the operating system: https://issues.redhat.com/browse/RHEL-18361