- Remote login
ssh server ssh -l user server # equivalently ssh user@server # lots of other flags available, e.g. ssh -d [debug level]; try ssh -h # escape from session with line-initial ~ (try ~?) - Remote command execution
ssh server cmd - Remote file transfer
# an ftp-ish client sftp server # a cp-ish client scp from-file to-file # which takes various flags -p preserver attributes/timestamps, # -r recursive, either from-file or to-file may be remote; # file specification takes the form which allows for lovely # things like (from A as user u1): scp u2@B:foo/fup.html u3@C:
- Port forwarding. In its typical use ssh is a standard client/server application: a client talks, from some dynamically assigned tcp port, to a server at tcp/22. However ssh is also able to forward connections from a second port on the client end (say some arbitrary dynamic port), through the basic ssh connection, and on to a second port at the ssh server end, say to a POP server. Port forwarding turns out to be very securing services and for firewall traversal. More on this later, probably, when we do firewalls.
- Ftp and telnet, file transfer and remote login protocols that involve sending passwords and data over the wire in plaintext.
- The Unix r-commands, rcp, rsh, rlogin that do respectively file transfer, remote command execution, remote login. The r-programs do away with passwords, but involve a weak form of authentication. A given host, as we touched on briefly in session 1 in connection with TCP session hijacking, can define other machines to be trusted. It does so by entering their hostnames in certain configuration files (globally, /etc/hosts.equiv, per user, ~/.rhosts). A user u on a remote trusted machine would then be able to connect to the trusting machine as local user u without having to supply a password. The main weakness in this scheme has to do with the form of authentication it uses: a request comes in to the trusting machine; it extracts the source IP address, does a reverse lookup to find the corresponding domain name, and compares the result to entries in the config files. This procedure is susceptible to IP spoofing and subversion of the DNS system, both of which turn out to be reasonably easy to do - those protocols have few security features.
- SSH provides the core security services encryption,
authentication, and integrity. It authenticates the server
using public key cryptographic methods; it does bulk data
encryption using symmetrical algorithms, leaving the choice of
these to be negotiated between client and server; and it
provides data integrity by way of the usual hash functions.
In all these respects, as we'll see, SSH resembles SSL. However there are important differences in the ways the two protocols operate. For example, in SSH the server is authenticated using public key cryptography, but this doesn't (yet) involve the use of X.509 certificates (the SSH v2 protocol allows for a server to pass a certificate to a client, but at this point all going implementations deal with the raw keys). Further, SSH has a much more extensive apparatus for dealing with client authentication than does SSL: in SSL, client authentication is optional and in practice rarely performed; when it is done, it amounts simply to a transfer of a digital certificate; SSH sessions, on the other hand, almost invariably include client authentication, and the protocol offers a number of modes of authentication.
- SSH v2 involves three sub-protocols--a transport
protocol that handles connection setup, server authentication,
and algorithm negotiation; an authentication protocol
that handles user authentication; and a connection
protocol that deals with the multiple data and control streams
that pass through the channel. Here's the basic structure of
the transport protocol, seen from the point of view of a
connection-initiating sequence:
- After a generic TCP connect, the two sides exchange version strings (especially important when there are large populations of both v1- and v2-speakers floating around).
- Switch to a binary protocol. The packet format is going to look like this:
uint32 packet_length byte padding_length byte[packet_length - padding_length - 1] payload byte[padding_length] padding byte[MAC_length] MAC (i.e., hash) - Now start negotiating, and in particular we need to
figure out what key exchange method to use, so each side
sends a SSH_MSG_KEXINIT message. You might think this
negotiation would take awhile--we're always going to be
worried about how many round-trips the protocol consumes,
right?--but in practice there's only one key exchange
method defined--Diffie-Hellman with SHA-1 hashing--and the
standard allows you to guess, i.e., to follow up
your initial offer immediately with a packet built for the
key exchange method you think the other party will
agree to. Setting the first_kex_packet_follows flag in
your initial offer means "the thing that follows isn't me
sneezing, it's an answer to what I think you're going to
say".
The various strings in the SSH_MSG_KEXINIT message consist of defined string constants for the various algorithms, comma-separated, and listed in decreasing order of preference. If both parties have the same algorithm in a given category ranked highest they use that; otherwise they use the algorithm most highly ranked by the client that the server knows how to do (and that's consistent with other algorithms selected). So here's what the initial offer looks like:
byte SSH_MSG_KEXINIT byte[16] cookie (random bytes) string kex_algorithms string encryption_algorithms_client_to_server string encryption_algorithms_server_to_client string mac_algorithms_client_to_server string mac_algorithms_server_to_client string compression_algorithms_client_to_server string compression_algorithms_server_to_client string languages_client_to_server string languages_server_to_client boolean first_kex_packet_follows uint32 reserved - Now guess, i.e., start in with Diffie-Hellman
calculations. In what follows, V_C = the client's version
string, V_S = the server's; I_C = the payload of the
client's SSH_MSG_KEXINIT message, I_S the server's; K_S =
the server's public key. The Diffie-Hellman operators g
and p are defined in the standard, i.e., they're known to
both parties in advance.
- Client
- Pick random x
- Send
byte SSH_MSG_KEXDH_INIT mpint e (= g**x mod p)
- Server (having received client's message)
- Pick random y, compute f = g**y mod p
- Compute
- K = e**y mod p (K is the Diffie-Hellman shared secret)
- H = SHA-1(V_C || V_S || I_C || I_S || K_S || e || f || K)
- Generate a signature s on H using server's private key
- Send
byte SSH_MSG_KEXDH_REPLY string K_S (this is the pub key) mpint f string s
- Client
- Verify that K_S is really the host key for the server (should have a copy in our local store - this is how we avoid the man-in-the-middle attacks, and verify we know who we're talking to)
- Compute
- K = f**x mod p (client's copy of shared secret)
- H (same calculation as server performed)
- Verify s (i.e., we should be able to get H back by decrypting s with K_S; if we can do this we've verified the server)
- Client and server now generate the various session keys from K and H (the "shared secret", as we'll see too in the case of SSL, is really just input to further manipulation that produces the actual keys, the further manipulation consisting of hashing K, H, and some literal values defined in the standards documents
- The next messages exchanged are a pair of SSH_MSG_NEWKEYs--i.e., each side announces it's about to start communicating using the keys and algorithms just negotiated
- All this is before it's even really got going!
At this point the session can move in various directions. Most commonly the client will request an operation involving one of the other sub-protocols--and most commonly of all will move to client authentication. The form of this request is
byte SSH_MSG_SERVICE_REQUEST string service name ("ssh-userauth" | "ssh-connection")If the server's prepared to proceed, it responds with a SSH_MSG_SERVICE_ACCEPT.
- Client
- Password. The client authenticates against the password database on the SSH server. The difference between this and non-SSH remote login, e.g. via telnet, is that the password travels encrypted from client to server (i.e., when we reach this point, we're already talking across an encrypted channel)
- Trusted host.
- Every machine has a public/private key pair it can use to prove its identify, by the fact that each computer stores copies of the public key of every other computer it connects to. The protocol has each side prove to the other that it is who it's supposed to be. These public key database are either installed by hand, or created the first time a computer is contacted. (And hopefully that wasn't the time Eve was being Evil.)
- (Per user) public key
- User generates a key pair using ssh-keygen. The private key is kept at the client end, stored
in a file under ~/.ssh2, and is pointed to from ~/.ssh2/identification with an entry of the
form
IdKey id_dsa_1024_a...where id_dsa_1024_a is the name of the file holding the private key. A copy of the public key is moved to the user's account on the server (under ~/.ssh2 again), and pointed to from ~/.ssh2/authorization with an entry of the formKey id_dsa_1024_a.pub - When the user wants to connect to the server, the SSH client sends a copy of the public key
half of the key pair it wants to authenticate with; the server checks to see that this key is
authorized to connect to the account, then encrypts a challenge message with that key and
returns the encrypted challenge to the client; the client decrypts the message (with the
private key), hashes it, and returns the hash to the server; the server than compares this
value to its own hash of the challenge. This sequence assures the server that the entity
presenting the public key and asking for authorization in fact holds the corresponding
private key.
Observe that there are some subtleties here--for example the client hashes the decrypted challenge (rather than returning it as is) to avoid the possibility that the challenge was actually something cleverly but maliciously chosen by the server--e.g. the (henceforth non-repudiable) plaintext "I hereby bequeath all my worldly possessions to the owner of server S", or perhaps a message previously encrypted with the user's public key
- User generates a key pair using ssh-keygen. The private key is kept at the client end, stored
in a file under ~/.ssh2, and is pointed to from ~/.ssh2/identification with an entry of the
form
- An SSH connection involves, minimally, a TCP
connection between a client at a dynamic port and a
server at port 22. It may also involve a kind of virtual
connection between another pair of ports--one on the
client end, one on the server end--that goes through the
basic SSH connection.
Let's say you're on A and you'd like to access a POP server on B--you'd like to, but you're worried about your POP username and password going in plaintext over the network. Let's say also that SSH facilities exist on both A and B. What port forwarding lets you do is to pass the POP connection through the SSH one. Three things are required:
- At the server end, the SSH server will make a TCP connection to the POP server
- At the client end, the SSH client will make a connection to the SSH server; it will also listen for connections on a second (arbitrary) TCP port (let's say 7773).
- Now when you want to read mail from A, you tell your mail client to connect to port 7773 on A. But that port is really owned by your SSH client; it forwards stuff on to the SSH server, which forwards it again to the POP server. Return traffic goes back through the same chain.
ssh -L 7773:localhost:111 B
...where -L mean "I want local forwarding" (vs. -R, "I want remote forwarding", which we'll get to in a second), and where the triple "7773:localhost:111" indicates a local entry point for an application client, the service provider (n.b. "localhost" here doesn't mean A, the machine initiating the SSH connection, rather it's relative to B, the machine receiving it), and the relevant port on the service provider, then what gets set up is the following arrangement (TCP ports are bracketed; we have a couple well-known server ports, 22 and 111, the listening port for the SSH client, as specified on the command line, and a couple other dynamic ports, for which I've picked numbers out of thin air)This command still creates an ssh session on B, just as it would without the -L flag. It just has a side effect as well - the two ends of the connection listen for local connections on their respective computers, and pass that stuff back and forth as well.
The result is that on A, "telnet localhost 7773" will actually ring port 111 on B.
- Port forwarding with the -L flag is "local" forwarding. Conversely we have "remote" port forwarding
with -R. If for example you're on C and you say
ssh -R 15658:localhost:80 D
...your client will- Set up a TCP connection to the webserver on C
- Make an SSH connection to the SSH server on D, tell it to grab 15658 and send through anything that comes in to that port
- There is a caveat about who's allowed to connect to those high ports.
Going back to the previous "local" case. We open a port on A, 7773, and tell our mail client on
A that if it connects to 7773, it'll be magically--and securely--transported to the mail server. Fine, but
that port 7773, that's just a regular old TCP port, so could a mail client on any other host connect to
(A, 7773) and get to the mail server?
The answer turns out to be no, by default, but this can be overridden. By default, the application client has to be on the same machine as the SSH client. The way this is enforced has to do with the way network sockets are allocated. When you say "gimme TCP port 7773", by default a socket is "bound", for that port, on all your machine's network interfaces. It possible however to restrict that binding, and that's what's done in the case of port forwarding--you get the port, but it's only on the (machine-internal) "loopback" interface associated with the IP address 127.0.0.1. This means that someone trying to reach this port will have to be able to do so at the destination address 127.0.0.1--and only another process on the same machine can do that.
The default behavior can be overridden in a user's config file (~/.ssh2/ssh2_config) with an entry like
GatewayPorts yes
With such an entry in place, the application client and SSH client can communicate over any IP link - Port forwarding can also be extended on the SSH server side (to take the case of "local" port
forwarding). To stick with our first example, when we
say
ssh -L 7773:localhost:111 B
..."localhost" tells B that the destination server is on B itself, at port 111. But we can insert any destination we like here. For examplessh -L 7773:www.pardons-r-us.com:80 B
means- listen locally on 7773
- Make an SSH connection to B
- Send anything that comes in to 7773 over to B
- Have B send anything that comes through the pipe on to pardons-r-us
- Uses of extended port forwarding
- Firewall piercing. Let's say you're on J and you want to get to some service on L, let's say
POP again, tcp/111. But what if there's a firewall K between J and L, blocking tcp/111? Sounds
like trouble, but if K is a bastion host supporting SSH, you may be able to do
ssh -L 5159:L:111 K...and point your local mail client at 5159
- And here's an example that involves extending port forwarding from both the client side and
the server side. Imagine you've got a network that has a webserver intended for organization-internal
use. Clients on the network can access the webserver directly, but at the edge of your network you've
got a firewall that blocks access to port 80. Then all of a sudden you sprout a branch office in,
say, Port Moresby. You'd like those guys to be able to access the webserver, but the firewall gets
in the way. However if the local (home office, I mean) firewall either provides SSH service or will
pass SSH traffic through to a device behind it that does, we can extend the previous example as
follows:
On PM-firewall:
- Turn on GatewayPorts
- Do: ssh -L 4488:W:80 L
- Do something, e.g. with TCP wrappers, to ensure that only branch office clients access PM-firewall at 4488
This example is artificial and restricted in a number of ways--starting with the face that in the case of web service you'd probably just run an SSL-based server at the home end, together with some form of client authentication. But there are other services, and the overall setup is in any case instructive.
Observe that
- We have two unprotected networks--unprotected by SSH--at either end of the arrangement: there's nothing to ensure the privacy, integrity, etc., etc. of communications between the browsers and PM-firewall, similarly no protection between L and W.
- But we're not worried about this because by hypothesis those are our networks. Either our users are angels and we have nothing to worry about from them, or they're not and we do. Either way, we can take whatever additional security precautions we like in these zones.
- This is not however the case in the intervening Internet--there we control nothing, and we have reason to believe not everything and everyone is angelic. But we don't worry about this either because we have a tunnel, an encrypted, authenticating, integrity-checking pipe through the Internet, whose two endpoints are on our routers.
- This sort of structure captures the essential idea behind "virtual private networks".
- Firewall piercing. Let's say you're on J and you want to get to some service on L, let's say
POP again, tcp/111. But what if there's a firewall K between J and L, blocking tcp/111? Sounds
like trouble, but if K is a bastion host supporting SSH, you may be able to do