Supporting the VSA without adequate access

[unsichtbarre]

Case # 08193302
We have recently been working with veeam support extensively on an issue. Our case was escalated through several tears of support and finally we are reaching some resolution.
In the process, the support agents frequently needed information or files generated from commands run as root in the console of the VSA. As it stands the VSA provides no other means of access to run commands as root or easily remove generated files from the VSA after those commands are run.
I understand security concerns, but to adequately support a system running within one's own infrastructure, you need to be able to execute commands, sometimes very long strings or scripts which are provided by veeam support agents without having to type those commands one key at a time on a VMRC. You may then need to download files from the VSA using some means more practical then mounting the live image and downloading the files from the mounted file system.
Surely, as with VMware ESXi and other hypervisors, there must be a way of securely granting the correct authorized administrators remote SSH access to the appliance with the correct permissions either as root user or using the sudoers group. Even a console switch which would place the veeamadmin user in the suitors group for a very limited period of time, would be adequate.
We plan to continue to deploy the VSA, but being able to support it adequately after this experience is becoming a concern.

Thanks,
John

[david.domask]

Hi John,

Understood on the frustration -- it is possible to enable SSH access and use a remote shell (e.g., through PuTTY); while it will still be a restricted shell, it should make running at least the diagnostic commands support requests simple.

Noted on the request about "temporarily grant veeamadmin extra permissions", I do have some concerns on this but understood on the use case. Will discuss how we can make this smoother. Root over SSH i think is not ideal (and believe it violates disa-stig), but understood that it's a clumsy process for you.

[unsichtbarre]

Hi David, in my support case, almost none of what was requested was possible in a SSH session "permission denied." Moreover, transferring customo files off the VSA is ridiculously hard. I know you are concerned with STIG's, however as ESXi is a proven use-case (STIG-able) with root SSH access in certain circumstances, certanially the VSA ought to be accessible under "certain circumstances" to perform diagnostic/recovery operations.