Securing Overthere SSH Hosts with SUDO

Dan Robichau

January 22, 2021 23:05

At Digital.ai we talk a lot about the value of our agentless technology. There are a lot of reasons why agents are not a good idea as follows:

Forget about the tedious process of installing agents on all of your servers.
Forget about the overhead associated with maintaining them.
Forget about the security risks that you’re relying on your vendor to identify and fix in a timely manner.

We use the same trusted technology that you would use to access your systems. On Unix that would be ssh, sudo and su. These are the industry standards for allowing secure access to your remote Unix systems. With all of the resources in the development communities for these resources, any potential security vulnerability is quickly identified and patched. The patches are quickly made available by the OS providers and your local admins apply these patches to your systems.

For security reasons, some companies and system administrators like to control access to the service accounts that applications run as. The trade-off is that some users need access to run commands as those users to administer those systems. The administrator of a system can configure sshd to prevent people from logging on to the systems as the service account. Then we need to figure out how legitimate users can gain access to the service account to do their work. This is where tools like sudo and su come in. Digital.ai Deploy can also use these techniques to gain access to the service accounts to execute deployments on these systems.

I am going to demonstrate a few of the possible configurations that can be used to fairly tightly control access to these Unix systems and allow Digital.ai Deploy to execute deployments. One of the advantages of using a tool like Digital.ai Deploy is that you can control who has access to execute deploys on the systems in your organization as well as maintaining a log of all of the actions that were done. In addition to the audit logging in Digital.ai Deploy using sudo as the gatekeeper to the service account, there is an additional audit log on the actual system where the deployments are being done.

Digital.ai Deploy SUDO Interactive Host Configuration

First, let's look at an interactive sudo configuration. We'll start by configuring a host in Digital.ai Deploy then we will look at some of the possible configurations with ssh, sudo and su. For our first set of configurations, we will use sudo in an interactive configuration. For a lot of users when they try to execute a command on a Unix system they are required to retype their password just to make sure someone has not come up to an open terminal. This way we know that the use is actually who they say they are before we allow them to sudo execute and commands. Digital.ai Deploy can emulate this type of behavior. We can configure the Connection Type for the host to be INTERACTIVE_SUDO. This means that Digital.ai Deploy will ssh to the host and execute all of the commands via sudo supplying the password as requested.

Digital.ai Deploy has a property file to configure all of the default properties of the system. For the interactive sudo the only property we need to change is the overthere.SshHost.allocateDefaultPty. This parameter makes sure there is a PTY defined for the session.

Change the <xl_deploy>/conf/deployit-defaults.properties:
#DEFAULT: overthere.SshHost.sudoCommandPrefix=sudo -u {0}
#DEFAULT: overthere.SshHost.sudoQuoteCommand=false
overthere.SshHost.allocateDefaultPty=true

Next, we need to change sudoers file to add the following:

testusr ALL=(xebia) ALL

In Digital.ai Deploy we can run a connection test to verify our configuration. By using the journalctl or some other facility based on your server's configuration you can look in the system log or sudoers log and see what commands were run using sudo. An example log is as follows:

sudo[3359]: testusr : TTY=pts/4 ; PWD=/home/testusr ; USER=xebia ; COMMAND=/bin/ls /tmp
sudo[3359]: pam_unix(sudo:session): session opened for user xebia by testusr(uid=0)
stella sudo[3359]: pam_unix(sudo:session): session closed for user xebia
sshd[3358]: Received disconnect from XXX.XXX.XXX.XXX: 11:
sshd[3352]: pam_unix(sshd:session): session closed for user testusr
systemd-logind[485]: Removed session 307.

SSH + SUDO + SU Interactive

Change the <xl_deploy>/conf/deployit-defaults.properties:

overthere.SshHost.sudoCommandPrefix=sudo su - {0} –c 
overthere.SshHost.sudoQuoteCommand=true 
overthere.SshHost.allocateDefaultPty=true

Next, we need to change sudoers file to add the following:

Cmnd_Alias XLD = !/bin/su, /bin/su - xebia -c *, !/bin/bash
testusr ALL=(ALL) NOPASSWD: XLD

In Digital.ai Deploy we can run a connection test to verify our configuration. By using the journalctl or some other facility based on your server's configuration you can look in the system log or sudoers log and see what commands were run using sudo. An example log is as follows:

sudo[656]: testusr : TTY=pts/4 ; PWD=/home/testusr ; USER=root ; COMMAND=/bin/su 
   - xebia -c ls /tmp
sudo[656]: pam_unix(sudo:session): session opened for user root by testusr(uid=0)
su[679]: (to xebia) testusr on pts/4
su[679]: pam_unix(su-l:session): session opened for user xebia by testusr(uid=0)
su[679]: pam_unix(su-l:session): session closed for user xebia
sudo[656]: pam_unix(sudo:session): session closed for user root
sshd[655]: Received disconnect from 192.168.2.20: 11:
stella sshd[648]: pam_unix(sshd:session): session closed for user testusr
stella systemd-logind[485]: Removed session 287.
stella su[29563]: pam_unix(su-l:session): session closed for user testusr

Digital.ai Deploy SUDO Host Configuration

SSH + SUDO :NOPASSWD

<xl_deploy>/conf/deployit-defaults.properties:

#DEFAULT: overthere.SshHost.sudoCommandPrefix=sudo -u {0}
#DEFAULT: overthere.SshHost.sudoQuoteCommand=false
overthere.SshHost.allocateDefaultPty=true

Sudoers:

testusr ALL=(xebia) NOPASSWD: ALL

Journalctl:

sshd[2825]: Accepted password for testusr from 192.168.2.20 port 55657 ssh2
systemd-logind[485]: New session 302 of user testusr.
systemd[1]: Starting Session 302 of user testusr.
systemd[1]: Started Session 302 of user testusr.
sshd[2825]: pam_unix(sshd:session): session opened for user testusr by (uid=0)
sshd[2830]: Received disconnect from 192.168.2.20: 11:
sshd[2825]: pam_unix(sshd:session): session closed for user testusr systemd-logind[485]
   : Removed session 302.
sshd[2950]: Accepted password for testusr from 192.168.2.20 port 55658 ssh2
systemd-logind[485]: New session 303 of user testusr.
systemd[1]: Starting Session 303 of user testusr.
systemd[1]: Started Session 303 of user testusr.
sshd[2950]: pam_unix(sshd:session): session opened for user testusr by (uid=0)
sudo[2956]: testusr : TTY=pts/4 ; PWD=/home/testusr ; USER=xebia ; COMMAND=/bin/ls /tmp
sudo[2956]: pam_unix(sudo:session): session opened for user xebia by testusr(uid=0)
sudo[2956]: pam_unix(sudo:session): session closed for user xebia
sshd[2955]: Received disconnect from 192.168.2.20: 11:
sshd[2950]: pam_unix(sshd:session): session closed for user testusr
systemd-logind[485]: Removed session 303.

SSH + SUDO + SU :NOPASSWD