[GH-ISSUE #137] Add admin account seem doesn't work on my bastion

BreizhHardware commented

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

Owner

Originally created by @EnzoGislard on GitHub (Feb 4, 2021).
Original GitHub issue: https://github.com/ovh/the-bastion/issues/137

Hello,

When i added a admin account thanks to the script : setup-first-admin-account.sh, i create an account but i need to put his name on the bastion.conf to setup him in admin.

But I have trouble understanding how to setup an admin account, because when I created the first admin account, each time a group was created, it had all the rights to it, if I want my other admin accounts to have all the rights to the groups already created, I have to do everything manually?

moreover when I put an account in "superowner" in the bastion.conf, it does not work (contrary to the addition in admin which works)

Excuse me for these questions which can be found their answers in the documentation: /
I may have misread or misinterpreted some explanation,

Thank you for your help,

Originally created by @EnzoGislard on GitHub (Feb 4, 2021). Original GitHub issue: https://github.com/ovh/the-bastion/issues/137 Hello, When i added a admin account thanks to the script : setup-first-admin-account.sh, i create an account but i need to put his name on the bastion.conf to setup him in admin. But I have trouble understanding how to setup an admin account, because when I created the first admin account, each time a group was created, it had all the rights to it, if I want my other admin accounts to have all the rights to the groups already created, I have to do everything manually? moreover when I put an account in "superowner" in the bastion.conf, it does not work (contrary to the addition in admin which works) Excuse me for these questions which can be found their answers in the documentation: / I may have misread or misinterpreted some explanation, Thank you for your help,

BreizhHardware closed this issue

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

BreizhHardware commented

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

Author

Owner

@speed47 commented on GitHub (Feb 8, 2021):

Hello @EnzoGislard ,

To be a bastion admin, one has to:

Be declared in the config, in the adminAccounts array
Be added to the osh-admin system group (i.e. usermod -a -G osh-admin newadminuser)
Note that, as you noticed, a bastion admin also inherits the rights of a superowner

Same goes for a superowner:

Be declared in the superOwnerAccounts array
Be added to the osh-superowner group

This has to be done directly on the server, i.e. there is no --osh command to do it: this is on purpose, as those roles have very high privileges, and are not expected to change too often, so reducing the likeliness that a catastrophic bug in the code could make someone grant themselves such privileges. This is also why the system group is needed: if for some reason you can alter the configuration of the bastion, it won't be enough to elevate your privileges.

Now, about the so-called "restricted" commands, there is one system group per command, this is the case so that you can grant such commands to somebody who is NOT an admin or a superowner, if needed. This is done through the --osh accountGrantCommand command through the bastion.

However, you would expect at least the bastion admins to be granted on those restricted commands. This is actually done by the upgrade script automatically (if a new version brings a new restricted commands, admins are automatically granted on it). If you want to grant a new admin to all those commands, you can use /opt/bastion/bin/admin/grant-all-restricted-commands-to.sh newadminuser.

Does this answer your questions? If yes, could you point out which part was unclear, so that we can adjust the documentation if needs be? Thanks!

@speed47 commented on GitHub (Feb 8, 2021): Hello @EnzoGislard , To be a bastion admin, one has to: - Be declared in the config, in the `adminAccounts` array - Be added to the `osh-admin` system group (i.e. `usermod -a -G osh-admin newadminuser`) - Note that, as you noticed, a bastion admin also inherits the rights of a `superowner` Same goes for a superowner: - Be declared in the `superOwnerAccounts` array - Be added to the `osh-superowner` group This has to be done directly on the server, i.e. there is no `--osh` command to do it: this is on purpose, as those roles have very high privileges, and are not expected to change too often, so reducing the likeliness that a catastrophic bug in the code could make someone grant themselves such privileges. This is also why the system group is needed: if for some reason you can alter the configuration of the bastion, it won't be enough to elevate your privileges. Now, about the so-called "restricted" commands, there is one system group per command, this is the case so that you can grant such commands to somebody who is NOT an admin or a superowner, if needed. This is done through the `--osh accountGrantCommand` command through the bastion. However, you would expect at least the bastion admins to be granted on those restricted commands. This is actually done by the upgrade script automatically (if a new version brings a new restricted commands, admins are automatically granted on it). If you want to grant a new admin to all those commands, you can use `/opt/bastion/bin/admin/grant-all-restricted-commands-to.sh newadminuser`. Does this answer your questions? If yes, could you point out which part was unclear, so that we can adjust the documentation if needs be? Thanks!

BreizhHardware commented

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

Author

Owner

@EnzoGislard commented on GitHub (Feb 8, 2021):

Hello @speed47 ,

Thanks a lot for your detailed answers i will test that and i will get back to you :).

For the documentation do not touch anything, I am a beginner as I said I have probably misunderstood or missed information.

If I ever find something missing I will let you know. :)

But first I will follow your answer, thank you again!

Edit : I have trouble understanding your answer, but if I want to add an admin to groups I have to give him the rights (Owner GateKeeper ACLKeeper Member) one by one for each group?

Thanks

@EnzoGislard commented on GitHub (Feb 8, 2021): Hello @speed47 , Thanks a lot for your detailed answers i will test that and i will get back to you :). For the documentation do not touch anything, I am a beginner as I said I have probably misunderstood or missed information. If I ever find something missing I will let you know. :) But first I will follow your answer, thank you again! Edit : I have trouble understanding your answer, but if I want to add an admin to groups I have to give him the rights (Owner GateKeeper ACLKeeper Member) one by one for each group? Thanks

BreizhHardware commented

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

Author

Owner

@speed47 commented on GitHub (Feb 10, 2021):

Edit : I have trouble understanding your answer, but if I want to add an admin to groups I have to give him the rights (Owner GateKeeper ACLKeeper Member) one by one for each group?

No you don't have to, being implicitly an owner/gatekeeper/aclkeeper of all bastion groups is the definition of a superowner, and a bastion admin is always implicitly a superowner. Hence, when an admin (or superowner) tries to use a command that requires owner/gatekeeper/aclkeeper rights on a group, it'll work, with a message saying that they've just used their superowner super powers, as they were not explicitly an owner/gatekeeper/aclkeeper of said group.

@speed47 commented on GitHub (Feb 10, 2021): > Edit : I have trouble understanding your answer, but if I want to add an admin to groups I have to give him the rights (Owner GateKeeper ACLKeeper Member) one by one for each group? No you don't have to, being implicitly an owner/gatekeeper/aclkeeper of all bastion groups is the definition of a superowner, and a bastion admin is always implicitly a superowner. Hence, when an admin (or superowner) tries to use a command that requires owner/gatekeeper/aclkeeper rights on a group, it'll work, with a message saying that they've just used their superowner super powers, as they were not explicitly an owner/gatekeeper/aclkeeper of said group.

BreizhHardware commented

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

Author

Owner

@EnzoGislard commented on GitHub (Feb 10, 2021):

@speed47 Thanks for your answers, so i add an admin account with the command : /opt/bastion/bin/admin/setup-first-admin-account.sh USERNAME auto then i add the account on the admin account in the /etc/bastion.conf and i add the aliases on the bashrc. but he can't connect to the servers of the different groups, i missed something ?

When i do the command : accountInfo --account myaccount, i see that all seems ok :
~ myaacount is a bastion admin
~ myaacount is a bastion superowner
~ myaacount is a bastion auditor
~ myaacount has access to the following restricted commands:
blablabla

The only difference between my first admin account and this, is the group, i don't see the group for this account, and when i wanted to try a connection to a server it didn't work. (access denied)

I'm really sorry if I misunderstood something.

Thanks

EDIT : moreover I cannot add certain servers to the bastion (by doing the classic procedure: adding the key of the bastion group in the authorized_key file) but when adding to the server with: groupAddServer, it gives me a error of the type: ~ Couldn't connect to egislard@10.10.0.201 (ssh returned error 255). Hint: did you add the proper public key to the remote's authorized_keys?
while the key is present in the file, do you know where it could come from?

@EnzoGislard commented on GitHub (Feb 10, 2021): @speed47 Thanks for your answers, so i add an admin account with the command : /opt/bastion/bin/admin/setup-first-admin-account.sh USERNAME auto then i add the account on the admin account in the /etc/bastion.conf and i add the aliases on the bashrc. but he can't connect to the servers of the different groups, i missed something ? When i do the command : accountInfo --account myaccount, i see that all seems ok : ~ myaacount is a bastion admin ~ myaacount is a bastion superowner ~ myaacount is a bastion auditor ~ myaacount has access to the following restricted commands: blablabla The only difference between my first admin account and this, is the group, i don't see the group for this account, and when i wanted to try a connection to a server it didn't work. (access denied) I'm really sorry if I misunderstood something. Thanks EDIT : moreover I cannot add certain servers to the bastion (by doing the classic procedure: adding the key of the bastion group in the authorized_key file) but when adding to the server with: groupAddServer, it gives me a error of the type: `~ Couldn't connect to egislard@10.10.0.201 (ssh returned error 255). Hint: did you add the proper public key to the remote's authorized_keys? ` while the key is present in the file, do you know where it could come from?

BreizhHardware commented

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

Author

Owner

@speed47 commented on GitHub (Feb 17, 2021):

OK I understand now, you expected admins to be implicitly members of all groups. This is not the case indeed. However, as an admin is also a superowner, and a superowner is implicitly an owner of all groups, it means that an admin can get access to any group by themselves, doing:

--osh groupAddMember --group somegroup --account theiraccountname

Doing so uses their superowner powers and grant them access to the group, even if they're not explicitly a gatekeeper of the group. This is the wanted behavior: being an admin means their manage the bastion, but it doesn't mean an admin should implicitly have access to anything behind the bastion. Now, they can actually grant themselves this right as said above, but this way it is voluntary, it triggers a log, possibly pushed to a SIEM, and may trigger an alert if the behavior is not expected in the SIEM rules ;)

About your EDIT question, several things can provoke that, you might want to check in the logs of the remote server (10.10.0.201), possibly in auth.log (or where sshd logs its errors) to see why the remote server refused the key. If this is not obvious, you might want to set a higher debug log level on the remote server (LogLevel DEBUG in sshd_config). It can be because sshd can't read the authorized_keys file, or because the user is denied in the sshd_config using DenyUsers, or a whole range of other reasons!

@speed47 commented on GitHub (Feb 17, 2021): OK I understand now, you expected admins to be implicitly members of all groups. This is not the case indeed. However, as an admin is also a superowner, and a superowner is implicitly an owner of all groups, it means that an admin can get access to any group by themselves, doing: `--osh groupAddMember --group somegroup --account theiraccountname` Doing so uses their superowner powers and grant them access to the group, even if they're not explicitly a gatekeeper of the group. This is the wanted behavior: being an admin means their manage the bastion, but it doesn't mean an admin should implicitly have access to anything behind the bastion. Now, they can actually grant themselves this right as said above, but this way it is voluntary, it triggers a log, possibly pushed to a SIEM, and may trigger an alert if the behavior is not expected in the SIEM rules ;) About your EDIT question, several things can provoke that, you might want to check in the logs of the remote server (10.10.0.201), possibly in auth.log (or where sshd logs its errors) to see why the remote server refused the key. If this is not obvious, you might want to set a higher debug log level on the remote server (LogLevel DEBUG in sshd_config). It can be because sshd can't read the authorized_keys file, or because the user is denied in the sshd_config using DenyUsers, or a whole range of other reasons!

BreizhHardware commented

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

Author

Owner

@EnzoGislard commented on GitHub (Feb 17, 2021):

Oh ok ! Thanks a lot for your answers and your help ! I understand better how the bastion works now ^^

Thank you for your help and for your understanding! I can close the ticket now and thanks for your answers about the SSH problem.

I would promote this tool which is very practical and easy to use once mastered :).

Have a good day,

Thanks,

@EnzoGislard commented on GitHub (Feb 17, 2021): Oh ok ! Thanks a lot for your answers and your help ! I understand better how the bastion works now ^^ Thank you for your help and for your understanding! I can close the ticket now and thanks for your answers about the SSH problem. I would promote this tool which is very practical and easy to use once mastered :). Have a good day, Thanks,

BreizhHardware referenced this issue

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

[PR #30] [MERGED] enh: packages-check.sh: add qrencode-libs for rhel/centos #181

Rows
Columns

[GH-ISSUE #137] Add admin account seem doesn't work on my bastion #30