Configuring SSH to Use Public Key Authentication
In addition to authenticating to the SSH server with a username and
password combination, you can also configure your sshd daemon to allow
authentication using an RSA or DSA public key.
For this to work, the public key of the user on the client system must be stored in the
~/.ssh/ authorized_keys
file in the home directory of the user on the server system that you will
authenticate as. To do this, you need to securely copy the public key from
the client system to the server system. The private key, of course, remains
on the client system.
If you configure the SSH server to use public key authentication:
a) The SSH client tells the SSH server which public key should be used for
authentication when the SSH session is initially established.
b)The SSH server then checks to see if it has that client’s public key; if
it does, it will generate a random number and encrypt it with that
public key.
c) It then sends the encrypted number to the client, which
decrypts it using the private key associated with the public key.
d) The client then calculates an MD5 checksum of the number it received from
the server.
e) It sends the checksum back over the SSH server system,
which then calculates its own MD5 checksum of the number it originally
sent. If the two checksums match, the user is automatically logged in.
To configure public key authentication, the first thing you need to do
is create the public/ private key pair on the client system so that
you can send the public key to the SSH server. This can be done using
the
ssh-keygen
command. Complete the following:
1. At the shell prompt of the client system, enter
ssh-keygen –t rsa
or
ssh-keygen –t dsa
depending on which encryption method your SSH server supports. To be safe,
you can simply use both commands to make two key pairs—one for RSA encryption
and the other for DSA encryption.
2. When prompted for the file in which the private key will be saved,
press enter to use the default filename of
~/.ssh/id_rsa
or
~/.ssh/id_dsa
The associated public key will be saved as
~/.ssh/id_rsa.pub
or
~/.ssh/id_dsa.pub
respectively.
3. When prompted, enter a passphrase for the key. It is important that
you use a passphrase. If you don’t, then anyone who manages to get a
copy of your key files could authenticate to the SSH server without
being required to enter a passphrase. Assigning a passphrase to the
key renders the key useless if someone doesn’t know it.
At this point, your key pair is created. An example of creating an RSA
key pair is shown here:
rtracy@ws1:~> ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/rtracy/.ssh/id_rsa): Enter
passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/rtracy/.ssh/id_rsa. Your
public key has been saved in /home/rtracy/.ssh/id_rsa.pub. The key
fingerprint is: ba:14:48:14:de:fd:42:40:f2:4b:c8:8b:03:a4:6d:fc
rtracy@ws1
The key's randomart image is:
+--[ RSA 2048]----+
| . +oo |
|oo + = o |
|o + = + o |
|o++o . |
| oEoS. |
| . o. |
|o|
| .. |
|.|
+-----------------+
rtracy@ws1:~>
The next thing you need to do is to copy the public key you just
created to the SSH server.
An easy (and secure) way to do this is to use the
scp
command you learned about earlier in this chapter. The
syntax is
scp ~/.ssh/key_name.pub user_name@address_of_SSH_server:filename
In the example shown here, the RSA public key for the local rtracy
user on WS1 is copied to the home directory of the rtracy user on WS3
and saved in a file named keyfile:
rtracy@ws1:~> scp ~/.ssh/id_rsa.pub ws3:keyfile
Password:
id_rsa.pub 100% 392 0.4KB/s 00:00
rtracy@ws1:~>
At this point, the contents of the key file you just copied need to be
appended to the end of the
~/.ssh/authorized_keys
file in the home directory of the user you will connect to the SSH server as.
An easy way to do this is to connect to the SSH server system using a standard
(password- authenticated) SSH session and then use the cat command to
append the contents of the key file to the end of the
~/.ssh/authorized_keys
file in the user’s home directory. An example of how to do this is shown here:
rtracy@ws1:~> ssh -l rtracy ws3
Password:
Last login: Thu Jun 2 15:05:34 2011 from 192.168.1.84
rtracy@WS3:~> mkdir ~/.ssh
rtracy@WS3:~> cat keyfile >> ~/.ssh/authorized_keys
rtracy@WS3:~>
In this example, I logged in to the WS3 system via an SSH connection
as the remote rtracy user and then created the hidden .ssh directory
in that user’s home directory. I had to create the directory because
it didn’t exist yet. If the .ssh directory already exists, you can
skip this step and just append the contents of the key file to the end
of the authorized_keys file.
Notice in the example that I used the cat command with the >> redirection
characters to add the contents of the file named keyfile to the end of the authorized_keys file.
In this example, the authorized_keys file didn’t exist yet, so the
redirection process automatically created it for me. Because of this,
I could have actually just used a single > redirection character
because the file didn’t exist.
If, on the other hand, the authorized _keys file does already exist,
it’s very important that you remember to use the >> redirection
characters instead of >. Remember, using >> will append the output of
the command to the end of the specified file. Using a single
redirection > character will overwrite the entire file with the output
of the command. That wouldn’t be a good thing if the authorized_keys
file already had several keys in it that you wanted to keep.
You can now test the configuration to see if public key authentication
works. If you’re still logged in to an SSH session with the SSH
server, exit out of it. Then establish a new SSH session with the
server. You should be prompted for the key file’s passphrase instead
of a username and password, as shown in Figure 18-9.
Once you enter the passphrase, you will be authenticated to the SSH
server. Notice in the next example that no password was requested to
establish the SSH session:
rtracy@ws1:~> ssh -l rtracy ws3
Last login: Thu Jun 2 16:13:39 2011 from 192.168.1.84
rtracy@WS3:~>
If desired, you can use the
ssh-agent
command to eliminate the need to enter the passphrase every time you establish
an SSH connection.
Complete the following:
1. At the shell prompt of your client system, enter
ssh-agent bash
2. At the shell prompt, enter
ssh-add ~/.ssh/id_rsa
or
ssh-add ~/.ssh/id_dsa
depending on which key file you have created.
3. When prompted, enter the key file’s passphrase. When you do, you
should be prompted that the identity has been added. An example
follows:
rtracy@ws1:~> ssh-agent bash
rtracy@ws1:~> ssh-add ~/.ssh/id_rsa
Enter passphrase for /home/rtracy/.ssh/id_rsa:
Identity added: /home/rtracy/.ssh/id_rsa (/home/rtracy/.ssh/id_rsa)
rtracy@ws1:~>
Once this is done, the ssh-agent process stores the passphrase in
memory. It then listens for SSH requests and automatically provides
the key passphrase for you when requested.
LX0-104 Exam Objectives (X)
Showing posts with label configuring. Show all posts
Showing posts with label configuring. Show all posts
Thursday, December 22, 2016
Encryption IV
Tunneling Traffic Through SSH
One of the key security issues you must deal with as a system
administrator is the fact that many commonly used network protocols
transfer information as clear text. Good examples of this are the POP3
and IMAP daemons we discussed in the preceding chapter. We noted that
for your Linux MTA to download e-mail messages to client systems, you
must first enable either your POP3 or IMAP daemon via xinetd. Once
done, end users can use an e-mail client to connect to the MTA and
download their mail using the appropriate protocol. The problem,
however, is the fact that both of these daemons transfer data as clear
text by default. That means the usernames and passwords users send to
authenticate to the MTA are sent as clear text along with all the con-
tents of their e-mail messages. This allows anyone with a sniffer to
capture packets and view the contents of the transmissions.
The good news is SSH can be used to encrypt clear-text traffic by
tunneling it through an SSH connection. When client software for the
tunneled protocol (such as an e-mail client using POP3) establishes a
connection with the local SSH client, the traffic is encrypted using
SSH and tunneled through to the SSH server. On the SSH server end, the
traffic is decrypted and then forwarded to the appropriate target
service (in this case, the POP3 daemon). This is great, because the
information is encrypted before being transmitted, even though the
original protocol (in this case, POP3) doesn’t support encryption.
Let’s walk through an example of how you can use SSH to tunnel POP3 traffic:
1. Make sure the ssh client is installed on the local system where the
e-mail client will run.
2. Make sure the sshd daemon is installed and running on the POP3 server.
3. Ensure IP port 22 is open on the server where sshd is running.
4. On the system where sshd is running, switch to root and edit the
/etc/ssh/sshd_config
file.
5. Locate the AllowTcpForwarding parameter, uncomment it if necessary,
and then set it to a value of yes. An example is shown here:
AllowTcpForwarding yes
6. Save your changes to the file and exit the editor.
7. Restart the sshd daemon by entering systemctl restart sshd at the
shell prompt (as root).
8. Switch to the client system.
9. Create a local ssh tunnel from a local high IP port (in this
example, port 2345) to port 110 on the POP3 server using the following
command (enter the remote user’s password when prompted):
ssh -f -N -L 2345:pop3_host_address:110 user_name@pop3_host_address
The options specified in this command do the following:
• –N and –f
Tell ssh not to execute a command remotely on the server
and to run in the background after prompting for the remote user’s
password
• –L
Specifies three things:
• The local port to be used for the client end of the tunnel (in
this case, 2345)
• The hostname or IP address of the remote POP3 server
• The port on the remote server that will be used for the server
end of the tunnel (in this case, 110)
You don’t have to use port 2345. You can use the same port on both
ends if desired. However, be aware that you will need to switch to the
root user if you want to use a port number less than 1024 on the
client side of the tunnel. These are called privileged ports.
10. With the tunnel established, configure the local e-mail client
program to retrieve mail from the local system on the port you
configured for the client end of the SSH tunnel. In this example, you
would configure it to get mail from the local system’s IP address on
port 2345. An example of how to do this with the Evolution e-mail
client is shown in Figure 18-6.
Note that I used the hostname of the local host, not the POP3 server, in the Server field.
I also added the port number of the workstation end of the tunnel to the end of the
hostname.
At this point, when the client uses the POP3 protocol to download new
messages, the SSH client on the local system will encrypt the request
and forward it to the SSH server through the SSH tunnel you
established. The SSH server will receive the request, decrypt it, and
then pass the data on to the local port 110, where the POP3 daemon is
listening. The cool thing about this process is that it is completely
transparent to the e-mail client software. As far as it’s concerned,
it’s retrieving e-mail from a local POP3 server.
You can test the tunnel you created using the telnet command from the
client end of the tunnel. The syntax is
telnet localhost client_tunnel_port
Here’s an example:
telnet localhost 2345
When you do this, you should see a connection established with the remote system where the POP3 daemon is running. An example is shown in Figure 18-7.
You can also tunnel your X server traffic to remote X clients using an SSH connection. This is important because unencrypted X traffic provides an attacker with a gold mine of information that he or she can use to compromise your systems.
To configure a remote X client without encryption, you can use the
following procedure:
1. On the remote X client, enter
xhost +X_server_hostname
This tells the client to accept connections from the X server.
2. On the X server, enter
DISPLAY=X_client_hostname:0.0
and then enter
export DISPLAY
This tells the X server to display its output on the remote X client.
3. From the X client, use the ssh client to access the shell prompt on
the X server and then run the graphical application you want displayed
on the X client. For example, you could enter gedit at the shell
prompt to remotely display the gedit text editor. You could also enter
office at the shell prompt to remotely display the OpenOffice.org
suite.
This procedure works, but all the X traffic is transmitted
unencrypted. This isn’t good. Instead, you should use SSH to tunnel
the X server traffic between the X server and the X client. You can do
this using one of the following options:
• Use the –X option with the ssh client program.
• Set the
ForwardX11
option to a value of
yes
in the
/etc/ssh/ssh_config
file on the X client system.
Once this is done, you then need to set the
X11Forwarding
option to
yes
in the
/etc/ssh/sshd_config
file on the X server system.
LX0-104 Exam Objectives (X)
One of the key security issues you must deal with as a system
administrator is the fact that many commonly used network protocols
transfer information as clear text. Good examples of this are the POP3
and IMAP daemons we discussed in the preceding chapter. We noted that
for your Linux MTA to download e-mail messages to client systems, you
must first enable either your POP3 or IMAP daemon via xinetd. Once
done, end users can use an e-mail client to connect to the MTA and
download their mail using the appropriate protocol. The problem,
however, is the fact that both of these daemons transfer data as clear
text by default. That means the usernames and passwords users send to
authenticate to the MTA are sent as clear text along with all the con-
tents of their e-mail messages. This allows anyone with a sniffer to
capture packets and view the contents of the transmissions.
The good news is SSH can be used to encrypt clear-text traffic by
tunneling it through an SSH connection. When client software for the
tunneled protocol (such as an e-mail client using POP3) establishes a
connection with the local SSH client, the traffic is encrypted using
SSH and tunneled through to the SSH server. On the SSH server end, the
traffic is decrypted and then forwarded to the appropriate target
service (in this case, the POP3 daemon). This is great, because the
information is encrypted before being transmitted, even though the
original protocol (in this case, POP3) doesn’t support encryption.
Let’s walk through an example of how you can use SSH to tunnel POP3 traffic:
1. Make sure the ssh client is installed on the local system where the
e-mail client will run.
2. Make sure the sshd daemon is installed and running on the POP3 server.
3. Ensure IP port 22 is open on the server where sshd is running.
4. On the system where sshd is running, switch to root and edit the
/etc/ssh/sshd_config
file.
5. Locate the AllowTcpForwarding parameter, uncomment it if necessary,
and then set it to a value of yes. An example is shown here:
AllowTcpForwarding yes
6. Save your changes to the file and exit the editor.
7. Restart the sshd daemon by entering systemctl restart sshd at the
shell prompt (as root).
8. Switch to the client system.
9. Create a local ssh tunnel from a local high IP port (in this
example, port 2345) to port 110 on the POP3 server using the following
command (enter the remote user’s password when prompted):
ssh -f -N -L 2345:pop3_host_address:110 user_name@pop3_host_address
The options specified in this command do the following:
• –N and –f
Tell ssh not to execute a command remotely on the server
and to run in the background after prompting for the remote user’s
password
• –L
Specifies three things:
• The local port to be used for the client end of the tunnel (in
this case, 2345)
• The hostname or IP address of the remote POP3 server
• The port on the remote server that will be used for the server
end of the tunnel (in this case, 110)
You don’t have to use port 2345. You can use the same port on both
ends if desired. However, be aware that you will need to switch to the
root user if you want to use a port number less than 1024 on the
client side of the tunnel. These are called privileged ports.
10. With the tunnel established, configure the local e-mail client
program to retrieve mail from the local system on the port you
configured for the client end of the SSH tunnel. In this example, you
would configure it to get mail from the local system’s IP address on
port 2345. An example of how to do this with the Evolution e-mail
client is shown in Figure 18-6.
Note that I used the hostname of the local host, not the POP3 server, in the Server field.
I also added the port number of the workstation end of the tunnel to the end of the
hostname.
At this point, when the client uses the POP3 protocol to download new
messages, the SSH client on the local system will encrypt the request
and forward it to the SSH server through the SSH tunnel you
established. The SSH server will receive the request, decrypt it, and
then pass the data on to the local port 110, where the POP3 daemon is
listening. The cool thing about this process is that it is completely
transparent to the e-mail client software. As far as it’s concerned,
it’s retrieving e-mail from a local POP3 server.
You can test the tunnel you created using the telnet command from the
client end of the tunnel. The syntax is
telnet localhost client_tunnel_port
Here’s an example:
telnet localhost 2345
When you do this, you should see a connection established with the remote system where the POP3 daemon is running. An example is shown in Figure 18-7.
You can also tunnel your X server traffic to remote X clients using an SSH connection. This is important because unencrypted X traffic provides an attacker with a gold mine of information that he or she can use to compromise your systems.
To configure a remote X client without encryption, you can use the
following procedure:
1. On the remote X client, enter
xhost +X_server_hostname
This tells the client to accept connections from the X server.
2. On the X server, enter
DISPLAY=X_client_hostname:0.0
and then enter
export DISPLAY
This tells the X server to display its output on the remote X client.
3. From the X client, use the ssh client to access the shell prompt on
the X server and then run the graphical application you want displayed
on the X client. For example, you could enter gedit at the shell
prompt to remotely display the gedit text editor. You could also enter
office at the shell prompt to remotely display the OpenOffice.org
suite.
This procedure works, but all the X traffic is transmitted
unencrypted. This isn’t good. Instead, you should use SSH to tunnel
the X server traffic between the X server and the X client. You can do
this using one of the following options:
• Use the –X option with the ssh client program.
• Set the
ForwardX11
option to a value of
yes
in the
/etc/ssh/ssh_config
file on the X client system.
Once this is done, you then need to set the
X11Forwarding
option to
yes
in the
/etc/ssh/sshd_config
file on the X server system.
LX0-104 Exam Objectives (X)
Tuesday, December 20, 2016
Securing I
Configuring xinetd and inetd
In this part of this chapter, you learn how to configure Linux
“super-daemons.” Most Linux distributions install a wide variety of
network services during the system installation process. Most of these
services, such as Telnet, are very handy and provide a valuable
service. However, they aren’t needed most of the time. We need a way
to provide these services when requested but then unload them when
they aren’t needed, saving memory, reducing CPU utilization, and
increasing the overall security of the system.
Depending on your distribution, there are two ways to do this. The
following options are discussed here:
• Configuring xinetd
• Configuring inetd
Configuring xinetd
Many Linux distributions include a special daemon called xinetd that
can be used to manage a number of different network services. In this
part of this chapter, you learn how to configure and use xinetd. We’ll
discuss the following topics:
• How xinetd works
• Configuring xinetd network services
• Using TCP Wrappers
Let’s begin by discussing how the xinetd daemon works.
How xinetd Works
The xinetd daemon is a super-daemon. It’s called a super-daemon
because it acts as an intermediary between the user requesting network
services and the daemons on the system that provide the actual
service. This is shown in Figure 17-26.
When a request for one of the network services managed by xinetd
arrives at the system, it is received and processed by xinetd, not the
network daemon being requested. The xinetd daemon then starts the
daemon for the requested service and forwards the request to it. When
the request has been fulfilled and the network service is no longer
needed, xinetd unloads the daemon from memory.
Some of the network services managed by xinetd include the following:
• chargen
• daytime
• echo
• ftp
• pop3
• rsync
• smtp
Configuring xinetd Network Services
As with all the network services I’ve discussed, the xinetd
configuration files are stored in /etc. The xinetd daemon itself is
configured using the
/etc/xinetd.conf
file. Generally speaking, you won’t need to make many changes to this file. The default
configuration usually works very well.
At the end of this file you will notice a directive that reads
includedir /etc/xinetd.d
This line tells the xinetd daemon to use the configuration files in
/etc/xinetd.d. These files tell xinetd how to start each service when
requested. Each of these files is used to configure the startup of a
particular service managed by xinetd.
For example, the
vsftpd file
in
/etc/xinetd.d
is used to configure the vsftpd FTP server daemon. The xinetd configuration
settings for vsftpd in this file are shown here:
service ftp
{
socket_type = stream
protocol = tcp
wait = no
user = root
server = /usr/sbin/vsftpd
# server_args =
# log_on_success += DURATION USERID
# log_on_failure += USERID
# nice = 10
disable = yes
}
This file doesn’t configure the daemon itself. It only tells xinetd
how to start up the daemon. The actual configuration file for the
vsftpd daemon itself is in /etc/vsftpd.conf.
One of the most important parameters in the
/etc/xinetd.d/vsftpd
file is the disable directive.
This directive specifies whether or not xinetd is allowed to start the
daemon when requested.
In the preceding example, this directive is set to yes, which means the daemon will not
be started when requested.
The daemon to actually start is specified by the
server = directive
In the example, xinetd will start the /usr/sbin/vsftpd daemon.
server = /usr/sbin/vsftpd
To enable this daemon, you need to edit this file and change the disable
parameter to a value of no.
disable = no
After changing a value in any of the files in /etc/xinetd.d, you need to
restart the xinetd daemon using its init script in /etc/rc.d/init.d or /etc/init.d.
TIP If you enable a service provided by xinetd, you’ll need to create
an exception in your Linux system’s host firewall to allow traffic for
the IP port used by the daemon.
Using TCP Wrappers
If you enable a particular service using its configuration file in the
/etc/xinetd.d/ directory, any host can connect to it through xinetd.
However, depending on how your system is deployed, you may need to
control access to these network services. You may want to limit access
to only a specific set of hosts and deny access to everyone else.
If this is the case, you need to configure these services to use TCP
Wrappers, which are used by xinetd to start and run the network
services using a set of configuration files that specify who can and
who can’t access the service.
To use TCP Wrappers, you first need to enable the functionality in
each service’s configuration file in /etc/xinetd.d. Do the following:
1. Verify that the tcpd package has been installed on your Linux system.
2. Open the appropriate configuration file in a text editor.
3. Comment out the existing server = line from the file.
4. Add the following line:
server = /usr/sbin/tcpd
This will cause xinetd to start the tcpd daemon instead of the service
daemon itself.
5. Add the following line:
server_args = path_to_daemon
This tells the tcpd daemon to then run the requested network daemon.
In the example shown here, the /etc/xinetd.d/telnet file has been
configured to run the vsftpd daemon within a TCP Wrapper:
service ftp
{
# #
socket_type = stream
protocol = tcp
wait = no
user = root
# server = /usr/sbin/vsftpd
server = /usr/sbin/tcpd
server_args = /usr/sbin/vsftpd
# log_on_success += DURATION USERID
# log_on_failure += USERID
# nice = 10
disable = no
}
6. Save the file and restart the xinetd daemon.
Next, you need to create your access controls. The tcpd daemon uses
the
/etc/hosts.allow
and
/etc/hosts.deny
files to specify who can access the services it manages.
Entries in /etc/hosts.allow are allowed access.
Hosts in /etc/hosts.deny are not allowed access.
The syntax for both of these files is
service: host_addresses
As these files are processed, the search stops as soon as a matching
condition is found in a file. Files are no longer processed after this
occurs. The following steps occur in the order shown:
• Access will be granted if a matching entry is found in the
/etc/hosts.allow file.
• If not, access will be denied if a matching entry is found in the
/etc/hosts.deny file.
• If this does not occur, access will be granted.
For example, suppose you needed to configure the /etc/hosts.allow file
to allow access to the vsftpd daemon for just a few specific hosts.
The following entry grants access to the vsftpd service to hosts with
the IP addresses of 192.168.1.10 and 192.168.1.102.
vsftpd: 192.168.1.10, 192.168.1.102
Some distributions use the inetd daemon instead of xinetd. This daemon
works in much the same manner as xinetd. Let’s learn how it works
next.
Configuring inetd
The inetd daemon is a super-daemon like xinetd, but it is typically
used on older Linux distributions. Like xinetd, the inetd daemon acts
as a mediator for connection requests to network services running on
the Linux host. It accepts connection requests from client systems,
starts the requested service, and then forwards the requests from
clients to the newly started daemon. When the transaction is complete
and the connection from the client is terminated, the daemon is
stopped on the Linux host.
As we discussed with xinetd, managing the network services on your
Linux host in this way has advantages and disadvantages. Key among
these is the fact that it conserves system memory and CPU resources.
The network daemon is started only when it is needed. When it isn’t
needed, it’s removed from memory until it is requested again. However,
this benefit comes at a cost in terms of latency. When a service is
requested by a client, the client must wait for a short period of time
while the necessary daemon is loaded and the connection established.
Therefore, inetd (and xinetd) should only be used to manage network
services that are needed only occasionally on the system.
The inetd daemon is configured using the
/etc/inetd.conf
file. Unlike the xinetd daemon, all the services managed by inetd are configured in
this single configuration file.
Each line in this file configures a single service to be managed by inetd. The syntax used in
inted.conf is shown here:
service_name socket_type protocol flags user executable arguments
Each of the parameters in this line is described in Table 17-6. Here
is a sample entry in inetd.conf for the vsftpd daemon:
ftp stream tcp nowait ftp /usr/sbin/tcpd vsftpd
Notice in this example that you can use TCP Wrappers with inetd just
as you did with xinetd. In this example, when a client tries to
establish an FTP connection with this Linux host, the inetd daemon
will start the tcpd daemon and pass to it the name of the actual
daemon to be started (vsftpd) as a server argument. As with xinetd,
using TCP Wrappers with inetd allows you to control access to the
network services running on the host using
the
/etc/hosts.allow
and
/etc/ hosts.deny
files.
LX0-104 Exam Objectives (V and U, 323, 647 - 689)
In this part of this chapter, you learn how to configure Linux
“super-daemons.” Most Linux distributions install a wide variety of
network services during the system installation process. Most of these
services, such as Telnet, are very handy and provide a valuable
service. However, they aren’t needed most of the time. We need a way
to provide these services when requested but then unload them when
they aren’t needed, saving memory, reducing CPU utilization, and
increasing the overall security of the system.
Depending on your distribution, there are two ways to do this. The
following options are discussed here:
• Configuring xinetd
• Configuring inetd
Configuring xinetd
Many Linux distributions include a special daemon called xinetd that
can be used to manage a number of different network services. In this
part of this chapter, you learn how to configure and use xinetd. We’ll
discuss the following topics:
• How xinetd works
• Configuring xinetd network services
• Using TCP Wrappers
Let’s begin by discussing how the xinetd daemon works.
How xinetd Works
The xinetd daemon is a super-daemon. It’s called a super-daemon
because it acts as an intermediary between the user requesting network
services and the daemons on the system that provide the actual
service. This is shown in Figure 17-26.
When a request for one of the network services managed by xinetd
arrives at the system, it is received and processed by xinetd, not the
network daemon being requested. The xinetd daemon then starts the
daemon for the requested service and forwards the request to it. When
the request has been fulfilled and the network service is no longer
needed, xinetd unloads the daemon from memory.
Some of the network services managed by xinetd include the following:
• chargen
• daytime
• echo
• ftp
• pop3
• rsync
• smtp
Configuring xinetd Network Services
As with all the network services I’ve discussed, the xinetd
configuration files are stored in /etc. The xinetd daemon itself is
configured using the
/etc/xinetd.conf
file. Generally speaking, you won’t need to make many changes to this file. The default
configuration usually works very well.
At the end of this file you will notice a directive that reads
includedir /etc/xinetd.d
This line tells the xinetd daemon to use the configuration files in
/etc/xinetd.d. These files tell xinetd how to start each service when
requested. Each of these files is used to configure the startup of a
particular service managed by xinetd.
For example, the
vsftpd file
in
/etc/xinetd.d
is used to configure the vsftpd FTP server daemon. The xinetd configuration
settings for vsftpd in this file are shown here:
service ftp
{
socket_type = stream
protocol = tcp
wait = no
user = root
server = /usr/sbin/vsftpd
# server_args =
# log_on_success += DURATION USERID
# log_on_failure += USERID
# nice = 10
disable = yes
}
This file doesn’t configure the daemon itself. It only tells xinetd
how to start up the daemon. The actual configuration file for the
vsftpd daemon itself is in /etc/vsftpd.conf.
One of the most important parameters in the
/etc/xinetd.d/vsftpd
file is the disable directive.
This directive specifies whether or not xinetd is allowed to start the
daemon when requested.
In the preceding example, this directive is set to yes, which means the daemon will not
be started when requested.
The daemon to actually start is specified by the
server = directive
In the example, xinetd will start the /usr/sbin/vsftpd daemon.
server = /usr/sbin/vsftpd
To enable this daemon, you need to edit this file and change the disable
parameter to a value of no.
disable = no
After changing a value in any of the files in /etc/xinetd.d, you need to
restart the xinetd daemon using its init script in /etc/rc.d/init.d or /etc/init.d.
TIP If you enable a service provided by xinetd, you’ll need to create
an exception in your Linux system’s host firewall to allow traffic for
the IP port used by the daemon.
Using TCP Wrappers
If you enable a particular service using its configuration file in the
/etc/xinetd.d/ directory, any host can connect to it through xinetd.
However, depending on how your system is deployed, you may need to
control access to these network services. You may want to limit access
to only a specific set of hosts and deny access to everyone else.
If this is the case, you need to configure these services to use TCP
Wrappers, which are used by xinetd to start and run the network
services using a set of configuration files that specify who can and
who can’t access the service.
To use TCP Wrappers, you first need to enable the functionality in
each service’s configuration file in /etc/xinetd.d. Do the following:
1. Verify that the tcpd package has been installed on your Linux system.
2. Open the appropriate configuration file in a text editor.
3. Comment out the existing server = line from the file.
4. Add the following line:
server = /usr/sbin/tcpd
This will cause xinetd to start the tcpd daemon instead of the service
daemon itself.
5. Add the following line:
server_args = path_to_daemon
This tells the tcpd daemon to then run the requested network daemon.
In the example shown here, the /etc/xinetd.d/telnet file has been
configured to run the vsftpd daemon within a TCP Wrapper:
service ftp
{
# #
socket_type = stream
protocol = tcp
wait = no
user = root
# server = /usr/sbin/vsftpd
server = /usr/sbin/tcpd
server_args = /usr/sbin/vsftpd
# log_on_success += DURATION USERID
# log_on_failure += USERID
# nice = 10
disable = no
}
6. Save the file and restart the xinetd daemon.
Next, you need to create your access controls. The tcpd daemon uses
the
/etc/hosts.allow
and
/etc/hosts.deny
files to specify who can access the services it manages.
Entries in /etc/hosts.allow are allowed access.
Hosts in /etc/hosts.deny are not allowed access.
The syntax for both of these files is
service: host_addresses
As these files are processed, the search stops as soon as a matching
condition is found in a file. Files are no longer processed after this
occurs. The following steps occur in the order shown:
• Access will be granted if a matching entry is found in the
/etc/hosts.allow file.
• If not, access will be denied if a matching entry is found in the
/etc/hosts.deny file.
• If this does not occur, access will be granted.
For example, suppose you needed to configure the /etc/hosts.allow file
to allow access to the vsftpd daemon for just a few specific hosts.
The following entry grants access to the vsftpd service to hosts with
the IP addresses of 192.168.1.10 and 192.168.1.102.
vsftpd: 192.168.1.10, 192.168.1.102
Some distributions use the inetd daemon instead of xinetd. This daemon
works in much the same manner as xinetd. Let’s learn how it works
next.
Configuring inetd
The inetd daemon is a super-daemon like xinetd, but it is typically
used on older Linux distributions. Like xinetd, the inetd daemon acts
as a mediator for connection requests to network services running on
the Linux host. It accepts connection requests from client systems,
starts the requested service, and then forwards the requests from
clients to the newly started daemon. When the transaction is complete
and the connection from the client is terminated, the daemon is
stopped on the Linux host.
As we discussed with xinetd, managing the network services on your
Linux host in this way has advantages and disadvantages. Key among
these is the fact that it conserves system memory and CPU resources.
The network daemon is started only when it is needed. When it isn’t
needed, it’s removed from memory until it is requested again. However,
this benefit comes at a cost in terms of latency. When a service is
requested by a client, the client must wait for a short period of time
while the necessary daemon is loaded and the connection established.
Therefore, inetd (and xinetd) should only be used to manage network
services that are needed only occasionally on the system.
The inetd daemon is configured using the
/etc/inetd.conf
file. Unlike the xinetd daemon, all the services managed by inetd are configured in
this single configuration file.
Each line in this file configures a single service to be managed by inetd. The syntax used in
inted.conf is shown here:
service_name socket_type protocol flags user executable arguments
Each of the parameters in this line is described in Table 17-6. Here
is a sample entry in inetd.conf for the vsftpd daemon:
ftp stream tcp nowait ftp /usr/sbin/tcpd vsftpd
Notice in this example that you can use TCP Wrappers with inetd just
as you did with xinetd. In this example, when a client tries to
establish an FTP connection with this Linux host, the inetd daemon
will start the tcpd daemon and pass to it the name of the actual
daemon to be started (vsftpd) as a server argument. As with xinetd,
using TCP Wrappers with inetd allows you to control access to the
network services running on the host using
the
/etc/hosts.allow
and
/etc/ hosts.deny
files.
LX0-104 Exam Objectives (V and U, 323, 647 - 689)
Monday, December 19, 2016
Configuring Network VI
Configuring IPv6
Before we move on in this chapter, we need to spend some time
discussing IPv6 address configuration. There are actually several
configuration options when it comes to IPv6 addressing. The first is
to use static assignment. As with IPv4, static IPv6 address
assignments require you to manually assign the entire 128-bit IPv6
address and prefix to the host.
This can be done from the shell prompt using a command-line utility such as
ifconfig
or
ip
Alternatively, you can manually enter the address and prefix in the appropriate
interface configuration file in
/etc/sysconfig/network
Another configuration option is to use static partial assignment.
Using this method, the prefix is statically assigned, but the
interface ID portion of the address is automatically generated using
the host’s MAC address.
Another configuration option is to use stateless auto-configuration,
which is affectionately called SLAC. Using SLAC, we allow IPv6 hosts
to automatically generate their own interface ID, but we require them
to obtain a correct prefix and default gateway address from a network
router (usually the default gateway) using the Neighbor Discovery
Protocol (NDP). NDP uses the following messages for autoconfiguration:
• Router solicitation (RS) messages are sent from network hosts
requesting that any listening router respond.
• Router advertisement (RA) messages are sent by the router in
response to RS messages received from network hosts. These messages
inform the network hosts of the correct IPv6 prefix they should use,
along with the default gateway address.
NDP is also used by network hosts to discover the MAC address of other
interfaces on the network, thus completely replacing the ARP when
using IPv6. However, NDP cannot provide network hosts with the address
of your DNS server. It can only provide the network prefix and the
default gateway address.
The final IPv6 address configuration option is to use DHCP. As with
IPv4, IPv6 address assignments can be made automatically using an
updated version of DHCP called DHCPv6. Because IPv6 has so many more
configuration options than IPv4, DHCPv6 operates in a different
manner. There are two different modes:
• Stateful DHCPv6
Configures the DHCP server to provide each IPv6 DHCP
client with an IP address, the default gateway address, and the DNS
server IP address. The DHCP server tracks the status of each IPv6 DHCP
client, hence the name stateful.
• Stateless DHCPv6
Does not assign IPv6 addressees to IPv6 clients,
nor does not track their status. In this configuration, the DHCPv6
server simply assigns the DNS server IP address to network hosts.
Obviously, stateless DHCPv6 does not provide a complete addressing
solution. Instead, it must be used in conjunction with other IPv6
address assignment schemes, such as SLAC.
When an IPv6 host boots up, it follows the process described next to
configure an address on its network interface:
1. The host automatically generates an IPv6 link-local address using
the link-local prefix (which usually starts with FE80) combined with
an interface ID derived from its MAC address.
2. The host sends a neighbor solicitation (NS) message addressed to
its own link-local address to make sure another host on the network
isn’t already using it.
3. The host sends out a multicast RS message, which should be received
by all routers on the same network segment. If no routers respond, the
host attempts to use stateful DHCPv6 to receive an IPv6 address.
4. If a router receives the RS message, it then sends a multicast RA
message to all hosts on the network segment. The RA message identifies
how the IPv6 address is to be configured. Possible options include the
following:
• Obtain all IPv6 configuration information from a DHCPv6 server. If
this is the case, the host sends out a REQUEST message to any
listening DHCPv6 server.
• Use stateless autoconfiguration to get the prefix and default
gateway from the RA message and to generate the interface ID portion
of its address automatically. The address of the DNS must then be
obtained from a DHCPv6 server.
5. If a static IPv6 address has been configured or if stateful
autoconfiguration has been used, the host sends an NS message to make
sure no one else is using its address.
LX0-104 Exam Objectives (T)
Before we move on in this chapter, we need to spend some time
discussing IPv6 address configuration. There are actually several
configuration options when it comes to IPv6 addressing. The first is
to use static assignment. As with IPv4, static IPv6 address
assignments require you to manually assign the entire 128-bit IPv6
address and prefix to the host.
This can be done from the shell prompt using a command-line utility such as
ifconfig
or
ip
Alternatively, you can manually enter the address and prefix in the appropriate
interface configuration file in
/etc/sysconfig/network
Another configuration option is to use static partial assignment.
Using this method, the prefix is statically assigned, but the
interface ID portion of the address is automatically generated using
the host’s MAC address.
Another configuration option is to use stateless auto-configuration,
which is affectionately called SLAC. Using SLAC, we allow IPv6 hosts
to automatically generate their own interface ID, but we require them
to obtain a correct prefix and default gateway address from a network
router (usually the default gateway) using the Neighbor Discovery
Protocol (NDP). NDP uses the following messages for autoconfiguration:
• Router solicitation (RS) messages are sent from network hosts
requesting that any listening router respond.
• Router advertisement (RA) messages are sent by the router in
response to RS messages received from network hosts. These messages
inform the network hosts of the correct IPv6 prefix they should use,
along with the default gateway address.
NDP is also used by network hosts to discover the MAC address of other
interfaces on the network, thus completely replacing the ARP when
using IPv6. However, NDP cannot provide network hosts with the address
of your DNS server. It can only provide the network prefix and the
default gateway address.
The final IPv6 address configuration option is to use DHCP. As with
IPv4, IPv6 address assignments can be made automatically using an
updated version of DHCP called DHCPv6. Because IPv6 has so many more
configuration options than IPv4, DHCPv6 operates in a different
manner. There are two different modes:
• Stateful DHCPv6
Configures the DHCP server to provide each IPv6 DHCP
client with an IP address, the default gateway address, and the DNS
server IP address. The DHCP server tracks the status of each IPv6 DHCP
client, hence the name stateful.
• Stateless DHCPv6
Does not assign IPv6 addressees to IPv6 clients,
nor does not track their status. In this configuration, the DHCPv6
server simply assigns the DNS server IP address to network hosts.
Obviously, stateless DHCPv6 does not provide a complete addressing
solution. Instead, it must be used in conjunction with other IPv6
address assignment schemes, such as SLAC.
When an IPv6 host boots up, it follows the process described next to
configure an address on its network interface:
1. The host automatically generates an IPv6 link-local address using
the link-local prefix (which usually starts with FE80) combined with
an interface ID derived from its MAC address.
2. The host sends a neighbor solicitation (NS) message addressed to
its own link-local address to make sure another host on the network
isn’t already using it.
3. The host sends out a multicast RS message, which should be received
by all routers on the same network segment. If no routers respond, the
host attempts to use stateful DHCPv6 to receive an IPv6 address.
4. If a router receives the RS message, it then sends a multicast RA
message to all hosts on the network segment. The RA message identifies
how the IPv6 address is to be configured. Possible options include the
following:
• Obtain all IPv6 configuration information from a DHCPv6 server. If
this is the case, the host sends out a REQUEST message to any
listening DHCPv6 server.
• Use stateless autoconfiguration to get the prefix and default
gateway from the RA message and to generate the interface ID portion
of its address automatically. The address of the DNS must then be
obtained from a DHCPv6 server.
5. If a static IPv6 address has been configured or if stateful
autoconfiguration has been used, the host sends an NS message to make
sure no one else is using its address.
LX0-104 Exam Objectives (T)
Tuesday, December 13, 2016
Printing VI
Configuring a CUPS Printer
All CUPS printers are defined in the
/etc/cups/printers.conf
file.
Although you can manually edit this file, you really should use the
CUPS web-based administration utility instead. Configuring a CUPS
printer is a snap with it. You can either configure CUPS to service a
locally attached printer (and optionally make it available to other
network users) or connect to a CUPS printer over the network. For
example, to configure CUPS to use a locally attached printer, do the
following:
1) On your Linux system, start a web browser and navigate to
http://localhost:631.
2) Select Administration. The screen in Figure 16-5 is displayed.
3) Under Printers, select Add Printer.
4) When prompted, log in as the administrative user you created
previously. The screen in Figure 16-6 is displayed.
5) Select a locally attached printer type under Local Printers and
then select Continue. A screen similar to that shown in Figure 16-7 is
displayed.
TIP You could also select a network printer in this screen. All
broadcasting CUPS printers on other network hosts are listed under
Discovered Network Printers. To send print jobs to one of these
printers, just select it.
6) In the Name field, enter a name for the printer.
7) In the Description field, enter a description of the printer.
8) In the Location field, enter a location for the printer.
9) If you want to share the printer with other network users, mark
Share This Printer.
10) Select Continue. The screen in Figure 16-8 is displayed.
11) Select the printer manufacturer; then select Continue.
12) In the Model field, select your printer model; then select Add Printer.
13) Configure your default options for the printer, such as paper
size, color model, media source, print quality, two-sided printing,
and so on. When complete, select Set Default Options.
At this point, a page is displayed indicating your printer has been
added. The current status of your printer is displayed, similar to
that shown in Figure 16-9.
From the Printer Status page, you can manage your CUPS printer. You
can send a test page, stop the printer, kill a print job, modify the
printer configuration, or delete the printer altogether. At this
point, you can send print jobs to the printer. If you’re using a
graphical X application, you can simply select File | Print; then
select the printer and click OK. You can also send print jobs from the
command line to the printer. This is done using the lp command, which
will send a specified file to the printer. The syntax for using lp is
lp –d printer_name filename
For example, if I wanted to print the myfiles file in the current
directory to the HPLJ2 printer I just created, I
would enter
lp –d HPLJ5 ./myfiles
at the shell prompt, as shown here: openSUSE:~ # lp -d HPLJ2 ./myfiles
request id is HPLJ2-2 (1 file(s))
As you can see in this example, the
job is created and assigned an ID (in this case, HPLJ2-2). The job is
added to the print queue and sent to the printer. The lp utility
includes a variety of options besides –d that you can use to create
print jobs, including the following:
• –n x Prints x number of copies
• –m E-mails a confirmation message to my local user account when the
job is finished printing
• –q x Sets the priority of the print job to x
• –o landscape Prints the file landscape instead of portrait
• –o sides=2 Prints the file double-sided on a printer that supports duplexing
You can also configure other Linux systems to print to the CUPS
printer. Simply configure a new printer, but specify that it listen
for CUPS announcements. The CUPS printer you configured should be
displayed within 30 seconds. After you select it, all print jobs sent
to that printer will be redirected over the network connection to your
CUPS printer.
In addition, if you’ve installed Samba on your system, your CUPS
printers are automatically shared. You can connect to them from
Windows workstations and submit print jobs. Now that’s cool!
LX0-104 Exam Objectives (Q)
All CUPS printers are defined in the
/etc/cups/printers.conf
file.
Although you can manually edit this file, you really should use the
CUPS web-based administration utility instead. Configuring a CUPS
printer is a snap with it. You can either configure CUPS to service a
locally attached printer (and optionally make it available to other
network users) or connect to a CUPS printer over the network. For
example, to configure CUPS to use a locally attached printer, do the
following:
1) On your Linux system, start a web browser and navigate to
http://localhost:631.
2) Select Administration. The screen in Figure 16-5 is displayed.
3) Under Printers, select Add Printer.
4) When prompted, log in as the administrative user you created
previously. The screen in Figure 16-6 is displayed.
5) Select a locally attached printer type under Local Printers and
then select Continue. A screen similar to that shown in Figure 16-7 is
displayed.
TIP You could also select a network printer in this screen. All
broadcasting CUPS printers on other network hosts are listed under
Discovered Network Printers. To send print jobs to one of these
printers, just select it.
6) In the Name field, enter a name for the printer.
7) In the Description field, enter a description of the printer.
8) In the Location field, enter a location for the printer.
9) If you want to share the printer with other network users, mark
Share This Printer.
10) Select Continue. The screen in Figure 16-8 is displayed.
11) Select the printer manufacturer; then select Continue.
12) In the Model field, select your printer model; then select Add Printer.
13) Configure your default options for the printer, such as paper
size, color model, media source, print quality, two-sided printing,
and so on. When complete, select Set Default Options.
At this point, a page is displayed indicating your printer has been
added. The current status of your printer is displayed, similar to
that shown in Figure 16-9.
From the Printer Status page, you can manage your CUPS printer. You
can send a test page, stop the printer, kill a print job, modify the
printer configuration, or delete the printer altogether. At this
point, you can send print jobs to the printer. If you’re using a
graphical X application, you can simply select File | Print; then
select the printer and click OK. You can also send print jobs from the
command line to the printer. This is done using the lp command, which
will send a specified file to the printer. The syntax for using lp is
lp –d printer_name filename
For example, if I wanted to print the myfiles file in the current
directory to the HPLJ2 printer I just created, I
would enter
lp –d HPLJ5 ./myfiles
at the shell prompt, as shown here: openSUSE:~ # lp -d HPLJ2 ./myfiles
request id is HPLJ2-2 (1 file(s))
As you can see in this example, the
job is created and assigned an ID (in this case, HPLJ2-2). The job is
added to the print queue and sent to the printer. The lp utility
includes a variety of options besides –d that you can use to create
print jobs, including the following:
• –n x Prints x number of copies
• –m E-mails a confirmation message to my local user account when the
job is finished printing
• –q x Sets the priority of the print job to x
• –o landscape Prints the file landscape instead of portrait
• –o sides=2 Prints the file double-sided on a printer that supports duplexing
You can also configure other Linux systems to print to the CUPS
printer. Simply configure a new printer, but specify that it listen
for CUPS announcements. The CUPS printer you configured should be
displayed within 30 seconds. After you select it, all print jobs sent
to that printer will be redirected over the network connection to your
CUPS printer.
In addition, if you’ve installed Samba on your system, your CUPS
printers are automatically shared. You can connect to them from
Windows workstations and submit print jobs. Now that’s cool!
LX0-104 Exam Objectives (Q)
Printing IV
Configuring CUPS
The CUPS service appears complicated, and under the hood, it is.
Fortunately, the developers who wrote CUPS made it very easy for you
and me to configure and manage. In this part of this chapter, you’re
going learn how to configure CUPS by learning about the following
topics:
• Configuring the CUPS service
• Configuring a CUPS printer
• Using command-line tools to manage CUPS
Let’s begin by discussing how to configure the cupsd daemon.
LX0-104 Exam Objectives (Q)
The CUPS service appears complicated, and under the hood, it is.
Fortunately, the developers who wrote CUPS made it very easy for you
and me to configure and manage. In this part of this chapter, you’re
going learn how to configure CUPS by learning about the following
topics:
• Configuring the CUPS service
• Configuring a CUPS printer
• Using command-line tools to manage CUPS
Let’s begin by discussing how to configure the cupsd daemon.
LX0-104 Exam Objectives (Q)
Subscribe to:
Posts (Atom)