Keyed SSH reasonable/feasible?

[escalf]

I'm considering requiring users on my system to use keyed SSH to connect. We're already taking steps for SSH security by binding it to an off IP and port, but my paranoid mind says that's not enough.

Is it really all that much added security to require users who wish to use SSH to generate keys, importing the public key via cPanel?

My thinking is that - eventually - someone is going to get stupid, and use an insecure password, and jailshell or no, I don't want that to happen, should they get cracked.

The problem I'm thinking we'd run into is the user creating a pub/priv key pair, uploading the public, and then not password protecting the private. If they're on a non-shared system, then that's perfectly fine. If they're on a shared system, that's a huge security risk.

Suggestions?
Comments?
Thoughts?

-Eric Scalf
CMH Onsite Solutions
CMHZ Networks

 

[chirpy]

Using key authentication is definitely more secure that using password authentication that could be cracked by brute force methods (especially with stupid passwords).

The main thing holding it back is the education curve usually needed for users.

There's no security risk in anyone seeing the clients SSH key on the shared server as this is their PUBLIC key. Their private key is stored on their PC for their SSH client to use. If that's what you're worried about, then it's no more or less secure that if someone stores their passwords on their PC or on a sticky note on their monitor. If you're referring to clients using internet cafes, then educating them to use USB sticks to store their PRIVATE key on should be used. That seems less trouble than teaching them how to generate a key pair

 

[Infopro]

I've switched over to this myself and it wasn't hard to do at all. Thanks to the links chirpys Server Security Check provides. This one in particular was easy to follow and understand.

I actually used one of the features in WHM to add the key (Manage SSH keys) instead of doing it via SSH as described in the article. Worked fine.


Thank you again Sir.

 

[escalf]

Using key authentication is definitely more secure that using password authentication that could be cracked by brute force methods (especially with stupid passwords).

Unfortunately, the majority of end users will use stupid passwords. I, myself, am a fan of the 64-character, random case, random symbol, random number algorythm. heh. ...Speaking of, _is_ there a limit, anymore, to the password length on linux? (In this case, CentOS... for my personal server, slackware.)

The main thing holding it back is the education curve usually needed for users.

I plan to have very well-written how-to's on the support site, including screencaps of each step of the process in generating them with puttygen, and using putty to connect.

If you're referring to clients using internet cafes, then educating them to use USB sticks to store their PRIVATE key on should be used. That seems less trouble than teaching them how to generate a key pair

That seems like you're saying there's an easy way to generate a key pair for each user through, say, WHM? Thus far, it appears that the keys have to be generated by the user in their own cPanel. Am I mistaken on that? If it's possible for me to generate keys for each user, individually, then I'm all for that!

Thanks!
-Eric

 

[djmerlyn]

Well, I'm sorta new to this SSH Key stuff... I've been looking at it for a while, and have contemplated diving in to it a couple times but hesitated...

So, here I am in the latest WHM update and I see a "manage SSH key" area... That's nice, it might make a couple things easier... Then I also see in the transfer/copy account area it likes to use the SSH keys now...

The question I have may be simple, hope so...

If server1 and server2 have an SSH key relationship... What is to stop a script on an account on either server from connecting via SSH to the remote server? What level of authentication happens there, as the servers both trust each other?

Is the key perhaps encrypted, then still requires a password/username combo?

Thanks

 

[escalf]

You are correct in assuming that SSH keys have password protection. Well, they have the possibility of being password protected, although one can bypass that in generation. Personally, I always protect mine with a minimum of a 20 character randomly generated password that encompasses mixed case alphanumerics, symbols, and special symbols (those generated by holding down ALT and using the number pad). As it's a bitch to remember for every time I log into a server via SSH (oh, some 20 times a day), I use an "agent" program to 'store' my key, and hold authentication. The only time I have to enter the password is when I start the computer of a morning, and if I unload the agent when I'm going to be away from the computer for a bit (Screensavers serve as a good enough temporary locker, but if I'm going to be away for say, 20 - 30 minutes or more, I'm unloading sensitive materials, and re-encrypting any encrypted materials).

...anywho, to answer your question more specifically, yes, if machine one and machine two have an SSH trust, or share a common key (Machine 2 has the public key stored on it, and Machine 1 has the public and private keys), then yes, the machines can connect to one another, and a script could generate the SSH connection, provided it had access to the key file (always 'chmod 600' your key file (or, if you're really paranoid, chmod 400)). If you take proper steps to secure your private key (locating it in a non-standard directory, 'chmod 600', etc...) they a malicious script will most likely not be able to use the key and trust to connect.

In all cases, however, it is up to the user to be vigalint against accidentally running malicious scripts, and keeping their account as secure as possible.