Sudo vs ssh/pka to access root

Proposal:

Use secure shell (ssh) with public key authentication (pka) to directly access root and other privileged accounts on UNIX

The standard paradigm to control access to the root and other sensitive accounts on UNIX systems utilizes personal accounts for administrative personnel, passwords, and sudo. While generally accepted, this approach has significant vulnerabilities that can be circumvented via ssh using pka. Additional procedures and scripts can be put in place to further enhance the security of pka access to privileged accounts - something that's difficult and/or impossible to do with sudo access.

Who am I?

I was a Russian Linguist in the United States Air Force for 12 years during which time I held elevated security clearances. The importance of communications, information, operations, and computer security was continually impressed upon me. In 1987, I took over supervision of the Small Computer Support Branch for my military unit. In that role, I wrote and implemented most of the regulations, policies, and procedures for computer security for my unit and wing. Additinally, I had significant input into the regulations of the Electronic Security Command. In my civilian career, I've generated security policies for two companies and conducted UNIX security audits for numerous clients. I am also a (EC-Council) Certified Ethical Hacker and (ISC2) Certified Information System Security Professional (CISSP). Security in general and computer security in particular has been an integral part of my entire adult life.

Background

There are two very valid reasons for prohibiting direct password-based access to root and other privileged accounts: authentication and non-repudiation.

1. Authentication: Authentication is the process through which information is obtained and verified before authorizing access to specific resources. For the purposes of this document, those resources are the root and other sensitive accounts on the UNIX systems.
   

   There are three factors of authentication

   1. Something you know
   2. Something you have
   3. Something you are

   The validitiy and trust in the authentication process increases with the number of factors employed.

   Password based authentication, be it telnet, ssh, or web based, is single factor authentication. You know the password.

   Most people that work in reasonably large companies are familiar with the secure ID tokens used for remote access to the company network. These employ 2-factor authentication as you have the token and know the PIN that enables it.

   ssh/pka is also 2-factor authentication as you have the private key and know the passphrase to it.

   The third factor is generally classified as biotmetrics (retinal scans, finger prints, etc) and isn't widely used in the civilian community for authentication yet.

2. Non-repudiation: With respect to computer security, repudiation refers to a user's ability to refuse responsibility for activities done with his or her account. Non-repudiation, therefore, refers to all policies, procedures, and technical constraints which would limit a user's ability to refuse that responsibillity.

Root access model comparisons:

1. sudo access: As stated, the commonly accepted paradigm is to have the UNIX admin log into a system using his or her personal account, then execute sudo su - or something similar to gain root authority. The intent of this process is to have the admin authenticate twice - once for the personal account and again for root. Since this is strictly password based (1-factor) authentication, it suffers from a number of weaknesses:
   1. Passwords are crackable: On most major variants of UNIX, passwords can be up to 255 characters; however, only the first eight are sigificant. This reduces the possible complexity of passwords to something that can be identified via brute force attacks. In 1987, I calculated that it would take 1,973 years to crack my password. Today, using a desktop PC, that would take approximately three weeks. Additionally, programs are readily available that will attempt to identify passwords via dictionary attacks. At one particular client, I was able to crack 87% of the accounts, including several admin accounts with sudo access to root, using these programs.
   2. Passwords are interceptable: telnet and ftp both transmit the password to the remote host in the clear. This means that anyone with a network sniffer can easily intercept the password.
   3. There's only one authentication: Despite the intent, the current paradigm effectively authenticates the user only once. While there are two separate password checks, it's the exact same password in both cases. If the intent is truly to force two separate authentications, then sudo access to root should be disabled in favor of entering the root password via a su command. This, however, raises a host of other security concerns.
   4. Possibly not even one authentication: During security audits, I routinely find the NOPASSWORD option in use in sudo configurations. This removes the second password check for the admin account to gain root privileges. Now, the black hat doesn't even need to know the admin's password - he just has to find an open terminal.
   5. Access removal isn't automatic: During one security audit, I found an admin, gone from the company for at least six months, referenced in sudoers file for 33 systems.
   6. Post employment activity isn't flagged: If someone were to gain access to one of the systems referenced above, he would automatically have access to the root account. Nothing would get flagged because, according to the configuration files, the access is perfectly valid.
   7. Weak authentication/non-repudiation: For all the reasons speicified above, the authentication process using sudo is weak. Since password based authentication is inherently weak, a user can easily and believably say "That wasn't me" when presented with evidence of account malfeasance
2. ssh/pka: Through a deceptively simple mathmatical formula, ssh authenticates systems against a list of known hosts, then sets up an encrypted tunnel between the client and the server. All this happens before a password or public key authentication sequence begins which is one of the biggest reasons for using ssh over telnet and scp/sftp over ftp. With pka, passphrases are not transmitted to the authenticating host. Instead, the same process for host authentication is used to authenticate the user. Even if the black hats had a network sniffer or a remote system had a key logger program running, a user could log in with complete security as neither a password nor a passphrase are ever sent. While no security model is completely foolproof, ssh/pka eliminates many of the weaknesses of password based authentication:
   1. 2-factor authentication: As stated, pka users must have a private key and know the passphrase to it. Access or knowledge of only one of these items does the black hat no good. This increases the security of the authentication process and reduces the ability of users to deny responsibility for their actions.
   2. pka is not prone to password/passphrase cracking attackes: Effectively, passphrases are the passwords to the private key. Passphrases can be up to 255 characters and are significant the entire length. While I doubt my passphrase would take upwards of 2000 years to crack, I'm confident the length of time to do so is back in the realm of years instead of weeks.
   3. ssh/pka configuraiton is complex: There literally is no way to accidentally configure ssh/pka access to a system. There are a number of steps that must be completed accurately before ssh/pka access to a specific key is possible. This greatly reduces the ability of users to repudiate their actions. Since root passwords are generally shared across systems, an admin could "accidentally" access a system for which he has no legitimate need. There is no such possibility using ssh/pka.
   4. pka is secure: pka is the core technology used for digital signatures and openssl, the technology that implements secure web sites for banking, online shopping, and auctions. All of these online activities would be impossible if there were not a reasonable level of faith in the level of non-repudiation supplied by pka.
   5. With some minor modifications to the default configuration, ssh logs the same or more information than does sudo. For example, this entry shows me sudo'ing into root on myhost:
      

      Jan  1 13:26:55 2008 : oleary : HOST=myhost : TTY=pts/0 ;
          PWD=/home/dkoleary/working/ssh/comparison ; USER=root ; COMMAND=/usr/bin/su -

      That shows date and time, who I am, what target ID I accessed, and the command I used. This log entry does not show what system I accessed myhost from, however. While a detailed analysis of the log files would identify that, it would take some additional time.

      Conversely, the ssh/pka access logs entries:

      Jan  1 13:30:51 myhost sshd[143]: Connection from 192.168.12.26 port 51798
      Jan  1 13:30:51 myhost sshd[143]: Failed none for root from 192.168.12.26 port 51798 ssh2
      Jan  1 13:30:51 myhost sshd[143]: Found matching DSA key: c2:dc:f6:dc:29:2a:86:24:f4:6c:c5:d0:61:90:a5:f3
      Jan  1 13:30:52 myhost sshd[143]: Accepted publickey for root from 192.168.12.26 port 51798 ssh2
      Jan  1 13:30:52 myhost sshd[143]: Found matching DSA key: c2:dc:f6:dc:29:2a:86:24:f4:6c:c5:d0:61:90:a5:f3
      Jan  1 13:30:52 myhost sshd[143]: Connection closed by 192.168.12.26
      

      These log entries too show date, time, target account. They also show the system that I accessed myhost from which would enable quicker tracing of the access back to its source. Using the default configuration, it could be somewhat more difficult to identify the user; however, with a minor modification, that too is easily done:

      # ssh-keygen -l -f ./dkoleary_laptop.pub
      1024 c2:dc:f6:dc:29:2a:86:24:f4:6c:c5:d0:61:90:a5:f3 ./dkoleary_laptop.pub

      Note that the key fingerprints match exactly.

Required/suggested modifications:

As discussed above, ssh/pka provides greatly improved security authentication and can log the same information as does sudo. There are four actions required to enable that level of security, two optional ones to improve the maintenance of the ssh/pka environment and two additional scripts can be implemented to further enhance the automation of access removal and post employment access alerts.

1. required: sshd_config must be modified to enable SyslogFacility (normally auth) and LogLevel must be set to VERBOSE. These settings enable syslog to log the fingerprints of the key pair used for access.
2. required: PermitRootLogin must be set to without-password to prevent password based authentication into root and allow pka. On most installations of openssh, it defaults to yes which also enables password authentcation. Ssh password authentication suffers from the same weaknesses as any other password based authentication process.
3. required: Solaris systems don't typically log auth.info events. In order to record the key fingerprints, syslog.conf must be updated appropirately.
4. required: Secure shell, regardless of authentication mechanism, enables remote command execution. While this greatly enhances an admin's abiilty to do his or her job, it's equally important to log what commands are being executed. This is easily done through the use of forced commands which are run regardless of what the user enters on the command line and are thus perfect for logging the commands that admins run remotely. For example:
   

   $ ssh myhost ls -ld /tmp
   drwxrwxrwt  69 bin        bin          24576 Jan  4 08:32 /tmp
   $ ssh myhost tail -15 /var/adm/syslog/syslog.log
   Jan  4 08:30:49 myhost inetd[19731]: registrar/tcp: Connection from myhost (192.168.12.24) at Fri Jan  4 08:30:49 2008
   Jan  4 08:32:19 myhost sshd[19794]: Connection from 192.168.12.24 port 62633
   Jan  4 08:32:20 myhost sshd[19794]: Failed none for root from 192.168.12.24 port 62633 ssh2
   Jan  4 08:32:20 myhost sshd[19794]: Found matching DSA key: c2:dc:f6:dc:29:2a:86:24:f4:6c:c5:d0:61:90:a5:f3
   Jan  4 08:32:20 myhost sshd[19794]: Accepted publickey for root from 192.168.12.24 port 62633 ssh2
   Jan  4 08:32:20 myhost sshd[19794]: Found matching DSA key: c2:dc:f6:dc:29:2a:86:24:f4:6c:c5:d0:61:90:a5:f3
   Jan  4 08:32:20 myhost syslog: ssh/pka executed ls -ld /tmp
   Jan  4 08:32:20 myhost sshd[19794]: Connection closed by 192.168.12.24
   Jan  4 08:32:20 myhost sshd[19794]: Closing connection to 192.168.12.24
   Jan  4 08:32:35 myhost sshd[19807]: Connection from 192.168.12.24 port 62634
   Jan  4 08:32:36 myhost sshd[19807]: Failed none for root from 192.168.12.24 port 62634 ssh2
   Jan  4 08:32:36 myhost sshd[19807]: Found matching DSA key: c2:dc:f6:dc:29:2a:86:24:f4:6c:c5:d0:61:90:a5:f3
   Jan  4 08:32:36 myhost sshd[19807]: Accepted publickey for root from 192.168.12.24 port 62634 ssh2
   Jan  4 08:32:36 myhost sshd[19807]: Found matching DSA key: c2:dc:f6:dc:29:2a:86:24:f4:6c:c5:d0:61:90:a5:f3
   Jan  4 08:32:36 myhost syslog: ssh/pka executed tail -15 /var/adm/syslog/syslog.log
   

   The underlined/bold lines show the commands I ran and that they're reflected in the system's syslog.

   This functionality is enabled by setting an option in the public key:

   command="/root/bin/sshroot" ssh-dss AAAAB3NzaC1kc3MAAACBALKnuTrmoeO6X1TI6gWSq5ysxx [[ LOTS snipped ]]

   Regardless of what's entered on the command line, ssh will execute /root/bin/sshroot. That script logs the commands via the logger command and then runs the commands as requested. The script is available here

5. optional: Develop a process for key management

   openssh keeps all authorized public keys in one file - one very long public key per line:
   

   command="/root/bin/sshroot" ssh-dss AAAAB3NzaC1kc3MAAACBALKnuT
   rmoeO6X1TI6gWSq5ysxx+BzufrbfZGRcZTAZgVTityx4I+vpP6U+IveSH+gqbgkSCjD
   P6g1Jl64IIAYEchMBpIl1Kx6reEzJlAM9FQk/FhAt2EJQaiyhVq4R5FBf8E2WRJTBHx
   KdBEMiNTae+/1VNhpFURDBCozcU0e2Z7AAAAFQC5ORw9d7+dSMNkfY38InxUYsnCWQA
   AAIEAk3uSlj0421cRkdvgd8TFdlA0uGYb9UxV8/oJb8TboKeoebNldqXQxQzf+bJBAr
   7OEd9fMZzsdjQYslf5kWB04Fi9mC3ZVMviQfDzG/Qy34JodaZGMtQmhpYwPV3O85KiB
   79rhM3PafcwGc1NwkoJkw0yMg+Dx7jPKi8aiC3+QF8AAACAJEeK+UjoOZHdLTP4/jKd
   ttpGNCPS/dieXwANT4rj7uavXRoezP+GY/JvKGw2q6UVjvCZ79nkjgBOK4LktSE2QqW
   usR/6wmV67SbqqjGrOHw0NT72gxuOEV+THI45cwcLwQSiw/SBsXXPEdlXRYRPFDo0r0
   kqLlzMhOQIDDukRIE= dkoleary@myhost.com

   That's one line. In a generic/default environment, if an admin were to leave the company, we would have to edit the authorized_keys file on each system individually, search for the correct key, and delete it. Many iterations of that and you have yourself an official unholy nightmare.

   One way around this issue is to use cfengine which is a software product that helps centralize management of files across an enviornment. Cfengine configuration is way beyond the scope of this document; however, if used, removing a key could be as simple as editing one file and waiting for the next cfengine run - typically every half an hour

   On systems that aren't cfengine managed, I maintain each key authorized to a specifc account in a separate file under ~/.ssh/pub_keys

   admin1_myhost.pub
   dkoleary_laptop.pub
   admin2.pub

   Recreating the authorized_keys file is easy:

   cd ~/.ssh/pub_keys
   cat *.pub > ../authorized_keys
   

   Adding or deleting access is a simple matter of copying in or deleting the appropriate key file, then running those two commands.

6. optional: Set a daemon process to watch the log files for unauthorized finger prints. This can be as simple as grep'ing key finger prints against a local list.

   At one client, I configured a centralized logging server on a management node. Using syslog-ng on the management node, I sent any lines with sshd in them through a script filter called ssh_logger which would compare the fingerprints against a cfengine managed file of key fingerprints. If there was was not a match or a match but an unauthorized access, the script would automatically page out to the on call SA. All of the SAs would receive an email in the morning showing who accessed their systems.

7. optional: Set public key files to a root controlled directory. While this nominally increases the work load on the SA, it does prevent people from providing access to the system without the SA's knowledge. This also greatly enhances the ease of cfengine management of public keys. I've typically used /etc/ssheksys as the location for these files.

ssh/pka concerns

No security model is perfect and ssh/pka does have it's share of items over which to be concerned.

First and foremost, utilizing this model effectively moves some of the authentication off of the target system. Some admins are known to use null passphrased keys as their default, interactive keys. If you do this, you are putting your root account at risk. If you regularly leave your terminal unlocked, you are putting your root account at risk.

There are ways around some of these concerns; however, the cost of implementing thse can increase rather dramatically and very quickly.

My typical concern is that the SAs will use null passphrased keys. You can test for a null passphrased key by obtaining a copy of the private key and attempting to add it into an ssh-agent command. If it loads without asking for a passphrase, then the SA is using a null passphrased key.

If you implement that, though, the SA may simply put a passphrase on the key, provide a copy, then remove the passphrase again. You can get around this by setting up a management node and configuring the sshd on each host to accept ssh connections only from that management node. On that management node, you can then scan for private keys and attempt to add them to an ssh-agent procss as described above.

So, what happens if your management node crashes? You have just lost ssh access to your entire environment. You can get around this by clustering the management node or by configuring several management nodes.

Hopefully, it's obvious by now that there are always ways to address security concerns; however, ever time you address one concern, you're opening up possibilities of others.

I generally suggest that the concern of null passphrased keys be addressed through education. If I see someone using a null passphrased key, I tell them why its a bad idea and how they can get the exact same ability through the use of ssh-agents.

A second concern is that this level of access can be dangerous for inexperienced or careless administrators. Running the following loop will result in a very long and very bad day:

for h in $(cat list-o-hosts)
do
   echo ${h}
   ssh -l root ${h} rm /etc/shadow
done

I actually saw an admin doing that. Fortunately, I was able to stop him before he hit the final enter and I was able to have my heart attack in peace.

There really is no sure way around inexperience or carelessness. Every time you make something idiot proof, nature develops a better idiot.

Summary

From a security viewpoint, particularly relating to authentication and non-repudiation, ssh/pka is inherently superior to any form of password authentication. With some modifications and scripting, it can provide for automatic access removal and invalid access attempt alerts, something that is difficult, if not impossible to do with the password/sudo access paradigm.

Feel free to contact me at dkoleary@olearycomputers.com with any questions, comments, or concerns.