Showing posts with label ssh. Show all posts
Showing posts with label ssh. Show all posts

Friday, 6 June 2014

Configure or Disable SSH

This is part of a series of articles on Red Hat Server Hardening.

SSH is the usual means of accessing and interacting with a server. Unless the keyboard and monitor are physically connected directly to the server, then access will most likely be via SSH. However, if SSH is not required, then disable it:
/sbin/chkconfig sshd off

The default SSH configuration means that automated cracking scripts and bots trying to break into a server know exactly where to go and what to do. They know the name of the root account, and they know they can SSH onto the server on port 22. The first line of defence is therefore to disable direct root access via SSH, and change the access port.

Changes to SSH are made via the SSH configuration file: /etc/ssh/sshd_config.

Prevent direct root login from SSH

In the config file, find the line that reads:
PermitRootLogin yes

Change yes to no. This prevents users from logging into the server as root via SSH. This adds an extra layer of security. Any hacker trying to get into root will have to get in as a normal user first, then try to access root from there. Warning: Make sure you have a regular user account first before doing this, otherwise you will not be able to access root.

Limit SSH access to a subset of users

If possible, limit SSH access to a subset of users. If there are many user accounts on the server, but only a few need to log into it via SSH, then doing this is a worthwhile exercise.This makes a hacker's job even more difficult because they will have to guess the both the name of an authorised user, and their password.

The AllowUsers parameter is not included in /etc/ssh/sshd_config by default, so it will need to be added:
AllowUsers john paul george ringo

Alternatively, create a group called sshusers and only add the users that need remote access:
groupadd sshusers
usermod -aG sshusers john
usermod -aG sshusers paul
usermod -aG sshusers george
usermod -aG sshusers ringo

Then, add the following line to /etc/ssh/sshd_config:
AllowGroups sshusers
Note:- The AllowUsers and AllowGroups parameters are mutually incompatible, with AllowUsers taking precedent.

Change the default SSH port

Change the default SSH port number of 22 to some other higher level port number.
Note:- The Internet Assigned Numbers Authority (IANA) is responsible for the global coordination of the DNS Root, IP addressing, and other Internet protocol resources. It is good practice to follow their port assignment guidelines. Having said that, port numbers are divided into three ranges: Well Known Ports, Registered Ports, and Dynamic and/or Private Ports. The Well Known Ports are those from 0 through 1023 and SHOULD NOT be used. Registered Ports are those from 1024 through 49151 should also be avoided too. Dynamic and/or Private Ports are those from 49152 through 65535 and can be used.
Choose an appropriate port, also making sure it not currently used on the system, and update the following line in /etc/ssh/sshd_config:
Port <New Port Number>
Make sure, obviously, that anyone who needs to ssh onto the server knows the correct port number. To log in, they will need to add -p <new port number> to the end of the ssh command.

Once all of the necessary changes have been made to /etc/ssh/sshd_config, restart the service so that these changes take effect.
service sshd restart

Wednesday, 14 May 2014

Running SSH From Within Cron

SSH does not run from within cron, because it is password authorised.

To get round this, use a script to generate the password prior to running the actual script, eg:
0 9 * * * . /.ssh-agent.sh; /home/milned/scripts/testntp.sh If the call of the ssh-agent.sh script (needed to supply the pass phrase) is omitted, it's just ssh being called inside the bash shell script.

Set Up SSH Agent Forwarding on a Server

This is part of a series of articles on Red Hat Server Hardening.

SSH is the Secure Shell protocol which can be used for command line access, file transfer and application tunnelling.

Overview

Password free access requires a public/private key pair. The server (sshd) has access to the public key, while only you and your SSH client have access to the private key. To authenticate the client convinces the server that it is in possession of the private key without actually sending it.

Private keys are protected by a pass phrase. This pass phrase is required each time the key is used. To allow repeated access without re-keying of the pass phrase, agent forwarding is used.

The SSH agent allows the pass phrase to be entered once only, e.g. at system start-up or in the originating shell and then caches the keys in memory, eliminating the need for the phrase to be entered for each access. Because the agent is forwarded the pass phrase is available for all sessions that can access the keys in the home directory, including chains of sessions.

Steps

The steps required to set up password free access are:
  1. Generate a key pair using OpenSSH
  2. Distribute public keys
  3. Configure agent forwarding

Generate SSH key pair

ssh-keygen is a program in the OpenSSH package that can be used to create key pairs. RSA is the current SSH key standard; DSA and RSA1 keys can be generated for compatibility with older systems.

Use the full path to ssh-keygen to ensure the correct OpenSSH binary is used, key in a pass phrase when prompted and accept the default file locations. 

> /usr/bin/ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/milned/.ssh/id_rsa):
Created directory '/home/milned/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/milned/.ssh/id_rsa.
Your public key has been saved in /home/milned/.ssh/id_rsa.pub.
The key fingerprint is:
77:3f:47:01:92:5f:d0:fe:3e:6a:03:a4:9a:0a:18:26 milned@nyssa

Similarly DSA and RSA1 keys can be generated. Again enter a pass phrase and accept the default file locations as prompted. Using the same pass phrase for all keys will simplify operation of the SSH agent. 

> /usr/bin/ssh-keygen -t dsa
> /usr/bin/ssh-keygen -t rsa1

Distribute SSH Public Keys

The public keys must be distributed to the user's authorized_keys file so that any SSH daemon with access to the user's home directory can use them.

> cd ~/.ssh
> cat *.pub > authorized_keys


Change the permissions on this file so it is not writable by other users.

> chmod go-w authorized_keys

Now check that key authentication is working, by using ssh to connect to the host you are currently logged in to using its hostname. You should be prompted for the pass phrase for one of your keys. If this is the first time you've talked to the machine you will also be asked to accept the host key, which you should do.

> ssh nyssa
The authenticity of host 'nyssa (127.0.0.1)' can't be established.
RSA key fingerprint is 85:4b:2a:53:48:52:9f:61:ed:0a:33:4a:9d:5e:d3:1a.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'nyssa' (RSA) to the list of known hosts.
Enter passphrase for key '/home/milned/.ssh/id_rsa':
Last login: Thu Nov 21 17:27:35 2013 from tegan
>


SSH access is now configured to use keys rather than a password to grant access. Access to the key is controlled by a pass phrase. In the next step agent forwarding is set up so that this pass phrase only needs to be entered once.

Configure SSH Agent Forwarding


To check if there is already an agent running use ssh-add.

> /usr/bin/ssh-add -l
Could not open a connection to your authentication agent

If this command reports anything else, then there is an agent running. Otherwise, start an agent using the command:

> exec ssh-agent $SHELL This creates a new shell process as a child of the agent with suitable environment variables set. This agent will live until you exit from this shell, and is only accessible from it.

Running ssh-add should now show the agent is present, but with no identities.
> /usr/bin/ssh-add -l
The agent has no identities
The next step is to add the keys using ssh-add. This will prompt you for the pass phrase for one of your keys, and then assuming they all have the same pass phrase, add them all to the agent:

> /usr/bin/ssh-add
Enter passphrase for /home/milned/.ssh/id_rsa:
Identity added: /home/milned/.ssh/id_rsa (/home/milned/.ssh/id_rsa)
Identity added: /home/milned/.ssh/id_dsa (/home/milned/.ssh/id_dsa)
Identity added: /home/milned/.ssh/identity (milned@nyssa)
Check the keys are available with ssh-add again, which should now report a list of key signatures.
> /usr/bin/ssh-add -l
1024 90:d1:83:5c:2a:33:9b:c7:ba:85:8e:ef:b7:c0:32:05 milned@nyssa (RSA1)
1024 9f:c0:e4:ed:f1:c4:ec:de:6e:af:4c:91:13:8d:58:45 /home/milned/.ssh/id_rsa (RSA)
1024 ab:a1:89:d7:d5:06:d2:d5:c4:18:e6:bc:65:37:96:dc /home/milned/.ssh/id_dsa (DSA)
You should now be able to use ssh to connect to any other machine which is running OpenSSH and has your home directory mounted, and not be prompted for a password. Chaining SSH connections (ssh from a to b and then from b to c) should work via agent forwarding.

Automating SSH Agent Forwarding

Rather than running the above manually, it can be built into the .bashrc file so that it starts automatically when bash is started.

> cd
> cat .bashrc
export PS1="\u@\H \w> "
PATH=$PATH:/usr/local/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin

Amend .bashrc as follows:
export PS1="\u@\H \w> "
PATH=$PATH:/usr/local/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin
ssh-agent > $HOME/.ssh-agent.sh
ssh_agent="$HOME/.ssh-agent.sh"
if [ -f $ssh_agent ]
then
  source $ssh_agent > /dev/null
fi
ssh-add
alias stat="perl -e'print "%o\n",(stat shift)[2] & 07777' $1"
export EDITOR=vi