Securing SSH

Yes you are right, you can get completly blocked if you missed your
options... what i do for this , is to have a second door. (another Linux
box) to wich i can go to.. and from this to the first and unblock me :)
but it depends on everyone wich option to take, anyway you are right,,,
mine is a little bit dangerous. :)
regards,
Guillermo.
jdow escribió:
> 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>