Advanced SSH Capabilities
Advanced OpenSSH configurations, such as improved auditing, remote user creation, root user checking, and PAM integration
This article assumes you are familiar with various Linux internals and describes various advanced configuration options for OpenSSH. These configuration details are provided AS IS. Banyan does not provide support for these capabilities.
- Banyan JITSU Installer
- Supported Operating Systems
- Installation Steps
- SSH Access Logging
Banyan JITSU Installer
OpenSSH can be configured to run a script to generate a principals file by leveraging the
AuthorizedPrincipalsCommand option within the OpenSSH config. This is useful for more complex role-based access where having a static
principals_file for each user is not enough.
Banyan’s Just-In-Time SSH User (JITSU) provisioning and auditing script leverages the
AuthorizedPrincipalsCommand option to enable advanced SSH capabilities, such as improved auditing, remote user creation, and root user checking.
Supported Operating Systems
Currently, Banyan JITSU installer has only been tested on Ubuntu 18.04 and are actively working on testing on other Linux distros.
Step 1. Download JITSU
1.1 Download the latest release of JITSU to the
1.2 Ensure you have assumed root privileges:
user@host$ sudo su - root@host#
1.3 Download and extract the Tarball installer, and then cd into the directory:
# create folder for the Tarball mkdir -p /opt/banyan-packages cd /opt/banyan-packages # get the jitsu repo - we plan to open source this soon wget https://docs.banyanops.com/img/feature-guides/infrastructure/ssh-servers/jitsu-0.1.1.zip unzip jitsu-0.1.1.zip cd jitsu-0.1.1
Step 2. Install JITSU
2.1 Run the installer:
# run the setup script ./setup-jitsu.sh # manage using systemctl systemctl status jitsu
Step 3. Set up SSHD to Trust Banyan Certificates
3.1 JITSU expects to find the Banyan SSH CA in
/etc/ssh/banyan_ca.pub. You can find this Certificate by navigating to Settings -> Advanced Settings in the Banyan Command Center.
3.2 Paste your Banyan SSH CA in
# paste in the Banyan SSH CA vi /etc/ssh/banyan_ca.pub
Step 4. Create Root and Default Roles Files that SSHD
AuthorizedPrincipals will check
When users attempt to log in as the user named
root, JITSU will check if they have the proper roles available in their SSH Certificate against the root roles file located in
# create the root.roles file # This is a newline-separated file which lists the Banyan roles required to SSH in as a user named `root` vi /opt/banyan/root.roles
When users attempt to log in as any user not named
root, JITSU will check if they have the proper roles available in their SSH Certificate against the default roles file located in
# create the default.roles file # This is a newline-separated file which lists the Banyan roles required to SSH in as a user not named `root` vi /opt/banyan/default.roles
Step 5. Test your setup by logging in as new user
The first time you log in as a new user, you will get a message saying the new user has been provisioned “just-in-time”.
$> ssh firstname.lastname@example.org Last login: Thu Sep 17 02:55:27 2020 from ip-172-31-75-97.ec2.internal -------------------------------------------- Your user has been successfully provisioned! Please log in again to access this server. --------------------------------------------
When you try again, you will be signed in as
$> ssh email@example.com Last login: Thu Sep 17 02:55:27 2020 from ip-172-31-75-97.ec2.internal [mynewuser@ip-172-31-1-2 ~]$
Note that when
libnss-ato is enabled you cannot create users locally via
useradd. To create local users, first disable
libnss-ato by updating the config file via
cp /etc/nsswitch.conf.noato /etc/nsswitch.conf. Renable
libnss-ato when you’re done.
SSH Access Logging
The SSHD daemon logs all access from SSH clients using auditd. On Debian-based flavors of Linux, the logs are typically stored in
/var/log/auth.log. On Fedora-based flavors, logs are at
When a user logs in using their SSHCert you can see their attribute information in the logs.
Jul 3 05:15:58 gitlab-host sshd: Accepted publickey for vagrant from 18.104.22.168 port 51178 ssh2: RSA-CERT ID firstname.lastname@example.org L1HF8B12345 (serial 12344) CA RSA SHA256:LGvtbCthk48jqxuggCJKAw6stao7VDIvd2OuRipczcs Jul 3 05:15:58 gitlab-host sshd: pam_unix(sshd:session): session opened for user vagrant by (uid=0)
For more advanced audit logging, you can use Linux PAM modules. Specifically, the pam_tty_audit module can track users’ actions on the terminal and, if configured, capture the exact keystrokes the user makes, and record them in the /var/log/audit/audit.log file.
In order to use the
pam_tty_audit PAM module a system must have auditd installed.
In order to set up this PAM module to record only root user sessions (including when a user elevates to the root user using
sudo su -, a system administrator must add this line:
session required pam_tty_audit.so disable=ubuntu enable=root
at the top of the following files:
The above files are for Debian-based operating systems like Ubuntu. For Fedora-based systems (like RHEL), the line must also be added to the top of
Once this is done, the following configuration option must also be added to the SSH Daemon config at
Restart the SSH daemon after its configuration is changed.
Now all logged user keystrokes can be viewed by running
As an example, if the root user logged in an SSH session at around 11:00 o’clock and tried to issue the
pwd command, but then deleted it and issued
ls instead, the
aureport --tty output will look like this:
# aureport --tty -ts today | tail =============================================== # date time event auid term sess comm data =============================================== 40. 08/28/2014 11:00:27 901 0 ? 76 bash "pwd",<backspace>,<backspace><backspace>,"ls",<ret>,"exit",<ret>
pam_tty_audit does not support live session auditing - logs may not be visible until the user logs out. Once a user logs our, their entire session is given to auditd.
Last modified: Apr 27, 2021