Closed eecsmap closed 5 months ago
I think it's reasonable opt-in feature especially given that VM ids can be random and that you might use a non standard password for the VMs.
Will it be okay to add an option to turn off the orchard account check and let the jumpbox run as anonymous service?
Please check out the new 0.21.0
release, it adds the --insecure-ssh-no-client-auth
command-line argument to orchard controller run
which enables this behavior.
Verified, it works as expected! Thanks!
First I would like to thank you for the implementation of ssh jumpbox!
I manage to setup and make it work. But not quite exactly as expected.
When I tried to substitute this new feature for the jumpbox I homemade, I realized that it requires orchard account with compute:write access. It made me start thinking my use case more.
I created orchard account to CM team to manage the services (allow jenkins server to create agents dynamically, allow dashboard to gather telemetry, etc). But I hesitate to give orchard account to users who just need to login the VM instances to debug their programs.
Before I have the homemade jumpbox, whenever a user come to me asking a way to login the VM, I will:
orchard ssh vm {their_target_vm}
to debug their programs. Sometimes they want toscp
unfortunately.Then after I build and deploy the jumpbox, user just do:
ssh -J jumpbox {user_name}@{their_target_vm}
In this way, normal user can focus on their own work without knowing anything about orchard. They don't need to install orchard. I don't need to leak any access to orchard service management. The only thing they need is just the
ssh
tool from their system, and the address:port of the jumpbox.I guess some kind of access control to the jumpbox is still valuable in some cases. But it is definitely helpful if it could be opt out.
Will it be okay to add an option to turn off the orchard account check and let the jumpbox run as anonymous service?