I'm not really a programmer and I recently came across this hack to insert a short sleep statement into auth-passwd.c within sshd. It seems to quickly confuse automated dictionary attacks. I've moved sshd to higher ports but apparently the cretins are now scanning to look for that and attacking on whatever port sshd shows up on. Anyway, the link to the hack is here: http://www.aerospacesoftware.com/ssh-kiddies.html Just wondering if any of the wizened programmers out there can think of any reason why this would be a bad thing to do. Cheers,
On Fri, 2006-03-10 at 16:32 -0500, Chris Mauritz wrote:> I'm not really a programmer and I recently came across this hack to > insert a short sleep statement into auth-passwd.c within sshd. It seems > to quickly confuse automated dictionary attacks. I've moved sshd to > higher ports but apparently the cretins are now scanning to look for > that and attacking on whatever port sshd shows up on. > > Anyway, the link to the hack is here: > > http://www.aerospacesoftware.com/ssh-kiddies.html > > Just wondering if any of the wizened programmers out there can think of > any reason why this would be a bad thing to do. > > Cheers,Other than remembering to put it back in when you upgrade each time? Probably a better course of action is to use strong passwords or better yet setup keys. Then it does not matter much how long or hard they guess passwords. You just have to ignore the noise in your log files. You could try port knocking. There are few implementations of that available and should reduce or eliminate the problem. But IMHO the best thing to do is make sure you use keys or at least good strong passwords, disable root ssh access, limit ssh to specific users. And ignore the noise in the logs.
On 3/10/06, Chris Mauritz <chrism at imntv.com> wrote:> I'm not really a programmer and I recently came across this hack to > insert a short sleep statement into auth-passwd.c within sshd. It seems > to quickly confuse automated dictionary attacks. I've moved sshd to > higher ports but apparently the cretins are now scanning to look for > that and attacking on whatever port sshd shows up on. > > Anyway, the link to the hack is here: > > http://www.aerospacesoftware.com/ssh-kiddies.html > > Just wondering if any of the wizened programmers out there can think of > any reason why this would be a bad thing to do.Messing with sshd source isn't something I'm ready to play around with. I'd rather farm it out to a 3rd party wrapper like denyhosts to block this crap. -- "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety'' Benjamin Franklin 1775
Chris Mauritz wrote:> I'm not really a programmer and I recently came across this hack to > insert a short sleep statement into auth-passwd.c within sshd. It > seems to quickly confuse automated dictionary attacks. I've moved > sshd to higher ports but apparently the cretins are now scanning to > look for that and attacking on whatever port sshd shows up on. > Anyway, the link to the hack is here: > > http://www.aerospacesoftware.com/ssh-kiddies.html > > Just wondering if any of the wizened programmers out there can think > of any reason why this would be a bad thing to do. > > Cheers, > > _______________________________________________ > CentOS mailing list > CentOS at centos.org > http://lists.centos.org/mailman/listinfo/centos > >you can try this : http://la-samhna.de/library/brutessh.html#3 Leonel
Because I am the only one who needs ssh access, I just install apf as a firewall, permit the ports I need the public to access, and deny ssh. Then I whitelist my own source IP "apf -a myip" and that ends the problem. -- Chris Mason -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
On Fri, 2006-03-10 at 16:32 -0500, Chris Mauritz wrote:> I'm not really a programmer and I recently came across this hack to > insert a short sleep statement into auth-passwd.c within sshd. It seems > to quickly confuse automated dictionary attacks. I've moved sshd to > higher ports but apparently the cretins are now scanning to look for > that and attacking on whatever port sshd shows up on.I dealt with these attacks by only allowing PubkeyAuthentication. # Authentication types PubkeyAuthentication yes AuthorizedKeysFile .ssh/authorized_keys PasswordAuthentication no ChallengeResponseAuthentication no This requires you to put your public key in .ssh/authorized_keys on remote servers. Make sure it's working before you set "PasswordAuthentication no" or you will lock yourself out. -David
Scot L. Harris wrote:>My question >was, if the known_hosts file is hashed how do you identify the entry for >the particular host so it can be removed when needed?The warning message tells you the line number of the entry in the known_hosts file: Add correct host key in /home/rmy/.ssh/known_hosts to get rid of this message. Offending key in /home/rmy/.ssh/known_hosts:22 RSA host key for localhost has changed and you have requested strict checking. Host key verification failed. Ron