This is the follow up of https://bugzilla.redhat.com/show_bug.cgi?id=2081182#c4
and https://bugzilla.redhat.com/show_bug.cgi?id=2081182#c5


+++ This bug was initially created as a clone of Bug #2081182 +++

Description of problem:
Under the details page of a VM with SSH exposed there is a User credentials section with a copy to clipboard button specifying an ssh command in the form:

ssh user@api-hostname -p <nodeport>

In the case of my IPI installed baremetal cluster, this never works for me. The api VIP is grabbed by the control plane and attempts to reach nodeports on that IP fail. If I change to a worker node's hostname or IP, it will work. 

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

How reproducible:
Always 

Steps to Reproduce:
1. Create VM from template (e.g. Fedora) using wizard
2. Select checkbox to expose SSH to the VM
3. Follow through to create VM and select details page.
4. Copy and attempt to use User credentials ssh command

Actual results:
Timeout

Expected results:
Ssh connection to VM

Additional info:
Several others have run into this as well. I am not sure whether it is an IPI only problem.

--- Additional comment from Aviv Turgeman on 2022-06-02 16:50:19 CST ---

moving back to 'ASSIGNED' as fix is not good

--- Additional comment from Guohua Ouyang on 2022-06-09 18:04:10 CST ---

verified on OCP-v4.11.0-47
The ssh command looks like: ssh test.uit-411-dev.cnv-qe.rhcloud.com -p 31837
and the ssh connection works from command line

--- Additional comment from errata-xmlrpc on 2022-06-10 13:37:56 CST ---

This bug has been added to advisory RHEA-2022:88137 by CPaaS, owned by Greg Allen (contra-dev/pipeline)

--- Additional comment from Fernando Lozano on 2022-07-23 03:08:48 CST ---

The default behavior of exposing SSH access to VMs using NodePort services is just not guaranteed to work. Switching from the API address/hostname to any other node might be a workaround for some customers and not work at all for others. Many customers all block ports other than the API and Ingress controller to all cluster nodes and that makes any NodePort service inaccessible.

This is not an issue created by OpenShift Virtualization and IMHO it is very misleading that the product UI offers that alternative. It creates an expectation that it "should work" when it should not, at least in environments configured according to hardneded security. We should educate our users better about the caveats of that setting and offer alternatives not only in product docs but also int the product's UI.

Unfortunately there's no alternative that guaranteed to work everywhere, at least not with the current supported OpenShift 4.10 product and I guess not even with the next EUS release 4.12. Which makes it even more important to provide caveats and alternatives in the product's UI and docs.

--- Additional comment from Yaacov Zamir on 2022-07-27 15:30:20 CST ---

(In reply to Fernando Lozano from comment #4)
> The default behavior of exposing SSH access to VMs using NodePort services
> is just not guaranteed to work.

Yes, my concern is that we do want to give this functionality * if it's set up on user cluster *
IMHO best we can do is notify users that this "REQUIRES CLUSTER NETWORK SETUP" to support this feature, and link to documentation. 

> Switching from the API address/hostname to
> any other node might be a workaround for some customers and not work at all
> for others.

Yes, IMHO prominent help text, saying this requires specific network setting to work will help here.

> This is not an issue created by OpenShift Virtualization and IMHO it is very
> misleading that the product UI offers that alternative. It creates an
> expectation that it "should work" when it should not

Documentation and in-the-UI help text that explains things can help

> Unfortunately there's no alternative that guaranteed to work everywhere, at
> least not with the current supported OpenShift 4.10 product and I guess not
> even with the next EUS release 4.12. Which makes it even more important to
> provide caveats and alternatives in the product's UI and docs.

Guohua hi,

we currently inform users that accessing SSH using "node port" require specific network/firewall settings, when they enable the service.
does it makes sense to add help notification + docs link near the "copy ssh command" as well?

cc:// Fernando

--- Additional comment from Guohua Ouyang on 2022-07-27 16:03:05 CST ---

(In reply to Yaacov Zamir from comment #5)
> (In reply to Fernando Lozano from comment #4)
> > The default behavior of exposing SSH access to VMs using NodePort services
> > is just not guaranteed to work.
> 
> Yes, my concern is that we do want to give this functionality * if it's set
> up on user cluster *
> IMHO best we can do is notify users that this "REQUIRES CLUSTER NETWORK
> SETUP" to support this feature, and link to documentation. 
> 
> > Switching from the API address/hostname to
> > any other node might be a workaround for some customers and not work at all
> > for others.
> 
> Yes, IMHO prominent help text, saying this requires specific network setting
> to work will help here.
> 
> > This is not an issue created by OpenShift Virtualization and IMHO it is very
> > misleading that the product UI offers that alternative. It creates an
> > expectation that it "should work" when it should not
> 
> Documentation and in-the-UI help text that explains things can help
> 
> > Unfortunately there's no alternative that guaranteed to work everywhere, at
> > least not with the current supported OpenShift 4.10 product and I guess not
> > even with the next EUS release 4.12. Which makes it even more important to
> > provide caveats and alternatives in the product's UI and docs.
> 
> Guohua hi,
> 
> we currently inform users that accessing SSH using "node port" require
> specific network/firewall settings, when they enable the service.
> does it makes sense to add help notification + docs link near the "copy ssh
> command" as well?

Any improvement here works for me, let me clone the bug to 4.12 for further investigation or discussion
> cc:// Fernando