On Sunday 04 October 2009 03:52:59 am Per Jessen wrote:
David C. Rankin wrote:
On Saturday 03 October 2009 06:21:32 am Per Jessen wrote:
Has anyone else noticed the wave of coordinated, distributed ssh attacks? Since Sep30 around 2100CET, I see a login attempt about once a minute, but coming from different IP-addresses. Looks like a coordinated attempt to circumvent the firewalls that block based on too many unsuccessful attempts.
/Per
Per,
Have you moved ssh to a high port yet? If you do, all noise on your ssh port will cease. Worth its weight in gold!
Until this distributed attack my regular method of blocking based on number of attempts from a single IP has worked just fine, but yes, I've now moved sshd to another port on all my external systems. The local systems don't allow external ssh access. I'm still considering moving to the no-password-login setup as Hans Witvliet suggested. It's clearly the optimal solution, I'm just a little concerned about the management when each server needs to "know" about (need to have the key) each possible client.
/Per
Per, That's the best part about it. On each host, just do cd ~/.ssh ssh-keygen -t dsa cp id_dsa id_dsa.hostname cp id_dsa.pub id_dsa.pub.hostname do the same thing for root but append an r to the end of the names (id_dsa.pub.hostnamer). Next, collect you public keys in one location on a box that you can reach from the lan. I just use ~/.pkeys. Then create an "authorized_keys" file that contains all the public keys. I just use a small script placed in the same directory as the keys that searches the directory and automatically adds any new keys in the directory to an authorized_keys file and then distributes it to the hosts on my network vi copy or rsync: http://www.3111skyline.com/download/linux/scripts/config/newkey-example.txt Another handy script for the clients is "rokey" (short for remove offending key). If a box is reloaded, etc. and you need to remove the key from your from ~/.ssh/known_hosts due to strict check being enabled, then just simply type: rokey key-number Where key-number is the number in the error message on the terminal. (just saves work;-) http://www.3111skyline.com/download/linux/scripts/config/rokey.txt Once you are all setup, then edit /etc/ssh/sshd_config and disable challenge/response and password authentication and you are done. No more password attempts will be allowed regardless of which port ssh is on. But, if ssh is on a high port, then you don't even get anything in the logs :p PasswordAuthentication no ChallengeResponseAuthentication no (don't forget the put your host/port combinations in either /etc/ssh/ssh_config (system wide) or ~/.ssh/config at the user level. Example:) Host alchemy.yourDomain.com alchemy Port 22 Host archangel.yourDomain.com archangel Port 10201 Host arete.yourDomain.com arete Port 10202 Host ecstasy.yourDomain.com ecstasy Port 10203 Host killerz.yourDomain.com killerz Port 22 Host dcrgx.yourDomain.com dcrgx Port 22 Yes the Port 22 defs are required, and you have to put Host on one line and Port on the following line. Then the port change is transparent for all ssh,rsync,scp,etc.. work. With sftp, you still have to specify the port number: sftp://host.domain.com:10203/home/per/... This may have already been covered, but if you want to limit ssh access to members of a specific group, you can do something like this with the AllowGroups parameter: AllowGroups wheel -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org