Securing SSH

aah ok.
But that's something he should either not use if necessary, or rather
secure with a .htaccess password.

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--==============52930982=Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature";
boundary="------------enig20483C4CC40E0EAA6E0B6BD4"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig20483C4CC40E0EAA6E0B6BD4
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

on 3-25-2008 11:28 AM Tim Alberts spake the following:
> David Mackintosh wrote:
>> On Tue, Mar 25, 2008 at 09:48:17AM -0700, Tim Alberts wrote:
>>  
>>> So I setup ssh on a server so I could do some work from home and I
>>> think the second I opened it every sorry monkey from around the world
>>> has been trying every account name imaginable to get into the system.
>>>
>>> What's a good way to deal with this?
>>>     
>>
>> This is what I do.
>>
>> http://wiki.xdroop.com/space/Linux/Limited+SSH+Access
>>
>>   
> That sounds great for getting around a remote dynamic IP address, but
> some more authentication/security on that web page is necessary,
> otherwise, anyone who finds that web page is given access?
Not really. Anyone who finds that page is only allowed to try and "access" ssh
port. You still need valid key/password and proper knowledge of the port.

Strictly speaking, yes; however in practice, the number of bots (or,
indeed, external users who are not me) who the magic web page to hit
(my actual page is not named as the example on the web page is!)
before attacking the ssh connection is zero; therefore since the goal
was to prevent stupid robots from brute-forcing my ssh and filling my
logs, it isn't necessary.  

I mean, strictly speaking you'd next have to insist on a proper SSL
connection to the web server, otherwise you are at risk of someone
sniffing the username and password used in the .htaccess process.
And then after that, you'd have to insist on some kind of security on
the remote system to ensure that your passwords are not being
captured.  Etc, etc.  

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--==============
01072332=Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature";
boundary="------------enig6CDFC5865A48318DA39510D9"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig6CDFC5865A48318DA39510D9
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

on 3-25-2008 11:46 AM Rudi Ahlers spake the following:
> John R Pierce wrote:
>> Rudi Ahlers wrote:
>>> Tim Alberts wrote:
>>>> ... sounds great for getting around a remote dynamic IP address, but
>>>> some more authentication/security on that web page is necessary,
>>>> otherwise, anyone who finds that web page is given access?
>>>>
>>>> _______________________________________________
>>>>
>>> Why?
>>> What is on that site which is very specific to the setup?
>>>
>>
>>
>> he's referring to YOUR controlling webpage, which they refer to as
>> my-sshd-access.php there.
>>
>>
>> _______________________________________________
>>
> aah ok.
> But that's something he should either not use if necessary, or rather
> secure with a .htaccess password.
>
Or just hide it and not name it "my-sshd-access.php". It is difficult to find
a web page you don't know exists if directory listing is off.

On Tuesday 25 March 2008 17:00:18 James A. Peltier wrote:
> Fail2Ban is a good brute force protector.  It works in conjunction with
> IPTables to block IPs that are "attacking" for a said duration of time.

And I can confirm that it's a doddle to set up.  The defaults were fine for 
me - nothing needed changing at all.

Anne

Scott Silva wrote:
> Or just hide it and not name it "my-sshd-access.php". It is difficult
> to find a web page you don't know exists if directory listing is off.


if you post your weblogs online, perhaps via an analysis package such as
Analog, DO be sure to exclude this file :)

I often create a hidden folder on my websites, named .secret or
something, and have any logging of activity in that folder directed to a
different private and secure log

Tim,

The important ones, imho --
1. disallow root login
2. disallow password authentication (use keys, as someone else has
described)
3. prevent multiple failed attempts using iptables:
# Log and block repeated attempts to access SSH
# See /proc/net/ipt_recent file for low-level data
# Block attempts to access SSH if 4 or more attempts made in the last 60
secs
-A RH-Firewall-1-INPUT -p tcp --syn --dport 22 -m recent --name
sshattack --set
-A RH-Firewall-1-INPUT -p tcp --dport 22 --syn -m recent --name
sshattack --rcheck --seconds 60 --hitcount 4 -j LOG --log-prefix "SSH
REJECT: "
-A RH-Firewall-1-INPUT -p tcp --dport 22 --syn -m recent --name
sshattack --rcheck --seconds 60 --hitcount 4 -j REJECT

4. if possible, limit ssh access to your static ip.

That all seems reasonably secure to me!

Liam

Is an option but a waste of time as a scanner will find the port it was moved
to.

>  2. use only SSH protocol 2

Agree

> 3. Install some brute force protection which can automatically ban an IP
>  on say 5 / 10 failed login attempts

Fail2ban comes to mind.

> 4. ONLY allow SSH access from your IP, if it's static. Or signup for a
> DynDNS account, and then only allow SSH access from your DynDNS domain

I would suggest using keys for logins.  No password needed and if the 
connecting machine doesn't have the key they don't get a chance to guess at
the password.

The idea of only allowing for strict ip address is good but what if you are on
the move?  Now you cannot log in either, but if you are using a key no matter 
where you are you have access.