Bug 2217919

Summary:	User cannot use 'virtcl ssh' command if key is not injected into VM before first boot
Product:	Container Native Virtualization (CNV)	Reporter:	Avital Pinnick <apinnick>
Component:	User Experience	Assignee:	Tal Nisan <tnisan>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Guohua Ouyang <gouyang>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	4.13.0	CC:	gouyang
Target Milestone:	---
Target Release:	4.14.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2023-08-01 05:23:08 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 Avital Pinnick 2023-06-27 13:13:21 UTC

Description of problem:
If a static public key is injected into a VM after it has booted for the first time, the 'virtctl ssh' command does not work.

This is, IMO, a serious problem because the SSH command is exposed in several places in the UI (VirtualMachines -> VirtualMachine details). However, if the user keeps the default Quick Create setting (start VM immediately), it is too late to add the SSH key. There is no warning in the QuickCreate modal to clear the "Start VM" checkbox if the user wants to be able to connect with virtctl SSH.

I encountered the same issue when I created a NodePort service for SSH.

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


How reproducible:


Steps to Reproduce:
1. Create a RHEL VM. (I tested both RHEL 8 and 9.)
2. Do not clear the "Boot VM after creation" checkbox.
3. After the VM is created and boots, add a static public key (new or existing secret) to the VM.
4. Reboot the VM to apply the change.
5. Copy the 'virtctl ssh' command and try to run it from the command line.

Actual results: Permission denied error.

Expected results: SSH connection works.

Additional info: Possible solution might be to disable the "Start VM" checkbox by default and add a tooltip saying that the key needs to be injected before first boot in order for SSH connection to work.

I noticed a separate issue but am not sure whether it is worth filing a bug for it. I had a VM that I could connect to using 'virtctl ssh'. I deleted the secret from my namespace and removed it from the VM. After rebooting the VM, I was still able 'virtctl ssh' to connect to the VM.

Comment 1 Avital Pinnick 2023-06-28 07:00:39 UTC

The upstream docs say that static keys are injected at startup: "The virtual machine's access credential API allows statically injecting SSH public keys at startup time independently of the cloud-init user data by placing the SSH public key into a Kubernetes Secret." (https://kubevirt.io/user-guide/virtual_machines/accessing_virtual_machines/#ssh-access). However, this is not indicated in our downstream docs or the UI. If the 'virtctl ssh' command is exposed in the VM page, then it is too late for a user to use the feature because the VM is already running. 

Perhaps the dynamic SSH keys feature will resolve the issue, but only for VMs that support that feature.

Comment 2 Guohua Ouyang 2023-08-01 05:23:08 UTC

Close the issue as it's been addressed by https://issues.redhat.com/browse/CNV-29233