SUSE Conversations


SSH (Secure Shell) Tricks



By: DamianMyerscough

January 18, 2008 3:50 pm

Reads:1222

Comments:3

Rating:0

This entry is part 1 of 3 in the series SSH (Secure Shell) Tricks

SSH (Secure Shell) Tricks

In this article we will cover some basic and advanced tricks with the SSH daemon along with some tips on tighten the security. The tricks that will be cover in this article are “port forwarding”, “reverse port forwarding”, “executing remote commands without the need of logging in” and “restricting user to SFTP access only”.

Introduction

The OpenSSH daemon is installed by default on all SUSE Linux distributions. OpenSSH is a replacement for the telnet, RCP and FTP daemons which all send data in clear text over a network, however the SSH daemon transmits all data encrypted thus making it hard for malicious users to gather sensitive data. OpenSSH also comes with a three major utilities which are listed in Table 1.

Utility Description
SSH This utility is used for connecting to the OpenSSH server and managing you’re machines remotely and securely.
SFTP This utility is identical to FTP accept SFTP provides encryption throughout the duration of the session.
SCP This utility allows you to transfer files from one machine using a secure encrypted tunnel. The difference between SCP and SFTP is that SCP requires no user interaction.

Table 1: OpenSSH utilities.

Port forwarding

OpenSSH provides a feature that allows you to tunnel insecure services over a secure encrypted tunnel thus making the insecure service much more secure. In this article we will forward VNC traffic which is usually on port 5901, Figure 1 shows the syntax used with Table 2 explaining what each qualifier is used for.

ssh -L <LOCAL PORT>:<HOST>:<REMOTE PORT> <REMOTE HOST>

Figure 1: SSH port forwarding syntax.

Syntax Description
-L “Specifies that the given port on the local (client) host is to be forwarded to the given host and port on the remote side.” (SSH man page, 2008)
<LOCAL PORT> This is the local port which you want all communications to occur on, if you are a non-privileged you must use ports greater than 1024.
<HOST> This is the host you would like to bind to, e.g. localhost, 127.0.0.1.
<REMOTE PORT> This is the port in which the service on the remote machine is bound to e.g. VNC is usually bound to 5901.
<REMOTE HOST> This is the remote host which is running the insecure service e.g. VNC.

Table 2: SSH syntax explained.

In this article we will be connection to a VNC server which has the IP address of “172.25.147.173″ and has VNC bound to port 5901, Figure 1.1 shows the syntax used to forward the 5901 port.

linux-hsx3:~ # ssh -L 2323:localhost:5901 172.25.147.173

Figure 1.1: Forwarding VNC traffic.

Once you have connected to the machine you can open another terminal on you’re local machine and type “netstat -ntl” which should show the port 2323 bound the the localhost. Once you know port 2323 has been bound you can open your VNC client and connect to your secure tunnel, for the destination host you would put “localhost” and with the port number of 2323.

The command used in Figure 1.1 works fine however, you can also supply the “-N” qualifier which will make a connection to the VNC server but won’t display a command prompt which makes it a little more secure if you leave your workstation unattended.

Reverse port forwarding

OpenSSH provides reverse port forwarding which is an excellent feature. The reverse port forwarding allows you to connect to a remote host and from that remote host connect back even if there is a firewall in between the two machines.

The syntax for reverse port forwarding is very similar to Figure 1, Table 2 also explains the syntax.

ssh -N -L <REMOTE PORT>:<HOST>:<LOCAL POR> <REMOTE HOST>

Figure 2: Reverse port forwarding syntax.

Syntax Description
-N This option does not allow remote commands to be executed.
-L “Specifies that the given port on the local (client) host is to be forwarded to the given host and port on the remote side.” (SSH man page, 2008)
<REMOTE PORT> This is the port you want to bind to on the remote system.
<HOST> This is the host you would like to bind to, e.g. localhost, 127.0.0.1 or a publicly available one.
<LOCAL PORT> This is the port in which the reversed host will connect to.
<REMOTE HOST> The host which you want to connect to and bind the port to.

Table 3: SSH syntax explained.

In this article we will show how reverse port forwarding works by writing a simple IP table rule which will block remote connections to the SSH port (22). Once we have blocked the SSH port we will use reverse port forwarding to make a connection. Figure 2.1 shows the IP table rule which will block SSH access.

linux-hsx3:~ # iptable -A INPUT -p tcp --dport 22 ! --src localhost -j DROP

Figure 2.1: Blocking SSH access.

Once you have blocked local SSH access you should SSH into another machine using reverse port forwarding as shown in Figure 2.2.

linux-hsx3:~ # ssh -N -R 2222:localhost:22 172.25.147.173

Figure 2.2: Reverse port forwarding.

When the connection has been established on the remote system you will be able to connect to the blocked SSH daemon by connecting to port 2222 as shown in Figure 2.3.

linux-hsx3:~ # ssh root@localhost -p 2222

Figure 2.3: Connecting to the blocked SSH daemon.

When you connect to port 2222 you will notice that you have SSHed into the connecting machine thus tunneling through the firewall.

Executing remote command(s)

This little tip shows you how to execute remote commands without having to login to a shell. I find this useful when I just need to check the integrity of a file(s), check the status of a machine or just execute a quick command. If you have ever issued the “ssh” command on its own you would have noticed that SSH accepts commands which get execute on the remote machine. Figure 3 shows the “ls” command being executed on the remote system without having to login to a shell.

linux-hsx3:~ # ssh root@172.25.147.173 “ls”
Desktop
Documents
mbox
Test1.txt
Test3.txt
linux-hsx3:~ #

Figure 3: Execute “ls” on the remote machine.

It is also possible to execute multiple commands by using command chaining e.g. ( ls ; uname -a ) as shown in Figure 3.1.

linux-hsx3:~ # ssh root@172.25.147.173 “ls ; uname -a”
Desktop
Documents
mbox
Test1.txt
Test3.txt
Linux linux-ypgt 2.6.16.46-0.12-default #1 Thu May 17 14:00:09 UTC 2007 i686 athlon i386 GNU/Linux
linux-hsx3:~ #

Figure 3.1: Executing multiple commands.

Allow only SFTP (Secure File Transfer Protocol)

In this section of the article we will look at how to only permit SFTP access and deny shell access. The first step is to add “/usr/lib/ssh/sftp-server” to the “/etc/shells” file, this is the shell which the user will have.

There are two methods to set the users shell either by editing the “/etc/passwd” file manually as shown in Figure 4 or using the “usermod” command as shown in Figure 4.1.

damian:x:1003:100::/home/damian:/usr/lib/ssh/sftp-server

Figure 4: Setting the users shell manually.

linux-hsx3:~ # usermod -s /usr/lib/ssh/sftp-server damian

Figure 4.1: Setting the users shell.

Once you have changed the users shell you should try and login as that user, you will notice that the users login fails and only displays their last login. If you use the “sftp” command you will notice that you are able to successfully login as shown in Figure 4.2.

linux-hsx3:~ # sftp damian@172.25.147.173

Figure 4.2: Logging into SFTP.

Tightening OpenSSH

OpenSSH provides a secure policy by default, however, it is possible to make you’re configuration even more secure by restricting the use of protocols, disabling password logins, not permitting remote root logins and many others. The options explained below can all be applied by editing the “/etc/ssh/sshd_config” file.

Protocol

The “Protocol” option in the configuration file lists the supported protocols that the server will serve. The protocol versions that are available are one and two, it is highly recommended that you don’t enable protocol version one and just enable protocol version two as version one is consider insecure.

Login

The login options that we will look at here are “LoginGraceTime” and “PertmitRootLogin”.

The first option “LoginGraceTime” is how long to wait for someone to login before terminating their connection, by default this is set to two minutes. I would recommend reducing this time to maybe 20 seconds as shown in Figure 5. The reason for reducing the login time is because no one should need two minutes to enter their password.

LoginGraceTime 20s

Figure 5: Reducing the login time to 20 seconds.

The second option “PermitRootLogin” is set to “yes” by default, this means that remote root logins are permitted thus allowing users to possible perform a brute force attack against the root users. I would strongly recommend that you change this option to “no” as shown in Figure 5.1.

PermitRootLogin no

Figure 5.1: Disabling remote root login.

Authentication

The final tip is to disable password logins and only permit public key authentication. The two options that need to be modified are “PasswordAuthentication” and “UsePam”, both of these values need to be set to “no” as shown in Figure 5.2.

PasswordAuthentication no
UsePam no

Figure 5.2: Disable password logins.

Once you have applied these two options and restarted the OpenSSH daemon you can try and login to you’re machine with a password but you may get the following error: “Permission denied (publickey,keyboard-interactive).” this is because the SSH daemon will now only accept public key authentication thus making brute force attacks useless.

Final Thoughts

The OpenSSH is a very flexible and powerful daemon, in this article we only touch on a few basic features which OpenSSH provides. The OpenSSH daemon provides a lot more sophisticated features such as public key authentication, X11 forwarding, agent forwarding and much more I would strongly recommend visiting the OpenSSH website (www.openssh.com).

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)
Series NavigationSSH (Secure Shell) Tricks II >>

Tags: ,
Categories: SUSE Linux Enterprise, SUSE Linux Enterprise Desktop, SUSE Linux Enterprise Server, Technical Solutions

Disclaimer: As with everything else at SUSE Conversations, this content is definitely not supported by SUSE (so don't even think of calling Support if you try something and it blows up).  It was contributed by a community member and is published "as is." It seems to have worked for at least one person, and might work for you. But please be sure to test, test, test before you do anything drastic with it.

3 Comments

  1. By:mfaris01

    I use these recommendations in my environment.

    Mike…

  2. By:blittrell

    Never knew SSH was so handy, will definetly book mark this page and start applying this..

    One question though, Why use a Preshared Key for authentication? Or do you have to guess the PSK then login to the system with the username password?

    Thanks

  3. By:DamianMyerscough

    Hello blittrell,

    The reason for public key authentication is that it provides tighter security. The reason being, password authentication can be brute forced thus allowing attackers to gain access to you’re machine whereas public key authentication requires a private key to gain access thus eliminating brute force attacks.

    I will do another guide on SSH soon and including more information
    on public key authentication.

Comment

RSS