You can log in to the Rhino VM Automation VMs either through the primary-user’s username and password using the virtual-console of your VNFI, or through an SSH connection from a remote machine using key-based authentication.
Logging in through a virtual console
You can log in to the Rhino VM Automation VMs through a virtual-console on your VNFI, using the primary user’s username and password for authentication.
|
You should only log in to Rhino VM Automation VMs through a virtual console when SSH access is unavailable. We recommend that you log in to Rhino VM Automation VMs using SSH. |
You can configure the primary user’s password
by creating a freeform-type secret with the desired value
and setting the value of the primary-user-password-secret-id field
in the product-options section for a VNFC in the SDF
to the ID of that secret.
See Secrets in the SDF for more information.
The primary user’s password is initially configured during the VM’s bootstrap process.
You can reconfigure the primary user’s password
by changing the value of the secret in the secrets-file,
re-running csar-secrets add as per Adding secrets to QSG,
and re-uploading your configuration using rvtconfig upload-config.
If the bootstrap process fails
and you cannot log in with your desired password,
your Customer Care Representative can provide you with a password to use here.
Logging in through SSH
You can log in to the Rhino VM Automation VMs using SSH from a remote machine.
SSH access to SGC VMs uses key-based authentication only.
Username/password authentication is disabled.
To authorize one or more SSH keys so that users can log in to VMs within a VNFC
as both the primary and low-privilege users,
add the SSH public keys to the ssh/authorized-keys list
within every instance section of a VNFC within the SDF,
and then run rvtconfig upload-config.
You can also authorize SSH keys for the low-privilege viewer user only
by adding them to the low-privilege-ssh-authorized-keys list
within the product-options section for a VNFC in the SDF.
The set of authorized SSH keys can be different for each VNFC/service group,
but must be identical for all VMs within a service group.
To revoke authorization for an SSH key,
remove the public key from the authorized-keys list for all VMs within a VNFC
or from the low-privilege-ssh-authorized-keys list in the product-options section of a VNFC,
and run rvtconfig upload-config again.
All public keys within the authorized-keys list for a VM instance
will be copied to the .ssh/authorized-keys file on the VM
for both the primary user and the low-privilege viewer user.
All public keys within the low-privilege-ssh-authorized-keys list for a VNFC
will be copied to the .ssh/authorized-keys file for the low-privilege user
for all VMs within the VNFC.
A user can then use a corresponding private key to SSH into a VM
by using the command ssh -i <path-to-ssh-private-key> <username>@<vm-management-ip-address>.
You can generate a public/private SSH key pair using the command ssh-keygen.
This command will prompt you for a passphrase with which to protect the private key,
and a path to the location the private key should be created in.
The public key will be created in the same location with a .pub suffix.
|
You can set the bit length of the private key using the -b flag of ssh-keygen.
The minimum length you can use for an SSH key is 2048 bits.
We recommend using SSH keys with a length of at least 4096 bits.
|
|
It is important to keep the SSH private key secret. Ideally an SSH private key should never leave the machine it was created on. |
