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)

[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

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

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.

Probably best to just whitelist SSH to known IPs.

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...)

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

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

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.

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://danielmiessler.com/blog/security-and-obscurity-does-c...

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.

'hunter2' is in the list.

Adminstrator would then set a new password by an accident.

My theory anyways.

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?

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.

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.

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

http://mwkworks.com/onsheepwolvesandsheepdogs.html

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

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".

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.)

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 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.

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

    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)

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.