Chapter 16 ■ telnet and SSh
304
An Overview of SSH
The first section of this book talked a lot about multiplexing—about how UDP (Chapter 2) and TCP (Chapter 3) take
the underlying IP protocol, which has no concept that there might actually be several users or applications on a single
computer that need to communicate, and add the concept of UDP and TCP port numbers so that several different
conversations between a pair of IP addresses can take place at the same time.
Once that basic level of multiplexing was established, we more or less left the topic behind. Through more than a
dozen chapters now, we have studied protocols that take a UDP or TCP connection and then happily use it for exactly
one thing—downloading a web page or transmitting an e-mail—never trying to do several things at the same time
over a single socket.
Now as we arrive at SSH, we find a protocol so sophisticated that it actually implements its own multiplexing.
Several “channels” of information can all share the same SSH socket. Every block of information SSH sends across its
socket is labeled with a “channel” identifier so that several conversations can share the socket.
There are at least two reasons that subchannels make sense. First, even though the channel ID takes up a bit of
bandwidth for every single block of information transmitted, the additional data is small compared to how much
extra information SSH has to transmit to negotiate and maintain encryption anyway. Second, channels make sense
because the real expense of an SSH connection is setting it up. Host key negotiation and authentication can together
take up several seconds of real time, and once the connection is established, you want to be able to use it for as many
operations as possible. Thanks to the SSH notion of a channel, you can amortize the high cost of connecting by
performing many operations before you let the connection close.
Once connected, you can create several kinds of channels:
• An interactive shell session, like that supported by Telnet• The individual execution of a single command• A file transfer session letting you browse the remote filesystem• A port forward that intercepts TCP connectionsYou will learn about all of these kinds of channels in the following sections.SSH Host Keys
When an SSH client first connects to a remote host, the two exchange temporary public keys that let them encrypt the
rest of their conversation without revealing any information to any watching third parties. Then, before the client is
willing to divulge any further information, it demands proof of the remote server’s identity. This makes good sense as
a first step: if you were really talking to a hacker’s software that has temporarily managed to grab the remote server’s
IP, you do not want SSH to divulge even your username—much less your password!
As you saw in Chapter 6, one answer to the problem of machine identity on the Internet is to build a public-key
infrastructure. First you designate a set of organizations called certificate authorities that can issue certs. Then you
install a list of their public keys in all of the web browsers and other SSL clients in existence. Then those organizations
charge you money to verify that you really are google.com (or whoever you are) and that you deserve to have your
google.com SSL certificate signed. Finally, you can install the certificate on your web server, and everyone will trust
your identity.
There are many problems with this system from the point of view of SSH. While it is true that you can build a
public-key infrastructure internal to an organization where you distribute your own signing authority’s certificates to
your web browsers or other applications and then can sign your own server certificates without paying a third party,
a public-key infrastructure would still be quite a cumbersome process for something like SSH. Server administrators
want to set up, use, and tear down servers all the time without having to talk to a central authority first.