Observations from two weeks of SSH brute force attacks • Hacker News Board

Re: Observations from two weeks of SSH brute force attacks

#51

Post by mike-cardwell » Fri, Jan 27, 2012, 12:02 PM UTC

gnosis wrote: post #50

mike-cardwell wrote: post #49

Earlier quoted context omitted.

"external drive" is not what a smart card is. You can not read the key from the smart card. The actual crypto operations involved in performing the authentication are handled on the card it's self. If your key is on a smart card it can not be stolen, even if the machine you're ssh'ing from has been compromised. This has real value and is not "insane" In your setup, if their machine is compromised, it doesn't matter i…

"If your key is on a smart card it can not be stolen, even if the machine you're ssh'ing from has been compromised." If the machine you're ssh'ing from has been compromised by a halfway competent attacker, there's no need for them to get the key from the smart card. They can log in to the remote machine by simply piggybacking on to your ssh session (with a compromised ssh client).

Of course. There is still significant value in not allowing the attacker to ssh at will from any box at any time though.

Re: Observations from two weeks of SSH brute force attacks

#52

Post by acdha » Fri, Jan 27, 2012, 2:45 PM UTC

peterwwillis wrote: post #29

A long time ago I used to have a general purpose server on a DSL line with port 22 open. I thought everything was fairly secure, patched up, etc... I never thought brute forcers would be able to guess one of my accounts (which was a friend's account actually). The kicker? The password was the username. I found out about the rootkit a few days after they got in. I tell ya, kids these days just don't know how to hide a…

Or use only public-key authentication. I've run many internet-exposed servers for years without problems or kludgy obscurity measures like port knocking simply by disabling all forms of password authentication. This is faster, easier and has the advantages of not requiring non-standard client software, being observable by an attacker on the same network, and avoids the sort of rote password entry which causes mistakes and discourages long, complex passwords.

Re: Observations from two weeks of SSH brute force attacks

#53

Post by acdha » Fri, Jan 27, 2012, 2:50 PM UTC

mike-cardwell wrote: post #22

bradleyland wrote: post #18

Earlier quoted context omitted.

"as long as they..." See, that's exactly why we don't allow password based authentication. While you can enforce strong passwords, you can't enforce that the user choose a password that is unique to your system, because you cannot know where else they may use this password. The recent Dreamhost security disclosure is a great example. What are the chances that a contractor is using the same password for a Dreamhost sh…

How do you "require" that they use a pass phrase with their key? You can tell them to do it, but it's up to them if they actually do.

You can do this with policy (or a custom SSH client) but it's really a mistake to treat it as the same situation unless your users are in the habit of sharing their private SSH key files around.

In most situations, getting access to the key file requires a local client compromise - at which point the attacker could simply install a keylogger.

Re: Observations from two weeks of SSH brute force attacks

#54

Post by Nick_C » Sat, Jan 28, 2012, 3:46 AM UTC

acdha wrote: post #52

peterwwillis wrote: post #29

A long time ago I used to have a general purpose server on a DSL line with port 22 open. I thought everything was fairly secure, patched up, etc... I never thought brute forcers would be able to guess one of my accounts (which was a friend's account actually). The kicker? The password was the username. I found out about the rootkit a few days after they got in. I tell ya, kids these days just don't know how to hide a…

Or use only public-key authentication. I've run many internet-exposed servers for years without problems or kludgy obscurity measures like port knocking simply by disabling all forms of password authentication. This is faster, easier and has the advantages of not requiring non-standard client software, being observable by an attacker on the same network, and avoids the sort of rote password entry which causes mistake…

With public key only authentication, how does a user get their public key on to the server in the first place?

I ask because I have two servers, one I am a client at DreamHost and I can't configure their sshd daemon, the second is my own VPS where I am root.

Re: Observations from two weeks of SSH brute force attacks

#55

Post by acdha » Sun, Jan 29, 2012, 1:08 AM UTC

Nick_C wrote: post #54

acdha wrote: post #52

Earlier quoted context omitted.

Or use only public-key authentication. I've run many internet-exposed servers for years without problems or kludgy obscurity measures like port knocking simply by disabling all forms of password authentication. This is faster, easier and has the advantages of not requiring non-standard client software, being observable by an attacker on the same network, and avoids the sort of rote password entry which causes mistake…

With public key only authentication, how does a user get their public key on to the server in the first place? I ask because I have two servers, one I am a client at DreamHost and I can't configure their sshd daemon, the second is my own VPS where I am root.

You only need the ability to write to a file in your home directory. In the case of a VPS you could do that before editing the sshd config (in large environments this is trivially automated as part of your install process, which is why e.g. Ubuntu EC2 images ship with public-key-only SSH by default).

In the case of a shared server you can't disable password auth, which is a powerful argument for using a unique password since that system is far more likely to be compromised.