SUSE Conversations


SSH (Secure Shell) Tricks III



By: DamianMyerscough

February 11, 2008 7:16 am

Reads:695

Comments:0

Rating:0

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

SSH Tricks Part III

This article is part three of SSH tricks, the first and second articles are available at [1] and [2]. In this article we will take a look at; building the latest version of OpenSSH (4.7), restricting users and groups access to the SSH daemon, disconnecting idle users and finally we will look at overriding settings on a per-user basis.

Building OpenSSH

In this section of the article we are going look at compiling the latest version of OpenSSH which can be downloaded from the [3] website. The OpenSSH package contains a RPM (Red hat Package Management) specification file which makes building OpenSSH very easy. When building the OpenSSH package six dependencies are need, Table 1 lists all the dependencies that are required.

Dependency Description
pam-devel This package include Files and Libraries for PAM-Development.
openssl-devel This package include Files and Libraries mandatory for Development.
krb5-devel MIT Kerberos5 – Include Files and Libraries for development.
xorg-x11-devel This package include Files and Libraries mandatory for Development.
tcpd-devel This package include Files and Libraries for the TCP wrapper library.
opensc-devel This package contains additional files needed for OpenSC development.

Table 1: Dependency files require for OpenSSH.

The dependency files listed in Table 1 can be easily installed using the “yast sw_single” command. Once you have installed all the dependency files, you will need to download the “x11-ssh-askpass” package which is another dependency that OpenSSH relies on. This package can be downloaded from [4] website.

Once you have download the “x11-ssh-askpass” and the OpenSSH packages you can move the “x11-ssh-askpass” package to the “/usr/src/packages/SOURCES” directory to compiled, before moving the OpenSSH package to the “/usr/src/packages/SOURCES” directory you will need to extract the archive first and copy the RPM specification file to the “/usr/src/packages/SPECS” directory as shown in Figure 1.

fmv-s8230-sk:~ # cp x11-ssh-askpass-1.2.4.1.tar.gz /usr/src/packages/SOURCES/
fmv-s8230-sk:~ # tar zvxf openssh-4.7p1.tar.gz
fmv-s8230-sk:~ # cd openssh-4.7p1/
fmv-s8230-sk:~/openssh-4.7p1 # cd contrib/
fmv-s8230-sk:~/openssh-4.7p1/contrib # cd suse
fmv-s8230-sk:~/openssh-4.7p1/contrib/suse # cp openssh.spec /usr/src/packages/SPECS/

fmv-s8230-sk:~ # cp openssh-4.7p1.tar.gz /usr/src/packages/SOURCES/

Figure 1: Preparing the build environment.

Once you have moved the files to there correct locations you will need to open the “openssh.spec” file to add some extra features such as; smartcard support, tcpwrappers support and PAM support. Table 2 lists what options we will enable in the SSH daemon and Figure 1.1 shows which part of the “openssh.spec” file to edit.

Dependency Description
–with-pam Enables PAM support.
–with-tcp-wrappers Enables tcpwrappers support.
–with-opensc Enables smartcard support using OpenSC.

Table 2: SSH features to enable.

%build

CFLAGS="$RPM_OPT_FLAGS" \
%configure      --prefix=/usr \
                --sysconfdir=%{_sysconfdir}/ssh \
                --mandir=%{_mandir} \
                --with-privsep-path=/var/lib/empty \
                --with-pam \
                --with-tcp-wrappers \
                --with-opensc \
                --libexecdir=%{_libdir}/ssh

Figure 1.1: “openssh.spec” RPM specification file.

Once you have altered the “openssh.spec” file you can save the changes and simply issue the “rpmbuild” command as shown in Figure 1.2.

fmv-s8230-sk:/usr/src/packages/SPECS # rpmbuild -bb openssh.spec

Figure 1.2: Building the RPM specification file.

Once the RPM specification file has been successfully compiled you should have two RPM files: “openssh-4.7p1-1.i586.rpm” and “openssh-4.7p1-1.i586.rpm” stored within the “/usr/src/packages/RPMS” directory.

Installing OpenSSH

Now that you have the two binary RPM files you can use the “rpm” command to begin the installing of the OpenSSH daemon as shown in Figure 1.3.

fmv-s8230-sk:/usr/src/packages/SPECS # cd ../RPMS/i586
fmv-s8230-sk:/usr/src/packages/RPMS/i586 # rpm -Uhv *.rpm
Preparing...                ########################################### [100%]
   1:openssh                warning: /etc/pam.d/sshd created as /etc/pam.d/sshd.rpmnew
########################################### [ 50%]
Updating etc/sysconfig/ssh...
Starting SuSEconfig, the SuSE Configuration Tool...
Running module permissions only
Reading /etc/sysconfig and updating the system...
Executing /sbin/conf.d/SuSEconfig.permissions...
Checking permissions and ownerships - using the permissions files
        /etc/permissions.d/mail-server
        /etc/permissions.d/postfix
        /etc/permissions.d/squid
        /etc/permissions.d/susehelp
        /etc/permissions
        /etc/permissions.easy
        /etc/permissions.local
setting /etc/ssh/sshd_config to root:root 0640. (wrong permissions 0600)

setting /usr/src/packages/RPMS/i586/ to root:root 1777. (wrong permissions 0755)

Finished.
   2:openssh-askpass        ########################################### [100%]

Figure 1.3: Installing the new OpenSSH daemon.

Once you have installed the new OpenSSH daemon you can issue the “service” command to start the SSH daemon as shown in Figure 1.4.

fmv-s8230-sk:~ # service sshd start

Figure 1.4: Starting the SSH daemon.

Once you have started the SSH daemon you can simply telnet into the local machine and see if the new banner is present, as shown in Figure 1.5.

fmv-s8230-sk:~ # telnet localhost 22
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
SSH-2.0-OpenSSH_4.7
^]
Protocol mismatch.
Connection closed by foreign host.

Figure 1.5: Checking the SSH banner.

Restricting users and groups

In this section of the article we are going to look at restricting users and groups from logging into the SSH daemon. There are four directives that are supported within the SSH global configuration file and they are: “AllowGroups”, “AllowUsers”, “DenyGroups” and “DenyUsers”. These directives allow you to specify which users/groups are allowed access, in this article we will use all the directives.

Allowing and denying groups

The first example we will look at is denying access to the users who are a member of the “users” group, Figure 2 shows the directive which I added to the “/etc/ssh/sshd_config” global configuration file.

...
DenyGroups users
...

Figure 2: Denying the group “users” access to the SSH daemon.

Once you have made the changes to the SSH global configuration file you will need to reload the SSH daemon, this can be done simply by issuing the “service” command as shown in Figure 2.1.

linux-m899:/etc/ssh # service sshd reload
Reload service sshd                                                   done

Figure 2.1: Reloading the SSH daemon configuration file.

Once the SSH daemon has been reloaded you can try and connect to the SSH daemon with a user that is a member of the “users” group. When a member of the “users” group attempts to connect to the SSH daemon they will be denied access, the effects are, the user is asked for their password even if the user specifies the correct password they will be asked again for their password.

In the second example we will allow the group “users” but deny access to anyone who is a member of the “root” group. Figure 2.2 shows the directives that were used.

...
DenyGroups root
AllowGroups users
...

Figure 2.2: Allowing the group “users” but denying the group “root”.

Once you have made the configuration changes you will need to reload the SSH daemon as shown in Figure 2.1. Once your SSH daemon has been reloaded you should now be able to login as a user that is a member of the “users” group, however, if you try to login as root you will be denied access. The “/var/log/messages” log file should show the user root attempting to login and why their access was denied as shown in Figure 2.3.

Feb  7 16:01:07 linux-m899 sshd[5106]: User root from 172.25.147.174 not allowed because a group is listed in DenyGroups

Figure 2.3: “/var/log/messages” log contents.

Allowing and denying users

Allowing and denying users is very similar to denying groups and allowing groups. The first example that we will look at is deny the user “damian”, Figure 2.4 shows the directive that we used in the SSH global configuration file.

...
DenyUsers damian
...

Figure 2.4: Denying the user “damian” access to the SSH daemon.

Once again when you make changes to the SSH global configuration file you need to reload the SSH daemon as shown in Figure 2.1. Once you have reloaded the SSH global configuration file you can try and login as the user “damian” and you will notice that this user is now being denied.

In this second example we will allow the user “jason” access to the SSH daemon. Figure 2.5 shows which directive was used.

...
AllowUsers jason
...

Figure 2.5: Allow the user “jason” access to the SSH daemon.

Once you have modified the SSH global configuration file again you will need to reload the SSH daemon as shown in Figure 2.1. The directive shown in Figure 2.5 adds an explicit deny to all other users, this has the similar effect to the “AllowGroups” directives. When allowing multiple users or groups you need to separate these with spaces as shown in Figure 2.6.

...
AllowUsers damian jason
DenyGroups root games
...

Figure 2.6: Adding multiple users and groups.

Disconnecting idle users

In this section we are going to look at disconnecting idle users from the SSH daemon. The reason for this is because some users leave there terminals unattended thus allowing malicious users to come along and start causing mischief. The “ssh_config” global configuration supports a directive called: “ClientAliveInterval”, this directive allows us to disconnect idle users as shown in Figure 3.

...
ClientAliveInterval 5m
...

Figure 3: Setting the idle time to five minutes.

Once you have modified the “sshd_config” global configuration file you will need to reload the SSH server as shown in Figure 2.1. Once you have reloaded the SSH daemon simply SSH into your machine and don’t type any commands for five minutes and you should be disconnected.

Overriding settings on a per-user basis

In this section we will look at blocking the user “damian” from performing X11 traffic forwarding and allow everyone else to forward X11 traffic. The configuration file which we will be working with is the SSH global configuration file.

The first directive that we need to modify is the “X11Forwarding” directive, by default this directive will be set to “no”, so you will need to set this directive to “yes” as shown in Figure 4.

...
X11Forwarding yes
...

Figure 4: Enabling X11 forwarding.

Once you have made changes to the “X11Forwarding” directive you will need to reload the SSH global configuration file as shown in Figure 2.1. Once the SSH daemon has been reloaded you can check to see if X11 forwarding is working as shown in Figure 4.1.

linux-m899:/etc/ssh # ssh -X damian@192.168.0.2

Figure 4.1: Forwarding X11 traffic.

Once you have the SSH daemon forwarding X11 traffic you can now disable the X11 traffic forwarding for the user “damian”. In the global configuration file near the bottom you can make an entry similar to the one shown in Figure 4.2 to disable the user “damian” from forwarding X11 traffic.

Match User damian
        X11Forwarding no

Figure 4.2: Disabling the user “damian” from forwarding X11 traffic.

Once you have made the changes to the global configuration file you will need to restart the SSH daemon as shown in Figure 4.3.

linux-m899:/etc/ssh # service sshd restart
Shutting down SSH daemon                                              done

Starting SSH daemon                                                   done

Figure 4.3: Restarting the SSH daemon.

Once you have restarted the SSH daemon you can try and forward X11 traffic again as the user “damian” and you will get a similar output to Figure 4.4.

[damian@localhost ~]$ ssh -X damian@192.168.0.2
damian@192.168.0.2's password: 
Last login: Mon Feb 11 10:08:03 2008 from 192.168.0.45
damian@fmv-s8230-sk:~> xclock 
Error: Can't open display:

Figure 4.4: Trying to forward X11 traffic as the user “damian”.

Final Thoughts

In this article we compiled the latest version of OpenSSH thus using even more of it’s newest features. I would recommend the latest version of OpenSSH to any administrator as the latest features allow for even more fine grind access.

Reference

[1] SSH (Secure Shell) Tricks: http://www.novell.com/communities/node/3258/ssh-secure-shell-tricks
[2] SSH (Secure Shell) Tricks II: http://www.novell.com/communities/node/3506/ssh-secure-shell-tricks-ii
[3] http://www.openssh.com/
[4] http://www.jmknoble.net/software/x11-ssh-askpass/

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 Navigation<< SSH (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.

Comment

RSS