Tips for Deploying Secure Shell in Linux and UNIX

Monday, January 10, 2011

Jamie Adams

4085079c6fe0be2fd371ddbac0c3e7db

There is no doubt that the de facto technology to gain remote command line access is through Secure Shell on Linux and UNIX systems.

While there are numerous security guidelines suggesting many different configuration settings, I think there are some fundamentals which are missed.

Secure Shell is, in my opinion, the best method for remote access due to its flexibility and security. It makes it attractive for system administrators as well as system developers and architects. The ability to easily execute commands on remote systems and retrieve files over “secure” channels is seductive. Especially, since there is little-to-no programming required to facilitate this. However, in my opinion, this should be done with caution.

First of all, Secure Shell (SSH) is a network protocol that allows data to be exchanged using a secure channel between two networked devices.1 SSH was designed as a replacement for Telnet and other insecure remote access methods, which send information, notably passwords, in plain text, rendering them susceptible to packet analysis.

The most common server daemon and client software which employs the SSH Protocol is developed by the OpenSSH Project. Of course, there are several SSH capable clients available including the popular Windows client called PuTTY.

Besides having encrypted communications, the idea of being able to remotely log in or copy a file from one machine to another without being prompted for a password is attractive to many developers and architects. Through the use of Public Key Infrastructure (PKI) the machines can “trust” certain keys and allow remote access.

This is great and many would ask, “What's your beef with it Jamie? You're just a grumpy paranoid old man.” Yes, I am. My beef is that this technique often gets abused and is sometimes deployed in a sloppy manner.

If you're going to use hands-free logins, please consider a couple of things. First of all, restrict access to the OpenSSH daemon through the use of host-based (iptables) firewall and network-based firewalls.

Also, restrict who (which users) can login using configuration options such as DenyUsers, AllowUsers, DenyGroups, and finally AllowGroups. Some system administrators create a user group called “sshusers” and then set “AllowGroups sshusers” in the configuration file. Then assign the “sshusers” as the secondary group to user accounts to login via Secure Shell.

Administrative, shared accounts such as Oracle should NEVER be logged into directly. Furthermore, “PermitRootLogin” should be set to “no” to prevent direct login to the root account.

As an added layer of protection ensure the “StrictModes” value is set to “yes”. Sometimes users, and system administrators, get sloppy and relax the discretionary access controls on user home directories where the SSH credentials are stored.

Finally, I would ensure that the Secure Shell service is using the strongest encryption possible and is only configured to accept protocol version 2 connections. Set the following in /etc/ssh/sshd_config:


Protocol 2
Ciphers blowfish-cbc,aes256-cbc,aes256-ctr,aes192-cbc,aes192-ctr,aes128-cbc,aes128-ctr


I hope this article got you thinking about how you use Secure Shell. I encourage you to read the various security guidelines and other recommendations that are available. In the end, however, one of the best defenses is diligence by system administrators who review and remove inactive user accounts and are aware of how their architecture is configured.

Cross-posted from Security Blanket Technical Blog

1. Network Working Group of the IETF, January 2006, RFC 4252, The Secure Shell (SSH) Authentication Protocol
Possibly Related Articles:
14039
Operating Systems
Unix SSH Operating Systems Linux Administration SecureShell
Post Rating I Like this!
0b8d1c9dc5f4a80e6646d8d18b8683fe
Ben Keeley Good article. For general info though, the key can just as easily have a password assigned so that connections to servers are not 'password-less'.
1294736485
4085079c6fe0be2fd371ddbac0c3e7db
Jamie Adams Thanks for the feedback Ben. I am not sure exactly what you mean. Could you elaborate or send a link for further info? I love examples. Thanks Jamie
1294747256
0b8d1c9dc5f4a80e6646d8d18b8683fe
Ben Keeley Hi,
When generating your key you assign a password rather than just pressing enter. Its not two factor authentication, as the destination still only checks the key not the password, its just you need the password to first unlock the key (if that makes sense).

https://help.ubuntu.com/community/SSH/OpenSSH/Keys#Generating%20RSA%20Keys

'Your SSH key passphrase is only used to protect your private key from thieves. It's never transmitted over the Internet, and the strength of your key has nothing to do with the strength of your passphrase.

You have to choose for yourself whether to use a passphrase with your RSA key. Ultimately, it's a choice between cursing the difficulty every time you have to type it in, or cursing your glibness when someone logs in to all your accounts and changes your password so you can't get in any more.

If you choose to use a passphrase, pick something strong and write it down on a piece of paper that you keep in a safe place. If you choose not to use a password, just press the return key without typing a password - you'll never be asked for one again. '

HTH
1294752084
4085079c6fe0be2fd371ddbac0c3e7db
Jamie Adams Ben... thanks for the information. yes, I have seen that technique quite often and that "pressing enter" is what I have heartburn about. I was hoping there was a way to enforce the use of a passphrase associated with key, too. So, we are still back to square one.

I still prefer OpenSSH and I love it for its flexibility. There is so many cool things you can do with it.

Thanks again for taking the time for adding additional information.
1294753091
4085079c6fe0be2fd371ddbac0c3e7db
Jamie Adams Let me elaborate on why this is such a thorn in my side. Years ago I rolled into a sysadmin shop where they had established what they called "centralized" authentication.

After investigating what these sysadmins had done, I was shocked and appalled.

They had configured OpenSSH to be able to login into multiple machines directly as root without being prompted for a password. They had created keys with no password (just hitting the return). They were then copying/distributing /etc/passwd and /etc/shadow files around these production systems.

No other safeguards in place to even mitigate the risks associated with these ridiculous design.

This is what I meant by, in my opinion, abuse and sloppy implementation!
1294753899
681afc0b54fe6a855e3b0215d3081d52
Susan V. James Jaime - Do you believe there's ever a way to actually use the SSH host-based authentication feature safely? If I don't administer the transmitting host, then I worry about lack of control of who has access to the transmitting host, and their capability or even awareness about safeguarding accounts on the trusted host from tampering.

I also have problems with the efficacy of using a passphrase - can't developers simply hard-code the passphrase into their automation scripts?

The problem of trusted root is a tough one to solve if there are automated housekeeping processes that have to be run as root and require your servers to trust root coming from a primary host. The problem can be solved but it takes some investment in thought about the solution, and effort to implement it. I've seen file distribution and collection done quite safely and effectively using NFS (appropriately restricted of course) and the "nobody" account. Have also seen it done with 3rd party software in shops that have money for this.
1294760989
681afc0b54fe6a855e3b0215d3081d52
Susan V. James Sorry - spelled your name wrong Jamie!
1294761029
4085079c6fe0be2fd371ddbac0c3e7db
Jamie Adams Susan excellent points... and for the record, I get "Jaime" a lot (the Spanish spelling) but my name is Scotch-Irish American but I respond to either!

I don't like host-based authentication feature simply for that trust factor of systems not under your purview. I might, in rare situations, find it acceptable for a load-balanced or compute cluster in which the nodes are tightly grouped on a private network.

I just believe there are better ways to do things. Again, in my opinion such flexible technologies get abused.

And your last paragraph, the idea of "trusted root" just makes me cringe. Everyone wants automation but at what cost?

I'd be interested in feedback from other readers because I tend to get stuck in my ways and a fresh point of view is always nice.

Thanks again for the feedback!
1294762863
4085079c6fe0be2fd371ddbac0c3e7db
Jamie Adams Actually, I meant "Scottish" roots. Not Scotch-Irish otherwise, I will get all kinds of grief from those nitpick about our American ethnic blends!
1294763292
681afc0b54fe6a855e3b0215d3081d52
Susan V. James I don't like trusted root either, but it manages to find its way into the solution at times. I would love to find out if there is some way to enforce dual factor authentication for automated trusted connections. Something like this: not only the ssh key pair, but also something like a token from a virtual token generator - the root account would also have to authenticate to some secondary device where the passphrase keeps changing (but somehow your root account alone can calculate what that is). Not sure how this can be done technically though. Do you know of anything like this?
1294768903
681afc0b54fe6a855e3b0215d3081d52
Susan V. James In general, I find root is used for far more activities than it really needs to be.
1294769003
4085079c6fe0be2fd371ddbac0c3e7db
Jamie Adams I agree 200% with your second statement regarding the overuse of root for EVERYTHING. Regarding your first comment, Ben Keeley gave me an interesting link: http://www.wikidsystems.com/?htf_ssh2 you might find it interesting.
1294769516
314f19f082e69886c20e31c70fe6dceb
Rod MacPherson Jamie,

That example might not have been so bad if that was done via a separate instance of SSH bound only to a management network and appropriately firewalled or hosts.allow and hosts.denyed on each machine to ensure that the root login could only come from the IP address of the control server.

But since it doesn't sound like that group even went to that extent to try to secure it they should be ashamed.
1294771087
4085079c6fe0be2fd371ddbac0c3e7db
Jamie Adams @Rod... thanks for your feedback! Yes, if they would have at least restricted it to a private non-routable network of handful of machines or any kind of mitigation ... but NO.

The worse thing is that when I arrive at the shop, they said they were in the process of upgrading their "centralized" authentication service. I said, "Cool. From what to what?" They said, "..from R-services to Secure shell for security reasons."

I responded in a confused tone, "huh!?!?" Then they describe their architecture.... Ugh, I wanted to beat my head against the wall."

1294771352
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.