Marking as blocker because oVirt/RHV 4.2 can't add a host to cluster when engine is running on the host attached to IPA. The only workaround for this issue is to remove/comment below line in /etc/ssh/ssh_config:

 ProxyCommand /usr/bin/sss_ssh_knownhostsproxy -p %p %h

Have you tried installing the client with --no-ssh?

It may fix(In reply to Rob Crittenden from comment #3)
> Have you tried installing the client with --no-ssh?

I didn't. It may fix the issue, but I think I can't say user to do that, because he may want to install the ipa-client with ssh enabled.

It doesn't disable ssh. It disables the configuration option that is causing you grief.

From ipa-client-install(1):

       --no-ssh
              Do not configure OpenSSH client.

(In reply to Rob Crittenden from comment #5)
> It doesn't disable ssh. It disables the configuration option that is causing
> you grief.
> 
> From ipa-client-install(1):
> 
>        --no-ssh
>               Do not configure OpenSSH client.

Is there any way how to reconfigure IPA installation to remove offending SSH configuration (something like "ipa-client-config --no-ssh")? If so, it could be valid workaround for users, but I don't think so that manual edit of ssh_config is acceptable.

IPA provides no mechanism to reconfigure post-installation. The only option other than manually changing the file would be to run ipa-client-install --uninstall and then re-run ipa-client-install --no-ssh.

Can you describe the scenario further? Who/what is doing these IPA client installations?

Sorry, I missed the need_info request.

The issue is that we are executing 'ansible-playbook' command from the Java application as external proccess. So ansible-playbook command will load ssh configuration. The issue is that the Java apllication is running as user who don't have any shell - it's using /sbin/nologin, when running the ansible-playbook command as such user it fails because it can't execute '/usr/bin/sss_ssh_knownhostsproxy'.

Ok, is there a reason you can't pass the --no-ssh option to the client installer?

Well it's customer who do that. So we must instruct them to do the re-installation with --no-ssh if during oVirt installation we detect that it is configured with --ssh. Ok, I think you can close this bug. Thanks.

Ok, closing as NOTABUG.

We hit this issue again in RHV in slightly different scenario. Unfortunately reinstalling ipa-client described in comment #7 does not sound acceptable.

Is this behavior of sss_ssh_knownhostsproxy by design or a bug? If it is by design, would it be at least possible to include configuration option that would disable it?

I'll change the component to openssh to get a confirmation from the openssh maintainers that it is expected that the ProxyCommand option only works for users with a proper shell and that there is no work-around if the shell is /bin/noloing.

Manual page for ssh_config clearly says this is expected behavior:

> ProxyCommand
>       Specifies the command to use to connect to the server.  The command
>       string extends to the end of the line, and is executed using the user's
>       shell ‘exec’ directive to avoid a lingering shell process.

There is no other way how to do this function, if you want to provide a way to specify somehow rich commands with IO redirection and others.

If you need a way to work around this, I propose to use -F switch of ssh for loading your own configuration file or just use /dev/null if you do not depend on any modified configuration.



On the side note for IPA, I wanted to ask you if you could stop modifying ssh_config and use the drop-in directory in /etc/ssh/ssh_config.d/ for your modification for future releases, if you don't do that yet.

Is there anything else to resolve in this bug?

Jakub, thank you for the details. I switch the ticket back to IPA to evaluate the /etc/ssh/ssh_config.d/ suggestion. Is there /etc/ssh/sshd_config.d/ as well? Btw, it looks like /etc/ssh/ssh_config.d/ is not mentioned in the man pages.

Tomáš, would it work for you to call 'ssh -F /dev/null ....' as a workaround?

(In reply to Sumit Bose from comment #17)

> Tomáš, would it work for you to call 'ssh -F /dev/null ....' as a workaround?

Definitely not. This prevents the application that calls ssh (or scp in our case) from using any system wide configuration which is far from ideal (think e.g. of Ciphers).

We're better of installing IPA with --no-ssh. At least the inherent risks and side effects of that are more obvious.

The client side drop in directory was not announced a lot and is implemented by simple include in the main ssh_config as you can notice. This drop-in directory is unfortunately not provided by upstream out of the box and it might not work on other distributions, but we already use it for distribution modification of default configuration.

The server side sshd_config include was not yet merged upstream so it is not part of our package.

Thinking about the original problem, you (ipa) could try to use Match exec block to check the user has useful shell before setting the ProxyCommand, but this would add an overhead of one more shell invocation for every ssh invocation, which might or might not be acceptable for you. Something like this should do the job:

# assumes that if a user does not have shell (/sbin/nologin),
# this will return nonzero exit code and proxy command will be ignored
Match exec true   
        ProxyCommand /usr/bin/sss_ssh_knownhostsproxy -p %p %h

Thanks again Jakub, now I really switch the ticket back to IPA.

Upstream ticket:
https://pagure.io/freeipa/issue/7676