Record SSH session commands / email audit(command) history

Problem/Justification
(What is the problem you are trying to solve with this feature/improvement or why should it be considered?)

At present SSH command history is wiped at end of session

Have the option of having command history be persistent across sessions (with the option of increasing the history size)

Also/or the option to email the command history as an audit/debugging trail means that if a user has to resort to the command line for any action those assisting will have the ability to confirm that the user did not make any typos more easily and they can see the history

Impact
(How is this feature going to impact all TrueNAS users? What are the benefits and advantages? Are there disadvantages?)

The ability to see what was actually typed vs what the user thought they typed

security of seeing commands

User Story
(Please give a short description on how you envision some user taking advantage of this feature, what are the steps a user will follow to accomplish it)

My memory isn’t the greatest (ME/CFS) so having this option means I can refer back easily to what I was doing in the previous session

This is handy when you are checking what has happened after a hardware change where these is a lot of repeated commands

another use is moving into deep level directories e.g.

/mnt/Pool2/main-dir/sub/prog/data/assets/shapes/equipment/oil/drilling

The security aspect is one thing, but your User Story may be aided by simply using the shell $HISTFILE file.

In zsh that is often something like ~/.zsh_history or similar. Other shells will use different names.

I will say that the HISTFILE is not enough if the goal truly is security, as it can be tampered with if an intruder has the motivation to do so.

I see that I missed commenting on having such a command history emailed somewhere. I would recommend against that, commands can often contain sensitive information and emailing those is a security risk.

If administrative actions were take using sudo (which is typically required for something important) then we already capture the commands in our sudo audit trails.

Found one of the issues

I’m using the old admin of admin not the new truenas_admin when I ssh’ed in & found that there wasn’t any files in /home/admin

checked the permissions on the folder and discovered that the owner was root

now changed


I restored a backup DB to create this system that been upgraded from the old FreeNAS 9.X days - that’s probably part of it

The home folder is wherever you set the home folder up to be when you created the user.
This will be somewhere on your available pools, not in /home.

You can check by editing the user in the TrueNAS GUI.

It’s on /Home

I am surprised that was possible to accomplish and I question if it works as you want it to.

Does it persist through updates? The way it’s set up means it’s stored on the boot-pool, and a consequence is that it will likely not survive a complete reinstall, should you ever need to do one.