Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Lax SSH Key Management A "Big Problem"

Unknown Lamer posted about 2 years ago | from the we're-all-doomed dept.

Privacy 212

cstacy writes "Tatu Yionen, inventor of SSH, says he feels 'a moral responsibility' to come out of retirement and warn that a 'little-noticed problem' could jeopardize the security of much of the world's confidential data. He is referring to the management (or lack thereof) of SSH keys (i.e. 'authorized_keys') files. He suggests that most organizations simply allow the SSH key files to be created, copied, accumulated, and abandoned, all over their network, making easy pickings for intruders to gain access. Do you think this is a widespread problem? How does your company manage SSH keys?" cstacy's summary here is accurate, but as charlesTheLurker notes, the article is a bit over the top: "The Washington Times claims that there's a huge vulnerability in ssh. It turns out that some reporter there has discovered that you can do passwordless login with the software, and has spun this into a story of a dangerous vulnerability. Sigh."

cancel ×

212 comments

Sorry! There are no comments related to the filter you selected.

erroneus (253617) FatASS needs PIZZA (-1)

Anonymous Coward | about 2 years ago | (#42395145)

"Oh... to eat pizza again..." by on Saturday December 22, @05:20PM (#42371769) Homepage from http://slashdot.org/comments.pl?sid=3335159&cid=42371769 [slashdot.org] since that disgusting fatbody pig is a waste of life with no self-control.

Re:erroneus (253617) FatASS needs PIZZA (-1)

Anonymous Coward | about 2 years ago | (#42396319)

Alright Peter, my love, we got it, you don't like pizza ...

Would you come back to bed now ?

Love,

Dad

Passwordless login (5, Funny)

Smallpond (221300) | about 2 years ago | (#42395153)

I've just noticed a huge vulnerability in keyless entry on cars - you can open the door without a key!

** just so we don't have a story without a car analogy **

Re:Passwordless login (1, Offtopic)

paiute (550198) | about 2 years ago | (#42395657)

I just learned you can gain access to the Library of Congress without being a Congressman.

Re:Passwordless login (2)

NatasRevol (731260) | about 2 years ago | (#42395735)

Or a librarian.

Or even Nicholas Cage.

Re:Passwordless login (1)

Sulphur (1548251) | about 2 years ago | (#42396443)

I've just noticed a huge vulnerability in keyless entry on cars - you can open the door without a key!

** just so we don't have a story without a car analogy **

You can get in some convertibles without opening the door even if the windows are up.

--

By not using SSH (1)

Anonymous Coward | about 2 years ago | (#42395165)

We manage this problem by having the office workplace be an offline, local office network. There isn't any connecting remotely through VPNs/SSH, if you're doing work, you come to work to do it.

Re:By not using SSH (3)

vlm (69642) | about 2 years ago | (#42395329)

What do you use to log in from one machine into another, telnet? Or instead of scp you ftp stuff?

Also I have several boxes where the only way I can run "X" GUI stuff (at home, my mythtv backends) is via SSH X11 forwarding.

Re:By not using SSH (1)

Anonymous Coward | about 2 years ago | (#42395467)

What do you use to log in from one machine into another, telnet? Or instead of scp you ftp stuff?

Also I have several boxes where the only way I can run "X" GUI stuff (at home, my mythtv backends) is via SSH X11 forwarding.

None of them are more than ten feet away from where anyone works, you walk over to it.

What will you do after your office closes due to being less productive than other workplaces?

I'm not sure, we only have two customers, both of whom have been with us for over thirty years, and they don't seem to be going anywhere. (it's kind of a niche business)

Re:By not using SSH (0, Troll)

obarel (670863) | about 2 years ago | (#42395553)

Your comments are very insightful to the problems that the article is talking about. Thank you for sharing your experience!

Re:By not using SSH (0)

Anonymous Coward | about 2 years ago | (#42395597)

Your comments are very insightful to the problems that the article is talking about. Thank you for sharing your experience!

I know, I probably seem like a troll, but like I said, it's a niche business, and is security related.

Anything other than physical access, with no WAN capability is not secure enough for what our (admittedly very small list) of customers are looking for.

Re:By not using SSH (1)

Smallpond (221300) | about 2 years ago | (#42395353)

What will you do after your office closes due to being less productive than other workplaces?

Re:By not using SSH (1)

sco08y (615665) | about 2 years ago | (#42395699)

What will you do after your office closes due to being less productive than other workplaces?

It's probably government. And, most likely, 90% of the users just use SSH and don't tell anyone.

Welcome to the past! (1)

Anonymous Coward | about 2 years ago | (#42395463)

You, sir, are living in the 20th century.

Re:By not using SSH (1)

gmuslera (3436) | about 2 years ago | (#42396017)

If you have to do things between computers in your local network (transfer a file, or execute a process, or whatever), doing it using an unencrypted protocol means that any computer doing sniffing in that network could get both content and access. And a trojan in the desktop of the clueless/weakest link on your network could give from inside access to people from outside.

Don't feel safe because not explicit access from outside, whats inside matters too.

who is doing this? (2)

datapharmer (1099455) | about 2 years ago | (#42395187)

Who exactly is it that isn't password protecting their ssh keys? I mean if you choose to press enter shame on you.

Re:who is doing this? (1)

Skinkie (815924) | about 2 years ago | (#42395243)

Most likely your offline backup script that rsyncs your changes over every night with you sleeping tight.

Re:who is doing this? (5, Insightful)

kthreadd (1558445) | about 2 years ago | (#42395373)

Then I would create a separate key for that service and restrict what it was allowed to do on remote end.

Re:who is doing this? (1)

h4rr4r (612664) | about 2 years ago | (#42395405)

That is what you should do.
I use rssh for something like this all the time and each process has it own user. That takes planning though and people are lazy.

Re:who is doing this? (1)

datapharmer (1099455) | about 2 years ago | (#42395443)

Exactly! chroot it, limit ssh by IP and run a second script on the server to do any additional housekeeping (move files/change permissions as necessary and cleanup). You shouldn't allow an unprotected key for an account with access to anything of value on your server. Being lazy isn't an excuse. You can be lazy and maintain security, it just takes a few extra minutes to set it up correctly the first time.

Re:who is doing this? (5, Funny)

Anonymous Coward | about 2 years ago | (#42396289)

I always run my backup scripts in chroot environments. I've also found that, as a bonus, they complete many orders of magnitude faster and use significantly less space. Huge wins all around.

Re:who is doing this? (0)

Anonymous Coward | about 2 years ago | (#42395417)

Also scripts that rdist out updated config files from a central management server - you need the key from the management server on all your servers.

You can do it manually when you have a few servers but when you have a few hundred or thousand you can't. Of course the keys should only be readable by root but if the management server is compromised so is everything else.

Re:who is doing this? (1)

datapharmer (1099455) | about 2 years ago | (#42395493)

yes, but there are other ways of securing these service accounts and the ssh keys have no business in any location that is network accessible and shouldn't be of danger even if they are (since their access should be very limited in scope).

Re:who is doing this? (1)

h4rr4r (612664) | about 2 years ago | (#42395511)

You could copy the files to some unprivileged user home dir and have the servers run a cronjob to mv and chown the files as needed. That way if they get the management server all they can do is bork the config files.

Re:who is doing this? (1)

betterunixthanunix (980855) | about 2 years ago | (#42395749)

  1. If this is for desktop use, it asks ssh-agent. If it cannot do that, oh well, the backup did not happen and hopefully I see an error message in the morning.
  2. If this is for something more general, it is a service that is confined in any number of ways (SELinux would be my preference).

...and on the remote end, whatever the backup script logs in as is confined -- no permissions to do anything other than write a backup.

Re:who is doing this? (5, Insightful)

sribe (304414) | about 2 years ago | (#42395283)

Who exactly is it that isn't password protecting their ssh keys?

Anyone who needs services to launch without manual intervention--which is a whole lot of services and a whole lot of people...

Re:who is doing this? (0)

Anonymous Coward | about 2 years ago | (#42395515)

You're obviously doing it wrong. We just put the password in another file, and use a script to handle it.

Re:who is doing this? (2)

vlm (69642) | about 2 years ago | (#42395615)

We just put the password in another file, and use a script to handle it.

Naah just put the password on the command line. What could possibly go wrong?

(Note, just kidding)

At one point I had at work an implementation looking a lot like the Debian development anon-ftp system... Sure, upload whatever you want, but if its more than 5 minutes old and has no valid GPG signature, then it gets wiped. On the other hand if its got a valid GPG sig, trust it and run it. If you're going to put an anon ftp server on the internet you need to partition upload and download so as not to become a warez site. I suppose if there was a buffer overflow in GPG (or the ftp server, or my lame little wrapper script) I would have been pretty well screwed. Also put some sensible limits on it for ddos reduction.

"Run any script you see, as long as its got a valid GPG sig..." is a pretty simple wrapper. Authenticate the code, not the transfer, more or less. Essentially, a crude DRM system... I wish this design/pattern were more "mainstream".

Re:who is doing this? (2)

h4rr4r (612664) | about 2 years ago | (#42395535)

Which is why we have things like chroot and rssh. Limiting the scope of the damage is a vital practice with those kinds of accounts.

Re:who is doing this? (2)

sribe (304414) | about 2 years ago | (#42395917)

Which is why we have things like chroot and rssh. Limiting the scope of the damage is a vital practice with those kinds of accounts.

Yep. And more directly related to the article--not being a dipshit idiot about the key files ;-)

Re:who is doing this? (0)

Anonymous Coward | about 2 years ago | (#42395537)

Who exactly is it that isn't password protecting their ssh keys?

Anyone who needs services to launch without manual intervention--which is a whole lot of services and a whole lot of people...

noob use an expect script to enter the passwd for you

Re:who is doing this? (0)

Anonymous Coward | about 2 years ago | (#42396107)

for backup limting ssh can still help protect u from being rooted - won't help your data though.

Re:who is doing this? (1)

dw (5168) | about 2 years ago | (#42395577)

A nice solution I use for myself (home and work) is to use the ssh-agent distributed with GnuPG. I have an OpenPGP card (http://g10code.com/p-card.html) which holds my private key and cannot be retrieved. The card itself is PIN protected. I don't have to worry about my private key ever showing up in the filesystem or backups.

This works nicely with the -A option to ssh, which sets up a control channel back to the authentication agent on my desktop. I can ssh to server A, then ssh from A to B using my local smart card. If I'm ssh'd to server A and need to leave my desk, I can unplug the card and immediately break the authentication chain.

If I were setting up an SSH scheme in a large organization, this would be my first line of defense.

Re:who is doing this? (1)

X.25 (255792) | about 2 years ago | (#42396323)

Who exactly is it that isn't password protecting their ssh keys? I mean if you choose to press enter shame on you.

It appears that you haven't seen any workplace yet.

Re:who is doing this? (4, Informative)

gmack (197796) | about 2 years ago | (#42396581)

It is not a matter of password protecting ssh keys, it is a matter of deleting obsolete keys from ~/.ssh/authorized_keys when they aren't used anymore. When someone quits or gets fired someone should be going through everything they have access to and removing the keys. They are remarkably easy to forget where they were put as well.

After running my head into this problem one too many times I ended up creating a management system that rebuilds every copy of authorized_keys on each server.

Not sure where you work.. (1)

xtal (49134) | about 2 years ago | (#42395213)

Unmanaged keys are most certainly a pretty serious security vulnerability, and I agree - in my experience it is endemic.

Key management - signing, validation, revocation - doesn't happen for free. Everything worthwhile requires effort.

Passwords are a worse vulnerability (5, Insightful)

betterunixthanunix (980855) | about 2 years ago | (#42395371)

I see brute force attacks on passwords all the time; you do not see that with keys. Yes, if you are dealing with an adversary who is organized, well-funded, and specifically attacking you, you should be taking extra precautions with keys (and with many other things), but for most SSH use-cases the adversary is just trying to find the least secure system anywhere on the net, and does not care who owns it.

So rather than scare people about poor key management, let's scare people about bad passwords -- which is nearly all passwords.

Re:Passwords are a worse vulnerability (3, Interesting)

vlm (69642) | about 2 years ago | (#42395427)

So rather than scare people about poor key management, let's scare people about bad passwords -- which is nearly all passwords.

Hey slashdot does anyone have an implementation where the sshd config would look something like:

PubkeyAuthentication yes
PasswordAuthentication no any/any
PasswordAuthentication yes 10.0.0.0/8

And no, last time I checked openssh could not do that. Either yes or no, no src address filtering.

The closest I could come up with is running two SSH servers on different port numbers and filter at the network level which src addrs can talk to which port.

Re:Passwords are a worse vulnerability (0)

Anonymous Coward | about 2 years ago | (#42395491)

you could probably write your own PAM module to let you do this

Re:Passwords are a worse vulnerability (1)

allo (1728082) | about 2 years ago | (#42395587)

why would you want passwords in your lan?
when you need passwords sometimes, when you are on the road with your laptop or at some pc, which is not yours, okay there its useful. But in you own lan, you always can access some ssh-key. So your policy isn't very useful that way.

Re:Passwords are a worse vulnerability (1)

vlm (69642) | about 2 years ago | (#42396327)

(years ago) I used to get blasted at home from China IP addrs trying various root passwords. Flooding my logs with failures. Since then I only allow key auth from the untrustable internet. I'd never allow password auth over the internet. Copying a key is not a big deal. Or logging into another machine that I know has a key, etc.

On the LAN, if some clown gets infected and port scanning / password scanning, I can literally walk over and physically take care of it.

Re:Passwords are a worse vulnerability (4, Informative)

Qzukk (229616) | about 2 years ago | (#42395673)

And no, last time I checked openssh could not do that

Last I checked, PasswordAuthentication is allowed inside a Match block, so

PubkeyAuthentication yes
PasswordAuthentication no
Match Address 10.0.0.0/8
        PasswordAuthentication yes

Re:Passwords are a worse vulnerability (1)

Sancho (17056) | about 2 years ago | (#42395691)

You should be able to approximate that using Match keywords in sshd_config.

Re:Passwords are a worse vulnerability (2)

ArsonSmith (13997) | about 2 years ago | (#42395709)

xinetd can. we launch a separate sshd with separate config file from xinetd with response from only certain ip addresses.

Re:Passwords are a worse vulnerability (4, Informative)

shaiay (21101) | about 2 years ago | (#42395909)

use the Match config file directive:

PubkeyAuthentication yes
PasswordAuthentication no
Match Address 10.0.0.0/8
PasswordAuthentication yes

Re:Passwords are a worse vulnerability (1)

Anonymous Coward | about 2 years ago | (#42395479)

The problem is the public as a whole is already well aware of piss poor passwords and just doesn't care. Key files however can be protected with rudimentary security built into just about every OS out there or with a myriad of more paranoid alternate solutions.

Would you leave your car keys on the hood of your car if you were in an area where you felt it essential to lock your car?

Re:Passwords are a worse vulnerability (1)

Shavano (2541114) | about 2 years ago | (#42395685)

I find it a useful thought exercise to presume that my computers are under specific, directed attack even though they probably aren't.

The Washington Times (-1, Offtopic)

hoboroadie (1726896) | about 2 years ago | (#42395255)

I'm curious to see if the fascistic editorial stance of the Times changes now that True Father has returned to the fold. [wikipedia.org]

Ignore the Wash Times (-1)

Anonymous Coward | about 2 years ago | (#42395259)

The Washington Times is a reactionary rag which no one in DC takes seriously. I suggest you all do the same, unless you're committing to a low-fact, high-hysteria diet this holiday season.

Your keys, my keys (4, Insightful)

kthreadd (1558445) | about 2 years ago | (#42395265)

I've worked at a place where someone thought it was a great idea to mass-add a specific entry everyones authorized_keys, "because then $x would just work". No need to tell everyone of course.

It's not enoguh that you know how to manage your keys. The rest of the organization has to know what's OK and not.

Re:Your keys, my keys (2)

vlm (69642) | about 2 years ago | (#42395361)

Would have been a lot funnier if they did

cat somekey > ~/.ssh/authorized_keys

rather than

cat somekey >> ~/.ssh/authorized_keys

I suppose that is one way to "solve" the problem.

Re:Your keys, my keys (1)

kthreadd (1558445) | about 2 years ago | (#42396419)

Turned out someone had a cron job that checked certain files for modifications, including authorized_keys. So it was detected fairly quickly.

With great power comes great responsibility, or whatever it is that sudo sais the first time you run it.

His name is (4, Informative)

LucidBeast (601749) | about 2 years ago | (#42395285)

Tatu Ylönen

Re:His name is (1)

Nimey (114278) | about 2 years ago | (#42395847)

Bloody sans-serif fonts.

Re:His name is (0)

Anonymous Coward | about 2 years ago | (#42395939)

No need to be so dramatic...

authorizedkeyscommand (1)

Anonymous Coward | about 2 years ago | (#42395313)

In my opinion, this is the interest of the new authorizedkeyscommand. A sample usage is available at http://www.sysadmin.org.au/index.php/2012/12/authorizedkeyscommand/

Inability of server to enforce policy (4, Insightful)

linuxtelephony (141049) | about 2 years ago | (#42395339)

The biggest issue with SSH is the inability of the server to enforce policy on the client keys. If I'm wrong, I'd love to be corrected and learn what I've been overlooking.

As it stands, there's no way for the server to reject a key that has no pass phrase, a poor passphrase, or an old pass phrase. Short of over-the-shoulder random audits of users using their keys, there's no way to enforce a policy that sets minimum standards for pass phrases on SSH keys.

To my way of thinking that is one of the bigger areas of risk with and drawbacks of the use of SSH.

Re:Inability of server to enforce policy (2)

h4rr4r (612664) | about 2 years ago | (#42395489)

If you are that worried about it you could disable the use of ssh keys. No one is going to be guessing the keys anyway, but it is a concern if someone copied one.

Re:Inability of server to enforce policy (4, Insightful)

vlm (69642) | about 2 years ago | (#42395517)

Its a mess. In more detail.

The pass phrase never leaves the client, right, so you'd have to magically protect against trojaned client that lies and pinky swears that it really did check.

Or send the passphrase cleartext to the server for the server to test it. That would be bad. Of course if you had a trustable connection between, then you could safely transfer the passphrase to the server for testing, but then you'd already trust the link so it would be pointless.

The solution is after you set up the trusted link you send the passphrase over the link and have the server verify the phrase and dump the connection if it fails.

There's probably some horrible failure mode where if a server is owned then you're really screwed because now it has your passphrase which is probably your gmail password and xbox password and who knows what else.

Kerberos does it (somewhat) better.

Re:Inability of server to enforce policy (2)

icebraining (1313345) | about 2 years ago | (#42395541)

That's because the server has no way of knowing anything about the passphrase unless the client tells it, and no way of knowing if the client is telling the truth, so it would be foolish to include such verification.

Re:Inability of server to enforce policy (2)

betterunixthanunix (980855) | about 2 years ago | (#42395639)

As it stands, there's no way for the server to reject a key that has no pass phrase, a poor passphrase, or an old pass phrase

There is, however, a way for the server to accept only particular client keys -- say, keys that are known to have been generated on a smart card. SSH can be configured to look for authorized keys somewhere that users cannot write to (a basic centralized keystore), and there is some amount of support for a PKI. You cannot force users to have good passphrases, but you can force them to use smartcards (which is probably better than a passphrase anyway).

Re:Inability of server to enforce policy (1)

icebraining (1313345) | about 2 years ago | (#42396445)

How does the server know the key came from a smartcard?

Re:Inability of server to enforce policy (1)

tburke261 (981079) | about 2 years ago | (#42395805)

If I'm wrong, I'd love to be corrected and learn what I've been overlooking.

One of the best things I've heard in a while on /. If only every commenter had this attitude!

Re:Inability of server to enforce policy (2)

DamnStupidElf (649844) | about 2 years ago | (#42395823)

This is basically the heart of the issue. Allowing users to add whatever keys they want (their uncle? Their best "friend" in Russia?) to their own user accounts circumvents the traditional authentication/authorization methods. When employees leave, occasionally their accounts stick around while things get cleaned up (or if they were especially bad and running production jobs out of their home account, they just stick around forever) their /etc/secrets entry gets a * for a password hash immediately but it's not obvious to check their personal .ssh directory and clean up authorized_keys. Especially if that annoying production job happens to use ssh in a non-trivial way. Single sign-on systems are a possible solution. OpenSSH supports Kerberos integration and that may be the way to go for big *nix enterprises.

Re:Inability of server to enforce policy (1)

shaiay (21101) | about 2 years ago | (#42395831)

The server not being able to force policy on the clients is inherent to the client-server system: If you client is un-trusted, you cannot enforce anything on it.

Unfortunately, while current OpenSSH supports multiple authentication options, they cannot be "stacked" - if you manage to authenticate in one way, you are in.

In my blog [blogspot.co.il] I suggest a solution: I show a way to force OpenSSH to ask for a (server based) password after key based login,. This way you can enforce password policy on the server (strong passwords, etc...) with the standard tools, and also require a key. The key can now be password-less.

Shai

erroneus (253617) FatASS blimp needs PIZZA (-1)

Anonymous Coward | about 2 years ago | (#42395365)

"Oh... to eat pizza again..." by erroneus (253617) on Saturday December 22, @05:20PM (#42371769) from http://slashdot.org/comments.pl?sid=3335159&cid=42371769 [slashdot.org] since that disgusting fatbody pig is an obese swine with no self-control, no dick and cowardly little worm.

be honest fuckers... (-1)

Anonymous Coward | about 2 years ago | (#42395379)

am i the only one who had this reaction:

1 second into the post: omg im gonna shit my pants

5 seconds into the post: omg it's worse than i thought

10 seconds into the post: oh looks like the world isnt coming to an end after all... i can keep wearing these pants for the rest of the day...

15 second's into the post: wait, this aint shit....

at end of post: omg this is a fucking troll

next step come read comments to see other people laugh

Re:be honest fuckers... (1)

nosubmit (2800659) | about 2 years ago | (#42395623)

-1? wtf

erroneus (253617) FatASS bloated PIG needs PIZZA (-1)

Anonymous Coward | about 2 years ago | (#42395411)

"Oh... to eat pizza again..." by erroneus (253617) on Saturday December 22, @05:20PM (#42371769) from http://slashdot.org/comments.pl?sid=3335159&cid=42371769 [slashdot.org] since that disgusting fatbody SWINE is a waste of life obese pig with no self-control and no dick.

erroneus (253617) FatASS needs PIZZA (-1)

Anonymous Coward | about 2 years ago | (#42395439)

"Oh... to eat pizza again..." by erroneus (253617) on Saturday December 22, @05:20PM (#42371769) from http://slashdot.org/comments.pl?sid=3335159&cid=42371769 [slashdot.org] since that disgusting BLOATED fatboy pig is a waste of life obese swine with no self-control and no dick.

Is your setup secure? (1)

joelwhitehouse (2571813) | about 2 years ago | (#42395445)

Post your 'authorized_keys' file and fqdn here to find out.

Re:Is your setup secure? (1)

ArsonSmith (13997) | about 2 years ago | (#42395793)

Public keys are just that. What good would that really do for you?

Re:Is your setup secure? (0)

Anonymous Coward | about 2 years ago | (#42395973)

He owns a quantum computer, so he can generate the matching private keys. Duh!

Re:Is your setup secure? (1)

godrik (1287354) | about 2 years ago | (#42396039)

remember the debian ssh key fiasco. How many people still use some of these not-so-random keys? I agree that posting your authorized_keys should not be a problem. But the least information on your setup out there is the better.

Re:Is your setup secure? (0)

Anonymous Coward | about 2 years ago | (#42396035)

Given that authorized_keys contains public keys, I'd take you up on that offer.

Unfortunately for all parties involved, Slashdot's filter won't let me. Filter error: That's an awful long string of letters there.

I could probably give you the private key as well and still be safe, given it has a pretty strong passphrase, but we'll never know, now, will we?

erroneus (253617) FatASS swine needs PIZZA (-1)

Anonymous Coward | about 2 years ago | (#42395459)

"Oh... to eat pizza again..." by erroneus (253617) on Saturday December 22, @05:20PM (#42371769) from http://slashdot.org/comments.pl?sid=3335159&cid=42371769 [slashdot.org] since that disgusting fatbody pig is a waste of life obese swine with no self-control and no dick.

erroneus (253617) FatASS craves PIZZA (-1)

Anonymous Coward | about 2 years ago | (#42395483)

"Oh... to eat pizza again..." by erroneus (253617) on Saturday December 22, @05:20PM (#42371769) from http://slashdot.org/comments.pl?sid=3335159&cid=42371769 [slashdot.org] since that disgusting fatbody pig is a waste of life obese swine with no self-control and no dick.

erroneus (253617) FatASS lardboy needs PIZZA (-1)

Anonymous Coward | about 2 years ago | (#42395499)

"Oh... to eat pizza again..." by erroneus (253617) on Saturday December 22, @05:20PM (#42371769) from http://slashdot.org/comments.pl?sid=3335159&cid=42371769 [slashdot.org] since that disgusting fatbody pig is a waste of life obese swine with no self-control and no dick.

Commercial SSH with key management (1)

blacksuit_uk (2802701) | about 2 years ago | (#42395513)

Quite dismayed that the orginal article doesn't start to go down a bit further looking at the commercial SSH solutions with various levels of key management; SSH inc, Dell(Quest/Vintella), Venafi, CA, FoxT and others. They've been doing business for decades, using "improved SSH key management" as one of their key messages, and their target markets are corporates with strong brands, energy companies, financial services organisations and goverments. Would like to see a new survey slicing up the Open SSH and Commercial SSH footprints.

erroneus (253617) FatASS blimp needs PIZZA (-1)

Anonymous Coward | about 2 years ago | (#42395521)

"Oh... to eat pizza again..." by erroneus (253617) on Saturday December 22, @05:20PM (#42371769) from http://slashdot.org/comments.pl?sid=3335159&cid=42371769 [slashdot.org] since that disgusting fatbody bloated pig is a waste of life obese swine with no self-control and no dick.

erroneus (253617) FatASS lardbody needs PIZZA (-1)

Anonymous Coward | about 2 years ago | (#42395545)

"Oh... to eat pizza again..." by erroneus (253617) on Saturday December 22, @05:20PM (#42371769) from http://slashdot.org/comments.pl?sid=3335159&cid=42371769 [slashdot.org] since that disgusting fatbody pig blimp is a waste of life obese swine with no self-control and no dick.

The name is not Tatu Yionen (1)

TheTruthIs (2499862) | about 2 years ago | (#42395547)

It's Tatu Ylonen.

erroneus (253617) FatASS pig needs PIZZA (-1)

Anonymous Coward | about 2 years ago | (#42395563)

"Oh... to eat pizza again..." by erroneus (253617) on Saturday December 22, @05:20PM (#42371769) from http://slashdot.org/comments.pl?sid=3335159&cid=42371769 [slashdot.org] since that disgusting fatbody lardbelly pig is a waste of life obese swine with no self-control and no dick.

openssh restrictions (1)

quags (448967) | about 2 years ago | (#42395573)

Sure lax anything is a problem. If you are placing authorized_keys files that are wide open, to a wide open SSH that just sits around for years, ya I see a problem. If done right there are restrictions that can be added in an authorized_keys file

from="IP.address" - set a key to only be able to be accessed by a certain ip
command="some command" - only allow a certain command to be run.

I also feel that ssh should not be wide open if possible. IP restricted by either a firewall, tcp wrappers or AllowUsers in sshd_config.

erroneus (253617) FatASS swine needs PIZZA (-1)

Anonymous Coward | about 2 years ago | (#42395575)

"Oh... to eat pizza again..." by erroneus (253617) on Saturday December 22, @05:20PM (#42371769) from http://slashdot.org/comments.pl?sid=3335159&cid=42371769 [slashdot.org] since that disgusting fatbody pig is a waste of life obese swine with no self-control and no dick.

/. Summary Over the Top RE: Washington Times (0)

Anonymous Coward | about 2 years ago | (#42395589)

So I read the TFA. And while the Times article is a bit on the sensational side, so is Slashdot's characterization. I saw nothing to indicate that "some reporter there has discovered that you can do passwordless login with the software, and has spun this into a story of a dangerous vulnerability"... I did see the reporter speaking to an expert about an obscure, but real, problem and reporting on it. I suspect because that expert raised the issue himself.

All news organizations tend to sensationalize, not just those with which the majority of Slashdot editors and readers have editorial disagreements with, because it sells papers (or airtime or page views). If the Times is to be faulted, it's for characterizing this problem as a 'glitch' rather than a management practices problem in the headline.

erroneus (253617) FatASS balloon needs PIZZA (-1)

Anonymous Coward | about 2 years ago | (#42395605)

"Oh... to eat pizza again..." by erroneus (253617) on Saturday December 22, @05:20PM (#42371769) from http://slashdot.org/comments.pl?sid=3335159&cid=42371769 [slashdot.org] since that disgusting fatbody pig blimp is a waste of life obese swine with no self-control and no dick.

erroneus (253617) FatASS hog needs PIZZA (-1)

Anonymous Coward | about 2 years ago | (#42395611)

"Oh... to eat pizza again..." by erroneus (253617) on Saturday December 22, @05:20PM (#42371769) from http://slashdot.org/comments.pl?sid=3335159&cid=42371769 [slashdot.org] since that disgusting fatbody pig hog is a waste of life obese swine with no self-control and no dick.

erroneus (253617) FatASS needs PIZZA (-1)

Anonymous Coward | about 2 years ago | (#42395631)

"Oh... to eat pizza again..." by erroneus (253617) on Saturday December 22, @05:20PM (#42371769) from http://slashdot.org/comments.pl?sid=3335159&cid=42371769 [slashdot.org] since that disgusting fatbody pig is a waste of life obese swine with no self-control and no dick.

erroneus (253617) FatASS hog needs PIZZA (-1)

Anonymous Coward | about 2 years ago | (#42395647)

"Oh... to eat pizza again..." by erroneus (253617) on Saturday December 22, @05:20PM (#42371769) from http://slashdot.org/comments.pl?sid=3335159&cid=42371769 [slashdot.org] since that disgusting fatbody pig is a waste of life obese swine with no self-control and no dick.

Some solutions to key management (0)

Anonymous Coward | about 2 years ago | (#42395659)

#1 "Good Enough" Is "Good Enough":
'AuthorizedKeysFile /etc/ssh/keys/%u'

#2 "Best Practice":
Compile openssh with LPK patch (LDAP Public Key) and use 'AuthorizedKeysFile /dev/null'

Second way is centralized and much more secure.

erroneus (253617) FatASS needs PIZZA (-1)

Anonymous Coward | about 2 years ago | (#42395665)

"Oh... to eat pizza again..." by erroneus (253617) on Saturday December 22, @05:20PM (#42371769) from http://slashdot.org/comments.pl?sid=3335159&cid=42371769 [slashdot.org] since that disgusting fatbody pig is a waste of life obese swine with no self-control and no dick.

erroneus (253617) FatASS needs PIZZA (-1)

Anonymous Coward | about 2 years ago | (#42395687)

"Oh... to eat pizza again..." by erroneus (253617) on Saturday December 22, @05:20PM (#42371769) from http://slashdot.org/comments.pl?sid=3335159&cid=42371769 [slashdot.org] since that disgusting fatbody pig is a waste of life obese swine with no self-control and no dick.

erroneus (253617) FatASS sloth needs PIZZA (-1)

Anonymous Coward | about 2 years ago | (#42395703)

"Oh... to eat pizza again..." by erroneus (253617) on Saturday December 22, @05:20PM (#42371769) from http://slashdot.org/comments.pl?sid=3335159&cid=42371769 [slashdot.org] since that disgusting fatbody pig is a waste of life obese swine with no self-control and no dick.

erroneus (253617) FatASS needs PIZZA (-1)

Anonymous Coward | about 2 years ago | (#42395711)

"Oh... to eat pizza again..." by erroneus (253617) on Saturday December 22, @05:20PM (#42371769) from http://slashdot.org/comments.pl?sid=3335159&cid=42371769 [slashdot.org] since that disgusting fatbody pig is a waste of life obese swine with no self-control and no dick.

Our policy (0)

Anonymous Coward | about 2 years ago | (#42395861)

SSH keys for the root account are managed by cfengine/chef/puppet/etc and those are held only by users. Someone quits, all servers have updated authorized_keys in a few minutes. If someone with non-root permission quits then it's just one server that needs to have a user account locked out appropriately.

Servers can ssh into each other for special purposes (eg: remote backups), but not as root. They have to go into an account created just for them where the user's "shell" will do the work on its behalf using sudo where necessary. Sure it's a bit more annoying but it's the Right Way.

And don't forget about a possible authorized_keys2 file! If you're doing custom automation of SSH key management, treat authorized_keys2 the same way you do authorized_keys.

TODO: Key rotation policy for users :-(

Guilty (0)

Anonymous Coward | about 2 years ago | (#42395985)

This article is pretty much about me.

It's not hard (2)

geekboybt (866398) | about 2 years ago | (#42395991)

Managing SSH keys for known service accounts is easy with configuration management tools like Puppet, Chef, or Salt.

I'd be glad if they just used some keys at my corp (0)

Anonymous Coward | about 2 years ago | (#42396011)

instead of using easily-guessable passwords :-(

We've used it for backups (1)

93 Escort Wagon (326346) | about 2 years ago | (#42396171)

It's not perfect, but - if you restrict where it (ostensibly) can connect from, and you restrict it to a specific command, I wouldn't exactly consider it low-hanging fruit.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?