Improving Protection on SSH Connections

Improving Protection on SSH Connections - Printable Version

+- Linux-Noob Forums (https://www.linux-noob.com/forums)
+-- Forum: Linux Server Administration (https://www.linux-noob.com/forums/forum-8.html)
+--- Forum: Remote Access (https://www.linux-noob.com/forums/forum-88.html)
+--- Thread: Improving Protection on SSH Connections (/thread-2522.html)

Improving Protection on SSH Connections - znx - 2005-07-31

=[ Intro

Nowadays SSH scans are a fact of life and as a linux user we must

continually improve the protection that we provide to our services to

ensure that we don't become another statistic. Fortunately enough SSH comes

with the ability to login using public and private keys instead of password

authentication. Whilst passwords can be guessed or cracked it is far less

likely that a key can be cracked. Hopefully this howto will be provide you

a step-by-step method to improving your SSH security, its important to note

that I am assuming that you already have SSH installed and running.

=[ Creating the Key Pair

First of all we need to generate our key pair, you do this on the machine

that you plan on connecting from.

==[ GNU/Linux Systems

Open up a terminal and type the following command:

Code:
   user@host:~$ ssh-keygen -t dsa

   Generating public/private dsa key pair.

   Enter file in which to save the key (/home/user/.ssh/id_dsa):

   Enter passphrase (empty for no passphrase): 

   Enter same passphrase again: 

   Your identification has been saved in /home/user/.ssh/id_dsa.

   Your public key has been saved in /home/user/.ssh/id_dsa.pub.

   The key fingerprint is:

   34:1f:94:0f:8f:28:0b:f8:17:ed:ce:cb:36:55:99:83 user@host

The default location is the ".ssh" folder inside your home directory, this

is where we want the files to be so accept that. At the point where it

asks for a passphrase, enter a strong password. This password is very

important, it protects the private key. If someone steals your private key

it will be unusable without your passphrase.

Once this is complete you will have a DSA key pair. You have the private

key (id_dsa) and the public key (id_dsa.pub) both stored in the .ssh folder

under your home directory. The public key is the key that we copy over to

the machine that you wish to connect to.

==[ Windows Systems (Putty)

You will need to have installed putty via the installer as this gives us

the program that we require to run to generate our keys.

Start up PuTTYgen.

Select SSH2 DSA from Parameters (at the bottom).

Click on Generate.

Wiggle the mouse around ion the blank space.

Alter the comment to be "user@host".

Add a passphrase (and retype it).

Save the public and private keys.

Start up Pageant.

Right-click on icon in the system tray, selecting Load key.

Type in your passphrase.

Now your Windows system is prepared to send the key to the server. Store

your private key somewhere safe.

==[ Sending the Public Key

With either the Windows machine or the Linux machine send the public key

you have created over to machine that you will be connecting to. Make sure

when you do this you use "scp" like this:

Code:
   user@host:~$ cd .ssh/

   user@host:~$ scp id_dsa.pub USER@SERVER:./id_dsa.pub

Replacing USER and SERVER with the details of the username and hostname of

the server you are connecting to. Windows machine should use WinSCP or

another similar utility. Using scp to copy over to the other machine ensure

that the data is encrypted, this protects the possiblity of someone

intercepting your public key during transfer.

=[ Setting up the Server

Ok so we now have everything we need prepared on the machine that we will

connect from and we have also sent the data required to the server. The

next step is to prepare the server for using public key authentication.

==[ Using a public key created by 'ssh-keygen'

Login to the server as you would usually and then execute these commands:

Code:
   user@server:~$ cd .ssh

   user@server:~$ touch authorized_keys

   user@server:~$ chmod 600 authorized_keys

   user@server:~$ cat ../id_dsa.pub >> authorized_keys

   user@server:~$ rm ../id_dsa.pub

This has placed the public key into the 'authorized_keys' file, this is a

file that SSH checks for when a user connects and any key in it is

available for testing with public key authentication.

==[ Using a public key created by 'PuTTYgen'

Unfortunately the layout of the key that PuTTYgen creates differs from the

layout that SSH (on Linux) excepts, this means that we need to edit the

public key to make it usuable under Linux. Fortunately enough its not too

hard.

Open the public key that you created, it will look something like this:

---- BEGIN SSH2 PUBLIC KEY ----

Comment: "user@host"

AAAAB3NzaC1kc3MAAACBANmj5ago5F/QP50X2nxD9FkSIDFoSVv1KavQNjlONStv

PuJvF1AQLcDYjGrtFnK8Wn7sEzz1VZcOYTDq6pxy0xDyoQLjYTWVpVM3vVLETfJc

XVNejswt6SGshEW4R1Ys9xKaTPwRejEHe8FLqEkapTCj56dp47J5JOHs4b8SkAPl

AAAAFQD89oWHllh2NDH0lIiEwqts0RArzwAAAIBAflemdNoJwPn6ayVyYNM2bO0p

szzguxKstAvEyojWuIo4srYqUj8c6x6QqLxIvjwi94J8BEDvo7+rmG2PLSwM5Ovm

jyfHUpPD+c6iPLvioGfwQB+B0M/E1frkwteophR9P1Jf1seRDemKL3pY37jdYpq7

NCsJhiMy/NGntcgoagAAAIEAmyxLKQpBDQ8nUT1Fv+YhdBgCWIDQixgwcGZJjJ3d

AiHyDlJ5jXp6ba4ccS5FW2F068yoLY3uQNh1Jt+aUrFyZoc33rrrk34czLK4FKNp

M9V2+KTI8EL/1JeM3/jjl9IhZTLRzSaQinKA5SAXhYnXxfFPlhPislY968Kzag0J

Dag=

---- END SSH2 PUBLIC KEY ----

You should edit the file to make it look like this:

ssh-dss AAAAB3NzaC1kc3MAAACBANmj5ago5F/QP50X2nxD9FkSIDFoSVv1KavQNjlONStvPuJvF1AQ

LcDYjGrtFnK8Wn7sEzz1VZcOYTDq6pxy0xDyoQLjYTWVpVM3vVLETfJcXVNejswt6SGshEW4R1Ys9xKa

TPwRejEHe8FLqEkapTCj56dp47J5JOHs4b8SkAPlAAAAFQD89oWHllh2NDH0lIiEwqts0RArzwAAAIBA

flemdNoJwPn6ayVyYNM2bO0pszzguxKstAvEyojWuIo4srYqUj8c6x6QqLxIvjwi94J8BEDvo7+rmG2P

LSwM5OvmjyfHUpPD+c6iPLvioGfwQB+B0M/E1frkwteophR9P1Jf1seRDemKL3pY37jdYpq7NCsJhiMy

/NGntcgoagAAAIEAmyxLKQpBDQ8nUT1Fv+YhdBgCWIDQixgwcGZJjJ3dAiHyDlJ5jXp6ba4ccS5FW2F0

68yoLY3uQNh1Jt+aUrFyZoc33rrrk34czLK4FKNpM9V2+KTI8EL/1JeM3/jjl9IhZTLRzSaQinKA5SAX

hYnXxfFPlhPislY968Kzag0JDag= user@host

Notice that this is all on one line, the comment is now at the end and the

addition of the words "ssh-dss" to the beginning.

=[ Logging in with Public Keys

Now you can try logging in again, this time you will experience a slightly

different look:

Code:
   user@host:~$ ssh -l USER SERVER

   Enter passphrase for key '/home/USER/.ssh/id_dsa':

   Linux SERVER 2.6.12.3 #1 Sun Jul 31 23:08:02 UTC 2005 i686 GNU/Linux

   You have new mail.

   Last login: Sun Jul 31 22:12:32 2005 from HOST

   USER@SERVER:~$

Using Putty is a matter of loading the private key into Pageant and then

connecting as normal.

=[ Disallowing Password Logins

Now that we have secured the server using public key authentication we no

longer need, nor want, password authentication. Simply open up your

sshd_config file (/etc/ssh/sshd_config) and edit this line:

# PasswordAuthentication yes

Change to:

PasswordAuthentication no

UsePAM no

Thats it, your SSH server will now only accept public keys and will simply

refuse all password attempts (even the right password won't get you in :)).

=[ Final Ideas

Tired of typing in the passphrase all the time? Linux has that covered too:

Code:
   user@host:~$ eval `ssh-agent -s`

   Agent pid 12719

   user@host:~$ ssh-add /home/user/.ssh/id_dsa

   Enter passphrase for /home/user/.ssh/id_dsa

   Identity added: /home/user/.ssh/id_dsa (/home/user/.ssh/id_dsa)

   user@host:~$

Now it will last as long as ssh-add is running, you can lock and unlock the

agent, you can also set a life time for how long it should store the

key in its memory, cool!

Improving Protection on SSH Connections - seeno - 2005-08-01

brilliant tutorial, keep up the good work! :)

Improving Protection on SSH Connections - anyweb - 2005-08-01

moved to correct area of the forums and pinned.

cheers

anyweb

Improving Protection on SSH Connections - xDamox - 2005-08-01

Good tutorial znx :)

Improving Protection on SSH Connections - znx - 2005-08-01

Quote:brilliant tutorial, keep up the good work! :)

cheers!

Quote:moved to correct area of the forums and pinned.

cheers!

Quote:Good tutorial znx :)

CHEERS!

hehe B)

Improving Protection on SSH Connections - znx - 2005-08-04

after muttering to omnix.. i've decided to add this little bit about the choice of keys...

under the ssh2 protocol (please tell me that NOONE runs ssh1 anymore) you have a choice of keys.. dsa or rsa. i choose to put dsa about, this is the patent free option (patents are EVIL [img]<___base_url___>/uploads/emoticons/default_ph34r.png[/img] da patent) or rsa.

after a little thought, rsa is the stronger key and it might make more sense for people to use rsa .. as quoting from putty's docs:

Quote:The PuTTY developers _strongly_ recommend you use RSA. DSA has an intrinsic weakness which makes it very easy to create a signature which contains enough information to give away the _private_ key! This would allow an attacker to pretend to be you for any number of future sessions. PuTTY's implementation has taken very careful precautions to avoid this weakness, but we cannot be 100% certain we have managed it, and if you have the choice we strongly recommend using RSA keys instead.

If you really need to connect to an SSH server which only supports DSA, then you probably have no choice but to use DSA. If you do use DSA, we recommend you do not use the same key to authenticate with more than one server.

says it all really.. ;)

Improving Protection on SSH Connections - dspln - 2005-12-05

Quote:Nowadays SSH scans are a fact of life...

My server had been up for 3 days before this got logged:

Quote:...Nov 20 06:05:43 tek1 sshd[20041]: Invalid user aaa from 211.192.139.21

Nov 20 06:05:44 tek1 sshd[20046]: Invalid user qqq from 211.192.139.21

Nov 20 06:05:46 tek1 sshd[20051]: Invalid user www from 211.192.139.21

Nov 20 06:05:47 tek1 sshd[20056]: Invalid user eee from 211.192.139.21

Nov 20 06:05:49 tek1 sshd[20061]: Invalid user rrr from 211.192.139.21

Nov 20 06:05:50 tek1 sshd[20066]: Invalid user ttt from 211.192.139.21

Nov 20 06:05:52 tek1 sshd[20071]: Invalid user yyy from 211.192.139.21

Nov 20 06:05:53 tek1 sshd[20076]: Invalid user uuu from 211.192.139.21

Nov 20 06:05:55 tek1 sshd[20081]: Invalid user iii from 211.192.139.21

Nov 20 06:05:56 tek1 sshd[20086]: Invalid user ooo from 211.192.139.21

...

;)

I did exactly as you did, including switching to rsa after I read the warning in Putty :)

I also use Putty Authentication Agent (PAGEANT.EXE) - to avoid retyping passphrases.

The one problem I have with sshd is, I changed it to run on a different port (6022), and ssh works fine, but sftp won't connect. Anyone know why this might be?

I also allow only my homeip to connect:

iptables -I INPUT -s ${homeip} -p TCP --dport 6022 -j ACCEPT

My home ip is DHCP, but it only changes when I change the router (like switching from a Linksys home router to a gentoo homebuilt router :)).

So in case my ip does change again, I added port knock to the server to allow the new address in

/etc/knockd.conf

Code:
[options]

    logfile = /var/log/knockd.log

[openMain]

    sequence    = 7000,8000,9000

    seq_timeout = 15

    command     = /usr/util/knockset.sh open %IP%

    tcpflags    = syn

[closeMain]

    sequence    = 9000,800,7000

    seq_timeout = 15

    command     = /usr/util/knockset.sh close %IP%

    tcpflags    = syn

/usr/util/knockset.sh

Code:
#!/bin/bash

#knockset.sh called from /etc/knock.conf

ports="8888 pop3s imaps https http domain smtp 6022"

ip=$2

doports () {

for p in $ports; do

    iptables -$IorD INPUT -s $ip -p TCP --dport $p -j ACCEPT

done

iptables -$IorD INPUT -s $ip -p UDP --dport domain -j ACCEPT

iptables -$IorD INPUT -s $ip -p icmp -j ACCEPT

}

open() {

IorD="I"

doports

}

close() {

IorD="D"

doports

}

case $1 in

open) open;;

close) close;;

[?]) print >&2 "Usage $0 [open] [close] ip.address.to.change"

    exit;;

esac

Improving Protection on SSH Connections - znx - 2005-12-05

Quote:I did exactly as you did, including switching to rsa after I read the warning in Putty :)

I also use Putty Authentication Agent (PAGEANT.EXE) - to avoid retyping passphrases.

The one problem I have with sshd is, I changed it to run on a different port (6022), and ssh works fine, but sftp won't connect. Anyone know why this might be?

sftp works through the same system as ssh, so if you can ssh you can sftp. this means that the only other thing it could really be would be something missing in the config (/etc/ssh/sshd_config):

Code:
Subsystem sftp /usr/lib/misc/sftp-server

This is required, I believe the default has it disabled :/ ? sftp basic just binds you to a different system once you have logged in with ssh.

ace about the port knocking, I played with it for a bit but sort of always didn't care much for "security through obscurity"..

Improving Protection on SSH Connections - znx - 2006-05-06

Quote:The one problem I have with sshd is, I changed it to run on a different port (6022), and ssh works fine, but sftp won't connect. Anyone know why this might be?

Just came back to this and had another though, are you selecting the port for sftp to work on?

Code:
sftp -oPort=6022 user@host.com