I think it would be handy also for testing, because without a change like this one we don't have a good way of testing https://github.com/SSSD/sssd/pull/237 for example

I think it would be handy also for testing, because without a change like this one we don't have a good way of testing https://github.com/SSSD/sssd/pull/237 for example

+1

Does this need more design/discussion or is it "just" a matter of doing it now? From the Cockpit side we can work with either proposal (although I find it a bit more elegant to write to stdout instead of always touching the file system). Thanks!

I think this just needs someone to hack on the code now.

PR: https://github.com/SSSD/sssd/pull/618

• master:
  36f2fe8
  b1141e4
  49bb452

@martinpitt please let me/us know if you'd like to try a test package.

@jhrozek : Thanks! I will carve out some time to work on this in two weeks (after PTO), so if that feature is in RHEL or Fedora by then, that's fine. Otherwise I would indeed appreciate a test package. That interface looks good indeed, we can use that in cockpit-ssh.

I haven't tested libssh, but as long as it supports the proxy command, the sss_ssh_knownhostsproxy should work as well. There is nothing inherently openssh specific (I hope..)

Seeing libssh source code there is support for the proxy command, so we should be ok. Thank you.

@jhrozek : I plan to work on this tomorrow, so if you have a test package (for Fedora 28 preferably, but rhel-8 works too), I'd appreciate. Is that already in sssd 2.0 (which went to rawhide a week ago? (But this can't just be installed on F28, needs a newer glibc).

I looked at this more closely: We have some cases (particularly, direct URL login to a remote machine, like https://localhost:9090/=user@1.2.3.4/system) where cockpit checks if a host is known even before starting the ssh connection. I think (this was all before my time, and Peter left last year) the concern was to avoid tricking someone into connecting to rogue hosts by making them click on URLs with remote cockpit logins.

So under that aspect, I'm not sure if letting ssh check through ProxyCommand works or is too late. From the ssh POV it should be okay, as ssh then only talks through the proxy command and does not make a direct connection to the target host, right? So the question is if sss_ssh_knownhostsproxy also does that, i. e. if it checks the central known hosts database (for a matching host name) before initiating the TCP connection to the target host. If that is so, then we could really just use the ProxyCommand functionality. If not, i. e. it first connects to the target ssh, asks for the host key, and uses that to look up in known_hosts, then cockpit-ssh has to do the host name matching directly.

@martinpitt:

Just replying to the first paragraph: the patch is also part of the latest f28 build (https://koji.fedoraproject.org/koji/buildinfo?buildID=1138209).

@martinpitt About the mode of operation, if I understand you correctly, it's the former. sss_ssh_authorizedkeys first looks up the host based on its canonicalized hostname. If the host can't be looked up, sss_ssh_authorizedkeys returns an error, otherwise, if the host is found, it would start proxying the data.

But I was also under the impression that you were after printing the host key only?

btw as @fidencio said, you don't have to use the 2.0 release in rawhide, you can use F-28 as long as you use 1.16.3.

@jrhozek: That mode of operation would be perfect indeed, then we can use that mode in the future. But teaching all that to cockpit-ssh is a much more intrusive change, and at this point might be too intrusive for RHEL downstream, so we'll use the feature to print the host key for the time being.

Indeed I verified that the change is in latest F28. Thanks!

@jhrozek : Just letting you know that I now have cockpit-ssh working with the--pubkey option. Works very nicely, thank you! I still hope that we can make this more elegant at some day, but this will do nicely for the short term.

You're welcome, thank you for testing. If there are any specific issues you have in mind about making this more elegant, please do file a ticket so we track them somewhere.

Just thinking aloud here.

@jhrozek: So for now you can either check this with (1) sss_ssh_knownhostsproxy --pubkey $HOSTNAME or (2) ssh-keygen -F $HOSTNAME -f /var/lib/sss/pubconf/known_hosts. Both (helper program and cached file location) ought to be an internal implementation detail; (1) is not available in older distributions, but at least the helper program is in $PATH. (2) does not work right away as you first have to ensure that the cached file actually exists, and making the file name location a public API doesn't seem desirable either.

But even having to know about this mechanism (and re-implementing it in cockpit-ssh) isn't an elegant solution IMHO, as all of that should be an implementation detail. So in that sense, I don't think we should actually add anything else to sss_ssh_knownhostsproxy, the --pubkey workaround is good enough for now.

So aside from using ssh itself, there might be a more elegant mechanism with using libssh's option parsing and re-using that for known hosts checking. I need to check the new 0.8 API, perhaps it helps with that regard.

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/4568

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.