Bug 2217919 - User cannot use 'virtcl ssh' command if key is not injected into VM before first boot
Summary: User cannot use 'virtcl ssh' command if key is not injected into VM before fi...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Container Native Virtualization (CNV)
Classification: Red Hat
Component: User Experience
Version: 4.13.0
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
: 4.14.0
Assignee: Tal Nisan
QA Contact: Guohua Ouyang
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2023-06-27 13:13 UTC by Avital Pinnick
Modified: 2023-08-01 05:23 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2023-08-01 05:23:08 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker CNV-30335 0 None None None 2023-06-27 13:16:03 UTC

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


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