On Fri, Oct 18, 2019 at 05:57:40AM +0000, Vinícius Ferrão wrote: > > > On 17 Oct 2019, at 03:52, Sumit Bose > <[email protected]<mailto:[email protected]>> wrote: > > On Thu, Oct 17, 2019 at 04:32:05AM +0000, Vinícius Ferrão wrote: > > > On 16 Oct 2019, at 16:01, Rob Crittenden > <[email protected]<mailto:[email protected]><mailto:[email protected]>> > wrote: > > Vinícius Ferrão wrote: > > > On 15 Oct 2019, at 17:49, Rob Crittenden > <[email protected]<mailto:[email protected]><mailto:[email protected]> > <mailto:[email protected]>> wrote: > > Vinícius Ferrão wrote: > Hi Rob > > On 15 Oct 2019, at 10:22, Rob Crittenden > <[email protected]<mailto:[email protected]><mailto:[email protected]> > <mailto:[email protected]> > <mailto:[email protected]>> wrote: > > Vinícius Ferrão via FreeIPA-users wrote: > Hello, > > I’m trying to implement SSH Hostbased Authentication between IPA > joined machines but I’m with difficulties regarding: > > * The /etc/ssh/ssh_known_hosts file. > > In a FreeIPA environment the known_hosts are stored on IPA, and I’m > aware of the ProxyCommand /usr/bin/sss_ssh_knownhostsproxy; but how > can I create this file with the entries from FreeIPA? > > Why do you want to? That is the point of the proxy, so dynamic files > don't need to be maintained. > > Because it appears to be a requirement. Unfortunately SSH does not look > at /var/lib/sss/pubconf/known_hosts: > > debug1: userauth_hostbased: cuser admin chost > hpclab01.cluster.iq.ufrj.br<http://hpclab01.cluster.iq.ufrj.br><http://hpclab01.cluster.iq.ufrj.br> > <http://hpclab01.cluster.iq.ufrj.br> > <http://hpclab01.cluster.iq.ufrj.br>. pkalg > ecdsa-sha2-nistp256 slen 100 [preauth] > debug3: mm_key_allowed entering [preauth] > debug3: mm_request_send entering: type 22 [preauth] > debug3: mm_key_allowed: waiting for MONITOR_ANS_KEYALLOWED [preauth] > debug3: mm_request_receive_expect entering: type 23 [preauth] > debug3: mm_request_receive entering [preauth] > debug3: mm_request_receive entering > debug3: monitor_read: checking request 22 > debug3: mm_answer_keyallowed entering > debug3: mm_answer_keyallowed: key_from_blob: 0x561842345040 > debug2: hostbased_key_allowed: chost > hpclab01.cluster.iq.ufrj.br<http://hpclab01.cluster.iq.ufrj.br><http://hpclab01.cluster.iq.ufrj.br> > <http://hpclab01.cluster.iq.ufrj.br> > <http://hpclab01.cluster.iq.ufrj.br>. resolvedname > hpclab01.cluster.iq.ufrj.br<http://hpclab01.cluster.iq.ufrj.br><http://hpclab01.cluster.iq.ufrj.br> > <http://hpclab01.cluster.iq.ufrj.br> > <http://hpclab01.cluster.iq.ufrj.br> ipaddr > 172.26.0.1 > debug2: stripping trailing dot from chost > hpclab01.cluster.iq.ufrj.br<http://hpclab01.cluster.iq.ufrj.br><http://hpclab01.cluster.iq.ufrj.br> > <http://hpclab01.cluster.iq.ufrj.br> > <http://hpclab01.cluster.iq.ufrj.br>. > debug2: auth_rhosts2: clientuser admin hostname > hpclab01.cluster.iq.ufrj.br<http://hpclab01.cluster.iq.ufrj.br><http://hpclab01.cluster.iq.ufrj.br> > <http://hpclab01.cluster.iq.ufrj.br> > <http://hpclab01.cluster.iq.ufrj.br> ipaddr > 172.26.0.1 > debug1: temporarily_use_uid: 1683000000/1683000000 (e=0/0) > debug1: restore_uid: 0/0 > debug1: fd 8 clearing O_NONBLOCK > debug2: hostbased_key_allowed: access allowed by auth_rhosts2 > debug1: temporarily_use_uid: 1683000000/1683000000 (e=0/0) > debug1: restore_uid: 0/0 > debug1: check_key_in_hostfiles: key for host > hpclab01.cluster.iq.ufrj.br<http://hpclab01.cluster.iq.ufrj.br><http://hpclab01.cluster.iq.ufrj.br> > <http://hpclab01.cluster.iq.ufrj.br> > <http://hpclab01.cluster.iq.ufrj.br> not found > debug1: temporarily_use_uid: 1683000000/1683000000 (e=0/0) > debug1: restore_uid: 0/0 > debug1: check_key_in_hostfiles: key for host > hpclab01.cluster.iq.ufrj.br<http://hpclab01.cluster.iq.ufrj.br><http://hpclab01.cluster.iq.ufrj.br> > <http://hpclab01.cluster.iq.ufrj.br> > <http://hpclab01.cluster.iq.ufrj.br> not found > debug3: mm_answer_keyallowed: key 0x561842345040 is not allowed > Failed hostbased for admin from 172.26.0.1 port 55634 ssh2: ECDSA > SHA256:wJ0OVmkiVnMjuoiRe5sdBVz5sMTTKIbYRWorTk+CnUQ, client user "admin", > client host > "hpclab01.cluster.iq.ufrj.br<http://hpclab01.cluster.iq.ufrj.br><http://hpclab01.cluster.iq.ufrj.br> > <http://hpclab01.cluster.iq.ufrj.br> > <http://hpclab01.cluster.iq.ufrj.br>” > > It does for me: > > debug3: hostkeys_foreach: reading file "/root/.ssh/known_hosts" > debug3: hostkeys_foreach: reading file "/var/lib/sss/pubconf/known_hosts" > debug3: record_hostkey: found key type ED25519 in file > /var/lib/sss/pubconf/known_hosts:2 > debug3: record_hostkey: found key type RSA in file > /var/lib/sss/pubconf/known_hosts:4 > debug3: record_hostkey: found key type ECDSA in file > /var/lib/sss/pubconf/known_hosts:6 > > The client only pushes the SSHFP records on enrollment if IPA is serving > DNS. > > Rob, I’m not sure if we are talking about the same thing. In fact this > part works for me too: > > You're right, I missed the hostbased-part. I don't know that anyone has > tried this before. Perhaps someone from the sssd team would know since > they manage the proxy. > > rob > > Hi again Rob, it’s ok. HBA is not a common thing. > > I digged further on this issue and I got almost everything working as > expected, except for the known_hosts issue. The netgroup worked through > FreeIPA which is what I was looking for. So the only missing piece are the > keys. > > What is happening is that the server (the destination machine, running sshd) > must know the public key of the client (the connecting machine). And by > default it looks on /etc/ssh/ssh_known_hosts. I’m almost certain that this is > by design for Hostbased Authentication. > > This is OK, since I can symlink from /var/lib/sss/pubconf/known_hosts to > /etc/ssh/ssh_known_hosts and Hostbased Authentication works! But… > > Since the destination machine, haven’t issued any ssh connection to outside, > it does not have an /var/lib/sss/pubconf/known_hosts file populated. It does > not know about other machines, and when trying to connect with Hostbased it > simply fails. > > The /var/lib/sss/pubconf/known_hosts file is generated when the ssh client > tries to connect to a remote joined IPA host. On /etc/ssh/ssh_config we have > this lines: > > GlobalKnownHostsFile /var/lib/sss/pubconf/known_hosts > PubkeyAuthentication yes > ProxyCommand /usr/bin/sss_ssh_knownhostsproxy -p %p %h > > But that’s the problem. Only the client runs those commands. Theres nothing > similar, or nothing that I know for /etc/ssh/sshd_config, which manages the > server configuration. > > So that’s the problem basically. > > Do you have any ideia who should I contact about this? You said that’s > probably from the sssd team but even with this explanation it’s still from > sssd? I’m not sure if this will be solved without an RFE or anything like > that. > > Hi, > > yes, this most probably is an RFE for SSSD. Hostbased authentication was > not considered when the SSH related features were added to SSSD. > > Do I understand correctly that if you link > /var/lib/sss/pubconf/known_hosts and /etc/ssh/ssh_known_hosts on the > server side and then call > > sss_ssh_knownhostsproxy -k client.ipa.domain > > to refresh /var/lib/sss/pubconf/known_hosts with the client keys you can > connect from the client to the server with hostbased authentication as > expected? > > I can confirm: this trick works. > > [root@hpclab01 ~]# rm /var/lib/sss/pubconf/known_hosts > [root@hpclab01 ~]# !cat > cat /var/lib/sss/pubconf/known_hosts > cat: /var/lib/sss/pubconf/known_hosts: No such file or directory > > [root@hpclab01 ~]# sss_ssh_knownhostsproxy hpclab01
Hi, it might be easier to use the '-k' option. This will print the key to stdout as well but does not try to open a connection. > SSH-2.0-OpenSSH_7.4 > > Protocol mismatch. > > [root@hpclab01 ~]# cat /var/lib/sss/pubconf/known_hosts > |1|z9KS0phLNWHVVdFsM93CvPft3hM=|EViceVq6CLcj46ZvI+e4KelOb1Y= ssh-ed25519 > AAAAC3NzaC1lZDI1NTE5AAAAIJEO12B13c3rMzteoSSng11NHCQVJBIr5rZVUG/tbKi6 > > > > > > The /usr/bin/sss_ssh_knownhostsproxy executable can be called by sshd, the > server daemon during the client connection? If yes perhaps we can find a > solution. > > I'm not aware of an automatic solution. sshd can check authorized keys > with the help of AuthorizedKeysCommand but it looks like there is > nothing for hostbased authentication. > > As a workaround you can create a cron job which calls > 'sss_ssh_knownhostsproxy -k client.ipa.domain' for all expected clients > on a regular basis to refresh the keys. > > Yeah, I’m not sure if it will fit my environment. I’m trying to build an HPC > system with FreeIPA as identity core. Running a cronjob to fetch the keys on > a stateless node I don’t know if this would work as expected and there’s the > problem with the hosts. I need to constantly update the node list > (dynamically) to fetch keys dynamically. I think it’s too many moving parts > to end up breaking. > > Anyway, I think I will raise an RFE on SSSD. Where should I open the RFE? > Here: https://pagure.io/SSSD/sssd/issues Yes, that's the right place. bye, Sumit > > Thanks guys... > > > > HTH > > bye, > Sumit > > > Thank you very much Rob. > > V. > > > _______________________________________________ FreeIPA-users mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/[email protected]
