/usr/share/doc/debian-handbook/html/sect.remote-login.html is in debian-handbook 7.20140126.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 | <?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>9.2. Remote Login</title><link rel="stylesheet" type="text/css" href="Common_Content/css/default.css" /><link rel="stylesheet" media="print" href="Common_Content/css/print.css" type="text/css" /><meta name="generator" content="publican 3.2.1" /><meta name="package" content="Debian-debian-handbook-7-en-US-1.0-1" /><meta name="keywords" content="System boot, Initscripts, SSH, Telnet, Rights, Permissions, Supervision, Inetd, Cron, Backup, Hotplug, PCMCIA, APM, ACPI" /><link rel="home" href="index.html" title="The Debian Administrator's Handbook" /><link rel="up" href="unix-services.html" title="Chapter 9. Unix Services" /><link rel="prev" href="unix-services.html" title="Chapter 9. Unix Services" /><link rel="next" href="sect.rights-management.html" title="9.3. Managing Rights" /></head><body><p id="title"><a class="left" href="http://www.debian.org"><img alt="Product Site" src="Common_Content/images//image_left.png" /></a><a class="right" href="http://debian-handbook.info"><img alt="Documentation Site" src="Common_Content/images//image_right.png" /></a></p><ul class="docnav top"><li class="previous"><a accesskey="p" href="unix-services.html"><strong>Prev</strong></a></li><li class="home">The Debian Administrator's Handbook</li><li class="next"><a accesskey="n" href="sect.rights-management.html"><strong>Next</strong></a></li></ul><div class="section"><div class="titlepage"><div><div><h2 class="title"><a xmlns="" id="sect.remote-login"></a>9.2. Remote Login</h2></div></div></div><div class="para">
It is essential for an administrator to be able to connect to a computer remotely. Servers, confined in their own room, are rarely equipped with permanent keyboards and monitors — but they are connected to the network.
</div><div class="sidebar"><div class="titlepage"><div><div><p class="title"><strong><span class="emphasis"><em>BACK TO BASICS</em></span> Client, server</strong></p></div></div></div><a id="idm1222235180" class="indexterm"></a><a id="idm1222234476" class="indexterm"></a><div class="para">
A system where several processes communicate with each other is often described with the “client/server” metaphor. The server is the program that takes requests coming from a client and executes them. It is the client that controls operations, the server doesn't take any initiative of its own.
</div></div><a id="idm1222233156" class="indexterm"></a><a id="idm1222232452" class="indexterm"></a><div class="section"><div class="titlepage"><div><div><h3 class="title"><a xmlns="" id="sect.ssh"></a>9.2.1. Secure Remote Login: SSH</h3></div></div></div><a id="idm1222231420" class="indexterm"></a><a id="idm1222230940" class="indexterm"></a><div class="para">
The <span class="emphasis"><em>SSH</em></span> (Secure SHell) protocol was designed with security and reliability in mind. Connections using SSH are secure: the partner is authenticated and all data exchanges are encrypted.
</div><div class="sidebar"><div class="titlepage"><div><div><p class="title"><strong><span class="emphasis"><em>CULTURE</em></span> Telnet and RSH are obsolete</strong></p></div></div></div><a id="idm1224257532" class="indexterm"></a><a id="idm1224256972" class="indexterm"></a><div class="para">
Before SSH, <span class="emphasis"><em>Telnet</em></span> and <span class="emphasis"><em>RSH</em></span> were the main tools used to login remotely. They are now largely obsolete and should no longer be used even if Debian still provides them.
</div></div><div class="sidebar"><div class="titlepage"><div><div><p class="title"><strong><span class="emphasis"><em>VOCABULARY</em></span> Authentication, encryption</strong></p></div></div></div><div class="para">
When you need to give a client the ability to conduct or trigger actions on a server, security is important. You must ensure the identity of the client; this is authentication. This identity usually consists of a password that must be kept secret, or any other client could get the password. This is the purpose of encryption, which is a form of encoding that allows two systems to communicate confidential information on a public channel while protecting it from being readable to others.
</div><div class="para">
Authentication and encryption are often mentioned together, both because they are frequently used together, and because they are usually implemented with similar mathematical concepts.
</div></div><div class="para">
SSH also offers two file transfer services. <code class="command">scp</code> is a command line tool that can be used like <code class="command">cp</code>, except that any path to another machine is prefixed with the machine's name, followed by a colon.
</div><pre class="screen"><code class="computeroutput">$ </code><strong class="userinput"><code>scp file machine:/tmp/</code></strong></pre><div class="para">
<code class="command">sftp</code> is an interactive command, similar to <code class="command">ftp</code>. In a single session, <code class="command">sftp</code> can transfer several files, and it is possible to manipulate remote files with it (delete, rename, change permissions, etc.).
</div><a id="idm1224251324" class="indexterm"></a><a id="idm1224250764" class="indexterm"></a><div class="para">
Debian uses OpenSSH, a free version of SSH maintained by the <code class="command">OpenBSD</code> project (a free operating system based on the BSD kernel, focused on security) and fork of the original SSH software developed by the SSH Communications Security Corp company, of Finland. This company initially developed SSH as free software, but eventually decided to continue its development under a proprietary license. The OpenBSD project then created OpenSSH to maintain a free version of SSH.
</div><a id="idm1224249276" class="indexterm"></a><div class="sidebar"><div class="titlepage"><div><div><p class="title"><strong><span class="emphasis"><em>BACK TO BASICS</em></span> <span class="foreignphrase"><em class="foreignphrase">Fork</em></span></strong></p></div></div></div><a id="idm1224248108" class="indexterm"></a><div class="para">
A “fork”, in the software field, means a new project that starts as a clone of an existing project, and that will compete with it. From there on, both software will usually quickly diverge in terms of new developments. A fork is often the result of disagreements within the development team.
</div><div class="para">
The option to fork a project is a direct result of the very nature of free software; a fork is a healthy event when it enables the continuation of a project as free software (for example in case of license changes). A fork arising from technical or personal disagreements is often a waste of human resources; another resolution would be preferable. Mergers of two projects that previously went through a prior fork are not unheard of.
</div></div><div class="para">
OpenSSH is split into two packages: the client part is in the <span class="pkg pkg">openssh-client</span> package, and the server is in the <span class="pkg pkg">openssh-server</span> package. The <span class="pkg pkg">ssh</span> meta-package depends on both parts and facilitates installation of both (<code class="command">apt-get install ssh</code>).
</div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a xmlns="" id="sect.ssh-key-based-auth"></a>9.2.1.1. Key-Based Authentication</h4></div></div></div><div class="para">
Each time someone logs in over SSH, the remote server asks for a password to authenticate the user. This can be problematic if you want to automate a connection, or if you use a tool that requires frequent connections over SSH. This is why SSH offers a key-based authentication system.
</div><div class="para">
The user generates a key pair on the client machine with <code class="command">ssh-keygen -t rsa</code>; the public key is stored in <code class="filename">~/.ssh/id_rsa.pub</code>, while the corresponding private key is stored in <code class="filename">~/.ssh/id_rsa</code>. The user then uses <code class="command">ssh-copy-id <em class="replaceable"><code>server</code></em></code> to add their public key to the <code class="filename">~/.ssh/authorized_keys</code> file on the server. If the private key was not protected with a “passphrase” at the time of its creation, all subsequent logins on the server will work without a password. Otherwise, the private key must be decrypted each time by entering the passphrase. Fortunately, <code class="command">ssh-agent</code> allows us to keep private keys in memory to not have to regularly re-enter the password. For this, you simply use <code class="command">ssh-add</code> (once per work session) provided that the session is already associated with a functional instance of <code class="command">ssh-agent</code>. Debian activates it by default in graphical sessions, but this can be deactivated by changing <code class="filename">/etc/X11/Xsession.options</code>. For a console session, you can manually start it with <code class="command">eval $(ssh-agent)</code>.
</div><div class="sidebar"><div class="titlepage"><div><div><p class="title"><strong><span class="emphasis"><em>SECURITY</em></span> Protection of the private key</strong></p></div></div></div><div class="para">
Whoever has the private key can login on the account thus configured. This is why access to the private key is protected by a “passphrase”. Someone who acquires a copy of a private key file (for example, <code class="filename">~/.ssh/id_rsa</code>) still has to know this phrase in order to be able to use it. This additional protection is not, however, impregnable, and if you think that this file has been compromised, it is best to disable that key on the computers in which it has been installed (by removing it from the <code class="filename">authorized_keys</code> files) and replacing it with a newly generated key.
</div></div><div class="sidebar"><div class="titlepage"><div><div><p class="title"><strong><span class="emphasis"><em>CULTURE</em></span> OpenSSL flaw in Debian <span class="distribution distribution">Etch</span></strong></p></div></div></div><div class="para">
The OpenSSL library, as initially provided in Debian <span class="distribution distribution">Etch</span>, had a serious problem in its random number generator (RNG). Indeed, the Debian maintainer had made a change so that applications using it would no longer generate warnings when analyzed by memory testing tools like <code class="command">valgrind</code>. Unfortunately, this change also meant that the RNG was employing only one source of entropy corresponding to the process number (PID) whose 32,000 possible values do not offer enough randomness. <div xmlns="" class="url">→ <a xmlns="http://www.w3.org/1999/xhtml" href="http://www.debian.org/security/2008/dsa-1571">http://www.debian.org/security/2008/dsa-1571</a></div>
</div><div class="para">
Specifically, whenever OpenSSL was used to generate a key, it always produced a key within a known set of hundreds of thousands of keys (32,000 multiplied by a small number of key lengths). This affected SSH keys, SSL keys, and X.509 certificates used by numerous applications, such as OpenVPN. A cracker had only to try all of the keys to gain unauthorized access. To reduce the impact of the problem, the SSH daemon was modified to refuse problematic keys that are listed in the <span class="pkg pkg">openssh-blacklist</span> and <span class="pkg pkg">openssh-blacklist-extra</span> packages. Additionally, the <code class="command">ssh-vulnkey</code> command allows identification of possibly compromised keys in the system.
</div><div class="para">
A more thorough analysis of this incident brings to light that it is the result of multiple (small) problems, both at the OpenSSL project, as well as with the Debian package maintainer. A widely used library like OpenSSL should — without modifications — not generate warnings when tested by <code class="command">valgrind</code>. Furthermore, the code (especially the parts as sensitive as the RNG) should be better commented to prevent such errors. The Debian maintainer, for his part, wanting to validate his modifications with the OpenSSL developers, simply explained his modifications without providing them the corresponding patch to review. He also did not clearly identify himself as the maintainer of the corresponding Debian package. Finally, in his maintenance choices, the maintainer did not clearly document the changes made to the original code; all the modifications are effectively stored in a Subversion repository, but they ended up all lumped into one single patch during creation of the source package.
</div><div class="para">
It is difficult under such conditions to find the corrective measures to prevent such incidents from recurring. The lesson to be learned here is that every divergence Debian introduces to upstream software must be justified, documented, submitted to the upstream project when possible, and widely publicized. It is from this perspective that the new source package format (“3.0 (quilt)”) and the Debian patch tracker were developed. <div xmlns="" class="url">→ <a xmlns="http://www.w3.org/1999/xhtml" href="http://patch-tracker.debian.org">http://patch-tracker.debian.org</a></div>
</div></div></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a xmlns="" id="sect.ssh-x11"></a>9.2.1.2. Using Remote X11 Applications</h4></div></div></div><div class="para">
The SSH protocol allows forwarding of graphical data (“X11” session, from the name of the most widespread graphical system in Unix); the server then keeps a dedicated channel for those data. Specifically, a graphical program executed remotely can be displayed on the X.org server of the local screen, and the whole session (input and display) will be secure. Since this feature allows remote applications to interfere with the local system, it is disabled by default. You can enable it by specifying <code class="literal">X11Forwarding yes</code> in the server configuration file (<code class="filename">/etc/ssh/sshd_config</code>). Finally, the user must also request it by adding the <code class="literal">-X</code> option to the <code class="command">ssh</code> command-line.
</div></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a xmlns="" id="sect.ssh-port-forwarding"></a>9.2.1.3. Creating Encrypted Tunnels with Port Forwarding</h4></div></div></div><a id="idm1224228212" class="indexterm"></a><div class="para">
Its <code class="literal">-R</code> and <code class="literal">-L</code> options allow <code class="command">ssh</code> to create “encrypted tunnels” between two machines, securely forwarding a local TCP port (see sidebar <a class="xref" href="network-infrastructure.html#sidebar.tcp-udp"><span class="emphasis"><em>BACK TO BASICS</em></span> TCP/UDP</a>) to a remote machine or vice versa.
</div><div class="sidebar"><div class="titlepage"><div><div><p class="title"><strong><span class="emphasis"><em>VOCABULARY</em></span> Tunnel</strong></p></div></div></div><a id="idm1224225868" class="indexterm"></a><a id="idm1224225164" class="indexterm"></a><div class="para">
The Internet, and most LANs that are connected to it, operate in packet mode and not in connected mode, meaning that a packet issued from one computer to another is going to be stopped at several intermediary routers to find its way to its destination. You can still simulate a connected operation where the stream is encapsulated in normal IP packets. These packets follow their usual route, but the stream is reconstructed unchanged at the destination. We call this a “tunnel”, analogous to a road tunnel in which vehicles drive directly from the entrance (input) to the exit (output) without encountering any intersections, as opposed to a path on the surface that would involve intersections and changing direction.
</div><div class="para">
You can use this opportunity to add encryption to the tunnel: the stream that flows through it is then unrecognizable from the outside, but it is returned in decrypted form at the exit of the tunnel.
</div></div><div class="para">
<code class="command">ssh -L 8000:server:25 intermediary</code> establishes an SSH session with the <em class="replaceable"><code>intermediary</code></em> host and listens to local port 8000 (see <a class="xref" href="sect.remote-login.html#figure.ssh-L">Figure 9.2, “Forwarding a local port with SSH”</a>). For any connection established on this port, <code class="command">ssh</code> will initiate a connection from the <em class="replaceable"><code>intermediary</code></em> computer to port 25 on the <em class="replaceable"><code>server</code></em>, and will bind both connections together.
</div><div class="para">
<code class="command">ssh -R 8000:server:25 intermediary</code> also establishes an SSH session to the <em class="replaceable"><code>intermediary</code></em> computer, but it is on this machine that <code class="command">ssh</code> listens to port 8000 (see <a class="xref" href="sect.remote-login.html#figure.ssh-R">Figure 9.3, “Forwarding a remote port with SSH”</a>). Any connection established on this port will cause <code class="command">ssh</code> to open a connection from the local machine on to port 25 of the <em class="replaceable"><code>server</code></em>, and to bind both connections together.
</div><div class="para">
In both cases, connections are made to port 25 on the <em class="replaceable"><code>server</code></em> host, which pass through the SSH tunnel established between the local machine and the <em class="replaceable"><code>intermediary</code></em> machine. In the first case, the entrance to the tunnel is local port 8000, and the data move towards the <em class="replaceable"><code>intermediary</code></em> machine before being directed to the <em class="replaceable"><code>server</code></em> on the “public” network. In the second case, the input and output in the tunnel are reversed; the entrance is port 8000 on the <em class="replaceable"><code>intermediary</code></em> machine, the output is on the local host, and the data are then directed to the <em class="replaceable"><code>server</code></em>. In practice, the server is usually either the local machine or the intermediary. That way SSH secures the connection from one end to the other.
</div><div class="figure"><a xmlns="" id="figure.ssh-L"></a><div class="figure-contents"><div class="mediaobject"><img src="images/ssh-L.png" alt="Forwarding a local port with SSH" /></div></div><p class="title"><strong>Figure 9.2. Forwarding a local port with SSH</strong></p></div><br class="figure-break" /><div class="figure"><a xmlns="" id="figure.ssh-R"></a><div class="figure-contents"><div class="mediaobject"><img src="images/ssh-R.png" alt="Forwarding a remote port with SSH" /></div></div><p class="title"><strong>Figure 9.3. Forwarding a remote port with SSH</strong></p></div><br class="figure-break" /></div></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a xmlns="" id="sect.remote-desktops"></a>9.2.2. Using Remote Graphical Desktops</h3></div></div></div><div class="para">
VNC (Virtual Network Computing) allows remote access to graphical desktops.
</div><a id="idm1224212660" class="indexterm"></a><a id="idm1224212180" class="indexterm"></a><a id="idm1224211716" class="indexterm"></a><a id="idm1224211012" class="indexterm"></a><a id="idm1224210548" class="indexterm"></a><div class="para">
This tool is mostly used for technical assistance; the administrator can see the errors that the user is facing, and show them the correct course of action without having to stand by them.
</div><a id="idm1224209612" class="indexterm"></a><a id="idm1224208900" class="indexterm"></a><a id="idm1224208188" class="indexterm"></a><div class="para">
First, the user must authorize sharing their session. The GNOME and KDE graphical desktop environments include, respectively, <code class="command">vino</code> and <code class="command">krfb</code>, which provide a graphical interface that allows sharing an existing session over VNC (both are identified as <span class="emphasis"><em>Desktop Sharing</em></span> either in the GNOME application list or in the KDE menu). For other graphical desktop environments, the <code class="command">x11vnc</code> command (from the Debian package of the same name) serves the same purpose; you can make it available to the user with an explicit icon.
</div><a id="idm1224205836" class="indexterm"></a><a id="idm1224205124" class="indexterm"></a><a id="idm1224204412" class="indexterm"></a><a id="idm1224203700" class="indexterm"></a><div class="para">
When the graphical session is made available by VNC, the administrator must connect to it with a VNC client. GNOME has <code class="command">vinagre</code> and <code class="command">remmina</code> for that, while KDE includes <code class="command">krdc</code> (in the menu at <span class="guimenu"><strong>K</strong></span> → <span class="guisubmenu"><strong>Internet</strong></span> → <span class="guimenuitem"><strong>Remote Desktop Client</strong></span>). There are other VNC clients that use the command line, such as <code class="command">xvnc4viewer</code> in the Debian package of the same name. Once connected, the administrator can see what's going on, work on the machine remotely, and show the user how to proceed.
</div><div class="sidebar"><div class="titlepage"><div><div><p class="title"><strong><span class="emphasis"><em>SECURITY</em></span> VNC over SSH</strong></p></div></div></div><a id="idm1224200036" class="indexterm"></a><div class="para">
If you want to connect by VNC, and you don't want your data sent in clear text on the network, it is possible to encapsulate the data in an SSH tunnel (see <a class="xref" href="sect.remote-login.html#sect.ssh-port-forwarding">Section 9.2.1.3, “Creating Encrypted Tunnels with Port Forwarding”</a>). You simply have to know that VNC uses port 5900 by default for the first screen (called “localhost:0”), 5901 for the second (called “localhost:1”), etc.
</div><div class="para">
The <code class="command">ssh -L localhost:5901:localhost:5900 -N -T <em class="replaceable"><code>machine</code></em></code> command creates a tunnel between local port 5901 in the localhost interface and port 5900 of the <em class="replaceable"><code>machine</code></em> host. The first “localhost” restricts SSH to listening to only that interface on the local machine. The second “localhost” indicates the interface on the remote machine which will receive the network traffic entering in “localhost:5901”. Thus <code class="command">vncviewer localhost:1</code> will connect the VNC client to the remote screen, even though you indicate the name of the local machine.
</div><div class="para">
When the VNC session is closed, remember to close the tunnel by also quitting the corresponding SSH session.
</div></div><div class="sidebar"><div class="titlepage"><div><div><p class="title"><strong><span class="emphasis"><em>BACK TO BASICS</em></span> Display manager</strong></p></div></div></div><a id="idm1224195980" class="indexterm"></a><a id="idm1224195420" class="indexterm"></a><a id="idm1224194860" class="indexterm"></a><a id="idm1224194300" class="indexterm"></a><a id="idm1224193740" class="indexterm"></a><a id="idm1224193036" class="indexterm"></a><div class="para">
<code class="command">gdm</code>, <code class="command">kdm</code>, <code class="command">lightdm</code>, and <code class="command">xdm</code> are Display Managers. They take control of the graphical interface shortly after boot in order to provide the user a login screen. Once the user has logged in, they execute the programs needed to start a graphical work session.
</div></div><div class="para">
VNC also works for mobile users, or company executives, who occasionally need to login from their home to access a remote desktop similar to the one they use at work. The configuration of such a service is more complicated: you first install the <span class="pkg pkg">vnc4server</span> package, change the configuration of the display manager to accept <code class="literal">XDMCP Query</code> requests (for <code class="command">gdm3</code>, this can be done by adding <code class="literal">Enable=true</code> in the “xdmcp” section of <code class="filename">/etc/gdm3/daemon.conf</code>), and finally, start the VNC server with <code class="command">inetd</code> so that a session is automatically started when a user tries to login. For example, you may add this line to <code class="filename">/etc/inetd.conf</code>:
</div><pre class="programlisting">5950 stream tcp nowait nobody.tty /usr/bin/Xvnc Xvnc -inetd -query localhost -once -geometry 1024x768 -depth 16 securitytypes=none
</pre><div class="para">
Redirecting incoming connections to the display manager solves the problem of authentication, because only users with local accounts will pass the <code class="command">gdm</code> login screen (or equivalent <code class="command">kdm</code>, <code class="command">xdm</code>, etc.). As this operation allows multiple simultaneous logins without any problem (provided the server is powerful enough), it can even be used to provide complete desktops for mobile users (or for less powerful desktop systems, configured as thin clients). Users simply login to the server's screen with <code class="command">vncviewer <em class="replaceable"><code>server</code></em>:50</code>, because the port used is 5950.
</div><a id="idm1224186364" class="indexterm"></a></div></div><ul class="docnav"><li class="previous"><a accesskey="p" href="unix-services.html"><strong>Prev</strong>Chapter 9. Unix Services</a></li><li class="up"><a accesskey="u" href="#"><strong>Up</strong></a></li><li class="home"><a accesskey="h" href="index.html"><strong>Home</strong></a></li><li class="next"><a accesskey="n" href="sect.rights-management.html"><strong>Next</strong>9.3. Managing Rights</a></li></ul></body></html>
|