SSH Hostbased Authentication with FreeIPA

[Vinícius Ferrão]

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?

* Another issue is with the /etc/ssh/shosts.equiv file. 

	It supports plain hostnames or netgroups, which is a NIS thing. FreeIPA offers any
netgroups compatibility? I’m expecting to put something like: @nodes on this file to keep
it simple. Any changes on IPA hosts would be reflected automatically.

Thanks,

PS: Further documentation about SSH Hostbased Authentication:
https://en.wikibooks.org/wiki/OpenSSH/Cookbook/Host-based_Authentication

[Rob Crittenden]

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.

>  * Another issue is with the /etc/ssh/shosts.equiv file. 
>  
>  	It supports plain hostnames or netgroups, which is a NIS thing. FreeIPA offers any
> netgroups compatibility? I’m expecting to put something like: @nodes on this file to keep
> it simple. Any changes on IPA hosts would be reflected automatically. 
IPA hostgroups are automatically mirrored as netgroups.

rob

[Vinícius Ferrão]

Hi Rob

On 15 Oct 2019, at 10:22, Rob Crittenden
<[e-mail]<mailto:[e-mail]>> 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>. 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>. resolvedname
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>.
debug2: auth_rhosts2: clientuser admin hostname
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> 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> 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>”


If you look at the sshd log there is this:
debug1: check_key_in_hostfiles: key for host
hpclab01.cluster.iq.ufrj.br<http://hpclab01.cluster.iq.ufrj.br> not found




But if I create the file manually it will work:

debug1: check_key_in_hostfiles: key for
hpclab01.cluster.iq.ufrj.br<http://hpclab01.cluster.iq.ufrj.br> found at
/etc/ssh/ssh_known_hosts:1



Any ideias?


* Another issue is with the /etc/ssh/shosts.equiv file.

It supports plain hostnames or netgroups, which is a NIS thing. FreeIPA offers any
netgroups compatibility? I’m expecting to put something like: @nodes on this file to keep
it simple. Any changes on IPA hosts would be reflected automatically.

IPA hostgroups are automatically mirrored as netgroups.

Nice, this worked flawlessly!!!


rob

Thank you very much.

V.

[Rob Crittenden]

Vinícius Ferrão wrote:
>  Hi Rob
>  
> > On 15 Oct 2019, at 10:22, Rob Crittenden <rcritten(a)redhat.com
> > <mailto:[e-mail]>> 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>;. 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>;. resolvedname
>  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>;.
>  debug2: auth_rhosts2: clientuser admin hostname
>  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> 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> 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>” 
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

>  
>  
>  If you look at the sshd log there is this:
>  debug1: check_key_in_hostfiles: key for host hpclab01.cluster.iq.ufrj.br
>  <http://hpclab01.cluster.iq.ufrj.br> not found
>  
>  
>  
>  
>  But if I create the file manually it will work:
>  
>  debug1: check_key_in_hostfiles: key for hpclab01.cluster.iq.ufrj.br
>  <http://hpclab01.cluster.iq.ufrj.br> found at /etc/ssh/ssh_known_hosts:1
>  
>  
>  
>  Any ideias?
>  
> >
> >> * Another issue is with the /etc/ssh/shosts.equiv file.
> >>
> >> It supports plain hostnames or netgroups, which is a NIS thing.
> >> FreeIPA offers any netgroups compatibility? I’m expecting to put
> >> something like: @nodes on this file to keep it simple. Any changes on
> >> IPA hosts would be reflected automatically.
> >
> > IPA hostgroups are automatically mirrored as netgroups.
>  
>  Nice, this worked flawlessly!!!
>  
> >
> > rob
>  
>  Thank you very much.
>  
>  V.
>  
>

[Vinícius Ferrão]

On 15 Oct 2019, at 17:49, Rob Crittenden
<[e-mail]<mailto:[e-mail]>> wrote:

Vinícius Ferrão wrote:
Hi Rob

On 15 Oct 2019, at 10:22, Rob Crittenden
<[e-mail]<mailto:[e-mail]>
<mailto:[e-mail]>> 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>;. 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>;. resolvedname
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>;.
debug2: auth_rhosts2: clientuser admin hostname
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> 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> 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>”

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:

debug1: Authenticating to hpclab03:22 as 'root'
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 ECDSA in file /var/lib/sss/pubconf/known_hosts:4
debug3: record_hostkey: found key type RSA in file /var/lib/sss/pubconf/known_hosts:6
debug3: load_hostkeys: loaded 3 keys from hpclab03

But it’s not here the problem. The problem is when starting HBA (Hostbased
Authentication).

debug1: Next authentication method: hostbased

Here is the problem:

debug3: userauth_hostbased: trying key type
[e-mail]<mailto:[e-mail]>
debug3: userauth_hostbased: trying key type
[e-mail]<mailto:[e-mail]>
debug3: userauth_hostbased: trying key type
[e-mail]<mailto:[e-mail]>
debug3: userauth_hostbased: trying key type
[e-mail]<mailto:[e-mail]>
debug3: userauth_hostbased: trying key type
[e-mail]<mailto:[e-mail]>
debug3: userauth_hostbased: trying key type
[e-mail]<mailto:[e-mail]>
debug3: userauth_hostbased: trying key type ecdsa-sha2-nistp256
debug1: userauth_hostbased: trying hostkey ecdsa-sha2-nistp256
SHA256:Nwwv7gndOGwipEM3I8AGQEUX7OP9LvgFG0V7TXJ0XcI
debug2: userauth_hostbased: chost
hpclab01.cluster.iq.ufrj.br<http://hpclab01.cluster.iq.ufrj.br>.
debug3: send packet: type 50
debug2: we sent a hostbased packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue:
publickey,gssapi-keyex,gssapi-with-mic,keyboard-interactive,hostbased
debug3: userauth_hostbased: trying key type ecdsa-sha2-nistp256
debug3: userauth_hostbased: trying key type ecdsa-sha2-nistp384
debug3: userauth_hostbased: trying key type ecdsa-sha2-nistp521
debug3: userauth_hostbased: trying key type ssh-ed25519
debug1: userauth_hostbased: trying hostkey ssh-ed25519
SHA256:9O5hkM8gLvGPcoZE9t5zbGxAxHGq7RsCZ5ScjltBZpQ
debug2: userauth_hostbased: chost
hpclab01.cluster.iq.ufrj.br<http://hpclab01.cluster.iq.ufrj.br>.
debug3: send packet: type 50
debug2: we sent a hostbased packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue:
publickey,gssapi-keyex,gssapi-with-mic,keyboard-interactive,hostbased
debug3: userauth_hostbased: trying key type ssh-ed25519
debug3: userauth_hostbased: trying key type rsa-sha2-512
debug3: userauth_hostbased: trying key type rsa-sha2-256
debug3: userauth_hostbased: trying key type ssh-rsa
debug1: userauth_hostbased: trying hostkey ssh-rsa
SHA256:+Zl4g2C+AALTHr0K/qkcSDkU6wVQ+CygatAn7x9bRUI
debug2: userauth_hostbased: chost
hpclab01.cluster.iq.ufrj.br<http://hpclab01.cluster.iq.ufrj.br>.
debug3: send packet: type 50
debug2: we sent a hostbased packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue:
publickey,gssapi-keyex,gssapi-with-mic,keyboard-interactive,hostbased
debug3: userauth_hostbased: trying key type ssh-rsa
debug3: userauth_hostbased: trying key type ssh-dss
debug1: No more client hostkeys for hostbased authentication.

If I manually create the file: /etc/ssh/ssh_known_hosts with the entries it works, so it’s
definitely not looking in /var/lib/sss/pubconf/known_hosts or the proxy isn’t being called
during HBA.

If it’s still not clear what I mean I can try to rephrase it.

Thanks again.


rob



If you look at the sshd log there is this:
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> not found




But if I create the file manually it will work:

debug1: check_key_in_hostfiles: key for
hpclab01.cluster.iq.ufrj.br<http://hpclab01.cluster.iq.ufrj.br>
<http://hpclab01.cluster.iq.ufrj.br> found at /etc/ssh/ssh_known_hosts:1



Any ideias?


* Another issue is with the /etc/ssh/shosts.equiv file.

It supports plain hostnames or netgroups, which is a NIS thing.
FreeIPA offers any netgroups compatibility? I’m expecting to put
something like: @nodes on this file to keep it simple. Any changes on
IPA hosts would be reflected automatically.

IPA hostgroups are automatically mirrored as netgroups.

Nice, this worked flawlessly!!!


rob

Thank you very much.

V.

[Rob Crittenden]

Vinícius Ferrão wrote:
>  
>  
> > On 15 Oct 2019, at 17:49, Rob Crittenden <rcritten(a)redhat.com
> > <mailto:[e-mail]>> wrote:
> >
> > Vinícius Ferrão wrote:
> >> Hi Rob
> >>
> >>> On 15 Oct 2019, at 10:22, Rob Crittenden <rcritten(a)redhat.com
> >>> <mailto:[e-mail]>
> >>> <mailto:[e-mail]>> 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>;. 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>;. resolvedname
> >> 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>;.
> >> debug2: auth_rhosts2: clientuser admin hostname
> >> 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> 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> 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>”
> >
> > 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

[Vinícius Ferrão]

On 16 Oct 2019, at 16:01, Rob Crittenden
<[e-mail]<mailto:[e-mail]>> wrote:

Vinícius Ferrão wrote:


On 15 Oct 2019, at 17:49, Rob Crittenden
<[e-mail]<mailto:[e-mail]>
<mailto:[e-mail]>> wrote:

Vinícius Ferrão wrote:
Hi Rob

On 15 Oct 2019, at 10:22, Rob Crittenden
<[e-mail]<mailto:[e-mail]>
<mailto:[e-mail]>
<mailto:[e-mail]>> 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>;. 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>;. resolvedname
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>;.
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> 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> 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> 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>”

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.

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.

Thank you very much Rob.

V.

[Sumit Bose]

On Thu, Oct 17, 2019 at 04:32:05AM +0000, Vinícius Ferrão wrote:
>  
>  
>  On 16 Oct 2019, at 16:01, Rob Crittenden
> <[e-mail]<mailto:[e-mail]>> wrote:
>  
>  Vinícius Ferrão wrote:
>  
>  
>  On 15 Oct 2019, at 17:49, Rob Crittenden
> <[e-mail]<mailto:[e-mail]>
>  <mailto:[e-mail]>> wrote:
>  
>  Vinícius Ferrão wrote:
>  Hi Rob
>  
>  On 15 Oct 2019, at 10:22, Rob Crittenden
> <[e-mail]<mailto:[e-mail]>
>  <mailto:[e-mail]>
>  <mailto:[e-mail]>> 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>;. 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>;. resolvedname
>  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>;.
>  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> 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> 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> 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>”
>  
>  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?

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

HTH

bye,
Sumit

> 
> Thank you very much Rob.
> 
> V.
> 
>

[Vinícius Ferrão]

On 17 Oct 2019, at 03:52, Sumit Bose
<[e-mail]<mailto:[e-mail]>> 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
<[e-mail]<mailto:[e-mail]><mailto:[e-mail]>>
wrote:

Vinícius Ferrão wrote:


On 15 Oct 2019, at 17:49, Rob Crittenden
<[e-mail]<mailto:[e-mail]><mailto:[e-mail]>
<mailto:[e-mail]>> wrote:

Vinícius Ferrão wrote:
Hi Rob

On 15 Oct 2019, at 10:22, Rob Crittenden
<[e-mail]<mailto:[e-mail]><mailto:[e-mail]>
<mailto:[e-mail]>
<mailto:[e-mail]>> 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
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

Thanks guys...



HTH

bye,
Sumit


Thank you very much Rob.

V.

[Sumit Bose]

On Fri, Oct 18, 2019 at 05:57:40AM +0000, Vinícius Ferrão wrote:
>  
>  
>  On 17 Oct 2019, at 03:52, Sumit Bose
> <[e-mail]<mailto:[e-mail]>> 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
> <[e-mail]<mailto:[e-mail]><mailto:[e-mail]>>
> wrote:
>  
>  Vinícius Ferrão wrote:
>  
>  
>  On 15 Oct 2019, at 17:49, Rob Crittenden
> <[e-mail]<mailto:[e-mail]><mailto:[e-mail]>
>  <mailto:[e-mail]>> wrote:
>  
>  Vinícius Ferrão wrote:
>  Hi Rob
>  
>  On 15 Oct 2019, at 10:22, Rob Crittenden
> <[e-mail]<mailto:[e-mail]><mailto:[e-mail]>
>  <mailto:[e-mail]>
>  <mailto:[e-mail]>> 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.
> 
> 
>

[Vinícius Ferrão]

On 18 Oct 2019, at 03:20, Sumit Bose
<[e-mail]<mailto:[e-mail]>> wrote:

On Fri, Oct 18, 2019 at 05:57:40AM +0000, Vinícius Ferrão wrote:


On 17 Oct 2019, at 03:52, Sumit Bose
<[e-mail]<mailto:[e-mail]><mailto:[e-mail]>>
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
<[e-mail]<mailto:[e-mail]><mailto:[e-mail]><mailto:[e-mail]>>
wrote:

Vinícius Ferrão wrote:


On 15 Oct 2019, at 17:49, Rob Crittenden
<[e-mail]<mailto:[e-mail]><mailto:[e-mail]><mailto:[e-mail]>
<mailto:[e-mail]>> wrote:

Vinícius Ferrão wrote:
Hi Rob

On 15 Oct 2019, at 10:22, Rob Crittenden
<[e-mail]<mailto:[e-mail]><mailto:[e-mail]><mailto:[e-mail]>
<mailto:[e-mail]>
<mailto:[e-mail]>> 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>
<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>
<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>
<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>
<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>
<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>
<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>
<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>
<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.

I think it’s not available on my version… I’m running EL 7.6.

[root@hpclab01 ~]# sss_ssh_knownhostsproxy -k hpclab01
Usage: sss_ssh_knownhostsproxy [-?] [-?|--help] [--usage] [-p|--port INT]
        [-d|--domain STRING] HOST [PROXY_COMMAND]
unknown option[root@hpclab01 ~]# sss_ssh_knownhostsproxy -K hpclab01
Usage: sss_ssh_knownhostsproxy [-?] [-?|--help] [--usage] [-p|--port INT]
        [-d|--domain STRING] HOST [PROXY_COMMAND]
unknown option[root@hpclab01 ~]# rpm -qa | grep -i sssd
sssd-common-1.16.2-13.el7_6.8.x86_64
sssd-common-pac-1.16.2-13.el7_6.8.x86_64
sssd-ipa-1.16.2-13.el7_6.8.x86_64
sssd-ldap-1.16.2-13.el7_6.8.x86_64
sssd-1.16.2-13.el7_6.8.x86_64
sssd-krb5-common-1.16.2-13.el7_6.8.x86_64
sssd-ad-1.16.2-13.el7_6.8.x86_64
sssd-krb5-1.16.2-13.el7_6.8.x86_64
sssd-proxy-1.16.2-13.el7_6.8.x86_64
python-sssdconfig-1.16.2-13.el7_6.8.noarch
sssd-client-1.16.2-13.el7_6.8.x86_64



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.

Thanks I will do a proper RFE with everything explained and report back here.


bye,
Sumit


Thanks guys...



HTH

bye,
Sumit


Thank you very much Rob.

V.

[Vinícius Ferrão]

Guys, thank you all.

I’ve opened an issue on the SSSD page:
https://pagure.io/SSSD/sssd/issue/4106

Feel free to add anything related.

Thanks.

On 18 Oct 2019, at 03:24, Vinícius Ferrão via FreeIPA-users
<[e-mail]<mailto:[e-mail]>>
wrote:



On 18 Oct 2019, at 03:20, Sumit Bose
<[e-mail]<mailto:[e-mail]>> wrote:

On Fri, Oct 18, 2019 at 05:57:40AM +0000, Vinícius Ferrão wrote:


On 17 Oct 2019, at 03:52, Sumit Bose
<[e-mail]<mailto:[e-mail]><mailto:[e-mail]>>
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
<[e-mail]<mailto:[e-mail]><mailto:[e-mail]><mailto:[e-mail]>>
wrote:

Vinícius Ferrão wrote:


On 15 Oct 2019, at 17:49, Rob Crittenden
<[e-mail]<mailto:[e-mail]><mailto:[e-mail]><mailto:[e-mail]>
<mailto:[e-mail]>> wrote:

Vinícius Ferrão wrote:
Hi Rob

On 15 Oct 2019, at 10:22, Rob Crittenden
<[e-mail]<mailto:[e-mail]><mailto:[e-mail]><mailto:[e-mail]>
<mailto:[e-mail]>
<mailto:[e-mail]>> 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<http://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<http://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<http://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<http://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<http://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<http://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<http://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<http://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.

I think it’s not available on my version… I’m running EL 7.6.

[root@hpclab01 ~]# sss_ssh_knownhostsproxy -k hpclab01
Usage: sss_ssh_knownhostsproxy [-?] [-?|--help] [--usage] [-p|--port INT]
        [-d|--domain STRING] HOST [PROXY_COMMAND]
unknown option[root@hpclab01 ~]# sss_ssh_knownhostsproxy -K hpclab01
Usage: sss_ssh_knownhostsproxy [-?] [-?|--help] [--usage] [-p|--port INT]
        [-d|--domain STRING] HOST [PROXY_COMMAND]
unknown option[root@hpclab01 ~]# rpm -qa | grep -i sssd
sssd-common-1.16.2-13.el7_6.8.x86_64
sssd-common-pac-1.16.2-13.el7_6.8.x86_64
sssd-ipa-1.16.2-13.el7_6.8.x86_64
sssd-ldap-1.16.2-13.el7_6.8.x86_64
sssd-1.16.2-13.el7_6.8.x86_64
sssd-krb5-common-1.16.2-13.el7_6.8.x86_64
sssd-ad-1.16.2-13.el7_6.8.x86_64
sssd-krb5-1.16.2-13.el7_6.8.x86_64
sssd-proxy-1.16.2-13.el7_6.8.x86_64
python-sssdconfig-1.16.2-13.el7_6.8.noarch
sssd-client-1.16.2-13.el7_6.8.x86_64



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.

Thanks I will do a proper RFE with everything explained and report back here.


bye,
Sumit


Thanks guys...



HTH

bye,
Sumit


Thank you very much Rob.

V.




_______________________________________________
FreeIPA-users mailing list --
[e-mail]<mailto:[e-mail]>
To unsubscribe send an email to
[e-mail]<mailto:[e-mail]>
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/[e-mail]...