Patch to Log SSH Passwords – One Year Results | Hacker News Reader

Patch to Log SSH Passwords – One Year Results

w8rbt.org

81 pointsw8rbt59 comments

So, some stats:

There's 350,032 unique passwords in there.

* 122,094 (~35%) are in the rockyou dump (which has 14,344,391 unique entries) * 2898 passwords in my list of cracked linkedin passwords, excluding those in the rockyou dump (2,002,484 unique entries) * 27,639 are in the phpbb dump i have (184,344 unique entries)

I also detected 1893 palindromes out of 350064 total lines. Finally a (laughable) real-world use for my palindrome detection project[1].

[1] https://github.com/montanaflynn/palindromes/

Edit: I also pulled some more stats out of just the passwords:

  Total characters: 2938676
  Average character count: 8.39544955889747
  Median character count: 6
  Maximum character count: 294

Sorry about the formatting there sucking. :-(

If you're running an ssh server that allows password authentication, make sure you're also running fail2ban.[1] Too many failed login attempts will block the IP (at an iptables level) for a configurable time period.

[1]: http://www.fail2ban.org/wiki/index.php/Main_Page

You also might want to consider changing your SSH Port

http://danielmiessler.com/blog/security-and-obscurity-does-c...

As the author of that post says it greatly reduces the login attempts. It has been my experience as well.

An analogy with a house it would be like making a brick wall behind your front door and making a new door on the side of the house.

Sure, it would not change significantly the time for a determined thief wanting your house specifically,.

However moving the door would do wonders against some punk with a bunch of keys who runs around trying them on all neighborhood doors.

You still have to make sure you have a good lock and door.

I like pam_shield, personally.

https://github.com/jtniehof/pam_shield

Back in the day, disabling password auth but leaving keyboard_interactive on would stop a lot of these things, but I don't think that's true any more.

If you're going for a security plan of obscurity (which, IMO, is what fail2ban is), I'd just change the SSH port, instead.

Now I'm confused. Why do you consider blocking someone that clearly is trying to brute force his way in 'obscure'?

You're right, it's not.

If you don't improve the 'hardness' of the authentication scheme - that is, if you continue to use a password instead of, say, SSH keys - then, for all intents and purposes, you've just made the system more _obscure_, rather than improving _actual_ security.

To be sure, a dedicated brute forcer could still brute force any system using f2b... it just might take a few months/years instead of a few days.

(However, as noted by other commenters, there's something to be said about obscurity within a system's overall security scheme. You just have to strike a balance...)

It's not obscurity, it's rate limiting.

Obscurity is a perfectly legitimate and valid security technique.

Relying on obscurity alone is the mistake you are alluding to.

Why wouldn't you recommend using fail2ban and changing the port?

>Relying on obscurity alone is the mistake you are alluding to.

Ok, sure.

>Why wouldn't you recommend using fail2ban and changing the port?

IMO, changing the port will have nearly the same overall effect as f2b: minimizing the number of failed password attempts from unknown users.

To that end, changing the port is changing one value in a config file, which has the attractive advantage of being far simpler to setup + maintain.

I can confirm that changing the port does drastically reduce login attempts but also that it is not to zero, I had 45 yesterday, for instance but here's the kicker - all from the same IP.

Setup and maintenance are virtually zero though, for f2b. I know, I just installed it.

A one liner to install on most systems and updates along with everything else when your package manager does the updates.

http://www.cvedetails.com/vulnerability-list/vendor_id-5567/...

Probably best to just whitelist SSH to known IPs.

Curious what you are pointing out here? Just the number? 8 security vilnerabities? What's the count at which I am supposed to stop using a product?

I assume that he's pointing out that even better than running something like fail2ban (or "pf", where available) is not allowing SSH connections from 0/0.

On the BSDs, you can use "pf" to do this as well with the (minor) advantage that it doesn't require installing another piece of software.

You can do the same with nothing more than iptables on Linux (using "recent").

I'll save you the time of downloading the full results.

'hunter2' is in the list.

How come when I type "hunter2" it comes up "*"?

I wonder what's up with all the super long entries in there. Bugs in the bots?

I'd guess that they're unique passwords taken from plain text password dumps that ended up in dictionaries.

It looks like ever wrote the scanner (that hit this honeypot) thought it would be a great idea to count on instances where terminal becomes laggy/crashes during a password change.

Adminstrator would then set a new password by an accident.

My theory anyways.

Wait, who is logging SSH passwords? Is this an intentional attack on OpenSSH Portable or is it a honeypot?

Sheep dogs and wolves. The sheep have no idea. If you are asking the question, take a deep breath and say, "bah".

Yeah. Bah at you all day long.

http://dilbert.com/strips/comic/1996-07-27/

I thought people would understand the reference I was making, but it totally failed... my apologies. It's a good read.

http://mwkworks.com/onsheepwolvesandsheepdogs.html

Hang any SSHD on the internet, and within minutes you get these attempts. You can choose to log the passwords if you like and this is what you would see.

Wow you're right. I just setup my own VPS yesterday. Decided to check the auth logs and the first invalid user attempt occurred less than 3 hours from my first login.

The "POSSIBLE BREAK-IN ATTEMPT!" message worried me for a bit but a little googling and the fact I've disabled password login calmed me down.

Presumably, changing my sshd port will drastically reduce these attempts right? Or do attackers routinely port scan servers?

I changed my port from 22 to a higher one and the user attempts are completely gone.

Only nuisance is that the higher ports may be blocked, for example my uni blocks my new ssh port so I can't connect to the vps when I'm on campus.

If you don't host any https websites on the VPS, using 443 will almost always get past port blocking.

Or just use both :) https://dgl.cx/2010/01/haproxy-ssh-and-ssl-on-same-port

Another choice is port 8080.

Yes, most of the time i use a different port than 22 and the noise all but dissapears.

Mind you it isn't that this is a defense, but it gets the drive-by scanning stuff out of the log.

By all means disable password login, and all direct root login.

I just don't know why people still use passwords with SSH anyway! (ie userify and stuff)

Not sure why you're getting downvotes. I use key authentication for all my SSH needs.

If it's important enough to still need a password on top of that, the password can go on the key.

Huh? Always encrypt the ssh-key, and use ssh-agent for convenience. That said it is now quite easy to set up proper two-factor authentication: eg key and otp.

On OS X, the keychain app caches the private key password forever. Even after a reboot. Any idea how to fix this? Ideally Keychain should ask me again (say) an hour after my last login with the same key.

I don't think you can set this at a key-specific level, but in Keychain Access, you can ctrl-click on the keychain and set it to lock after x min of inactivity / when sleeping.

I'm not sure if you can put your ssh keys on a specific (non-login) keychain.

If you want those, you may want to go to Keychain Access > Preferences > First Aid > uncheck "Keep login keychain unlocked".

You can drag-and-drop items between keychains -- you just need to enter the passwords for both keychains when doing so.

This makes it possible to keep valuable items in one or more auxiliary keychains set to always prompt (lock after 0 minutes). (This technique isn't a panacea but it contributes to defense in depth.)

Brilliant, I didn't know you could lock them.

However, it doesn't solve the agent caching problem. Once a key has been added the agent, Keychain never asks again, even after it's locked.

ssh-add has an option "-t <seconds>" to make added keys automatically expire. That will work, but it only works for newly added keys. As far as I can tell, the Keychain helper calls ssh-add to add keys, and I don't see a way to have it pass -t.

Edit: Looks like holmar's suggestion below to change the ssh-agent daemon to run with -t would fix this.

I'm using this here: http://apple.stackexchange.com/questions/118223/make-my-pass...

well, for generating/uploading your key, you need a password.

When I was first introduced to SSH, the administrator had me transmit my public key to them and they added it to my account themselves, and that's how I've done it on all the servers I administrate since. This way, you can disable password authentication entirely.

Who is proposing using passwords for SSH is a good idea? This is a honeypot.

It's just a honeypot, not a real server with password-based auth.

At work we have to send data to a few third parties, it's pretty much up to them how they set up their end. I think everything is using SFTP at least, but a few still have passwords rather than keys. The accounts are restricted so you can't get a full shell though. My guess is these systems are designed by non-technical people who don't really understand the issues.

https://home.regit.org/2014/06/pshitt-collect-passwords-used...

Use 2 factor auth with ssh via Yubikey or TOTP and it doesn't matter if they try to brute force you

I'm considering using those yubikey modes for ssh or local login on certain servers and in certain situations, though it requires some changes on each server to enable it.

I'm quite fond of the Yubikey NEO's openpgp applet paired with gpg-agent's ability to act as a compatible ssh-agent, allows standard SSH key login to any server with no server changes at all. I love the idea of my GPG and SSH key being truly portable in a very reasonably sized formfactor as well.

Really no passwords with spaces in them, or a data-preparation error?

Defeat shoulder surfers -- just use n spaces and m spaces to spell your password in morse code, appearing as all spaces.

I would be curious to know why this got downvoted. I went looking for "correct horse battery staple" and then realized that apparently the bots hadn't tried any passwords with spaces in them, but also that the patch uses spaces as a delimiter...

Damn! I was certain nobody would guess my password of eight commas.

Shit!! Someone guessed my password as well, on line 1120!

    000000.000000000**0000000000000000000ooooo000111222333000OOO00OO0O0O0011447700384zxh.007Martin00idc805188..e0102030114110123.01234.01234.*012345601234567.*0123456789!@0123lhb0123014785236901601hr0205\\023022-58810235025516700270301fjfzw1=-03110368350037804047

I thought for sure a 260-character password with 1,560 bits of entropy would be sufficient. I better go change it right away :O

use ssh keys or use iptables whitelisting on all your boxes

Alternatively or in addition, add a firewall rule to permanently ban any IPs after too many failed attempts or simultaneous connections, make sure root login is disabled, and/or put sshd on a non-standard port (I find the last one a bit of security theater, but it will reduce some wasted traffic if nothing else.) Here's my pf rule for ssh (brute force filter):

    table <sshbans> persist
    block quick from <sshbans>
    pass quick proto tcp from any to any port ssh \
      flags S/SA keep state \
      (max-src-conn 15, max-src-conn-rate 5/3, \
      overload <sshbans> flush global)

Raise the values a bit if you have other SSH users on your box.

I get about 50 new bans a day. It's pretty much guaranteed if you have a server on the web with port 22 open, that bots will be attempting to brute-force it.

Reply on news.ycombinator.com