SENSOR = Don"t run a service; just listen on this port and log all attempts to access.
IPv4 = Use IPv4 only.
IPv6 = Use IPv6 only.
disable Boolean option determining whether this service is on.
socket_type stream dgram raw seqpacket protocol Must be a valid protocol listed in /etc/protocols.
wait Normally, TCP services have wait set to "no", whereas UDP services have wait set to "yes".
user Username the service runs as.
group Group the service runs as.
instances The number of services that can run at once. The default is no limit.
nice Server priority (nice value).
server Full path to the server program that will run.
server_args Command-line arguments pa.s.sed to the server.
only_from Allows you to restrict access by IP address, network, or hostname.
no_access Deny access from this IP address, network, or hostname.
access_times Determines what hours of the day this service is available, in the form HH:MM HH:MM.
log_type Options are SYSLOG or FILE.
log_on_success What variables will be logged on a successful connection.
log_on_failure What variables will be logged on a failed connection.
port What port xinetd should listen on for this service. should listen on for this service.
bind What IP address xinetd should listen on. Useful for multihomed machines. should listen on. Useful for multihomed machines.
per_source Maximum number of connections from a single IP address.
max_load After the one-minute load average of the machine reaches this amount, stop accepting connections until the load goes below this number.
Once the disable = no disable = no option is set in our option is set in our /etc/xinetd.d/imap /etc/xinetd.d/imap file and the file and the xinetd xinetd service is restarted, we can use the service is restarted, we can use the netstat netstat command to verify that command to verify that xinetd xinetd is ready for incoming is ready for incoming imap imap connections: connections: #netstat--tcp-anp|grep":143"
tcp00:::143:::*LISTEN15959/xinetd Security with TCP_WRAPPERS With the original inetd inetd service, the servers that were managed rarely had any advanced access control options of their own. These services were often remnants of the early days of the Internet, when systems were a little more trusted than they are today. Examples of these mostly deprecated services are service, the servers that were managed rarely had any advanced access control options of their own. These services were often remnants of the early days of the Internet, when systems were a little more trusted than they are today. Examples of these mostly deprecated services are finger finger, echo echo, daytime daytime, telnet telnet, sh.e.l.l sh.e.l.l, exec exec, and talk talk, to name a few. xinetd xinetd added some more advanced controls, but both added some more advanced controls, but both inetd inetd and and xinetd xinetd are able to utilize the TCP_WRAPPER service to aid in access control. are able to utilize the TCP_WRAPPER service to aid in access control.
In order to utilize TCP_WRAPPERS, inetd inetd needs to call the user-s.p.a.ce program needs to call the user-s.p.a.ce program /usr/bin/tcpd /usr/bin/tcpd with an argument of the desired service, in order to "wrap" that service in the access control. This is not necessary with with an argument of the desired service, in order to "wrap" that service in the access control. This is not necessary with xinetd xinetd, as the xinetd xinetd binary has TCP_WRAPPERS support built-in, by nature of its link with the binary has TCP_WRAPPERS support built-in, by nature of its link with the libwrap libwrap library. You can see this with the library. You can see this with the /usr/bin/ldd /usr/bin/ldd command: command: #ldd/usr/sbin/xinetd linux-gate.so.1=>(0x0012d000) libselinux.so.1=>/lib/libselinux.so.1(0x0012e000) libwrap.so.0=>/lib/libwrap.so.0(0x00149000) libnsl.so.1=>/lib/libnsl.so.1(0x00151000) libm.so.6=>/lib/libm.so.6(0x0016a000) libcrypt.so.1=>/lib/libcrypt.so.1(0x00193000) libc.so.6=>/lib/libc.so.6(0x001c5000) libdl.so.2=>/lib/libdl.so.2(0x0031e000) /lib/ld-linux.so.2(0x00110000) Other services also have native TCP_WRAPPERS support by nature of their links to libwrap.so libwrap.so, including /usr/sbin/sshd /usr/sbin/sshd and and /usr/sbin/sendmail /usr/sbin/sendmail. You can run a simple sh.e.l.l script to determine what binaries in /usr/sbin/ /usr/sbin/ are linked against are linked against libwrap.so libwrap.so: #cd/usr/sbin #forfilein*
>{ >if[-f$file];then >result="ldd$file|grep-clibwrap"
>if["$result"-gt"0"];then >echo"/usr/sbin/$fileislinkedtolibwrap.so"
>fi >fi >} /usr/sbin/exportfsislinkedtolibwrap.so /usr/sbin/gdm-binaryislinkedtolibwrap.so /usr/sbin/mailstatsislinkedtolibwrap.so /usr/sbin/makemapislinkedtolibwrap.so /usr/sbin/praliasesislinkedtolibwrap.so /usr/sbin/rpcinfoislinkedtolibwrap.so /usr/sbin/rpc.mountdislinkedtolibwrap.so /usr/sbin/rpc.rquotadislinkedtolibwrap.so /usr/sbin/sendmailislinkedtolibwrap.so /usr/sbin/sendmail.sendmailislinkedtolibwrap.so /usr/sbin/smrshislinkedtolibwrap.so /usr/sbin/snmpdislinkedtolibwrap.so /usr/sbin/snmptrapdislinkedtolibwrap.so /usr/sbin/sshdislinkedtolibwrap.so /usr/sbin/stunnelislinkedtolibwrap.so /usr/sbin/vsftpdislinkedtolibwrap.so /usr/sbin/xinetdislinkedtolibwrap.so Configuration TCP_WRAPPERS is configured in two files, /etc/hosts.allow /etc/hosts.allow and and /etc/hosts.deny /etc/hosts.deny. These files contain rules that govern either all services or individual services. Like a firewall, it is usually good practice to adopt either a "block everything, only open what you need" mentality or an "open everything, block only what you don"t need" mentality when it comes to TCP_WRAPPERS. Here is an example of a sample configuration that blocks everything by default, but opens up access for a few services: #more/etc/hosts.deny ALL:ALL
#more/etc/hosts.allow sshd:ALLEXCEPT192.168.1.10 vsftpd:192.168.1.0/24EXCEPT192.168.1.10 The TCP_WRAPPERS files are read in real time by the servers that support them, so changes made to these files go into effect immediately. The example configuration denies all access by default, and then opens it up specifically for the sshd sshd and and vsftpd vsftpd services. Users from everywhere except the system 192.168.1.10 are allowed to connect to the services. Users from everywhere except the system 192.168.1.10 are allowed to connect to the sshd sshd service, and all users on the 192.168.1.0/24 network, except for 192.168.1.10, are allowed to connect to service, and all users on the 192.168.1.0/24 network, except for 192.168.1.10, are allowed to connect to vsftpd vsftpd.
Let"s a.s.sume that we have xinetd xinetd configured and running, with the configured and running, with the imap imap configuration as listed earlier. In addition, the configuration as listed earlier. In addition, the /etc/hosts.deny /etc/hosts.deny and and /etc/hosts.allow /etc/hosts.allow files are the same as our example. Our server system has an IP address of 10.0.0.1, and our client system has an IP address of 10.0.0.112. When an attempt is made to connect to the files are the same as our example. Our server system has an IP address of 10.0.0.1, and our client system has an IP address of 10.0.0.112. When an attempt is made to connect to the imap imap server on 10.0.0.1 from 10.0.0.112, the connection times out. We can see the details in server on 10.0.0.1 from 10.0.0.112, the connection times out. We can see the details in /var/log/messages /var/log/messages on the server: on the server: #tail/var/log/messages Jan2615:22:42serverxinetd[15959]:xinetdVersion2.3.14startedwith libwraploadavglabelednetworkingoptionscompiledin.
Jan2615:22:42serverxinetd[15959]:Startedworking:1availableservice Jan2615:23:23serverxinetd[15959]:START:imappid=15975 from=::ffff:10.0.0.112 Jan2615:23:28serverxinetd[15959]:EXIT:imapstatus=1pid=15975 duration=5(sec) Jan2615:26:30serverxinetd[15959]:START:imappid=16035 from=::ffff:10.0.0.112 Jan2615:26:30serverxinetd[16035]:libwraprefusedconnectionto imap(libwrap=imapd)from::ffff:10.0.0.112 Jan2615:26:30serverxinetd[16035]:FAIL:imaplibwrap from=::ffff:10.0.0.112 Jan2615:26:30serverxinetd[15959]:EXIT:imapstatus=0 pid=16035duration=0(sec) We can see from the syslog syslog messages that our attempt to connect to messages that our attempt to connect to imapd imapd was denied. In order to enable this access, we need to add the following line to was denied. In order to enable this access, we need to add the following line to /etc/hosts.allow /etc/hosts.allow: imapd:ALL or, if we want to limit it somewhat: imapd:10.0.0.0/24 After this change, we try our imap imap connection from the client again, and we get a connection. Logfiles on the server show our success: connection from the client again, and we get a connection. Logfiles on the server show our success: #tail/var/log/messages Jan2615:34:37fileservxinetd[15959]:START:imappid=16083 from=::ffff:10.0.0.112 Jan2615:34:42fileservxinetd[15959]:EXIT:imapstatus=1 pid=16083duration=5(sec)
Remember that you need to do more than simply configure /etc/hosts.deny /etc/hosts.deny and and /etc/hosts.allow /etc/hosts.allow to secure your system. Many popular applications, such as the Apache web server, do not link against to secure your system. Many popular applications, such as the Apache web server, do not link against libwrap.so libwrap.so, so they do not honor the entries you place in these configuration files.
Also, it is more and more common on network-enabled Linux machines (especially those connected directly to the Internet) to not run inetd inetd or or xinetd xinetd at all. If there are services that need to be run, such as at all. If there are services that need to be run, such as imapd imapd or or ftpd ftpd, they are often run as standalone daemons, largely because the lack of necessary memory in a server is not as much of a concern as it was years ago, and many of these newer services have built-in access controls that rival the ability of TCP_WRAPPERS. So if you are in doubt about whether or not you need a service that is handled by xinetd xinetd, you are probably safe to disable it, rather than having to worry about securing a service that might not be necessary.
On the ExamAlthough the inetd inetd service has largely been replaced by service has largely been replaced by xinetd xinetd, be familiar with the syntax of the inetd.conf inetd.conf file, because there is a good chance you will encounter questions about it on the LPI exams. The syntax of the file, because there is a good chance you will encounter questions about it on the LPI exams. The syntax of the /etc/hosts.deny /etc/hosts.deny and and /etc/hosts.allow /etc/hosts.allow files also will be a focus. files also will be a focus.
Chapter24.Securing Data with Encryption (Topic 110.3)
This Topic focuses on the methods used to secure Linux servers and workstations. Securing servers includes two basics steps: communicating between servers in a secure way, and then encrypting data on the servers themselves. The LPI knows that SSH is the most common method for communicating securely between servers. Therefore, the topic is covered fairly extensively on the exam and in this chapter.
SSH is used for many more purposes than simply communicating across insecure networks; it is used throughout the industry to configure remote systems and tunnel all sorts of traffic, from X Windows to email and FTP.
The second part of securing a server-making sure that stored data is properly encrypted-can be handled in myriad ways. However, the LPI recognizes that GNU Privacy Guard (GPG) has become the standard. Before we take a deep look at how SSH and GPG work, make sure that you understand this LPI Objective"s description perfectly: Objective 3: Securing Data with Encryption The candidate should be able to use public key techniques to secure data and communication. The key knowledge areas are: Perform basic OpenSSH 2 client configuration and usage.
Understand the role of OpenSSH 2 server host keys.
Perform basic GnuPG configuration and usage.
Understand SSH port tunnels (including X11 tunnels).
Following is the list of the used files, terms, and utilities: ssh ssh-keygen ssh-agent ssh-add ~/.ssh/id_rsa and id_rsa.pub ~/.ssh/id_dsa and id_dsa.pub /etc/ssh/ssh_host_rsa_key and and /etc/ssh/ssh_host_rsa_key.pub /etc/ssh/ssh_host_rsa_key.pub /etc/ssh/ssh_host_dsa_key and and /etc/ssh/ssh_host_dsa_key.pub /etc/ssh/ssh_host_dsa_key.pub ~/.ssh/authorized_keys and and ~/.ssh/authorized_keys2 ~/.ssh/authorized_keys2 /etc/ssh_known_hosts gpg ~/.gnupg/*
Objective 3: Securing Data With Encryption As you can see from this Objective, you need to know more than how to issue a couple of commands on a remote system. You also have to understand how to configure systems for public key encryption and how to use common SSH and encryption commands, including GPG.
Using Secure Sh.e.l.l (SSH) SSH, also known as Secure Sh.e.l.l, is a replacement for the obsolete telnet telnet command and command and rsh/rlogin/rcp rsh/rlogin/rcp suite. The primary use for SSH is to conduct encrypted sh.e.l.l sessions to remote hosts. However, it can also be used to copy files and to tunnel other protocols. suite. The primary use for SSH is to conduct encrypted sh.e.l.l sessions to remote hosts. However, it can also be used to copy files and to tunnel other protocols.
SSH is a server/client protocol offering sshd sshd as the server and the as the server and the ssh ssh and and scp scp commands as the client. The client connects to the server, they establish an encrypted session, and then the server demands authentication before finally logging in the client. commands as the client. The client connects to the server, they establish an encrypted session, and then the server demands authentication before finally logging in the client.
The ssh ssh command can be used either to execute a single command and return to the local terminal, or to establish a remote session that acts and feels just like logging into the remote system. In this regard, command can be used either to execute a single command and return to the local terminal, or to establish a remote session that acts and feels just like logging into the remote system. In this regard, ssh ssh acts like the obsolete acts like the obsolete rsh rsh command; used to log in, command; used to log in, ssh ssh acts like acts like rlogin rlogin and and telnet telnet.
The scp scp command copies files and directories to or from a remote system, acting like the obsolete command copies files and directories to or from a remote system, acting like the obsolete rcp rcp command. command.
In addition to simple login sessions and file copying, SSH can also provide transparent port forwarding, and as an extension of this, X authentication and forwarding. When you have an SSH session, you can start an X client on the remote machine, and the X Window System protocol will travel encrypted over your connection and display on your local machine without the need for settings such as DISPLAY=foo:0 DISPLAY=foo:0 or the or the xhost xhost or or xauth xauth commands. commands.
The implementation of SSH generally used on Linux systems is OpenSSH.
Installation and Configuration OpenSSH may or may not be installed on your system by default. When the SSH server (sshd) runs for the first time, it generates a host key for your machine. This key will serve to authenticate your host in subsequent SSH sessions. Then you will typically want to create SSH authentication keys for your own personal account, as well as the root account. After that, as the administrator you should review the configuration of sshd sshd, to see that you are comfortable with it.
The standard place for the central configuration of OpenSSH is the /etc/ssh /etc/ssh directory. Here you will find the server configuration in directory. Here you will find the server configuration in sshd_config sshd_config and default client configuration in and default client configuration in ssh_config ssh_config. Here are some highlights from the server configuration as installed on Debian: #Whatports,IPsandprotocolswelistenfor Port22 Protocol2 Port 22 is the standard port for the SSH protocol. Version 2 of the protocol is the most secure, whereas version 1 has some flaws that were hard to overcome. It is recommended to accept only version 2 now. To support both versions, put 2, 1 2, 1 on the on the Protocol Protocol line of the configuration file. line of the configuration file.
On the ExamSSH uses TCP port 22. Be prepared to know the preferred version of SSH (2) as well. The second version of SSH is preferable, because version 1 has long been known to have a weak encryption algorithm that has been broken.
Example /etc/ssh/sshd_config file #Authentication: PermitRootLoginyes
PubkeyAuthenticationyes
#rhostsauthenticationshouldnotbeused RhostsAuthenticationno #Don"treadtheuser"s~/.rhostsand~/.shostsfiles IgnoreRhostsyes #Forthistoworkyouwillalsoneedhostkeysin/etc/ssh_known_hosts #(forprotocolversion2) HostbasedAuthenticationno
#Todisabletunneledcleartextpa.s.swords,changetonohere!
Pa.s.swordAuthenticationyes OpenSSH ignores the host operating system setting for permitting root logins on nonconsole terminals. Instead, OpenSSH has its own setting in PermitRootLogin PermitRootLogin. The PubkeyAuthentication PubkeyAuthentication setting allows or denies login authentication based purely on public-key cryptography. You can trust this as far as you can trust the host on which the private parts of those keys are stored (unless they are protected by pa.s.sphrases, in which case you can trust them a bit further). setting allows or denies login authentication based purely on public-key cryptography. You can trust this as far as you can trust the host on which the private parts of those keys are stored (unless they are protected by pa.s.sphrases, in which case you can trust them a bit further).
IgnoreRhosts allows or denies the old-fashioned-and very insecure-rhosts authentication, used by the allows or denies the old-fashioned-and very insecure-rhosts authentication, used by the rsh/rlogin/rcp rsh/rlogin/rcp suite. This way of authenticating connections is not only insecure, but also made obsolete by public-key authentication. If you combine rhosts authentication with public-key authentication of the connecting host, on the other hand, it"s immediately a lot more secure-but host keys cannot be protected by pa.s.sphrases. Use of the rhosts authentication is still not recommended, but in some settings it is appropriate, and suite. This way of authenticating connections is not only insecure, but also made obsolete by public-key authentication. If you combine rhosts authentication with public-key authentication of the connecting host, on the other hand, it"s immediately a lot more secure-but host keys cannot be protected by pa.s.sphrases. Use of the rhosts authentication is still not recommended, but in some settings it is appropriate, and HostbasedAuthentication HostbasedAuthentication enables it. enables it.
Pa.s.swordAuthentication allows or denies authentication by the old-fashioned pa.s.swords read and stored by rhosts authentication. This requires that your users exercise good pa.s.sword maintenance, as with all other pa.s.sword-based authentication schemes. allows or denies authentication by the old-fashioned pa.s.swords read and stored by rhosts authentication. This requires that your users exercise good pa.s.sword maintenance, as with all other pa.s.sword-based authentication schemes.
X11Forwardingyes If X11 forwarding is enabled on the server and your client requests it (using the -X -X option), the client and server will forward traffic from a port on the server side to your option), the client and server will forward traffic from a port on the server side to your DISPLAY DISPLAY. The server sets the remote DISPLAY DISPLAY to the local port that to the local port that sshd sshd uses to transfer X Window System traffic to your local screen, as well as to accept input from your local devices. To secure this forwarding activity, the server will install an uses to transfer X Window System traffic to your local screen, as well as to accept input from your local devices. To secure this forwarding activity, the server will install an xauth xauth authentication token that it will enforce for all new connections. This port forwarding and extra authentication, which we"ll return to, makes OpenSSH a very versatile remote terminal program. authentication token that it will enforce for all new connections. This port forwarding and extra authentication, which we"ll return to, makes OpenSSH a very versatile remote terminal program.
DSA and RSA Overview The Digital Signature Algorithm (DSA) is an open standard used for creating digital signatures based on public key encryption. DSA is used in many different applications, including SSH and GPG, because it is an open standard and not subject to traditional copyright. The Rivest, Shamir, Adleman (RSA) algorithm is the first algorithm widely used to create digital signatures, but it is subject to copyright restrictions that some developers find onerous.
You will find that SSH uses RSA by default, whereas GPG uses DSA. As with many algorithms, you can specify various bit lengths; 1024 and 2048 are common lengths, but given the increase in processor speeds that permit ever-faster brute force attacks, 2048 is currently considered the minimal length to provide acceptable security.
Generating and Using Keys In most cases, you will want to generate SSH keys for your own accounts and perhaps your root account. Use ssh-keygen ssh-keygen for this. A reference for the needed commands appears at the end of this section (the short of it is: run for this. A reference for the needed commands appears at the end of this section (the short of it is: run ssh-keygen -t dsa ssh-keygen -t dsa and press the Enter key at all the prompts). This key allows pa.s.sword-less remote logins, as long as and press the Enter key at all the prompts). This key allows pa.s.sword-less remote logins, as long as PubkeyAuthentication PubkeyAuthentication is enabled in the server configuration file. is enabled in the server configuration file.
In ~/.ssh/id_dsa.pub ~/.ssh/id_dsa.pub you can find the public key you"ve generated through you can find the public key you"ve generated through ssh-keygen ssh-keygen. You need to transport this key to the remote machine. Because it"s a public key, it does not need to be secure. On the remote machine, put the key at the end of ~/.ssh/authorized_keys2 ~/.ssh/authorized_keys2. Once the key is in that file, all users who have the private-key counterpart will be able to log in to that remote account without a pa.s.sword.
Enabling bulk logins on multiple hosts for multiple users Sometimes it makes sense to let users log into other machines without having to set up authentication themselves. The easiest way to do this is to create and modify all the files on one machine, as described in the following procedure, and then use tar tar and and ssh ssh in a pipe to transfer them to the other hosts. in a pipe to transfer them to the other hosts.
1. Enable HostbasedAuthentication HostbasedAuthentication in in /etc/ssh/sshd_config /etc/ssh/sshd_config configuration files on all hosts. configuration files on all hosts.
On the Exam The exam may ask you about the HostbasedAuthentication HostbasedAuthentication feature and its purpose. Make sure that you know its purpose, as well as the exact location of the feature and its purpose. Make sure that you know its purpose, as well as the exact location of the /etc/ssh/sshd_config /etc/ssh/sshd_config file. file.
2. Your client configuration is in /etc/ssh/ssh_config /etc/ssh/ssh_config. All hosts should have HostbasedAuthentication yes HostbasedAuthentication yes set there, and if they have a set there, and if they have a PreferredAuthentications PreferredAuthentications statement, it should list statement, it should list hostbased hostbased first. The hosts" private keys should be readable only by first. The hosts" private keys should be readable only by root root (otherwise, the key would not be all that secret). Exactly what is needed to get SSH access to the keys depends on the version. If your SSH package includes an executable called (otherwise, the key would not be all that secret). Exactly what is needed to get SSH access to the keys depends on the version. If your SSH package includes an executable called ssh-keysign ssh-keysign, it must be SUID root (it may not be installed that way, so you must check this manually) and must provide the signing service that proves the host"s ident.i.ty in the key exchange. If the package does not contain ssh-keysign ssh-keysign, make sure the ssh ssh executable is SUID root through executable is SUID root through chmod u+s /usr/bin/ssh chmod u+s /usr/bin/ssh.
3. On each host, create /etc/ssh/shosts.equiv /etc/ssh/shosts.equiv. This file defines the hosts with equivalent security levels. In these files, enter the hostnames of all the hosts as they appear in reverse lookups.
4. On each host, create /etc/ssh/ssh_known_hosts /etc/ssh/ssh_known_hosts. This file must contain the host keys of all the hosts involved, under the names you used in the previous item. The easiest way to do this is to connect to all the hosts using the right names. After doing that, the user account that made the connections will have all the correct entries in its ~/.ssh/known_hosts ~/.ssh/known_hosts file. Simply transfer the entries to the system file. file. Simply transfer the entries to the system file.
After the previous steps are carried out on all the hosts, all ordinary users should be able to use ssh ssh back and forth between all the nodes with no other authentication. However, this is not true for the back and forth between all the nodes with no other authentication. However, this is not true for the root root user; she still needs user key or pa.s.sword authentication. Trusting a remote user; she still needs user key or pa.s.sword authentication. Trusting a remote root root is far more serious than trusting a mundane remote user. is far more serious than trusting a mundane remote user.
Using the RSA algorithm The RSA algorithm has become the de facto de facto standard used in SSH and is employed by default, although it is possible to use additional algorithms. When it comes time to save the key you generate using RSA, you can use any name you wish. However, most people stick to the defaults: standard used in SSH and is employed by default, although it is possible to use additional algorithms. When it comes time to save the key you generate using RSA, you can use any name you wish. However, most people stick to the defaults: ~/.ssh/id_rsa The name of the file that contains the private key. This file should be readable and writable only by the owner and no one else. If anyone else were to obtain a copy of this file, he would be able to decipher all communications encrypted by your copy of SSH.
~/.id_rsa.pub The name of the file that contains the public key. You can give this key to anyone you wish. Individuals will import this key into their keychains. Once a user imports this key, they can decipher encrypted text or files that you send to them.
The Server Public and Private Key When SSH first starts after installation, it will create a key pair, namely /etc/ssh/ssh_host_rsa_key /etc/ssh/ssh_host_rsa_key and and /etc/ssh/ssh_host_rsa_key.pub /etc/ssh/ssh_host_rsa_key.pub, a.s.suming that the server is using the default RSA algorithm. This public key always has a .pub .pub ending, and resides in the ending, and resides in the /etc/ssh/ /etc/ssh/ directory. The SSH server on your system uses this file to authenticate itself to anyone who logs on. The directory. The SSH server on your system uses this file to authenticate itself to anyone who logs on. The ssh-keygen ssh-keygen command can be used to view the contents of the public key file: command can be used to view the contents of the public key file: $ssh-keygen-l-f/etc/ssh/ssh_host_rsa_key.pub 102498:2g:h8:k9:de:9f:fg:90:34:v3:35:3j:26:24:26:7kssh_host_rsa_key.pub If the server is using the DSA algorithm, the key names will be as follows: /etc/ssh/ssh_host_dsa_key /etc/ssh/ssh_host_dsa_key.pub On the ExamMake sure that you know the syntax for the -t -t option of option of ssh-keygen ssh-keygen. Make sure that you understand the differences in filenames created between specifying the dsa dsa and the default and the default rsa rsa arguments to the arguments to the -t -t option. option.
ssh-agent ssh-agent makes it practical to use pa.s.sphrases on your private keys. The principle is to use makes it practical to use pa.s.sphrases on your private keys. The principle is to use ssh-agent ssh-agent to add your keys to a background agent on the system that will hold them in escrow. You give your pa.s.sphrase only once, when you add the key. The agent will give the keys out to other processes owned by you that request the keys. You should be aware that the to add your keys to a background agent on the system that will hold them in escrow. You give your pa.s.sphrase only once, when you add the key. The agent will give the keys out to other processes owned by you that request the keys. You should be aware that the root root user can also request the keys without your noticing, so you must trust the user can also request the keys without your noticing, so you must trust the root root user. user.
The process is quite simple; start the agent, and then add the pa.s.sphrase you used to create the key: $eval"ssh-agent"
Agentpid11487 $ssh-add Enterpa.s.sphrasefor/home/janl/.ssh/id_dsa:pa.s.sphrase Ident.i.tyadded:/home/janl/.ssh/id_dsa(/home/janl/.ssh/id_dsa) By default, all your keys will be added. If several of your keys have the same pa.s.sphrase, they will all be added without further questions. If they have different pa.s.sphrases, ssh-add ssh-add will be prompted for them. If you include a file on the will be prompted for them. If you include a file on the ssh-add ssh-add command line, the key in that file will be added and the command will not prompt for keys. command line, the key in that file will be added and the command will not prompt for keys.
ssh-agent works by setting two environment variables: works by setting two environment variables: SSH_AUTH_SOCK SSH_AUTH_SOCK, which names the socket on which to communicate with the agent, and SSH_AGENT_PID SSH_AGENT_PID, which makes it easy to kill the agent. That is also why the PID (process ID) shows up in the previous listing. The agent emits a sh.e.l.l script that, when evaluated, sets those variables correctly.
Since using pa.s.sphrases makes remote logins immeasurably more convenient, it may be a good idea to make it simple for your users to use pa.s.sphrases by starting ssh-agent ssh-agent whenever they log in. However, the users" whenever they log in. However, the users" .bashrc .bashrc or or .login .login scripts are not a good place for the command, nor is the system scripts are not a good place for the command, nor is the system /etc/profile /etc/profile, because you don"t need the command to run every time a new terminal is started. A good place to put it is in the system-wide Xsession Xsession scripts. Exactly which script is used to start an X session depends on which distribution and which desktop people use (KDE, GNOME, cla.s.sical X, their own custom session). But on Debian-based and Red Hat-based systems, there are standard ways to do it. scripts. Exactly which script is used to start an X session depends on which distribution and which desktop people use (KDE, GNOME, cla.s.sical X, their own custom session). But on Debian-based and Red Hat-based systems, there are standard ways to do it.
On Debian-based systems, if you put use-ssh-agent use-ssh-agent on a line by itself in on a line by itself in /etc/X11/xdm/xdm.options /etc/X11/xdm/xdm.options, anyone who later logs in with the X Window System will cause the script /etc/X11/Xsession.d/90xfree86-common_ssh-agent /etc/X11/Xsession.d/90xfree86-common_ssh-agent to run. It is reproduced here for convenience: to run. It is reproduced here for convenience: STARTSSH= Ss.h.a.gENT=/usr/bin/ssh-agent Ss.h.a.gENTARGS=
ifgrep-qs^use-ssh-agent"$OPTIONFILE";then if[-x"$Ss.h.a.gENT"-a-z"$SSH_AUTH_SOCK"-a-z"$SSH2_AUTH_SOCK"];then STARTSSH=yes if[-f/usr/bin/ssh-add1]&&cmp-s$Ss.h.a.gENT/usr/bin/ssh-agent2;then #usessh-agent2"sssh-agent1compatibilitymode Ss.h.a.gENTARGS=-1 fi fi fi
if[-n"$STARTSSH"];then REALSTARTUP="$Ss.h.a.gENT$Ss.h.a.gENTARGS$REALSTARTUP"
fi This script first looks for the system-wide use-ssh-agent use-ssh-agent setting, then very carefully checks whether any of the setting, then very carefully checks whether any of the ssh-agent ssh-agent-related variables are set already, because if they are set, an agent should already be running. Finally, it redefines REALSTARTUP REALSTARTUP so that the agent will be started later in the Debian scripts. The script could just as well have run so that the agent will be started later in the Debian scripts. The script could just as well have run eval "ssh-agent" eval "ssh-agent" directly. directly.
On Red Hatbased systems, you can accomplish the same effect by adding the preceding script to /etc/X11/xinit/xinitrc.d /etc/X11/xinit/xinitrc.d, but it should be changed to run the agent directly, as Red Hatbased systems do not set up all the environment variables that Debian-based systems do. In most versions of Linux, the agent is started automatically. This includes, for example, all recent versions of Ubuntu and other Debian-based systems.
But none of these automated systems adds any keys to the agent. That means that users will still be prompted for a pa.s.sphrase. Users can run ssh-add ssh-add (perhaps in their (perhaps in their .bashrc .bashrc files) and enter their pa.s.sphrases once into a sh.e.l.l terminal each time X starts. files) and enter their pa.s.sphrases once into a sh.e.l.l terminal each time X starts.
It may be a good idea to doctor the automated X setup further with an ssh-add ssh-add command. If run without a terminal, command. If run without a terminal, ssh-add ssh-add pops up a graphical pa.s.sphrase input box. pops up a graphical pa.s.sphrase input box.