Using SSH instead of su and sudo
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.