Using SSH instead of su and sudo

Russell Adams

2020-12-29 13:10

There are several ways to become root or another user in AIX. The most common is via su, and the second is via the open source sudo program. I recommend a third method, SSH to localhost.

Using su

su could be considered the original method for changing users. When you su to another user, you typically open a new login shell as that user (ie: su -) and then have access to any files and programs they would have. The environment is loaded in the login shell which is often required for applications.

Pros to using su:

Always installed, as it ships with AIX.
Fully supported by IBM, as it ships with AIX.
Can be used to become root or any other user, provided su is enabled for the destination account.
Logged to /var/adm/sulog
Flexible environment support, can change user with the current shell environment or open a login shell and load their environment.
Typically always available without additional configuration.

Cons to using su:

Requires plain text access to the password for the user!
This means you have to type or copy/paste the password into your session.
Typed passwords are often too short to be secure, and copy/paste exposes the password to clipboard attacks!
Groups must share plain text passwords for shared accounts (ie: DBA team and the oracle user).
Doesn't support other authentication methods than password.

su isn't going away, and is handy for things like cron jobs. It's very commonly used as root, and less common for switching between other users.

Using sudo

sudo is open source software which uses a configuration file to allow users to execute commands as other users, or open a shell as that user. This can be allowed without a password, and used for batch jobs.

Pros for using sudo:

Can be used to become root or any other user.
Can be logged to a file (not default).
Doesn't require plain text password for destination account. Prior knowledge and password sharing not required as the local user password is only being confirmed.

Cons for using sudo:

Not installed by default. Available for download from the IBM AIX Linux Toolkit.
Not supported by IBM. IBM makes sudo available in the Toolkit, however they provide no software support.
Logged to syslog by default, which is not recorded by default in AIX.
Always requires root to configure.
Still requires a plain text password to use, however typically it confirms the password of the account invoking sudo instead of the destination account.
No other authentication methods on AIX other than passwords.

sudo is frequently used in Linux, so it's a common choice across platforms even if we have to install it in AIX. It's often desirable over su for switching between non-root users.

The no password option is useful for accounts which frequently control other accounts (ie: a DBA account able to execute batch jobs as the DB daemon user without password). sudo can also be configured to allow groups of users to change to a user, for example a group called dba could all access a database superuser account (ie: oracle).

Using SSH to localhost to switch users

SSH is a practical alternative on AIX to allow a user to open a session to another user. (ie: ssh dbadmin@localhost)

Pros for using ssh:

Always installed, as it ships with AIX.
Fully supported by IBM, as it ships with AIX.
Can be used for root or any other user.
Logged to system authentication log (ie: wtmp)
Always loads user environment.
Minimal configuration by the destination user, not root.
Allows SSH keys for authentication, no passwords required!
Keys should be locked to only work from localhost, allowing secure same-system usage of password-less keys. This is similar to sudo without passwords for certain accounts.
Administrative users can access sensitive accounts like root with a secure key instead of sharing sensitive plain text passwords!
SSH accepts passwords, keys, certificates, and additional methods like smart cards and secure physical keys! Those methods are generally client side and require no additional software in AIX.
Keys can be locked by incoming IP address, and limited to execute a single command.

Cons for using ssh:

Always receive a login shell, local environment not preserved.

SSH to localhost solves many of the issues with other tools requiring plain text access to passwords across users. The usage of keys instead of passwords makes this method much more secure and less prone to error (ie: password typoes).

This can also allow better access management through the use of centrally managed SSH certificates.

Keys can be locked to only allow login from localhost (ie: passwordless cron jobs) by setting the from parameter in the user's key file $HOME/.ssh/authorized_keys as a prefix argument before the key:

from="127.0.0.1" ssh-rsa ...long key material....

Locking keys to localhost should be mandatory if the key is used for batch or passwordless access.

Keys can be locked to any source IP address, not just localhost. This can be used to help secure where a key can be used.

Finally a key can be limited to executing a single command specified by the user's authorized_keys file. This prevents the remote login from receiving a shell prompt or passing an adhoc command:

from="X.Y.Z.A",command="/usr/local/bin/backup.sh" ssh-rsa ...long key material....

This allows logins with the key only from source IP X.Y.Z.A, and the connection will trigger the backup script. No shell prompt or other commands allowed.

Be sure any scripts allowed in this manner have locking to prevent multiple executions!

Recommended solution: SSH to localhost as root

As covered in my article on SSH best practices I assert that direct logins as root over the network should be disabled. How then to become root?

I recommend that administrators use SSH keys and agents for logging into remote systems, and that they connect into an administrative non-root account (ie: admin). Once logged in, they can ssh root@localhost and use their ssh key via agent to become root. At no time is the root password needed!

There are a few configuration items to allow this method. The first is to disable root logins for SSH in /etc/ssh/sshd_config, allowing root login by key only from localhost. The second is to allow agent forwarding so that the administrator's ssh-agent is remotely accessible to authenticate root:

# You did set these right?
PermitRootLogin no
AllowAgentForwarding no

# Override on localhost to allow keys
Match Address 127.0.0.1
  PermitRootLogin prohibit-password

# Allow agents for admins
Match User admin
  AllowAgentForwarding yes

Keys on the root account don't require the from prefix parameter in root's authorized_keys file because SSHD will only allow key authentication when on the local loopback IP. Root login won't be allowed from any other network address.

Now your team of administrators can login securely to their systems as the root user with strong keys, and do not need to share and synchronize plain text passwords.

I do recommend that root passwords be kept in an enterprise password manager solution. That password may be required for maintenance or recovery operations, and should only be used on the system console.

Update: SSH's new ProxyJump directive!

Thanks to the new ProxyJump feature in OpenSSH 7.3, we can connect to a system as root in a single command:

% ssh -J myadmin@remotehost root@localhost

This is simpler than SSHing to remotehost as myadmin and then having to SSH again to root@localhost.

Root logins are still blocked to the network, and two authentication requests are still logged.