Bug 1544379 - ipa-client-install changes system wide ssh configuration
Summary: ipa-client-install changes system wide ssh configuration
Keywords:
Status: ASSIGNED
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: ipa
Version: 8.0
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: rc
: ---
Assignee: IPA Maintainers
QA Contact: ipa-qe
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-02-12 10:35 UTC by Ondra Machacek
Modified: 2019-12-05 14:54 UTC (History)
16 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-03-07 15:14:37 UTC
Type: Bug
Target Upstream Version:


Attachments (Terms of Use)

Description Ondra Machacek 2018-02-12 10:35:02 UTC
Description of problem:
ipa-client-install changes /etc/ssh/ssh_config, it may cause issue for system running along side with ipa client. 

It adds following line to ssh_config:

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

which is trying to execute '/usr/bin/sss_ssh_knownhostsproxy' command even with users which don't have shell, so it always fails to 'ssh'.

An example is oVirt. We execute ssh externaly with ovirt user which don't have shell. So it always fails. Please consider removing 'ProxyCommand' from ssh_config.

Version-Release number of selected component (if applicable):
ipa-client-install --version
4.6.3

How reproducible:
always

Steps to Reproduce:
1. Run ipa-client-install
2. Try to run ssh with user with /sbin/nologin shell.

Actual results:
Fail.

Expected results:
Success.

Additional info:

Comment 2 Martin Perina 2018-02-12 11:39:57 UTC
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

Comment 3 Rob Crittenden 2018-02-12 11:59:10 UTC
Have you tried installing the client with --no-ssh?

Comment 4 Ondra Machacek 2018-02-12 14:07:48 UTC
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.

Comment 5 Rob Crittenden 2018-02-12 15:42:18 UTC
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.

Comment 6 Martin Perina 2018-02-13 07:22:29 UTC
(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.

Comment 7 Rob Crittenden 2018-02-13 13:01:57 UTC
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.

Comment 9 Rob Crittenden 2018-02-16 20:55:25 UTC
Can you describe the scenario further? Who/what is doing these IPA client installations?

Comment 10 Ondra Machacek 2018-03-06 15:14:32 UTC
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'.

Comment 11 Rob Crittenden 2018-03-06 19:19:56 UTC
Ok, is there a reason you can't pass the --no-ssh option to the client installer?

Comment 12 Ondra Machacek 2018-03-07 06:50:53 UTC
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.

Comment 13 fbarreto 2018-03-07 15:14:37 UTC
Ok, closing as NOTABUG.

Comment 14 Tomáš Golembiovský 2018-08-13 09:05:29 UTC
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?

Comment 15 Sumit Bose 2018-08-16 12:32:15 UTC
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.

Comment 16 Jakub Jelen 2018-08-16 13:45:40 UTC
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?

Comment 17 Sumit Bose 2018-08-16 16:49:11 UTC
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?

Comment 18 Tomáš Golembiovský 2018-08-17 07:30:08 UTC
(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.

Comment 19 Jakub Jelen 2018-08-17 07:53:26 UTC
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

Comment 20 Sumit Bose 2018-08-17 08:25:19 UTC
Thanks again Jakub, now I really switch the ticket back to IPA.

Comment 21 Armando Biagioni Neto 2018-08-20 17:04:45 UTC
Upstream ticket:
https://pagure.io/freeipa/issue/7676


Note You need to log in before you can comment on or make changes to this bug.