Bug 2134283

Summary:	SSH key passphrase is not working if password was set previously
Product:	Red Hat Satellite	Reporter:	matt jia <mjia>
Component:	Remote Execution	Assignee:	Adam Ruzicka <aruzicka>
Status:	CLOSED ERRATA	QA Contact:	Peter Ondrejka <pondrejk>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	6.11.3	CC:	aruzicka, pcreech
Target Milestone:	6.13.0	Keywords:	Triaged, WorkAround
Target Release:	Unused
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	rubygem-smart_proxy_remote_execution_ssh-0.8.0	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2023-05-03 13:22:16 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description matt jia 2022-10-13 05:23:00 UTC

Description of problem:

As $subject, the issue is similar to this upstream ticket:

https://community.theforeman.org/t/remote-execution-fails-to-use-ssh-key/28395

Foreman issue:

https://projects.theforeman.org/issues/34867

As mentioned in the ticket, a workaround is to explicitly set password to nil:

~~~
echo 'Setting[:remote_execution_ssh_password] = nil' | foreman-rake console 
~~~

and restart the services.


Version-Release number of selected component (if applicable):


How reproducible:

Easy

Steps to Reproduce:
1. set Default SSH password
2. set Default SSH key passphrase
3. remove Default SSH passord
4. run a REX job

Actual results:

the job hangs and sshd debug shows the last line:

Postponed publickey for xxx from xxxxx port 39250 ssh2 [preauth]

Expected results:

the job should finish successfully. 



Additional info:

Comment 1 Adam Ruzicka 2022-10-13 09:19:51 UTC

There was a limitation in smart_proxy_remote_execution_ssh in versions >=0.5.0 and <0.8.0 which prevented the users from using both password and key passphrase, if both were provided one of them "won". Sadly, an empty value was still considered a value.

smart_proxy_remote_execution_ssh-0.8.0 contains reworked connection handling, which among other things, removes the limitation mentioned above.

> and restart the services.

That should not be necessary

Comment 2 matt jia 2022-10-13 09:49:21 UTC

(In reply to Adam Ruzicka from comment #1)
> 
> smart_proxy_remote_execution_ssh-0.8.0 contains reworked connection
> handling, which among other things, removes the limitation mentioned above.

Is smart_proxy_remote_execution_ssh-0.8.0 going to be landed on Satellite 6.12?

> > and restart the services.
> 
> That should not be necessary

Yeah, but it is what happened as reported by the customer. It does seem like the password got cached somehow...

Comment 3 Adam Ruzicka 2022-10-13 09:52:46 UTC

> Is smart_proxy_remote_execution_ssh-0.8.0 going to be landed on Satellite 6.12?

That's highly unlikely, 6.12 is built around the 0.7.z line

Comment 4 matt jia 2022-10-13 10:06:57 UTC

(In reply to Adam Ruzicka from comment #3)
> > Is smart_proxy_remote_execution_ssh-0.8.0 going to be landed on Satellite 6.12?
> 
> That's highly unlikely, 6.12 is built around the 0.7.z line

Fair enough. Luckily, we have a valid workaround here, :-)

Comment 7 Peter Ondrejka 2023-01-09 14:05:24 UTC

Verified on Satellite 6.13 snap 5, rex jobs are no longer hanging in the aforementioned scenario

Comment 10 errata-xmlrpc 2023-05-03 13:22:16 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Important: Satellite 6.13 Release), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2023:2097