Securing SSH

[jdow]

That is NOT what I consider a comfortable idea while I am on the road,
guillermo. The configuration I have simply rate limits attempts. So if
I screw up due to a keyboard with no capslock on it that I use with my
laptop, I am not permanently locked out. I can wait a couple minutes
and get in. (I also do this with pop3s and imaps. I REALLY want to be
able to get in from wherever I am likely to travel. Erm, I do tend to
lock out parts of the world I do not expect to visit. Most of Asia is
now blocked in front of my little tool as I discover netblocks that
make the attempts. It's interesting that few if any other parts of
the world seem to be running attacks. For every one attempt from say
the US I get two dozen from Asia. I'll have to unblock Southern
China soon. My partner's makeing a trip there for business in the
near future. I also maintain a permanent hole to ONE other address
on the net where I have a shell account. I figure that's safe and my
next level backup for getting in when I have to.)

I also trust the iptables firewall more than tcpwrappers, although I
keep both in the "circuit."

{^_^}    Joanne, color me paranoid.
----- Original Message ----- 
From: "Guillermo Garron" <ggarron at alketech.com>


>I can also recommend denyhosts
>
> yum install denyhosts
>
> when you fail n time the login via SSH your IP will be added to the /etc/hosts.deny/ you 
> can configure the "n" ...
>
> you can also configure it to avoid adding the IP of your office to the /etc/hosts.deny/ 
> even if you fail the logging, no matter how many times.
>
> This should mantain the hacker out of your system if you have a strong password for all 
> your users, and limit the "n"to a small number no dictionary attack should have success.
>
> hope it helps.
>
> regards,
>
> guillermo.
>
>
> jdow escribió:
>> From: "Brian D. McGrew" <brian at visionpro.com>
>>
>>> Good morning,
>>>
>>> I'm looking to tighten up my ssh configuration.  I have to have SSH open
>>> on the box at home so I can get to it from the office.  I've found
>>> several articles on securing ssh that include deny root access and
>>> require 'wheel' group membership for su.
>>>
>>> Is changing the port to something non-standard a good idea?  What else
>>> can I do; can someone point me to a good write up on it?
>>
>> At the risk of being tendentious about it this is the trick I found
>> works very well:
>>
>> ===8<---
>> $IPTABLES -A INPUT -p tcp --syn --dport 22 -m recent --name sshattack --set
>> $IPTABLES -A INPUT -p tcp --dport 22 --syn -m recent --name sshattack \
>>  --rcheck --seconds 120 --hitcount 3 -j LOG --log-prefix 'SSH REJECT: '
>> $IPTABLES -A INPUT -p tcp --dport 22 --syn -m recent --name sshattack \
>>  --rcheck --seconds 120 --hitcount 3 -j REJECT --reject-with tcp-reset
>> ===8<---
>>
>> Modify it to match your defines and names. I built my own set of rules
>> that have some special capabilities in them that I need. (I open a video
>> streaming hole when needed from another host on the system, for example.)
>>
>> What this does is prevent any site from making more than two tries in
>> 120 seconds. So far all attacks have been steady streams at VERY high
>> rates of connection attempt. They all get blocked after the first two.
>> Barring a cosmic accident with the right password being guessed right
>> off there's no chance of a break in even with ABCDefg as a password
>> before the Earth is engulfed by the Sun as the Sun ages. Even if they
>> get the 120 second rythmn going a decent password would be good just
>> an awesome long time. So it's not worth their efforts.
>>
>> {^_^}   Joanne
>>
>
> -- 
> fedora-list mailing list
> fedora-list at redhat.com
> To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list