Secure SSH - How To

[tuxituk]

Originally Posted by Akoellh

Thanks mate, made me laugh very hard indeed.

How many breakins into servers are via SSH compared to breakins via, let's say ..... the web server?

So logically, one should also take the web server off port 80, right?

Standard ports are there for a reason, moving ssh may help you to have smaller logs, which is nice, but anything more -especially mentioned in context with security- is just not true and leads to a false sense of security.

- If your SSH is configured securely, login attempts will fail on any port, large logs are an annoyance, but no security risk.

- If your SSH is configured insecurely, it will be insecure and prone to _successful_ attacks no matter which port it is running on.

Scanning wide ranges of ports on wide ranges of machines is not at all a problem, "professional" attackers use bot nets for that, finding out, that there is an SSH-server running on $PORT is a piece of cake.

 nmap -sV localhost -p 2222

Starting Nmap 5.00 ( http://nmap.org ) at 2009-11-04 12:14 CET
Interesting ports on localhost (127.0.0.1):
PORT     STATE SERVICE VERSION
2222/tcp open  ssh     OpenSSH 5.1 (protocol 2.0)

Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 0.28 seconds

Ha,

Glad I amused you

If you allow scans of your ports then yes you will be in trouble.

Blocking scans is also easy via a simple snort installation or similar IDS.

In the context of ssh I would still state that moving the port is easy and wise.

[Akoellh]

Originally Posted by tuxituk

If you allow scans of your ports then yes you will be in trouble.

How do you want to prevent that?

The only thing you can prevent me from scanning you is by disconnecting my machine from the net.

Originally Posted by tuxituk

Blocking scans is also easy via a simple snort installation or similar IDS.

I doubt that snort etc. block regular traffic and scanning a port is regular traffic, if done the correct way, you can not distinguish it from normal requests.

Originally Posted by tuxituk

In the context of ssh I would still state that moving the port is easy and wise.

Agreed easy and agreed on wise for some cases (private server perhaps), but it is not a security feature per se, that's my point.

[tuxituk]

Originally Posted by Akoellh

How do you want to prevent that?

The only thing you can prevent me from scanning you is by disconnecting my machine from the net.



I doubt that snort etc. block regular traffic and scanning a port is regular traffic, if done the correct way, you can not distinguish it from normal requests.



Agreed easy and agreed on wise for some cases (private server perhaps), but it is not a security feature per se, that's my point.

Ok, I can't stop you scanning, but I can stop you getting useful responses to the scans..

Agreed the use of moving the port number in a security context is mute.

Cheer for the feedback

J

[growbag]

Most attacks come from lamer kids using port scanning progs that they download and run.

These progs mostly check all the low (read as default) ports to find something nice like port 22 open, and then launch a password crack attack.

If they don't find anything in those low ports, they simply move onto the next sucker because it takes far too long to can all 65000 ports.

The logs grow very big very fast, and having 3-4gigs of disk space wasted on logs will choke any system. Even if you have a seperate partition for /var, I wouldn't expect it to be over 10 gigs!

Changing a port number in a conf file is a cheap, quick, and easy way of avoiding many problems.

I understand that it isn't a security thing, but is a common sense thing. A bit like NOT wearing a "Gay Rights now" T-Shirt at a skinhead concert!

[KJ44]

I find ssh-copy-id easier than the scp ... incantation

NAME
       ssh-copy-id  -  install  your identity.pub in a remote machine's authorized_keys

SYNOPSIS
       ssh-copy-id [-i [identity_file]] [user@]machine

DESCRIPTION
       ssh-copy-id is a script that uses ssh to  log  into  a  remote  machine (presumably  using  a login password, so password authentication should be enabled, unless you've done some clever use of multiple identities)

[tuxituk]

Originally Posted by KJ44

I find ssh-copy-id easier than the scp ... incantation

NAME
       ssh-copy-id  -  install  your identity.pub in a remote machine's authorized_keys

SYNOPSIS
       ssh-copy-id [-i [identity_file]] [user@]machine

DESCRIPTION
       ssh-copy-id is a script that uses ssh to  log  into  a  remote  machine (presumably  using  a login password, so password authentication should be enabled, unless you've done some clever use of multiple identities)

Cool, didn't know about that. I will check it out.


thanks

[Akoellh]

Another remark, just found something (quite) important missing.

- The private key will be in ~/.ssh/id_rsa on your box (OK, that was not it).

- Make sure to restrict access to that key to your user _only_, so

chmod 600 ~/.ssh/id_rsa

If access is not restricted, you will get this:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0640 for '/home/axel/.ssh/id_rsa' are too open.
It is recommended that your private key files are NOT accessible by others.
This private key will be ignored.
bad permissions: ignore key: /home/axel/.ssh/id_rsa
Permission denied (publickey).

[cjcox]

On Tue, 2009-11-03 at 22:56 +0000, tuxituk wrote:
> Hi,
> Some quick points here for how to secure SSH. what do people think ?
>
> thanks.
>
> How To-
>
> _*Securing_SSH*_
>
> SSH is normally enabled by default on Linux installations, so it goes
> without saying that a few simple security measures are required to keep
> the box free from brute force attacks. These measures are part of the
> SSH configuration and no additional software is required.
>
> If the machine is to be public facing then as a minimum I always follow
> these steps:
>
> Change the port the daemon is running on
> Remove access to root
> Enable certificate public/private key authentication
> _*
> Change_the_port*_
>
> The SSH daemon defaults to port 22. Changing the port the daemon runs
> on is very easy and is one of the best steps to securing the SSH
> daemon.

This does not "secure" it. What it does do is obscures the location
from the "bots" and programs out there that attempt to pound on
ssh using brute force username/password techniques. Your firewall
logs will LOVE you!!
....snip...
> Now connect to the daemon on the new port to check access:
>
> ssh username@ipaddress -P 1322
>
> note the use of the capitalised P for inserting a new port number..

Sadly, the ssh client historically uses LOWERCASE -p whereas
the scp program uses UPPERCASE -P. Just an fyi...

....snip...
>
> Change the line to:
>
> PermitRootLogin no

Highly recommended. If for whatever reason you have to allow
remote root, specify without-password or (better) if it's to execute
something specific, use forced-commands-only.

....snip..

The rest about disabling tunneled clear text passwords...
definitely good...

[cjcox]

On Wed, 2009-11-04 at 07:36 +0000, Akoellh wrote:
> Sorry for having to add one remark of criticism.
>
> Changing the port does _not_ improve security and is certainly _not_
> one of the "best steps" but only an additional and optional one.
>
> It only improves "obscurity" and might help keeping the logs clean from
> automated login attempts which are part of the "background noise" of the
> Internet today.

Hmmm... I'd say reducing your log sizes by literraly GIGABYTES daily
is a good thing... yes??

Don't feed the bots...

It's #1 on "best steps" IMHO because, it's the step that most people
seem to consider "optional"... and it NEEDS to be required for
anything on the Internet.

99% of bot work is done using known info. If you aren't pingable
and don't answer to well known ports... they generally move away
and go somewhere else (you look "down" to them). So unless you
like your network interfaces getting pounded on... DON'T FEED THE BOTS!

[hendersj]

On Thu, 05 Nov 2009 22:05:41 +0000, cjcox wrote:

> Hmmm... I'd say reducing your log sizes by literraly GIGABYTES daily is
> a good thing... yes??

GB? That would seem to indicate a bad logrotate policy to me.

Jim

--
Jim Henderson
openSUSE Forums Moderator