Bug 2084476 - The Virtual Machine Authorized SSH Key is not shown in the scripts tab.
Summary: The Virtual Machine Authorized SSH Key is not shown in the scripts tab.
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Container Native Virtualization (CNV)
Classification: Red Hat
Component: User Experience
Version: 4.11.0
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
: 4.11.0
Assignee: Ugo Palatucci
QA Contact: Guohua Ouyang
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2022-05-12 08:40 UTC by Yaacov Zamir
Modified: 2023-11-13 08:16 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-09-14 19:33:14 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github kubevirt-ui kubevirt-plugin pull 409 0 None open Bug 2084476: VM scripts tab Auth SSH Key fetch 2022-05-12 10:25:36 UTC
Red Hat Issue Tracker CNV-18209 0 None None None 2023-11-13 08:16:09 UTC
Red Hat Product Errata RHSA-2022:6526 0 None None None 2022-09-14 19:33:24 UTC

Description Yaacov Zamir 2022-05-12 08:40:53 UTC
Description of problem:
The Virtual Machine Authorized SSH Key is not shown in the scripts tab.

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


How reproducible:


Steps to Reproduce:
1. Select a VM with an authorized SSH key
2. Go in the VM details and select the scripts tab


Actual results:
The authorized ssh key is not shown

Expected results:
Be able to unlink the existing ssh key to the vm (edited) 

Additional info:
When editing a VM with exisiting secret, make sure not to create a new one if nothing changed.

Comment 1 Yaacov Zamir 2022-05-12 08:48:09 UTC
Note for verification:

vm with no previous secret:
show nothing in input box, and create new secret

vm with previous secret:
show secret content.

when saving
if nothing chnaged to nothing

if changes:
- create new secret.
   - inform user if a new secret was not created, and the old one will contiune to work
- if old secret owned by VM, delete it
   - inform user that a new secret was created, but the old one was not deleted
- if ols secret not owned by VM, don't delete it

Comment 2 Guohua Ouyang 2022-05-27 10:11:10 UTC
Adding or removing ssh key should has no impact with the existing ssh service. It should be hard to implement it and would be buggy.
If the key is changed, we should tell user to delete the ssh service and re-generate it, wdyt?

Comment 3 Yaacov Zamir 2022-05-29 15:33:15 UTC
(In reply to Guohua Ouyang from comment #2)
> Adding or removing ssh key should has no impact with the existing ssh
> service. It should be hard to implement it and would be buggy.
> If the key is changed, we should tell user to delete the ssh service and
> re-generate it, wdyt?

ssh service is not changed when ssh key change
A user need to start the vm first time to use the new key

with cloud init, you need:

a - create a vm without running it, with one key
b - check that you see the old key in the vm script tab
c - change the key, start the vm
d - check the ssh key in the vm, should be the new one.


--- 
Q1:
maybe we need to disable editing authorized key for vms that already run once vms ?
how do we know if vm already runed ?
 
Q2
we can make the authorized key work for machines already running, to make this work for an already running machine, we will need to switch to using guest agent instead of cloud-init
https://kubevirt.io/api-reference/master/definitions.html#_v1_sshpublickeyaccesscredentialpropagationmethod

but allowing users to choose qemuGuestAgent, is an RFE bug (different from this one?), because in the original design we only allowed for cloud-init.

Comment 4 Guohua Ouyang 2022-05-31 11:17:10 UTC
verified the bug on CNV-v4.11.0-423/OCP-v4.11.0-36
1. add a key which is not matching, ssh can connect to the VM, but rejected as the key is not matching
2. add a correct key, ssh to the VM is successfully

Comment 7 errata-xmlrpc 2022-09-14 19:33:14 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: OpenShift Virtualization 4.11.0 Images security and bug fix update), 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-2022:6526


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