[GH-ISSUE #392] Enforce connecting with user login8 on group access server #106

New issue

Closed

opened 2026-05-07 00:19:02 +02:00 by BreizhHardware · 2 comments

BreizhHardware commented

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

Owner

Originally created by @al26p on GitHub (Apr 27, 2023).
Original GitHub issue: https://github.com/ovh/the-bastion/issues/392

Hi,

Currently there is only the possibility to connect as (any) or as a certain user with Group Access.
Having the possibility to connect as (self) would be perfect !

│ Dear aprats, you have access to the following servers:
│              IP  PORT   USER                 ACCESS-BY ADDED-BY   ADDED-AT                                COMMENT
│ --------------- ----- ------ ------------------------- -------- ---------- --------------------------------------
│    11.11.111.1    22  (self) my-group(group-member)     gadmin  2021-11-15    mysuperserver.ovh

On this example I should only be able to connect as apratson mysuperserver.ovh

Thanks for your work !

Originally created by @al26p on GitHub (Apr 27, 2023). Original GitHub issue: https://github.com/ovh/the-bastion/issues/392 Hi, Currently there is only the possibility to connect as (any) or as a certain user with Group Access. Having the possibility to connect as (self) would be perfect ! ``` │ Dear aprats, you have access to the following servers: │ IP PORT USER ACCESS-BY ADDED-BY ADDED-AT COMMENT │ --------------- ----- ------ ------------------------- -------- ---------- -------------------------------------- │ 11.11.111.1 22 (self) my-group(group-member) gadmin 2021-11-15 mysuperserver.ovh ``` On this example I should only be able to connect as `aprats`on mysuperserver.ovh Thanks for your work !

BreizhHardware

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

closed this issue
added the
feature
label

BreizhHardware commented

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

Author

Owner

@speed47 commented on GitHub (Apr 27, 2023):

Interesting, I think we can extend --user <user> and --user-any with --user-self indeed

@speed47 commented on GitHub (Apr 27, 2023): Interesting, I think we can extend `--user <user>` and `--user-any` with `--user-self` indeed

BreizhHardware commented

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

Author

Owner

@speed47 commented on GitHub (Jun 1, 2023):

So, I've implemented this feature a bit differently in cf405badfb.

The idea is that if I had implemented something like --user-self in groups, this would have implied that all accounts on the remote server would have to share the same SSH key (namely, the group's egress key).

For example if we have 5 members in a group, and these 5 members would connect remotely using their own account name as the remote user name, because an ACL targeting the remote server would have been added with --user-self, the remote server would need to have 5 Linux accounts bearing these names, all sharing the group's egress key. This is already a bad practice per se, but it also means that if one of the group's ACLKeeper later added a new ACL with --user-any targeting the same remote server (or any CIDR in which the remote server would be included), any of these 5 members could connect using any of the 5 remote accounts on the remote server, which is probably not wanted at all. This would be an error on the ACLKeepers side, but it's not extremely obvious hence I don't want to add a feature that would make it too easy to make the mistake.

So, back to the feature I've implemented instead: two new options are available in the selfAddPersonalAccess plugin: widest_v4_prefix and self_remote_user_only, the documentation is available here. You can use this to allow this command to everyone (as explained here, but setting self_remote_user_only will ensure that accounts can only add accesses with their own account name as the remote user name. widest_v4_prefix optionally helps to further prevent abuse/misuse of this.

Another option is to auto-add such accesses directly on account creation (without requiring to grant selfAddPersonalAccess to users), as explained here.

@speed47 commented on GitHub (Jun 1, 2023): So, I've implemented this feature a bit differently in cf405badfbed727bbfb4aa826f35dc268fd1160a. The idea is that if I had implemented something like `--user-self` in groups, this would have implied that all accounts on the remote server would have to share the same SSH key (namely, the group's egress key). For example if we have 5 members in a group, and these 5 members would connect remotely using their own account name as the remote user name, because an ACL targeting the remote server would have been added with `--user-self`, the remote server would need to have 5 Linux accounts bearing these names, *all sharing the group's egress key*. This is already a bad practice per se, but it also means that if one of the group's ACLKeeper later added a new ACL with `--user-any` targeting the same remote server (or any CIDR in which the remote server would be included), any of these 5 members could connect using any of the 5 remote accounts on the remote server, which is probably not wanted at all. This would be an error on the ACLKeepers side, but it's not extremely obvious hence I don't want to add a feature that would make it too easy to make the mistake. So, back to the feature I've implemented instead: two new options are available in the `selfAddPersonalAccess` plugin: `widest_v4_prefix` and `self_remote_user_only`, the documentation is available [here](https://ovh.github.io/the-bastion/plugins/restricted/selfAddPersonalAccess.html#plugin-configuration). You can use this to allow this command to everyone (as explained [here](https://ovh.github.io/the-bastion/administration/configuration/bastion_conf.html#accountcreatesupplementarygroups), but setting `self_remote_user_only` will ensure that accounts can only add accesses with their own account name as the remote user name. `widest_v4_prefix` optionally helps to further prevent abuse/misuse of this. Another option is to auto-add such accesses directly on account creation (without requiring to grant `selfAddPersonalAccess` to users), as explained [here](https://ovh.github.io/the-bastion/administration/configuration/bastion_conf.html#accountcreatedefaultpersonalaccesses).

BreizhHardware referenced this issue

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

[PR #106] [MERGED] feat: revamp logs #241