04- Linux, Logging & SSH

Basic Networking Configuration

As an added bonus! More Linux Distributions!

In week 1, we set up networking in CentOS. Now let us do the same for a few other common distributions.

Mint 11
One nice thing about Mint 11 is that we do not have the trouble we have seen with the udev subsystem; copying a Mint 11 VM does change the MAC address of the interface, but we do not need to manually reconfigure entries from /etc/udev/rules.d.

To set up static addressing from the command line, modify the file /etc/networks/interfaces in a fashion similar to the following:

auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
address 192.168.1.63
netmask 255.255.255.0
gateway 192.168.1.1

The first two lines in this file are part of the Mint default install, while the remaining lines needed to be added.

The DNS server(s) are specified in the usual place, in /etc/resolv.conf.

Mint comes with a graphical tool to manage networks, however this tool cannot be used with any interfaces specified in /etc/networks/interfaces. To use it, navigate Menu → Control Center → Internet and Network → Network Connections. Select the interface (eth0) and enter the necessary data:

To change the hostname, modify the file /etc/hostname to include the full name (FQDN) of the host. Modify /etc/hosts in the same fashion as we did for CentOS 6.2; you do not need to keep separate entries for 127.0.0.1 and 127.0.1.1.

There is a graphical tool to manage the firewall on your Mint 11 system. To find it, navigate Menu → Administration → Firewall Configuration. By default though, the firewall is disabled.

Ubuntu 11.04
Ubuntu 11.04 is handled in essentially the same fashion as Mint 11. The configuration files are in the same place and handled in the same fashion. The Network Manager also is essentially the same, though you find it by navigating System → Preferences → Network Connections.

Like Mint 11, Ubuntu starts with its firewall disabled, but unlike Mint, it does not even install the graphical tool to manage the firewall (gufw), though the command line tool (ufw) is available. To install the graphical tool, grab the packag gufw_11.04-2-all.deb, either from the labshare or online and run

vimes@smallgods:~$ sudo dpkg -i Desktop/gufw_11.04.2-all.deb 
[sudo] password for vimes: 
Selecting previously deselected package gufw.
(Reading database ... 130073 files and directories currently installed.)
Unpacking gufw (from Desktop/gufw_11.04.2-all.deb) ...
Setting up gufw (11.04.2-0ubuntu1) ...
Processing triggers for bamfdaemon ...
Rebuilding /usr/share/applications/bamf.index...
Processing triggers for desktop-file-utils ...
Processing triggers for python-gmenu ...
Rebuilding /usr/share/applications/desktop.en_US.utf8.cache...
Processing triggers for hicolor-icon-theme ...
Processing triggers for man-db ...
Processing triggers for python-support ...
vimes@smallgods:~$

Once installed, the tool is run in the same fashion as it is under Mint 11.

Open SuSE 11.3
To configure networking for OpenSuSE, begin by making any corrections needed to /etc/udev/rules.d/70-persistent-net.rules.

We can set up a static IP address in Open SuSE in the same fashion as we did for CentOS; i.e. through /etc/sysconfig/network. If we want to change the hostname, then we can modify the value in /etc/HOSTNAME. The DNS server(s) are specified in the usual place, /etc/resolv.conf.

The primary administrative tool for OpenSuSE systems is called YaST, and it can be used to manage network settings. Find it by navigating Start Iguana → Computer → YaST. To modify the network settings, select Network Settings.

From the Overview tab, you can set the IP address; however the hostname also needs to be set from the Hostname/DNS tab. That tab is also used to specify the DNS server(s). The network gateway is specified in the Routing tab.

OpenSuSE manages its firewall by assigning the different interfaces to zones. After changing the entries in the /etc/udev/rules.d/70-persistent-net.rules file, you want to be sure that the new interface is in the proper zone; otherwise the firewall will not be correctly configured.

To manage the firewall, navigate Start Iguana → YaST → Security and Users → Firewall. From the Start-Up category, be sure that the Firewall is running, and from the Interfaces category, be sure that your interface eth0 is listed as belonging to the External Zone.

Logging in Linux

Linux systems use the syslog standard as the preferred method for system logs. An informal standard for many years, these were codified in RFC 3164 and then updated in RFC 5425. Various tools have been used to implement the syslog standard; for many years the most common was called syslog. That tool had a number of shortcomings, which led to the development of alternative implementations, including syslog-ng and rsyslog. The latter of these is used on all of the images provided to the class, though in slightly different versions. CentOS uses rsyslog 4.6.2, while Mint and Ubuntu use 4.6.4 and OpenSuSE uses 5.4.0

Programs running in a linux environment can dispatch a log message using syslog; see man 3 syslog to see the corresponding C function call. Each message is assigned two values- a facility, which identifies the type of message, and a severity, which determines its importance. The facilities are

• auth: Formerly used for security/authorization messages, but deprecated in favor of authpriv.
• authpriv: Used for security/authorization messages.
• cron: Used for time based services, including the clock daemon, cron.
• daemon: Used for system daemons without separate facility values
• ftp: Used for the ftp server.
• kern: Used solely for kernel messages.
• local0, local1, …, local7: Available for local system use.
• lpr: Used for the print subsystem.
• mail: Used for the mail server.
• news: Used for the news server (NNTP; see e.g. RFC 977).
• syslog: Used for messages generated by the syslog server itself.
• user: Default facility; used for generic messages.
• uucp: Used for the (now obsolete) Unix to Unix Copy system (UUCP).

The priorities are, in decreasing order of importance:

• emerg (emergency)
• alert
• crit (critical)
• err (error)
• warning
• notice
• info (informational)
• debug

Open the configuration file /etc/rsyslog.conf from your CentOS 6.2 machine, and take a look at the section marked rules. Before we even look at the documentation for rsyslog, can you determine where most log messages are sent? Where do the messages from the mail facility end up?

Create the file /var/log/testlog; then based on your reading of the rsyslog.conf file, modify it so that all messages get sent to that file. Save your changes, and restart the rsyslog service by running

[root@shades log]# /etc/init.d/rsyslog restart
Shutting down system logger:                               [  OK  ]
Starting system logger:                                    [  OK  ]
[root@shades log]#

When this is complete, take a look at your file /var/log/testlog; it should contain (at least) the log message saying that rsyslog was restarted. Also examine the file /var/log/messages to see if any messages were sent to both files. What conclusions do you draw?

Take a look at the man page for the tool logger. Using this tool, we can craft log messages with specified facilities and priorities. Modify your /etc/resolv.conf file so that only messages from local1 of priority err or higher are sent to the file /var/log/testlog. Restart rsyslog and test your settings by sending messages with various facilities and priorities.

Hey, wait a minute. You mean any user can send any log message they want to the log server on a Linux system? Demonstrate that you can use logger to send a message that makes it appear as if the named server has shut down.

Though rsyslog is quite complex, it is also solidly documented. Take a look at the file /usr/share/doc/rsyslog-4.6.2/manual.html

Let’s learn how to centralize the logs from multiple sources on a single host. We can do this with any of the different lab images provided to the class, however they all have the configuration files structures slightly differently.

The CentOS 6.2 configuration is probably the simplest, as it is all contained in the single file /etc/rsyslog.conf.

Mint 11 and Ubuntu 11.04 have a directive in the /etc/rsyslog.conf file to include all of the files in the directory /etc/rsyslog.d; there are two files, the 50-default.conf which determines where log messages of a given priority and facility are sent. It also includes the file 20-ufw.conf; this file requires that ll log messages that begin with the text “[UFW ” are sent to a separate file. UFW is the firewall configuration tool for Ubuntu machines. Note also that to start, stop, restart, or check the status of a service, the preferred method is to use the service command in the form

vimes@smallgods:~$ sudo service rsyslog status
[sudo] password for vimes: 
rsyslog start/running, process 619
vimes@smallgods:~$

Note also that the these systems store most messages in the file /var/log/syslog.

OpenSuSE 11.3 also includes all of the files in the directory /etc/rsyslog.d, however the only file so included is /etc/rsyslog.d/remote.conf which holds the configuration data for rsyslog to send and receive remote log entries. The script to start and stop the rsyslog server can be found at /etc/init.d/syslog rather than the (perhaps more obvious) choice /etc/init.d/rsyslog.

For definiteness, we will show to to configure the CentOS systems; you should be able to make the necessary modifications for the other provided distributions.

The original standard for syslog only allowed for sending and receiving remote logs via UDP on port 514. To configure our syslog server to do so, instead of providing a file name as the destination for our logs, we provide the ip address, preceded by “@”; so if we add the line

*.*							@192.168.1.64

to our rsyslog.conf file, we are sending all messages, regardless of facility or priority to the host 192.168.1.64 via UDP on port 514.

Set up your CentOS machine to send all of its logs to another linux machine (your choice!).

We are going to test this setup. It is good practice to use a packet sniffer like Wireshark whenever you are setting up and configuring a network server for the first time; it will often save hours of debugging time by providing you access to the raw data as it traverses the network. Wireshark was not installed by default on the CentOS 6.2 image provided to the class; however you can either use it from your Backtrack machine, or simply install it.

With Wireshark running, restart the log server on your host, and verify that the appropriate packets were sent.

Oddly enough though, a check of the destination log server will show nothing. That is because we have not yet configured it. First we must load the required module to receive UDP traffic, then tell it to listen on port 514. In the CentOS 6.2 /etc/rsyslog.conf file, these lines already exist and simply need to be uncommented:

# Provides UDP syslog reception
$ModLoad imudp.so
$UDPServerRun 514

Similar (commented out) lines exist in the configuration files for the other provided distributions.

Restart the rsyslog server on the listening host, and be sure to also open the proper port in the firewall. At this point, you will see all log messages on the first host arrive on the listening host. Of course, these settings can be tweaked so that only messages of a given facility and priority are sent to the remote host.

What are the advantages of having a centralized log server? What are the disadvantages of the approach described above? [Hint: Lots!]

Here is another hint. Try the following on your Backtrack box, where the IP address is the address of your log server.

root@bt:~# nc -w1 -u 192.168.1.60 514 <<< "Remote Log"

What entries (if any) appear in your log?

nc is the netcat command- it is well worth learning what we can do
with this command. If you want to specify the facility and/or priority via netcat, take a look at
http://linux.byexamples.com/archives/412/syslog-sending-log-from-remote-servers-to-syslog-daemon

We can use rsyslog to send logs via TCP; to do so add the entry

facility.priority @@ip.address:port

to /etc/rsyslog.conf

To enable rsyslog to receive remote logs (TCP), include the lines

# Provides TCP syslog reception
$ModLoad imtcp.so  
$InputTCPServerRun 514

in your rsyslog configuration files. These lines already exist (in different places) for the provided distributions. Note that we have selected TCP port 514 to receive the logs, but we could have selected other ports.

Again, open the firewall, and restart rsyslog

What are the advantages of using TCP instead of UDP?

What does a packet capture of TCP syslog traffic show?

What happens if you try

root@bt:~# nc 192.168.1.60 514 <<< "message"

where the ip address (and port) of the log server is 192.168.1.221 (514)?

Log Rotation

The logs generated cannot be kept indefinitely; as they continue to expand in size they will eventually consume all system resources. The logrotate tool is used on linux systems to compress, archive, rotate and delete log files.

Read the man page for logrotate.

Example- CentOS

• Read the file logrotate.conf
• How often are the log files rotated?
• How long are log files kept as archives?
• Are the log files compressed?
• Are their any special features for the log rotation of the DNS server logs?
• What about the web server logs?

Example- Ubuntu
Are there significant differences between the logrotate.conf for Ubuntu and CentOS?

Example- Open SuSE
Are there significant differences between the logrotate.conf for Open SuSE and CentOS and Ubuntu?

psacct

Installation and startup

There is a package that allows for much more detailed logging of what is being done on a Linux system called psacct or acct depending on the particular distribution

The tool is already installed on your CentOS virtual machine, though it is not enabled. Called psacct it is controlled in the usual fashion. The command

[root@shades ~]# /etc/init.d/psacct start
Starting process accounting:                               [  OK  ]

will start and stop the service, and we can ensure it starts on boot either via chkconfig or by navigating System → Administration → Services.

Called acct, it is not installed on our OpenSuSE machine; in fact it is not even on the install DVD. On the other hand, you can get the RPM either from the classroom labshare or directly from the official OpenSuSE package repository where it is named acct-6.3.5-823.1.i586.rpm. It can be installed in the usual fashion, e.g.

hippo:~ # rpm -ivh /home/vimes/Desktop/acct-6.3.5-823.1.i586.rpm 
Preparing...                ########################################### [100%]
   1:acct                   ########################################### [100%]
Creating /var/account/pacct

The package can be started from the command line

hippo:~ # /etc/init.d/acct start
Starting process accounting                                          done

To ensure that they start on boot, use either chkconfig or run YaST → Network Services → System Services (Runlevel):

For Ubuntu 11.04 the package is also named acct. You can find the software by grabbing it either from the labshare or directly from the Ubuntu software repository. Install it in the usual fashion:

vimes@smallgods:~$ sudo dpkg -i Desktop/acct_6.5.4-2.1ubuntu1_i386.deb 
Selecting previously deselected package acct.
(Reading database ... 130198 files and directories currently installed.)
Unpacking acct (from .../acct_6.5.4-2.1ubuntu1_i386.deb) ...
Setting up acct (6.5.4-2.1ubuntu1) ...
Turning on process accounting, file set to '/var/log/account/pacct'.
 * Done.
Processing triggers for doc-base ...
Processing 34 changed 1 added doc-base file(s)...
Registering documents with scrollkeeper...
Processing triggers for install-info ...
Processing triggers for man-db ...
Processing triggers for ureadahead ...
ureadahead will be reprofiled on next reboot
vimes@smallgods:~$

This will set up the package so that it will start and will start on the system’s next boot.

Installation on Mint 11 is handled in the same fashion as it was on Ubuntu, including using the same package.

Using psacct
The psacct package keeps track of a number of pieces of system information. For example, the command ac can be used to determine how may hours of connect time have been used.

[root@shades ~]# ac
	total      114.13

This shows that users have been connected to the system for 114.07 hours. If we want to see that number broken down by user, we can run

[root@shades ~]# ac -p
	vimes                              114.13
	root                                 0.00
	granny                               0.00
	agnes                                0.00
	total      114.13

to see that essentially all of the time has been from the user vimes, with the other users contributing essentially nothing to the total. We can use ac -d

[root@shades ~]# ac -d
Jan  1	total        0.28
Jan  2	total        0.04
Jan 27	total        0.91
Jan 28	total       25.41
Jan 29	total       11.96
Jan 31	total       16.50
Feb  1	total       26.95
Feb  4	total        0.79
Feb 11	total       19.42
Feb 12	total        9.44
Today	total        2.49

to get a breakdown by date; we can even combine them as ac -dp

[root@shades ~]# ac -pd
	vimes                                0.28
Jan  1	total        0.28
	vimes                                0.04
Jan  2	total        0.04
	vimes                                0.91
Jan 27	total        0.91
	vimes                               25.41
Jan 28	total       25.41
	vimes                               11.96
Jan 29	total       11.96
	vimes                               16.50
Jan 31	total       16.50
	vimes                               26.95
Feb  1	total       26.95
	vimes                                0.79
Feb  4	total        0.79
	vimes                               19.42
Feb 11	total       19.42
	vimes                                9.44
	root                                 0.00
	granny                               0.00
	agnes                                0.00
Feb 12	total        9.44
	vimes                                2.54
Today	total        2.54

Another useful feature of this package is the ability to determine the commands that have been run on the system. For example, to find out each time the command rm has been run, you can execute

[root@shades ~]# lastcomm rm
rm                      root     pts/0      0.00 secs Sat Feb 18 12:34
rm                      root     __         0.00 secs Sat Feb 18 12:27
rm                      root     __         0.00 secs Sat Feb 18 12:27
rm                      root     __         0.00 secs Sat Feb 18 12:27

From this we see that the rm command has been run only four times since accounting started. We can also sort by user. Running

[root@shades ~]# lastcomm vimes
bash                  X vimes    pts/2      0.00 secs Sat Feb 18 12:44
lastcomm                vimes    pts/2      0.00 secs Sat Feb 18 12:44
bash               F    vimes    pts/2      0.00 secs Sat Feb 18 12:44
id                      vimes    pts/2      0.00 secs Sat Feb 18 12:44
grep                    vimes    pts/2      0.00 secs Sat Feb 18 12:44
bash               F    vimes    pts/2      0.00 secs Sat Feb 18 12:44
dircolors               vimes    pts/2      0.00 secs Sat Feb 18 12:44
bash               F    vimes    pts/2      0.00 secs Sat Feb 18 12:44
tput                    vimes    pts/2      0.00 secs Sat Feb 18 12:44
tty                     vimes    pts/2      0.00 secs Sat Feb 18 12:44
bash               F    vimes    pts/2      0.00 secs Sat Feb 18 12:44
id                      vimes    pts/2      0.00 secs Sat Feb 18 12:44
bash               F    vimes    pts/2      0.00 secs Sat Feb 18 12:44
id                      vimes    pts/2      0.00 secs Sat Feb 18 12:44
gnome-terminal          vimes    __         0.03 secs Sat Feb 18 12:44
gnome-panel        F    vimes    __         0.00 secs Sat Feb 18 12:44
unlzma                  vimes    pts/1      0.00 secs Sat Feb 18 12:43
gzip                    vimes    pts/1      0.00 secs Sat Feb 18 12:43
man                     vimes    pts/1      0.00 secs Sat Feb 18 12:35
sh                      vimes    pts/1      0.00 secs Sat Feb 18 12:35
less                    vimes    pts/1      0.00 secs Sat Feb 18 12:35

we find the command recently executed by the user vimes. You can read the man page for lastcomm to determine the significance of the flags (e.g. the F that occasionally appears.)

If you want to find out information about previously run commands, you can use the sa tool; it is able to give you information on the cpu usage of all of the commands run on the system. See the man page for more details.

Splunk

Installation: On CentOS or OpenSuSE run choose the right rpm (32 bit or 64 bit) and then run

[root@shades Desktop]# rpm -ivh ./splunk-4.3-115073-linux-2.6-x86_64.rpm 
warning: ./splunk-4.3-115073-linux-2.6-x86_64.rpm: Header V3 DSA/SHA1 
Signature, key ID 653fb112: NOKEY
Preparing...                ########################################### [100%]
   1:splunk                 ########################################### [100%]
----------------------------------------------------------------------
Splunk has been installed in:
        /opt/splunk

To start Splunk, run the command:
        /opt/splunk/bin/splunk start

To use the Splunk Web interface, point your browser at:
    http://shades.cosc.tu:8000

Complete documentation is at http://docs.splunk.com/Documentation/Splunk
----------------------------------------------------------------------

while on Mint or Ubuntu, run

scours Desktop # dpkg -i ./splunk-4.3-115073-linux-2.6-intel.deb 
Selecting previously deselected package splunk.
(Reading database ... 141527 files and directories currently installed.)
Unpacking splunk (from .../splunk-4.3-115073-linux-2.6-intel.deb) ...
Setting up splunk (4.3-115073) ...
----------------------------------------------------------------------
Splunk has been installed in:
        /opt/splunk

To start Splunk, run the command:
        /opt/splunk/bin/splunk start

To use the Splunk Web interface, point your browser at:
    http://scours.cosc.tu:8000

Complete documentation is at http://docs.splunk.com/Documentation/Splunk
----------------------------------------------------------------------

Splunk launches with a default license valid for 60 days and up to 500 MB of data per day. It also comes with a free license that allows it to be used provided certain conditions are met. You must accept the license agreement the first time you run the tool. To change the license from the (after the system is running) from the trial license to the free license, first start splunk, and visit the splunk web page. Navigate Manager → License (near the bottom third of the page), and select Change License. The license key to use splunk as a free tool is available in the file /opt/splunk/etc/splunk-free.license. Copy the contents into the License key box (overwriting the old license), and then restart splunk.

To start splunk for the first time, run (as root, or via sudo)

[root@shades ~]# /opt/splunk/bin/splunk start

To use the tool, point a web browser to the host, on port 8000. If you want to use a browser from other than the host, you need to open the firewall. The decision to open the firewall to allow connections to the Splunk server is a trade-off between security and convenience. Hey- I wonder if the data passing to and from the server is encrypted. What do you think?

The first time the splunk is run, the account and password are provided and need to be changed.

Begin by visiting the Getting Started Tutorial, and read the pages for the various tabs.

From the Index Data tab, select On this Splunk Server, and choose a data source. I recommend beginning with /var/log/messages or /var/log/syslog depending on whether or not you are using a CentOS/Open SuSE machine or a Mint/Ubuntu machine.

Splunk can be extended with a number of apps. There is an app designed specifically to monitor the health and status of Unix and Linux hosts. If you are running your guest on a network with an Internet connection, you can find it and install it by navigating the Splunk Manager web page, App → Find more apps, then select Splunk for Unix and Linux. In the classroom laboratory, select the App menu item from Splunk
Manager, then Manage Apps. On that page, select Install App from File and provide it with the app.

The installation of a Splunk app will require a Splunk restart; this can be done from within the Splunk Manager.

Once Splunk is restarted, navigate Splunk Manager web page → app → *nix 4.5. From there, you can configure the data sources that you want the app to use.

Experiment with the data available on your server, both from the log data source you originally specified as well as from the *nix app.

If you want splunk to automatically start on boot, run (as root)

scours ~ # /opt/splunk/bin/splunk enable boot-start

Splunk can also be used to collect data from multiple machines and present all of the data in a coherent whole. To do so, we need to set up Splunk Forwarders (which send the data to the central server(s)) and Receivers (the central location(s) that record the results).

To set up a receiver, visit the Splunk Manager web page for that machine, and select Manager from the menu at the top right. Select Forwarding and Receiving, then Configure receiving. The receiver can listen on any unused TCP port, though TCP/9997 is the canonical choice. Choose your port(s) and select Save.

You then need to restart Splunk (Splunk Manager web page → Manager → Server controls → Restart Splunk) for the change(s) to take effect. This is a good time to ensure that the Firewall allows inbound traffic on the selected port(s).

On the forwarder, configure Splunk in essentially the same fashion as before; in particular be sure to select the data sources that you wish Splunk to collect. Then navigate Splunk Manager web page → Manager → Forwarding and Receiving → Configure Forwarding. [There is an option to use “Light Forwarding” where the full Splunk server is not running on the forwarder; we do not have time to cover this option.] Select New, the specify the host IP and listening port of the Splunk receiver. Save; then restart Splunk

Test out the result, and notice that you can now see the logs from both machines from one location.

There is much more that can be done with Splunk. As a simple example, suppose that we set up our Splunk server on the host scours.cosc.tu (192.168.1.63), and that our BIND DNS server is running on shades.cosc.tu (192.168.1.60) where we have configured Splunk to forward data from /var/log/messages to scours.cosc.tu. Suppose that we wanted to see what was going on with the DNS server. We could log in to shades.cosc.tu and look through /var/log/messages; if we had set up syslog forwarding we could even do that from a different host. The trouble though, is that you end up looking through the entire log. Sure, you could use grep and awk to parse the log, but Splunk makes this simpler. Navigate the Splunk web page, then select App and Search. In the Search box, enter

host="shades" named NOT "network unreachable"

This will search all of the Splunk data sources (which includes /var/log/messages from shades.cosc.tu) for any data from the host scours, that contains the word “named” but does not contain the phrase “network unreachable”. We already know from experience that because our BIND server is running on a private network we end up with a number of network unreachable errors; this lets us prune those from the search.

We end up with data like the following:

This has enabled us to get just the data we want in an easy access format. If we had multiple DNS servers, we could collate and coordinate the results from the different servers just as easily.

SSH

Starting the SSH Server.

On CentOS, the SSH server is already running and already allowed through the firewall; it is running version 5.3p1.

On Open SuSE, the server is installed but not enabled. To enable the server navigate
Start Iguana → YaST → System → System Services (Runlevel). Select sshd, and select enable. The Open SuSE 11.3 version if 5.4p1.

To open the firewall, navigate Start Iguana -> YaST -> Security and Users -> Firewall. From allowed Services; select Secure Shell Server, then Add; or from Advanced, select TCP Port 22.

On Ubuntu, the server is not present. Grab the package openssh-server_5.8p1-1ubuntu3_i386.deb either from the labshare or online.
Install it by running

vimes@smallgods:~$ sudo dpkg -i Desktop/openssh-server_5.8p1-1ubuntu3_i386.deb 
[sudo] password for vimes: 
Selecting previously deselected package openssh-server.
(Reading database ... 130180 files and directories currently installed.)
Unpacking openssh-server (from .../openssh-server_5.8p1-1ubuntu3_i386.deb) ...
Setting up openssh-server (1:5.8p1-1ubuntu3) ...
Creating SSH2 RSA key; this may take some time ...
Creating SSH2 DSA key; this may take some time ...
Creating SSH2 ECDSA key; this may take some time ...
ssh start/running, process 3148
Processing triggers for ureadahead ...
ureadahead will be reprofiled on next reboot
Processing triggers for ufw ...
Processing triggers for man-db ...
vimes@smallgods:~$

As noted earlier, the Ubuntu firewall is off by default; if you have enabled it, then you must open the necessary port.

Mint 11 is handled identically to Ubuntu including using the same package openssh-server_5.8p1-1ubuntu3_i386.deb

SSH PKI
SSH can use public keys to authenticate users; this is often more convenient than passwords. To set up the PKI, modify /etc/ssh/sshd_config to uncomment out the following lines (for CentOS 6.2 or OpenSuSE 11.3; the lines are slightly different for Mint 11 / Ubuntu 11.04).

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys

Restart sshd; on CentOS 6.2 & OpenSuSE 11.3 you can use

[root@shades ~]# service sshd restart
Stopping sshd:                                             [  OK  ]
Starting sshd:                                             [  OK  ]
[root@shades ~]#

while on Mint 11 & Ubuntu 11.04 you can use

vimes@smallgods:~$ sudo service ssh restart
[sudo] password for vimes: 
ssh start/running, process 2206
vimes@smallgods:~$

On the SSH server, for each user,

• Ensure that ~/.ssh is chmod 700 (rwx — —)
• Create file ~./ssh/authorized_keys (touch ~/.ssh/authorized_keys)
• Ensure that it has the right permissions (chmod 644 ~/.ssh/authorized_keys)

On the clients, for each user, you must first generate the keys. Run (on client, as user)

[vimes@shades .ssh]$ ssh-keygen 
Generating public/private rsa key pair.
Enter file in which to save the key (/home/vimes/.ssh/id_rsa): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/vimes/.ssh/id_rsa.
Your public key has been saved in /home/vimes/.ssh/id_rsa.pub.
The key fingerprint is:
3f:82:e7:0b:a4:5a:51:4b:a3:62:45:fc:3c:fd:e2:f1 vimes@shades.cosc.tu
The key's randomart image is:
+--[ RSA 2048]----+
|   ..            |
|   ..            |
|    .o+.         |
|   . ++o.        |
|  o o o.S.       |
| . . + .o..      |
|    o o.o+o      |
|   o   +..E.     |
|  .     o.       |
+-----------------+

The public key is ~/.ssh/id_rsa.pub, while the private key is ~/.ssh/id_rsa.

Copy public key from client to the file ~/.ssh/authorized_keys on the server.

ssh user@server and you are done. No password will be required.

Things you can do with ssh….

1. ssh user@remote_host command
2. scp user@remote_host:/path/to/file /local/path/to/file
3. sftp user@remote_host
4. ssh -Y user@remote_host. What does this one do? Check the man page!

Securing SSH
There are a number of things that we can do to try to secure our SSH server. First, we can prevent root from logging in directly. If someone needs root privileges from a remote site, they can log in as a regular user and then use either sudo or su. To make this change, add the line

PermitRootLogin no

to the sshd_config file. Note that the default state is to allow root logins; on the CentOs 6.2 and OpenSuSE 11.3 default configuration files a commented out line allowing root logins is present, while on the Mint 11 / Ubuntu 11.04 default configuration files the line is present and explicitly allows root logins.

Speaking of users, you may want to allow only certain users to be allowed to use SSH to log in to the box. The line

AllowUsers vimes granny margat

will allow only the listed users to be able to SSH into the machine; other users (e.g.nanny) would not be able to log in. Though using a white list of allowed users is generally preferred, you could create a black list of users not allowed to log in via the DenyUsers directive.

Be sure to use only SSH protocol 2, as the older SSH-1 has a number of vulnerabilities and should be considered obsolete. Though SSH-2 is the default, your sshd_config file should contain the line

Protocol 2

to ensure that the system does not fall back to SSH-1.

Useful References

Guide to Computer Security Log Management, Recommendations of the National Institute of Sandards and Technology, by Karen Kent and Murugiah Souppay. Online at http://csrc.nist.gov/publications/nistpubs/800-92/SP800-92.pdf