[GH-ISSUE #585] Always try authentication using personal access #152

New issue

Open

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

BreizhHardware commented

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

Owner

Originally created by @jon4hz on GitHub (Sep 13, 2025).
Original GitHub issue: https://github.com/ovh/the-bastion/issues/585

Heya,

I noticed that The Bastion won't try to authenticate using the personal access key, if a user has access to a server through a group membership only.
However, I think it would be useful, if there was an option to always try the personal access key as well.

Considering the following scenario:

I have a fleet of - let's say - 200 servers and 20 users that need to access them. All those servers have sssd configured and fetch the personal pubkey from an LDAP using sss_ssh_authorizedkeys.
To make the access management as simple as possible, I would like to create a group my-server-admins and promote one of those 20 users to an aclkeeper, so that they can add more servers to their fleet without requiring bastion admin permissions.
However, if a user has access to a server only through a group membership, The Bastion will only try to authenticate using the group's shared ssh key - which won't work as the servers require a personal key.

With the current implementation, a bastion admin would have to adjust the personal access for all those 20 users, if there are any changes to that fleet of servers. This could be avoided simply by always trying to authenticate using the personal access key.

Originally created by @jon4hz on GitHub (Sep 13, 2025). Original GitHub issue: https://github.com/ovh/the-bastion/issues/585 Heya, I noticed that The Bastion won't try to authenticate using the personal access key, if a user has access to a server through a group membership only. However, I think it would be useful, if there was an option to always try the personal access key as well. Considering the following scenario: I have a fleet of - let's say - 200 servers and 20 users that need to access them. All those servers have `sssd` configured and fetch the personal pubkey from an LDAP using `sss_ssh_authorizedkeys`. To make the access management as simple as possible, I would like to create a group `my-server-admins` and promote one of those 20 users to an aclkeeper, so that they can add more servers to their fleet without requiring bastion admin permissions. However, if a user has access to a server only through a group membership, The Bastion will only try to authenticate using the group's shared ssh key - which won't work as the servers require a personal key. With the current implementation, a bastion admin would have to adjust the personal access for all those 20 users, if there are any changes to that fleet of servers. This could be avoided simply by always trying to authenticate using the personal access key.

BreizhHardware commented

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

Author

Owner

@speed47 commented on GitHub (Sep 17, 2025):

Hello,

This is an interesting use case, and it doesn't fit exactly in either the group-based accesses nor the personal-based accesses as you outlined.

I think I would be more comfortable having such an option as a configuration item tied to a group (i.e. something like groupModify --try-personal-keys yes|no). The change might however not be extremely trivial because the two typologies of accesses (personal/group) are really separated. I'll have a look at it though.

In the meantime, here are a few ideas that might, at least partially, answer to your use case:

A) Create a service account on the bastion, with the accountAddPersonalAccess and accountDelPersonalAccess restricted commands, and make it update the 20 users personal ACLs automatically when a server is added/removed from the fleet. This implies a bit of automation either tied to your CMDB or to your way of provisioning servers.

B) Setup your bastion.conf to add a set of personal accesses at the same time as an account is created (https://ovh.github.io/the-bastion/administration/configuration/bastion_conf.html#accountcreatedefaultpersonalaccesses), by either adding large ranges, if you happen to have pre-allocated IP blocks where you know all your servers will be provisioned, or even adding ACCOUNT@0.0.0.0/0 in this config option, basically allowing the users to try their personal key on any valid IP. This is not as scary as it sounds, as it's never password-based on the egress side (well, except if you enabled it, but that's not the case by default and is always discouraged), so at worst, your users might attempt to connect to machines on the Internet using their personal keys, but it doesn't leak any usable data as it is public/private key cryptography-based.

@speed47 commented on GitHub (Sep 17, 2025): Hello, This is an interesting use case, and it doesn't fit exactly in either the group-based accesses nor the personal-based accesses as you outlined. I think I would be more comfortable having such an option as a configuration item tied to a group (i.e. something like `groupModify --try-personal-keys yes|no`). The change might however not be extremely trivial because the two typologies of accesses (personal/group) are really separated. I'll have a look at it though. In the meantime, here are a few ideas that might, at least partially, answer to your use case: A) Create a service account on the bastion, with the `accountAddPersonalAccess` and `accountDelPersonalAccess` restricted commands, and make it update the 20 users personal ACLs automatically when a server is added/removed from the fleet. This implies a bit of automation either tied to your CMDB or to your way of provisioning servers. B) Setup your `bastion.conf` to add a set of personal accesses at the same time as an account is created (https://ovh.github.io/the-bastion/administration/configuration/bastion_conf.html#accountcreatedefaultpersonalaccesses), by either adding large ranges, if you happen to have pre-allocated IP blocks where you know all your servers will be provisioned, or even adding `ACCOUNT@0.0.0.0/0` in this config option, basically allowing the users to try their personal key on any valid IP. This is not as scary as it sounds, as it's never password-based on the egress side (well, except if you enabled it, but that's not the case by default and is always discouraged), so at worst, your users might attempt to connect to machines on the Internet using their personal keys, but it doesn't leak any usable data as it is public/private key cryptography-based.

BreizhHardware commented

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

Author

Owner

@jon4hz commented on GitHub (Sep 17, 2025):

I think I would be more comfortable having such an option as a configuration item tied to a group (i.e. something like groupModify --try-personal-keys yes|no). The change might however not be extremely trivial because the two typologies of accesses (personal/group) are really separated. I'll have a look at it though.

That would be amazing. Thanks a lot for taking a look.

A) That is definitely my plan B.
I did a little prototyping for a terraform provider that could then abstract the logic and simplify personal access configuration, but having that feature natively would obviously make things easier.

B) Unfortunately, I don't have a predefined range that I could use for this. So I'd have to configure ACCOUNT@0.0.0.0/0 which I prefer not to, as this wouldn't fit in the group based access that I'm trying to implement.

@jon4hz commented on GitHub (Sep 17, 2025): > I think I would be more comfortable having such an option as a configuration item tied to a group (i.e. something like groupModify --try-personal-keys yes|no). The change might however not be extremely trivial because the two typologies of accesses (personal/group) are really separated. I'll have a look at it though. That would be amazing. Thanks a lot for taking a look. A) That is definitely my plan B. I did a little prototyping for a terraform provider that could then abstract the logic and simplify personal access configuration, but having that feature natively would obviously make things easier. B) Unfortunately, I don't have a predefined range that I could use for this. So I'd have to configure `ACCOUNT@0.0.0.0/0` which I prefer not to, as this wouldn't fit in the group based access that I'm trying to implement.