ITIS 3110 Lab 03

NTP, Syslog, and Secure Shell

Overview
Goals
You will configure a NTP server on your Debian VM that syncs time from the lab time source. Your CentOS VM and Pi
will be configured to sync to your Debian VM. Next, you will set up a syslog server on your Debian VM and send logs to it
from your CentOS VM and Pi. Finally you will deploy and configuration a secure shell (SSH) environment. You will learn
how to install SSH, generate keys, edit the sshd configuration file to specify different types of authentication, and configure
denyhosts. You will then use your client VM to log on to the server VM using SSH.

Deliverables (printed copy with cover and a backup to Moodle)

The printed copy of the lab will be as usual. Include introductory and concluding paragraphs, be
sure to document all entities with ** and answer all questions. Upload copies of your
configuration files and the authorized_keys and sshd_config files to Moodle.
Reminder: all information should be text files except when a screenshot is required!

Information tables**
This lab will use a Debian Virtual machine as the secure shell server and your host machine as the
client. Throughout this document, the terms host and client are used interchangeably to refer to a
terminal on your physical host machine. The first information table is to aid documenting the NTP
andSyslog setup, the second table is for the SSH setup.

Table 1: NTP and Syslog

Description

Formula

Used in Lab

Assigned Subnet (See 3110 Web)

Debian VM

172.16.(n).10

DEBIAN_IP

Raspberry Pi

172.16.(n).20

PI_IP

CentOS VM

172.16.(n).50

CENTOS_IP

NTP Source

172.16.1.253

172.16.1.253

Answer

Table 2: SSH Data

Description
Debian Username
Debian Password
Debian IP Address

Used in Lab
DEBIAN_USER
DEBIAN_IP

Value

Lab
Before starting make sure that network configuration for eth0 and lo interfaces are valid.
Also, make sure your Linux has a valid DNS server configuration. Remember eth0 and
lo are typical names, they may vary on your systems.

NTP
Check the Labs NTP server
1.

Install packages ntp and ntpdate

aptitude R install ntp ntpdate

2. Run ntpdate
/usr/sbin/ntpdate q 172.16.1.253
3. An example report from ntpdate is shown below. The stratum is highlighted in the report below.

prompt$ ntpdate -q clock1.unc.edu

9/14/2015 5:27:00 PM

Page 1 of 9

ITIS 3110 Lab 03

NTP, Syslog, and Secure Shell
server 152.2.21.1, stratum 2, offset 0.002288, delay 0.05145
17 Jan 21:47:01 ntpdate[800]: adjust time server 152.2.21.1 offset 0.002288 sec

Configuring Debian VM NTP Daemon

1.
a
b
c

Edit /etc/ntp.conf
Allow servers on local subnet to query our server
Comment out all lines beginning with server
Add a new line for the Labs NTP source
# Allow clients on 127.16.1.0/24 to query this server
restrict 172.16.(n).0 mask 255.255.255.0 nomodify notrap
# Commented out these servers
#server 0.debian.pool.ntp.org
#server 1.debian.pool.ntp.org
#server 2.debian.pool.ntp.org
#server 3.debian.pool.ntp.org
# Added a line for the Labs NTP source
server 172.16.1.253

2.
a
3.
a
b
4.
a
5.
a
b

Stop the NTP service

/etc/init.d/ntp stop
Set the clock manually
/usr/sbin/ntpdate 172.16.1.253
This step is not necessary but it should help your VMs clock synchronize with the labs time source more quickly
Start the NTP service
/etc/init.d/ntp start
** Check NTP server
ntpdate q DEBIAN_IP
Note: As long as you see a non-zero value for stratum youre fine and can ignore any warning. However it may take
several minutes for your NTP server to synchronize and report its stratum correctly

Configuring CentOS VM NTP Daemon

1.
2.
a
b

You should not configure the CentOS NTP daemon until the Debian NTP daemon has synchronized.
Edit /etc/ntp.conf
Comment out all lines beginning with server
Add a new line for your Debian VMs NTP source
# Commented out these servers
server 0.rhel.pool.ntp.org
server 1.rhel.pool.ntp.org
server 2.rhel.pool.ntp.org
# Added a line for my Debian VMs NTP source
server DEBIAN_IP

3.
a
b
c
4.
a
b

Stop NTP service

/etc/init.d/ntpd stop
service ntpd stop
Note: stop, start, restart and status are all options that can be used by service

Set the clock manually

/usr/sbin/ntpdate DEBIAN_IP
This step is not normally necessary but it should help your VMs clock synchronize to your Debian
time source more quickly
5. Start NTP service
a /etc/init.d/ntpd start
6. ** Check NTP
a /usr/sbin/ntpdate q CENTOS_IP
b Note: As long as you see a non-zero value for stratum youre fine and can ignore any warning.
However it may take several minutes for your NTP server to synchronize and report its stratum
correctly
c If your CentOS VM is having trouble synchronizing try commenting out the dummy stratum 10
server from the ntp.conf file.

9/14/2015 5:27:00 PM

Page 2 of 9

ITIS 3110 Lab 03

NTP, Syslog, and Secure Shell
Configuring the Raspberry Pi NTP Daemon
By this time you should be an NTP pro. Find the Raspbian NTP configuration file and configure it to
use the Debian NTP service.
After restarting the daemon, check that the Pi is getting the time from the Debian server.
Note: if ntpdate is not found on your Pi iInstall ntpdate from http://lab302-repo.hades.lab. If you
are at home download ntpdate deb file from an appropriate source and install it using following
command:
dpkg i ntpdate_4.2.6.p5+dfsg-3_armhf.deb

Syslog
Configuring Debian VM Syslog Daemon
1.
a.
b.

Debian uses rsyslogd, an enhanced replacement for the venerable syslog package. We will not be using all of its advanced
features for this lab.
Edit /etc/rsyslog.conf
Enable Logging of remote syslog messages
Send all log messages to a remote syslog server
# Uncommented the following lines. These enable
# Logging of incoming UDP messages from the network.
# This is normally achieved with the -r option to syslog
$ModLoad imudp
$UDPServerRun 514

2. Restart syslog server

a. /etc/init.d/rsyslog restart

Configuring CentOS VM Syslog Daemon

1.
a.

Edit /etc/rsyslog.conf
Send all log messages to your Debian VM. Ensure the following is in the file.
# Transmit all logs to my Debian VM
*.* @@DEBIAN_IP

2.
a.
b.
3.
a.
b.
c.
d.

Restart syslog server

/etc/init.d/syslog restart
Service rsyslog restart
** Test syslog
logger hello from userid on CentOS VM
Substitute your userid in the above command
The above message should appear in /var/log/syslog on your Debian VM.
** Document files in report

Configure the Pi Syslog Daemon

Follow the steps for the CentOS Syslog configuration. Dont forget to test with logger.

SSH
Installing Secure Shell
Note: Hopefully, you have used ssh server from both your Debian server VM and your CentOS client VM. In case you have
not completed the openssh server install:
To install the secure shell daemon on your server, you will use aptitude. As root on your Debian VM, execute:
# aptitude -R install openssh-server

This installs the daemon, generates server keys, and starts sshd automatically.
Determining Server IP Address
With your Debian VM, verify your IP address with the following command:
$ /sbin/ifconfig
Record this IP address in the Information table at the beginning of this document. You will need to use this IP address when
using SSH to log in to your server.

9/14/2015 5:27:00 PM

Page 3 of 9

ITIS 3110 Lab 03

NTP, Syslog, and Secure Shell
Testing Login with SSH
With the default sshd configuration file, password authentication will be enabled. From your hostmachine (client), try to log in to your server VM using SSH.
$ ssh DEBIAN_USER@DEBIAN_IP
You can type a few commands to verify you have access to the server. Type exit to close the session.

Installing DenyHosts
DenyHosts monitors the secure log (/var/log/auth.log on Debian) for failed login attempts. Its configuration file is in
/etc/denyhosts.conf, but the default configuration is acceptable for our uses.
# aptitude R install denyhosts
This installs the daemon and starts denyhosts automatically.

Testing DenyHosts
DenyHosts has different policies depending on whether a failed attempt is for a non-existent account, a normal account, or
the root account. Access to the root account is the strictest and therefore the easiest to test.
Run the SSH command twice and simply hit enter at the password prompts.
$ ssh root@DEBIAN_IP
Wait a moment, as blocking IP addresses is not instantaneous and then try to log in again using SSH. You should see the
error below.
$ ssh root@DEBIAN_IP
ssh_exchange_identification: Connection closed by remote host
You can also see the blocked IP address in /etc/hosts.deny on the server.

White-Listing an IP Address or Network

Occasionally you will need to white-list an IP address or network to prevent DenyHosts from blocking it. This can be
achieved by editing /etc/hosts.allow. In this lab, it makes sense to white-list the entire labs network, as below.
# White-list the Labs network
sshd: 172.16.0.0/255.255.0.0
After white-listing the network, you should be able to log in from your client again. This step is required to continue the
lab.

Generating Keys
We will next create a public/private key pair so we can connect more securely. On your client, execute the following
command.
$ ssh-keygen -t rsa -b 4096
This step requests a password that will be used to encrypt your private key on disk. It is not essential to set a password, but
it adds an extra layer of security. For this lab, DO NOT enter a password here.
This command will create two keys: id_rsa and id_rsa.pub in ~/.ssh/.

Copying Public Key to Server

We need to copy our public key to the server. The simplest method is to use secure shell to transfer the key. Run the
following command on the client to copy your public key to the server.
$ scp ~/.ssh/id_rsa.pub DEBIAN_USER@DEBIAN_IP:.
The above command transfers your public key to your home directory on the server. In UNIX parlance, . is the current
directory, which defaults to your home directory when doing a secure copy.

Authorizing Public Key on the Server

Next, we will authorize your public key to authenticate your user on the server. We first need to create an empty
authorized_keys file and configure its permissions correctly.

9/14/2015 5:27:00 PM

Page 4 of 9

ITIS 3110 Lab 03

NTP, Syslog, and Secure Shell
$ mkdir ~/.ssh
$ touch ~/.ssh/authorized_keys
$ chmod 700 ~/.ssh
$ chmod 600 ~/.ssh/authorized_keys
Reminder: The chmod command configures permissions for files and directories in Linux. The above example is using the
octal notation. 7=RWX, 6-RW-, 5=R-X, etc. First group is owner, then group, then world.
Once the authorized_keys file has been created, we need to append our public key to it.
$ cat id_rsa.pub >> ~/.ssh/authorized_keys
Keys should always be appended to the authorized_keys file as you may have multiple keys for multiple machines.

Modifying sshd_config
The configuration file for the SSH daemon is located in /etc/ssh/sshd_config on your server. We will be modifying lines
relating to authentication. Using your editor of choice you will need to locate and modify certain lines as follows:
# Make sure that we can authenticate using our public/private key pair
PubkeyAuthentication yes
# Disable logins using standard passwords
PasswordAuthentication no
You will need to restart sshd after your modifications to enable these changes. Execute:
# /etc/init.d/ssh restart

Testing Key-Based Login

From your client, try to log on to your server using SSH. You can also log on using the normal method:
$ ssh DEBIAN_USER@DEBIAN_IP
Assuming that you did not set a password on your private key, you should now have a shell on your Debian VM.
If your private key were not located in ~/.ssh/id_dsa or ~/.ssh/id_rsa, you would need to specify its location with as
follows:
$ ssh USER@HOST -i KEYFILE

SSH and the Pi

An ssh client should be part of the Raspbian Linux. Try logging onto the Debian SSH
Server with ssh on the PI.
What error occurs?
What change to the Debain SSH server configuration do you need to make to allow
the Pi to ssh to the Debian server using standard passwords?
Make the change to the Debian SSH configuration file and test. Document it working.**
Depending on your preference you may leave the change when done or remove the
change.

Questions
1.
2.
3.
4.
5.
6.
7.
8.
9.

What does nanos -w option do?

What does aptitudes -R option do? Use the man page for aptitude to answer this question.
What is the stratum of the Labs NTP source?
What is the stratum of your Debians NTP server?
What is the stratum of your CentOS client?
What does the *.* stand for when configuring the syslog destination?
If you do not create a passphrase for your ssh private key, what would happen if someone were able to copy your
private key file?
Using key based authentication with SSH and having no passphrases for the private key is very helpful in some
circumstances. What is one of these circumstances? (Think about using scp)
What, if any, are the security concerns of someone stealing your public key?

9/14/2015 5:27:00 PM

Page 5 of 9

ITIS 3110 Lab 03

NTP, Syslog, and Secure Shell
Overview
Goals
The installation of a DNS server that is authoritative for a sub domain of hades.lab. This DNS server should be capable of
answering any query of the hades.lab domain and its sub domains. It should also be able to answer any queries made of its
sub domain by the name server for the entire domain.
Stage two is taking the working DNS server for the sub domain and making it DNSSEC aware. This lab will not show how
integrate DNSSEC with other DNS servers as the lab's DNS server is not capable of speaking DNSSEC .

Deliverables

Lab Report Including the following

All the completed information sections throughout the lab
Description of the lab steps completed and the results
Any errors you encountered and the steps you took to resolve them
Any mistakes found or corrections made to the lab steps
Answers to the questions posed at the end of this lab
Text copies of the following in the report:
/etc/bind/named.conf.local
Zone file (e.g. /var/cache/bind/db.SUBZONE)
Text file containing the results of 'dig +dnssec t soa SUBZONE @DEBIAN_IP'

Information
Table 3
Description
Assigned Subnet Number:
Your Last Name:
Debian VM IP:
Raspbian Pi IP:
CentOS VM IP:
DNS Forwarder:
Subzone:

Formula
n
<last_name>
172.16.n.10
172.16.n.20
172.16.n.50
<last_name>.hades.lab

Used in Lab
DEBIAN_IP
PI_IP
CENTOS_IP
172.16.1.252
SUBZONE

Answer

172.16.1.252

If your last name is Jones, your SUBZONE would be jones.hades.lab. Use the last name as it appears (no uppercase
letters) on the IP subnet assignment page on Moodle. REMEMBER - as of this lab your DEBIAN_IP needs to end in 10.
The DNS glue records on the lab server have been set to point to 172.16.n.10. Any number other than 10 will not function
properly.

Stage 1: DNS Server Installation & Configuration

Getting Started
1.
2.

Load Debian VM
Verify the VMs IP Address matches the IP address you calculated in the Information section above
Refer to Lab 1 for information on viewing and modifying your IP address

Initial Installation and Configuration

3.
a
4.
a
i
ii
iii
b

Install the bind9 package

aptitude R install bind9
Edit /etc/bind/named.conf.options
Debian splits the standard named.conf into three separate files
named.conf boiler plate file. Contains some standard configuration and references the two files listed below. This file
almost never needs to be changed
named.conf.options contains site-specific configuration options to the name server
named.conf.local contains references to the local zones that this server controls
Uncomment the forwarders section and replace 0.0.0.0 with IP of the Labs DNS forwarder noted in the Information
section above

9/14/2015 5:27:00 PM

Page 6 of 9

ITIS 3110 Lab 03

NTP, Syslog, and Secure Shell
forwarders {
172.16.1.252;
};
5.
a
6.
a

Restart DNS Server

/etc/init.d/bind9 restart
Verify server is responding correctly
dig mirror.hades.lab @DEBIAN_IP
Note: You should see a non-zero value for the "Answer" when you do a dig. If you see a zero, there is an error. This is
generally true for all digs you do.

Creating a Sub Zone

1.
a

Edit /etc/bind/named.conf.local
Add a zone for your subzone you calculated in the Information section above
zone "SUBZONE" IN {
type master;
file "/var/cache/bind/db.SUBZONE";
allow-update { none; };
};

2.
a
b
c
d

Create a zone file for your subzone

e.g. /var/cache/bind/db.SUBZONE
The file name must match the file name referenced in named.conf.local
Use the IP addresses you calculated in the Information Section above
$TTL and Negative Cache TTL are both set to 2 minutes so mistakes any mistakes can be corrected quickly. In a real site,
you would want $TTL set to a minimum of one day and the Negative Cache TTL set to 15 minutes.
Use standard convention for the Serial, e.g. yyyymmddnn.
$ORIGIN SUBZONE.
$TTL
2m
@ IN SOA ns.SUBZONE. jwatso8.uncc.edu. (
2011091201
; Serial
1w
; Refresh
1d
; Retry
28d
; Expire
2m )
; Negative Cache TTL
;
@
IN
NS
ns.SUBZONE.
@
IN
A
DEBIAN_IP
ns.SUBZONE.
IN
A
DEBIAN_IP
debian
IN
A
DEBIAN_IP
raspbian
IN
A
PI-IP
centos
IN
A
CENTOS_IP
test.SUBZONE.

3.
a

IN

CNAME

Debian

Figure 1. If you make any mistakes in this file, update the Serial before

Verify the zone file you just wrote

named-checkzone SUBZONE /var/cache/bind/db.SUBZONE
Should return a statement saying everything is well. Correct any errors in your zone file before continuing.

4. Reload the DNS server

a rndc reload
5.
a
b
c

Verify that the server is responding correctly

dig debian.SUBZONE @DEBIAN_IP
dig debian.SUBZONE @172.16.1.252
Both dig commands should return the same information

Troubleshooting

The system log may contain useful error messages

/var/log/syslog
less is a useful command to view the log file
<shift>-G jumps to the last line of the log file
<shift>-F will monitor the log file

9/14/2015 5:27:00 PM

Page 7 of 9

ITIS 3110 Lab 03

NTP, Syslog, and Secure Shell

<ctrl>-C to stop monitor mode

q to quit

Stage 2: DNSSEC
1
a

Edit /etc/bind/named.conf.options
Enable DNSSEC
// Add this inside the options {} statement
dnssec-enable true;

2
a
b
3
a
b
i
c

Create /etc/bind/keys and cd to it

mkdir /etc/bind/keys
cd /etc/bind/keys
Generate DNSSEC Zone Signing Key for your domain
This step needs to be run from the /etc/bind/keys directory
dnssec-keygen r /dev/urandom a NSEC3RSASHA1 b 1024 n ZONE SUBZONE
Never use the -r /dev/urandom on a real server. It is included here for speed reasons
Note the name of your Zone Signing Key in the table below. Be aware that dnssec-keygen returns the key name without
the .key extension. Add the .key extension when recording the key file name
Generate DNSSEC Key Signing Key
This step needs to be run from the /etc/bind/keys directory
dnssec-keygen r /dev/urandom f KSK a NSEC3RSASHA1 b 2048 n ZONE SUBZONE
Note the name of your Key Signing Key in the table below. Be aware that dnssec-keygen returns the key name without the
.key extension. Add the .key extension when recording the key file name

4
a
b
c

Key Name
Zone Signing Key
Key Signing Key
5
a

6
a

7
a
b

Used in Lab
ZONE_SIGNING_KEY
KEY_SIGNING_KEY

File Name

Edit your zone file and $INCLUDE the two keys you noted in the table above
e.g. /var/cache/bind/db.SUBZONE
Remember to increment the zones serial number
; Append these two lines to your zone file.
$INCLUDE /etc/bind/keys/ZONE_SIGNING_KEY
Create a signed zone file
This step needs to be run from the /etc/bind/keys directory. It is all on one line.
dnssec-signzone r /dev/urandom -k KEY_SIGNING_KEY -o SUBZONE -t -A
/var/cache/bind/db.SUBZONE ZONE_SIGNING_KEY
Verify the zone file is signed correctly
named-checkzone SUBZONE /var/cache/bind/db.SUBZONE.signed
Should mention that the zone is signed
zone "SUBZONE" IN {
type master;
file "/var/cache/bind/db.SUBZONE.signed";
allow-update { none; };
};

Figure 2: Update /etc/bind/named.conf.local to use signed zone file

8
a
9
a
b

Reload the DNS server

rndc reload
Verify DNSSEC is working correctly
dig +dnssec centos.SUBZONE @DEBIAN_IP
The dig output should contain a number of RRSIGS that contain long alphanumeric strings. These are the
signatures for each record

Questions
1

Nowhere in this lab exercise did we modify the /etc/resolv.conf file to use the DNS server we created. Why does this
work?

9/14/2015 5:27:00 PM

Page 8 of 9

ITIS 3110 Lab 03

NTP, Syslog, and Secure Shell
2
a
3

Can you look up a host name in your sub domain from your host workstation? Please explain your answer and why you
think it does or does not work.
E.g. does dig debian.SUBZONE work on your host workstation.
Why is using /dev/urandom in the real world a bad idea? The manual page for random will likely help with answering this
question. (man 4 random) Explain in your own words how this could be exploited in practice.

9/14/2015 5:27:00 PM

Page 9 of 9