the-bastion icon indicating copy to clipboard operation
the-bastion copied to clipboard

Group members can connect under all target server users using the same group key

Open deepbluemussel opened this issue 3 years ago • 3 comments

Hello,

I guess this isn't a bug but just how ssh works (or maybe I just don't use OVH Bastion well).

All group members can connect under every users who use the group key on the target server.

For example a server has 3 system users and each of these users authorize the public key of a Bastion group. If one user want's to connect under one of the two other users, well, he can do it.

In the end, the connection to the servers can be traced by going back to the history from the bastion, but I still wonder about it because it's quite a suspicious behaviour.

deepbluemussel avatar Mar 15 '21 17:03 deepbluemussel

Hello,

If there are several accounts on the remote server, and these accounts should potentially not be used by the same people, then they shouldn't share the same keys. This is not bastion specific, this is how SSH works.

Group accesses are made to share the same accesses between people, with rights delegation so that teams can be independent, but in your case it sounds like, for the remote server you're talking about, people should probably use personal accesses, instead of group accesses. Indeed, each bastion user has their own set of "egress keys", that can be pushed to remote servers. These keys are specific to each account and can't be shared, so this sounds more like what you might need.

You might want to have a look at this blog post, it explains the two ways you can manage accesses (personal vs groups), most of the time, both are useful, as they answer different use cases.

speed47 avatar Mar 16 '21 16:03 speed47

Okay. I was just wondering if it was possible from the bastion to make the members of a group connect only with their respective login (option that could have been defined when creating the server in the group). It was mainly to facilitate the traceability but since we can trace the original connection on the bastion it is not a blocking point. Thank you

deepbluemussel avatar Mar 16 '21 16:03 deepbluemussel

If you want to have a better traceability while keeping group access, you can use the LC_BASTION and LC_BASTION_DETAILS environment variables that are pushed to each remote server when the bastion connects.

  • LC_BASTION bears the name of the account connecting (for legacy reasons)
  • LC_BASTION_DETAILS is a json with a lot of information you can pick from, to build a log message on the remote server

We use this in a /etc/ssh/sshrc file, which is a script launched by ssh when a user connects, this scripts gathers the information and pushes a log message to syslog, similar to this one:

Mar 19 08:57:04 bastion.example.org sshd[1424732]: Remote session: shell on pts/0 for root from 198.51.100.124 port 53534 by bastion remote user jdoe session uniqid 5fd29468d13f

With the uniqid, you can find the corresponding ttyrec and any other logs related to the session.

Note that this message can only be trusted when the "from" IP is from a bastion (in our setups, you can't ssh from anything else than a bastion), as in this case you can trust the LC_BASTION_* envvars. Otherwise, a user might craft those vars themselves, if they come from a machine they have a shell access to, and can override envvars.

speed47 avatar Mar 19 '21 09:03 speed47