[GH-ISSUE #361] Unable to "logout" to have your new rights applied #95

New issue

Closed

opened 2026-05-07 00:18:46 +02:00 by BreizhHardware · 11 comments

BreizhHardware commented 2026-05-07 00:18:46 +02:00

Owner

Copy link

Originally created by @airmoi on GitHub (Feb 15, 2023).
Original GitHub issue: https://github.com/ovh/the-bastion/issues/361

Hi,

Yet another one !
After a user was added to a group, he has a notice each time he tries to run a command and is unable to access hosts within that group :

❗ IMPORTANT: You have been added to new groups since the session started.
❗ You'll need to logout/login again from this interactive session to have
❗ your new rights applied, or you'll get sudo errors if you try to use them.

I tried to exit then log back again, lock the session... but it persists, how are we supposed to "logout" from an interactive session ? I couldn't find any information in the documentation

Originally created by @airmoi on GitHub (Feb 15, 2023). Original GitHub issue: https://github.com/ovh/the-bastion/issues/361 Hi, Yet another one ! After a user was added to a group, he has a notice each time he tries to run a command and is unable to access hosts within that group : > ❗ IMPORTANT: You have been added to new groups since the session started. > ❗ You'll need to logout/login again from this interactive session to have > ❗ your new rights applied, or you'll get sudo errors if you try to use them. I tried to exit then log back again, lock the session... but it persists, how are we supposed to "logout" from an interactive session ? I couldn't find any information in the documentation

BreizhHardware closed this issue 2026-05-07 00:18:46 +02:00

BreizhHardware commented 2026-05-07 00:18:47 +02:00

Author

Owner

Copy link

@speed47 commented on GitHub (Feb 15, 2023):

Hello,

You can just type "quit", or "exit", or CTRL+D, all three work to end your interactive session. You can also type "help" in the interactive session, which will give you the list of plugins, and also a few interactive-specific commands (such as "quit") :)

<!-- gh-comment-id:1431555926 --> @speed47 commented on GitHub (Feb 15, 2023): Hello, You can just type "quit", or "exit", or CTRL+D, all three work to end your interactive session. You can also type "help" in the interactive session, which will give you the list of plugins, and also a few interactive-specific commands (such as "quit") :)

BreizhHardware commented 2026-05-07 00:18:48 +02:00

Author

Owner

Copy link

@airmoi commented on GitHub (Feb 15, 2023):

I tried both exit/quit/^D commands but it remains

~ bssh --osh -i  
user@bastion> anycommand  
....  
│ ❗ IMPORTANT: You have been added to new groups since the session started.  
│ ❗ You'll need to logout/login again from this interactive session to have  
│ ❗ your new rights applied, or you'll get sudo errors if you try to use them.  
user@bastion> exit  
~ bssh --osh -i  
user@bastion> anycommand  
...
│ ❗ IMPORTANT: You have been added to new groups since the session started.
│ ❗ You'll need to logout/login again from this interactive session to have
│ ❗ your new rights applied, or you'll get sudo errors if you try to use them.
....

<!-- gh-comment-id:1431612161 --> @airmoi commented on GitHub (Feb 15, 2023): I tried both exit/quit/^D commands but it remains ```bash ~ bssh --osh -i user@bastion> anycommand .... │ ❗ IMPORTANT: You have been added to new groups since the session started. │ ❗ You'll need to logout/login again from this interactive session to have │ ❗ your new rights applied, or you'll get sudo errors if you try to use them. user@bastion> exit ~ bssh --osh -i user@bastion> anycommand ... │ ❗ IMPORTANT: You have been added to new groups since the session started. │ ❗ You'll need to logout/login again from this interactive session to have │ ❗ your new rights applied, or you'll get sudo errors if you try to use them. .... ```

BreizhHardware commented 2026-05-07 00:18:48 +02:00

Author

Owner

Copy link

@speed47 commented on GitHub (Feb 15, 2023):

Okay, so 2 things are a bit strange:

• bssh --osh -i should not work: --osh expects a plugin name as parameter (for example: bssh --osh info), and obviously -i is not a plugin name, so you should get an "Unknown command" error, instead of entering interactive session. If you did type this command and ended up in interactive session, could you paste your bssh alias, aka the output of the type bssh command?

• You definitely should not get the "you've been added to new groups" message when entering a new interactive session. I've just pushed a test branch on test-issue-361 which adds some debug, so I can better understand what's causing it on your system. It just has one commit on top of the current main branch, could you just git checkout your system to it, redo the steps where you end up with this message, and post the debug you have? A short howto follows:

On your bastion server, as root:

umask 0022
cd /opt/bastion
git fetch
git checkout test-issue-361
/opt/bastion/bin/admin/fixrights.sh

Then, enable debug mode for your account, for example if your bastion account name is "user", toggle debug this way:

/opt/bastion/bin/dev/debug_toggle.sh user on

You should then notice that you'll get far more output when using the bastion as "user".
Once you're done, to disable debug mode, use the command again but by specifying "off" instead of "on".

Don't forget to rollback the code to the version you were using previously, I'm assuming you were using the latest stable tagged version:

umask 0022
cd /opt/bastion
git checkout v3.09.02
/opt/bastion/bin/admin/fixrights.sh

The interesting part on the debug output will be there:

│ ❗ IMPORTANT: You have been added to new groups since the session started.
│ ❗ You'll need to logout/login again from this interactive session to have
│ ❗ your new rights applied, or you'll get sudo errors if you try to use them.
~ <547:/opt/bastion/bin/shell/osh.pl> list of session groups: ...
~ <547:/opt/bastion/bin/shell/osh.pl> list of current groups: ...

<!-- gh-comment-id:1431669061 --> @speed47 commented on GitHub (Feb 15, 2023): Okay, so 2 things are a bit strange: - `bssh --osh -i` should not work: `--osh` expects a plugin name as parameter (for example: `bssh --osh info`), and obviously `-i` is not a plugin name, so you should get an "Unknown command" error, instead of entering interactive session. If you did type this command and ended up in interactive session, could you paste your `bssh` alias, aka the output of the `type bssh` command? - You definitely should not get the "you've been added to new groups" message when entering a new interactive session. I've just pushed a test branch on `test-issue-361` which adds some debug, so I can better understand what's causing it on your system. It just has one commit on top of the current main branch, could you just git checkout your system to it, redo the steps where you end up with this message, and post the debug you have? A short howto follows: On your bastion server, as root: ``` umask 0022 cd /opt/bastion git fetch git checkout test-issue-361 /opt/bastion/bin/admin/fixrights.sh ``` Then, enable debug mode for your account, for example if your bastion account name is "user", toggle debug this way: ``` /opt/bastion/bin/dev/debug_toggle.sh user on ``` You should then notice that you'll get far more output when using the bastion as "user". Once you're done, to disable debug mode, use the command again but by specifying "off" instead of "on". Don't forget to rollback the code to the version you were using previously, I'm assuming you were using the latest stable tagged version: ``` umask 0022 cd /opt/bastion git checkout v3.09.02 /opt/bastion/bin/admin/fixrights.sh ``` The interesting part on the debug output will be there: ``` │ ❗ IMPORTANT: You have been added to new groups since the session started. │ ❗ You'll need to logout/login again from this interactive session to have │ ❗ your new rights applied, or you'll get sudo errors if you try to use them. ~ <547:/opt/bastion/bin/shell/osh.pl> list of session groups: ... ~ <547:/opt/bastion/bin/shell/osh.pl> list of current groups: ... ```

BreizhHardware commented 2026-05-07 00:18:48 +02:00

Author

Owner

Copy link

@airmoi commented on GitHub (Feb 15, 2023):

Hi,

My mistake, I used only -i option to log into interactive mode as stated here https://ovh.github.io/the-bastion/using/basics/first_steps.html#plugins
Here is the debug output :

│ ❗ IMPORTANT: You have been added to new groups since the session started.
│ ❗ You'll need to logout/login again from this interactive session to have
│ ❗ your new rights applied, or you'll get sudo errors if you try to use them.
~ <68983:/opt/bastion/bin/shell/osh.pl> list of session groups: bastion-users,keyfmcloud-support,mfa-totp-configd,toto,toto-tty
~ <68983:/opt/bastion/bin/shell/osh.pl> list of current groups: bastion-users,keyfmcloud-support,keytest1,mfa-totp-configd,toto,toto-tty

I just created a new group and add my user to this group then connect with this user using bssh -i to enter interactive mode then type info.
Also I figure out using bssh --osh info does not produce this message

<!-- gh-comment-id:1432048014 --> @airmoi commented on GitHub (Feb 15, 2023): Hi, My mistake, I used only `-i` option to log into interactive mode as stated here https://ovh.github.io/the-bastion/using/basics/first_steps.html#plugins Here is the debug output : > │ ❗ IMPORTANT: You have been added to new groups since the session started. > │ ❗ You'll need to logout/login again from this interactive session to have > │ ❗ your new rights applied, or you'll get sudo errors if you try to use them. > ~ <68983:/opt/bastion/bin/shell/osh.pl> list of session groups: bastion-users,keyfmcloud-support,mfa-totp-configd,toto,toto-tty > ~ <68983:/opt/bastion/bin/shell/osh.pl> list of current groups: bastion-users,keyfmcloud-support,keytest1,mfa-totp-configd,toto,toto-tty I just created a new group and add my user to this group then connect with this user using `bssh -i` to enter interactive mode then type `info`. Also I figure out using `bssh --osh info` does not produce this message

BreizhHardware commented 2026-05-07 00:18:49 +02:00

Author

Owner

Copy link

@speed47 commented on GitHub (Feb 16, 2023):

First things first, this is normal that you only get this message in interactive mode, it'll never appear anywhere else, because the issue it's warning you about can only happen in interactive mode.

Did you start the interactive session after the user was added to the group? (I think this is the case reading your message, but I want to be extra-sure).

Just to give you more context about the existence of this message: when you add some user to a bastion group, several things happen, and among those, this user is added to a Linux system group which represents the bastion group. Namely, if the bastion group is "test1", the user will be added to the system group "keytest1".

When you are in interactive mode, there's a process server-side (bastion-side) started under your Linux account user (representing your bastion user), and this process is alive as long as the interactive session is up. If you've been added to a new bastion group, your system user is added as a member of the Linux system group representing this bastion group. Under Linux, all processes running under a user that were started before the user was added as a member to a system group will NOT see that the user they're running under is now part of a new group. This is how Linux works, and AFAIK there is no way to "tell" this updated information to the already started process, i.e. the kernel will continue acting as if these preexisting processes have no access to the new group. This is also true for any new processes started by these processes (forking). The only way to "update" this information is to terminate the process and start it again (where it'll "see" the new group).

The message you're seeing is an heuristic to try to detect this case (i.e. your current user's group memberships have been changed since the interactive session was started), and it's just reminding you that if you try to use commands that do require the new memberships, these commands will fail because the interactive session doesn't have the required group memberships, as far as the Linux kernel is concerned. You have to exit and enter it again. Any other commands will work normally.

So far, I've never witnessed a system where this heuristic fails, and it seems to be the case on yours (if you confirm that you get this message even after entering a fresh interactive session). Technically, it means that the output of the command id -G -n youruser is different from the output of id -G -n (when ran as youruser), which should only be the case if you're running id -G -n from a shell that was started BEFORE you've been added to a new system group, as explained above.

What OS/distro/version are you using btw? Do you have setup anything special around the Linux user/group management, or PAM?

<!-- gh-comment-id:1433096334 --> @speed47 commented on GitHub (Feb 16, 2023): First things first, this is normal that you only get this message in interactive mode, it'll never appear anywhere else, because the issue it's warning you about can only happen in interactive mode. Did you start the interactive session *after* the user was added to the group? (I think this is the case reading your message, but I want to be extra-sure). Just to give you more context about the existence of this message: when you add some user to a bastion group, several things happen, and among those, this user is added to a Linux system group which represents the bastion group. Namely, if the bastion group is "test1", the user will be added to the system group "keytest1". When you are in interactive mode, there's a process server-side (bastion-side) started under your Linux account user (representing your bastion user), and this process is alive as long as the interactive session is up. If you've been added to a new bastion group, your system user is added as a member of the Linux system group representing this bastion group. Under Linux, all processes running under a user that were started *before* the user was added as a member to a system group will NOT see that the user they're running under is now part of a new group. This is how Linux works, and AFAIK there is no way to "tell" this updated information to the already started process, i.e. the kernel will continue acting as if these preexisting processes have no access to the new group. This is also true for any new processes started by these processes (forking). The only way to "update" this information is to terminate the process and start it again (where it'll "see" the new group). The message you're seeing is an heuristic to try to detect this case (i.e. your current user's group memberships have been changed since the interactive session was started), and it's just reminding you that if you try to use commands that do require the new memberships, these commands will fail because the interactive session doesn't have the required group memberships, as far as the Linux kernel is concerned. You have to exit and enter it again. Any other commands will work normally. So far, I've never witnessed a system where this heuristic fails, and it seems to be the case on yours (if you confirm that you get this message even after entering a fresh interactive session). Technically, it means that the output of the command `id -G -n youruser` is different from the output of `id -G -n` (when ran as youruser), which should only be the case if you're running `id -G -n` from a shell that was started BEFORE you've been added to a new system group, as explained above. What OS/distro/version are you using btw? Do you have setup anything special around the Linux user/group management, or PAM?

BreizhHardware commented 2026-05-07 00:18:49 +02:00

Author

Owner

Copy link

@airmoi commented on GitHub (Feb 16, 2023):

OS is Ubuntu 22.04, an OVH fresh install. I installed git first to clone the project and run the install process.

For more clarity, lets call the user toto

As all steps were run in the same terminal session, I logged in as admin, created the group, added toto to the group, logged off, then logged in as toto in interactive mode. This session should have been created after the user was added to the group.

However, I had connected to toto session some time before and I think this session process was never ended/killed when I exited. When I re-logged in, it seemed to reuse the old session process (which is the root cause, in my opinion, as this session was created before the user was added to the group).

As root, I performed a ps -aux | grep toto (while no interactive session was running). Here is the output:

root 110195 0.0 0.5 17056 10708 ? Ss 17:33 0:00 sshd: toto [priv]
toto 110199 0.3 0.5 17060 9988 ? Ss 17:34 0:00 /lib/systemd/systemd --user
toto 110200 0.0 0.2 104948 5108 ? S 17:34 0:00 (sd-pam)
toto 110206 0.0 0.4 17216 7984 ? S 17:34 0:00 sshd: toto@notty

I killed the two sshd processes and was able to re-login, solving the issue.

I can provide access to the bastion if you want, as it is only a test server with no sensitive data.

<!-- gh-comment-id:1433489948 --> @airmoi commented on GitHub (Feb 16, 2023): OS is Ubuntu 22.04, an OVH fresh install. I installed git first to clone the project and run the install process. For more clarity, lets call the user `toto` As all steps were run in the same terminal session, I logged in as admin, created the group, added `toto` to the group, logged off, then logged in as `toto` in interactive mode. This session should have been created after the user was added to the group. However, I had connected to `toto` session some time before and I think this session process was never ended/killed when I exited. When I re-logged in, it seemed to reuse the old session process (which is the root cause, in my opinion, as this session was created before the user was added to the group). As root, I performed a `ps -aux | grep toto` (while no interactive session was running). Here is the output: > root 110195 0.0 0.5 17056 10708 ? Ss 17:33 0:00 sshd: toto [priv] toto 110199 0.3 0.5 17060 9988 ? Ss 17:34 0:00 /lib/systemd/systemd --user toto 110200 0.0 0.2 104948 5108 ? S 17:34 0:00 (sd-pam) toto 110206 0.0 0.4 17216 7984 ? S 17:34 0:00 sshd: toto@notty > I killed the two sshd processes and was able to re-login, solving the issue. I can provide access to the bastion if you want, as it is only a test server with no sensitive data.

BreizhHardware commented 2026-05-07 00:18:49 +02:00

Author

Owner

Copy link

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

Interesting, as we don't use Ubuntu 22.04 in prod for bastions, maybe this is some new behavior on their side regarding sshd, will try to reproduce. This behavior wouldn't be catched by our integration tests (which do include Ubuntu though)

<!-- gh-comment-id:1434466984 --> @speed47 commented on GitHub (Feb 17, 2023): Interesting, as we don't use Ubuntu 22.04 in prod for bastions, maybe this is some new behavior on their side regarding sshd, will try to reproduce. This behavior wouldn't be catched by our integration tests (which do include Ubuntu though)

BreizhHardware commented 2026-05-07 00:18:50 +02:00

Author

Owner

Copy link

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

Just tried with a sandbox on Public Cloud with Ubuntu 22.04, and I can't seem to reproduce your issue. On my system, when toto disconnects, the server-side processes correctly go away (except systemd-user and sd-pam but that's expected).

Indeed the 2 processes you see after toto has disconnected should not be there, and in any case, should not be "reused" when toto connects!

Do you have a specific setup on your workstation regarding your SSH client? It seems that for some reason, the connection seems to stick after you exit. Can you check that your SSH client on your workstation has indeed completely exited when you exit interactive mode?

<!-- gh-comment-id:1434540143 --> @speed47 commented on GitHub (Feb 17, 2023): Just tried with a sandbox on Public Cloud with Ubuntu 22.04, and I can't seem to reproduce your issue. On my system, when toto disconnects, the server-side processes correctly go away (except systemd-user and sd-pam but that's expected). Indeed the 2 processes you see after toto has disconnected should not be there, and in any case, should not be "reused" when toto connects! Do you have a specific setup on your workstation regarding your SSH client? It seems that for some reason, the connection seems to stick after you exit. Can you check that your SSH client on your workstation has indeed completely exited when you exit interactive mode?

BreizhHardware commented 2026-05-07 00:18:50 +02:00

Author

Owner

Copy link

@airmoi commented on GitHub (Feb 23, 2023):

I have fig installed and also using zsh/Oh my zsh, perhaps one of these is responsible for the persistence of the session then.

I'll try to figure out which one is the culprit (if any) and also try using another "clean" workstation to see if that's the problem.

Thank you for taking the time to help me

<!-- gh-comment-id:1441685644 --> @airmoi commented on GitHub (Feb 23, 2023): I have fig installed and also using zsh/Oh my zsh, perhaps one of these is responsible for the persistence of the session then. I'll try to figure out which one is the culprit (if any) and also try using another "clean" workstation to see if that's the problem. Thank you for taking the time to help me

BreizhHardware commented 2026-05-07 00:18:50 +02:00

Author

Owner

Copy link

@airmoi commented on GitHub (Mar 9, 2023):

Finally I found the culprit !!

My .ssh/config had the ControlPersist yes option set for all server of my domain (can't remember why/when I set this)

However removing this option solves the issue

<!-- gh-comment-id:1462262031 --> @airmoi commented on GitHub (Mar 9, 2023): Finally I found the culprit !! My `.ssh/config` had the `ControlPersist yes` option set for all server of my domain (can't remember why/when I set this) However removing this option solves the issue

BreizhHardware commented 2026-05-07 00:18:50 +02:00

Author

Owner

Copy link

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

Ah, nice! Thanks for the followup!

<!-- gh-comment-id:1472649285 --> @speed47 commented on GitHub (Mar 16, 2023): Ah, nice! Thanks for the followup!

BreizhHardware referenced this issue 2026-05-07 00:19:55 +02:00

[PR #95] [MERGED] chore: checks_basic: verify that autogenerated doc is up to date #233

Sign in to join this conversation.

No Branch/Tag specified

Branches Tags

master

expifix

groupcreate_fix_uid

fix_group_gid_fast

gh-pages

clush

expiration

jsonvalidator

v3.23.01

v3.23.00

v3.22.00

v3.21.00

v3.20.00

v3.19.01

v3.19.00

v3.18.99-rc1

v3.18.00

v3.17.01

v3.17.00

v3.16.99-rc3

v3.16.99-rc2

v3.16.99-rc1

v3.16.01

v3.16.00

v3.15.00

v3.14.16

v3.14.15

v3.14.00

v3.13.01

v3.13.00

v3.12.00

v3.11.02

v3.11.01

v3.11.00

v3.10.00

v3.09.02

v3.09.00-really

v3.09.00

v3.09.00-rc3

v3.09.00-rc2

v3.09.00-rc1

v3.08.01

v3.08.00

v3.07.00

v3.06.00

v3.05.01

v3.05.00

v3.04.00

v3.03.99-rc2

v3.03.99-rc1

v3.03.01

v3.03.00

v3.02.00

v3.01.99-rc4

v3.01.99-rc3

v3.01.99-rc2

v3.01.99-rc1

v3.01.03

v3.01.02

v3.01.01

v3.01.00

v3.00.02

v3.00.01

v3.00.00

Labels

Clear labels   

answered

  

bug

  

documentation

  

enhancement

  

enhancement

  

feature

  

feature

  

kept-open-for-info

  

pull-request

Mirrored from GitHub Pull Request

  

question

No labels

answered

bug

documentation

enhancement

enhancement

feature

feature

kept-open-for-info

pull-request

question

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/the-bastion#95

No description provided.