[GH-ISSUE #157] Group members can connect under all target server users using the same group key #34

New issue

Open

opened 2026-05-07 00:17:55 +02:00 by BreizhHardware · 3 comments

BreizhHardware commented

2026-05-07 00:17:55 +02:00

Owner

Originally created by @deepbluemussel on GitHub (Mar 15, 2021).
Original GitHub issue: https://github.com/ovh/the-bastion/issues/157

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.

Originally created by @deepbluemussel on GitHub (Mar 15, 2021). Original GitHub issue: https://github.com/ovh/the-bastion/issues/157 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.

BreizhHardware added the

question

kept-open-for-info

labels

2026-05-07 00:17:55 +02:00

BreizhHardware commented

2026-05-07 00:17:56 +02:00

Author

Owner

@speed47 commented on GitHub (Mar 16, 2021):

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 commented on GitHub (Mar 16, 2021): 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](https://www.ovh.com/blog/the-ovhcloud-ssh-bastion-part-2-delegation-dizziness/), 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.

BreizhHardware commented

2026-05-07 00:17:56 +02:00

Author

Owner

@deepbluemussel commented on GitHub (Mar 16, 2021):

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 commented on GitHub (Mar 16, 2021): 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

BreizhHardware commented

2026-05-07 00:17:57 +02:00

Author

Owner

@speed47 commented on GitHub (Mar 19, 2021):

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 commented on GitHub (Mar 19, 2021): 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.

BreizhHardware referenced this issue

2026-05-07 00:19:41 +02:00

[PR #34] [MERGED] feat: add OpenSUSE 15.2 to the officially supported distros #183