Login shell does not survive reboot

[mausy5043]

I've installed bash and set the login-shell of my administrative user (admin) to it thusly:

Code Select Expand


sudo sh
chsh -s /usr/local/bin/bash admin


This works great. However, after a reboot the login-shell has changed back to /bin/csh.

This may be related but I don't consider this a problem: I also noticed that I needed to renew my SSH authorisation.

Is there a way to prevent the login-shell from reverting to the installer default?

[fabian]

This may be related but I don't consider this a problem: I also noticed that I needed to renew my SSH authorisation.

SSH keys must be stored in the user configuration.
Please note that this may change in the future.

Is there a way to prevent the login-shell from reverting to the installer default?

No, this is the expected behaviour. System users are managed by OPNsense and that is the reason why any manual change will not survive.
Shell settings must be added to the user in the GUI (legacy) system (needs some programming).

[mausy5043]

This may be related but I don't consider this a problem: I also noticed that I needed to renew my SSH authorisation.

SSH keys must be stored in the user configuration.
Please note that this may change in the future.

Yes. I transfer the SSH key using ssh-copy-id so it should end up in ~/.ssh/authorized_keys

Is there a way to prevent the login-shell from reverting to the installer default?

No, this is the expected behaviour. System users are managed by OPNsense and that is the reason why any manual change will not survive.
Shell settings must be added to the user in the GUI (legacy) system (needs some programming).

OK.  :-\

[fabian]

Yes. I transfer the SSH key using ssh-copy-id so it should end up in ~/.ssh/authorized_keys

Do it via the GUI: In Access -> Users you can paste the public key file into the text field. This will work.

[mausy5043]

Yes. I transfer the SSH key using ssh-copy-id so it should end up in ~/.ssh/authorized_keys

Do it via the GUI: In Access -> Users you can paste the public key file into the text field. This will work.

Cool. Didn't realize that. I'll give it a try.

[franco]

Users that are available on the GUI will be rewritten for consistency. The shell setting is generally possible to change, but it would require users to select a shell. It would, however, solve a problem we've been having with SFTP lately if we drop the shell privilege and instead allow the user to set a particular shell.

Have you tried to add a separate user from the command line? It may be that it is flushed on reboot, but I'm not entirely sure.


Cheers,
Franco

[franco]

PS: User shell can be manipulated here temporarily... https://github.com/opnsense/core/blob/c14000892b603a70c931aca44db01021e49d12d8/src/etc/inc/auth.inc#L442

[mausy5043]

Have you tried to add a separate user from the command line? It may be that it is flushed on reboot, but I'm not entirely sure.

I'll try that too as a test. I'm not keen on creating users that I don't need/use. They get forgotten about and become a security risk. I'll run some tests this week and will let you know.

[mausy5043]

PS: User shell can be manipulated here temporarily... https://github.com/opnsense/core/blob/c14000892b603a70c931aca44db01021e49d12d8/src/etc/inc/auth.inc#L442

I don't feel confident enough to start mucking about that deep in the code. ;D

[franco]

Well you can edit that shell pattern to get the desired result. The file is at /usr/local/etc/inc/auth.inc but overwritten by firmware updates until a permanent solution is added to the GUI. But we already have a plan. :)


Cheers,
Franco

[mausy5043]

I've created a test user with default shell /usr/local/bin/bash
While doing that I noticed that bash was not in /etc/shells. I think that's odd. Anyway, I added bash manually.


Tested a login via SSH to confirm that the user has bash as the login shell. :thumbs_up:

Rebooted.

Found that the test user nolonger exists on the system.  :(
Found that /etc/shells has forgotten about /usr/local/bin/bash   :-\

[franco]

Thanks for testing... so this is an expected recovery scenario albeit completely unwanted in your case.

Will find a way to make shells like bash coexist peacefully, but you will have to create the user from the GUI (and select the shell from there).

https://github.com/opnsense/core/issues/2154


Cheers,
Franco

[fabian]

that would be a workaround but  may do the job too. You can add the following to your SSH key:
command="/usr/local/bin/zsh" ssh-ed25519 <key data> Fabian