nomb--thanks for the tips. I'm already rolling with pubkey auth only, and it is a big improvement. Will consider changing the port--it is an option since I'm the only one logging in remotely. OS X keychain is cool for pubkeys with passwords, btw...it even works for sftp clients--no fuss, no muss, just drops you right into the account. I was surprised the first time I tried to login with pubkey in OS X Term and the OS presented a dialog for the pubkey password (not bash)...and it offers a checkbox for storing the local pubkey password in the keychain. Nice.

Awesome, well if you are using pubkeys and have password auth turned off then you shouldn't really see any failed password attemps because if they don't try to connect with a key it will just drop it.

nomb

OK, so I have:

PermitRootLogin no
PasswordAuthentication no
#PubkeyAuthentication yes
ChallengeResponseAuthentication no
UsePAM no
AllowUsers [my login name] <---my login, not root


I was also curious why the daemon is logging the way it is with these settings--I'm assuming it is showing the user name in the auth failure because the user name is being passed as a parameter, yes? So then the name isn't in the AllowUsers list and the daemon reports the "not listed in AllowUsers" entry...

Aside from some sort of url/parameter list overload or exploit to the daemon, with these settings, the cracker would need to know your private and public keys AND AllowUsers name to gain entry, correct? And given the two key sizes, aside from an act of the almighties, the chances of brute force are beyond the realm of possibility.

Unless an exploit is discovered in the handling of the public / private keys you are correct. But that is what privileged separation is suppose to help you with. There is also the possibility of a man-in-the-middle attack but someone would really have to want to be after you.

nomb