Inhaltsverzeichnis von SSH, The Secure Shell: The Definitive Guide

Inhaltsvorschau

Many people today have multiple computer accounts. If you're a reasonably savvy user, you might have a personal account with an Internet service provider (ISP), a work account on your employer's local network, and a few computers at home. You might also have permission to use other accounts owned by family members or friends.

If you have multiple accounts, it's natural to want to make connections between them. For instance, you might want to copy files between computers over a network, log into one account remotely from another, or transmit commands to a remote computer for execution. Various programs exist for these purposes, such as ftp for file transfers, telnet for remote logins, and rsh for remote execution of commands.

Unfortunately, many of these network-related programs have a fundamental problem: they lack security. If you transmit a sensitive file via the Internet, an intruder can potentially intercept and read the data. Even worse, if you log onto another computer remotely using a program such as telnet, your username and password can be intercepted as they travel over the network. Yikes!

How can these serious problems be prevented? You can use an encryption program to scramble your data into a secret code nobody else can read. You can install a firewall, a device that shields portions of a computer network from intruders, and keep all your communications behind it. Or you can use a wide range of other solutions, alone or combined, with varying complexity and cost.

SSH, the Secure Shell, is a popular, powerful, software-based approach to network security. Whenever data is sent by a computer to the network, SSH automatically encrypts (scrambles) it. Then, when the data reaches its intended recipient, SSH automatically decrypts (unscrambles) it. The result is transparent encryption: users can work normally, unaware that their communications are safely encrypted on the network. In addition, SSH uses modern, secure encryption algorithms and is effective enough to be found within mission-critical applications at major corporations.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

SSH, the Secure Shell, is a popular, powerful, software-based approach to network security. Whenever data is sent by a computer to the network, SSH automatically encrypts (scrambles) it. Then, when the data reaches its intended recipient, SSH automatically decrypts (unscrambles) it. The result is transparent encryption: users can work normally, unaware that their communications are safely encrypted on the network. In addition, SSH uses modern, secure encryption algorithms and is effective enough to be found within mission-critical applications at major corporations.

SSH has a client/server architecture, as shown in Figure 1-1. An SSH server program, typically installed and run by a system administrator, accepts or rejects incoming connections to its host computer. Users then run SSH client programs, typically on other computers, to make requests of the SSH server, such as "Please log me in," "Please send me a file," or "Please execute this command." All communications between clients and servers are securely encrypted and protected from modification.

Figure 1-1: SSH architecture

Our description is simplified but should give you a general idea of what SSH does. We'll go into depth later. For now, just remember that SSH clients communicate with SSH servers over encrypted network connections.

SSH software is very common today. It comes with most Linux distributions, Macintosh OS X, Sun Solaris, OpenBSD, and virtually all other Unix-inspired operating systems. Microsoft Windows has plenty of SSH clients and servers, both free and commercial. You can even find it for PalmOS, Commodore Amiga, and most other platforms. [13.3]

Many SSH clients are inspired by old Unix programs called the "r-commands:" rsh (remote shell), rlogin (remote login), and rcp (remote copy). In fact, for many purposes the SSH clients are drop-in replacements for the r-commands, so if you're still using them, switch to SSH immediately! The old r-commands are notoriously insecure, and the SSH learning curve is small.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Although SSH stands for Secure Shell, it is not a true shell in the sense of the Unix Bourne shell and C shell. It is not a command interpreter, nor does it provide wildcard expansion, command history, and so forth. Rather, SSH creates a channel for running a shell on a remote computer, with end-to-end encryption between the two systems.

SSH is also not a complete security solution—but then, nothing is. It won't protect computers from active break-in attempts or denial-of-service attacks, and it won't eliminate other hazards such as viruses, Trojan horses, and coffee spills. It does, however, provide robust and user-friendly encryption and authentication.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

SSH is a protocol, not a product. It is a specification of how to conduct secure communication over a network.

The SSH protocol covers authentication, encryption, and the integrity of data transmitted over a network, as shown in Figure 1-2. Let's define these terms:

Authentication: Reliably determines someone's identity. If you try to log into an account on a remote computer, SSH asks for digital proof of your identity. If you pass the test, you may log in; otherwise, SSH rejects the connection.
Encryption: Scrambles data so that it is unintelligible except to the intended recipients. This protects your data as it passes over the network.
Integrity: Guarantees the data traveling over the network arrives unaltered. If a third party captures and modifies your data in transit, SSH detects this fact.

Figure 1-2: Authentication, encryption, and integrity

In short, SSH makes network connections between computers, with strong guarantees that the parties on both ends of the connection are genuine. It also ensures that any data passing over these connections arrives unmodified and unread by eavesdroppers.

The first SSH product, created by Tatu Ylönen for Unix, was simply called "SSH." This caused confusion because SSH was also the name of the protocol. In this book, we use more precise terminology to refer to protocols, products, and programs, summarized in the sidebar "Terminology: SSH Protocols and Products." In short:

Protocols are denoted with dashes: SSH-1, SSH-2.
Products are denoted in mixed case, without dashes: OpenSSH, Tectia, PuTTY, etc.
Client programs are in lowercase: ssh, scp, putty, etc.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

So, what can SSH do? Let's run through some examples that demonstrate the major features of SSH, such as secure remote logins , secure file copying, and secure invocation of remote commands.

Suppose you have login accounts on several computers on the Internet. Common programs like telnet let you log into one computer from another, say, from your home PC to your web hosting provider, or from one office computer to another. Unfortunately, telnet and similar programs transmit your username and password in plain text over the Internet, where a malicious third party can intercept them. Additionally, your entire telnet session is readable by a network snooper.

Local computer ( local host, local machine): A computer on which you are logged in and, typically, running an SSH client.
Remote computer (remote host, remote machine): A second computer you connect to via your local computer. Typically, the remote computer is running an SSH server and is accessed via an SSH client. As a degenerate case, the local and remote computers can be the same machine.
Local user: A user logged into a local computer.
Remote user: A user logged into a remote computer.
Server: An SSH server program.
Server machine: A computer running an SSH server program. We sometimes simply write "server" for the server machine when the context makes clear (or irrelevant) the distinction between the running SSH server program and its host machine.
Client: An SSH client program.
Client machine: A computer running an SSH client. As with the server terminology, we simply write "client" when the context makes the meaning clear.
~ or $HOME: A user's home directory on a Unix machine, particularly when used in a file path such as ~/filename. Most shells recognize ~ as a user's home directory, with the notable exception of the Bourne shell.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

SSH1 and the SSH-1 protocol were developed in 1995 by Tatu Ylönen, a researcher at the Helsinki University of Technology in Finland. After his university network was the victim of a password-sniffing attack earlier that year, Ylönen whipped up SSH1 for himself. When beta versions started gaining attention, however, he realized his security product could be put to wider use.

In July 1995, SSH1 was released to the public as free software with source code, permitting people to copy and use the program without cost. By the end of the year, an estimated 20,000 users in 50 countries had adopted SSH1, and Ylönen was fending off 150 email messages per day requesting support. In response, Ylönen founded SSH Communications Security Corp., (SCS, http://www.ssh.com/) in December of 1995 to maintain, commercialize, and continue development of SSH. Today he is a board member and technical advisor to the company.

Also in 1995, Ylönen documented the SSH-1 protocol as an Internet Engineering Task Force (IETF) Internet Draft, which essentially described the operation of the SSH1 software after the fact. It was a somewhat ad hoc protocol with a number of problems and limitations discovered as the software grew in popularity. These problems couldn't be fixed without losing backward compatibility, so in 1996, SCS introduced a new, major version of the protocol, SSH 2.0 or SSH-2, that incorporates new algorithms and is incompatible with SSH-1. In response, the IETF formed a working group called Secure Shell (SECSH) to standardize the protocol and guide its development in the public interest. The SECSH working group submitted the first Internet Draft for the SSH-2.0 protocol in February 1997.

In 1998, SCS released the software product SSH Secure Shell (SSH2), based on the superior SSH-2 protocol. However, SSH2 didn't replace SSH1 in the field: it was missing some features of SSH1 and had a more restrictive license, so many users felt little reason to switch, even though SSH-2 is a better and more secure protocol.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

SSH is popular and convenient, but we certainly don't claim it is the ultimate security solution for all networks. Authentication, encryption, and network security originated long before SSH and have been incorporated into many other systems. Let's survey a few representative systems.

The Unix programs rsh, rlogin, and rcp--collectively known as the r-commands --are the direct ancestors of the SSH clients ssh, slogin, and scp. The user interfaces and visible functionality are nearly identical to their SSH counterparts, except that SSH clients are secure. The r-commands, in contrast, don't encrypt their connections and have a weak, easily subverted authentication model.

An r-command server relies on two mechanisms for security: a network naming service and the notion of "privileged" TCP ports. Upon receiving a connection from a client, the server obtains the network address of the originating host and translates it into a hostname. This hostname must be present in a configuration file on the server, typically /etc/hosts.equiv, for the server to permit access. The server also checks that the source TCP port number is in the range 1-1023, since these port numbers can be used only by the Unix superuser (or root uid). If the connection passes both checks, the server believes it is talking to a trusted program on a trusted host and logs in the client as whatever user it requests!

These two security checks are easily subverted. The translation of a network address to a hostname is done by a naming service such as Sun's Network Information Service (NIS) or the Internet Domain Name System (DNS). Most implementations and/or deployments of NIS and DNS services have security holes, presenting opportunities to trick the server into trusting a host it shouldn't. Then, a remote user can log into someone else's account on the server simply by having the same username.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

SSH is a powerful, convenient approach to protecting communications on a computer network. Through secure authentication and encryption technologies, SSH supports secure remote logins, secure remote command execution, secure file transfers, access control, TCP/IP port forwarding, and other important features.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

SSH is a simple idea but it has many parts, some of them complex. This chapter is designed to get you started with SSH quickly. We cover the basics of SSH's most immediately useful features:

Logging into a remote computer over a secure connection
Transferring files between computers over a secure connection

We also introduce authentication with cryptographic keys, a more secure alternative to ordinary passwords. Advanced uses of client programs, such as multiple keys, client configuration files, and TCP port forwarding, are covered in later chapters. Our examples in this chapter work with OpenSSH and Tectia on Linux and other Unix-inspired operating systems.

Suppose you're out of town on a business trip and want to access your files, which sit on a Unix machine belonging to your ISP, shell.isp.com. A friend at a nearby university agrees to let you log into her Linux account on the machine local.university.edu, and then remotely log into yours. For the remote login you could use the telnet program, but as we've seen, this connection between the machines is insecure. (No doubt some subversive college student would grab your password and turn your account into a renegade web server for pirated software and death metal MP3s.) Fortunately, both your friend's machine and your ISP's have an SSH product installed.

In the example running through the chapter, we represent the shell prompt of the local machine, local.university.edu, as a dollar sign ($) and the prompt on shell.isp.com as shell.isp.com>.

Suppose your remote username on shell.isp.com is pat. To connect to your remote account from your friend's account on local.university.edu, you type:

    $ ssh -l pat shell.isp.com

    pat's password: ******

    Last login: Mon Aug 16 19:32:51 2004 from quondam.nefertiti.org

    You have new mail.

    shell.isp.com>

This leads to the situation shown in Figure 2-1. The ssh command runs a client that contacts the SSH server on shell.isp.com

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Suppose you're out of town on a business trip and want to access your files, which sit on a Unix machine belonging to your ISP, shell.isp.com. A friend at a nearby university agrees to let you log into her Linux account on the machine local.university.edu, and then remotely log into yours. For the remote login you could use the telnet program, but as we've seen, this connection between the machines is insecure. (No doubt some subversive college student would grab your password and turn your account into a renegade web server for pirated software and death metal MP3s.) Fortunately, both your friend's machine and your ISP's have an SSH product installed.

In the example running through the chapter, we represent the shell prompt of the local machine, local.university.edu, as a dollar sign ($) and the prompt on shell.isp.com as shell.isp.com>.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Suppose your remote username on shell.isp.com is pat. To connect to your remote account from your friend's account on local.university.edu, you type:

    $ ssh -l pat shell.isp.com

    pat's password: ******

    Last login: Mon Aug 16 19:32:51 2004 from quondam.nefertiti.org

    You have new mail.

    shell.isp.com>

This leads to the situation shown in Figure 2-1. The ssh command runs a client that contacts the SSH server on shell.isp.com over the Internet, asking to be logged into the remote account with username pat. You can also provide user@host syntax instead of the -l option to accomplish the same thing:

    $ ssh pat@shell.isp.com

Figure 2-1: Our example scenario

On first contact, SSH establishes a secure channel between the client and the server so that all transmissions between them are encrypted. The client then prompts for your password, which it supplies to the server over the secure channel. The server authenticates you by checking that the password is correct and permits the login. All subsequent client/server exchanges are protected by that secure channel, including everything you type into the SSH application and everything it displays to you from shell.isp.com.

It's important to remember that the secure channel exists only between the SSH client and server machines. After logging into shell.isp.com via ssh, if you then telnet or ftp to a third machine, insecure.isp.com, the connection between shell.isp.com and insecure.isp.com is not secure. However, you can run another ssh client from shell.isp.com to insecure.isp.com, creating another secure channel, which keeps the chain of connections secure.

We've covered only the simplest use of ssh. Chapter 7 goes into far greater depth about its many features and options.

Continuing the story, suppose that while browsing your files, you encounter a PDF file you'd like to print. In order to send the file to a local printer at the university, you must first transfer the file to

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

The preceding example session provided a quick introduction to the most often-used client programs--ssh and scp--in a format to follow while sitting at your computer. Now that you have the basics, let's continue the example but include situations and complications glossed over the first time. These include the "known hosts" security feature and the SSH escape character.

If you're following at the computer as you read, your SSH clients might behave unexpectedly or differently from ours. As you will see throughout the book, SSH implementations are highly customizable, by both yourself and the system administrator, on either side of the secure connection. Although this chapter describes common behaviors of SSH programs based on their installation defaults, your system might be set up differently.

If commands don't work as you expect, try adding the -v ("verbose") command-line option, for example:

    $ ssh -v shell.isp.com

This causes the client to print lots of information about its progress, often revealing the source of the discrepancy.

The first time an SSH client encounters a new remote machine, it may report that it's never seen the machine before, printing a message like the following:

    $ ssh -l pat shell.isp.com

    The authenticity of host 'shell.isp.com (192.168.0.2)' can't be established.

    RSA key fingerprint is 77:a5:69:81:9b:eb:40:76:7b:13:04:a9:6c:f4:9c:5d.

    Are you sure you want to continue connecting (yes/no)?

Assuming you respond yes (the most common response), the client continues:

    Warning: Permanently added 'shell.isp.com,192.168.0.2' (RSA) to the list of known hosts

               .

This message appears only the first time you contact a particular remote host. The message is a security feature related to SSH's concept of known hosts.

Suppose an adversary wants to obtain your password. He knows you are using SSH, and so he can't monitor your connection by eavesdropping on the network. Instead, he subverts the naming service used by your local host so that the name of your intended remote host,

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

In our running example, the user pat is authenticated by the SSH server via login password. Passwords, however, have serious drawbacks:

In order for a password to be secure, it should be long and random, but such passwords are hard to memorize.
A password sent across the network, even protected by an SSH secure channel, can be captured when it arrives on the remote host if that host has been compromised.
Most operating systems support only a single password per account. For shared accounts (e.g., a superuser account), this presents difficulties:
- Password changes are inconvenient because the new password must be communicated to all people with access to the account.
- Tracking usage of the account becomes difficult because the operating system doesn't distinguish between the different users of the account.

To address these problems, SSH supports public-key authentication: instead of relying on the password scheme of the host operating system, SSH may use cryptographic keys . [3.2.2] Keys are more secure than passwords in general and address all the weaknesses mentioned earlier.

A key is a digital identity. It's a unique string of binary data that means "This is me, honestly, I swear." And with a little cryptographic magic, your SSH client can prove to a server that its key is genuine, and you are really you.

An SSH identity uses a pair of keys, one private and one public. The private key is a closely guarded secret only you have. Your SSH clients use it to prove your identity to servers. The public key is, like the name says, public. You place it freely into your accounts on SSH server machines. During authentication, the SSH client and server have a little conversation about your private and public key. If they match (according to a cryptographic test), your identity is proven, and authentication succeeds.

The following sequence demonstrates the conversation between client and server. [3.4.2.4] (It occurs behind the scenes, so you don't need to memorize it or anything; we just thought you might be interested.)

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Each time you run ssh or scp with public-key authentication, you have to retype your passphrase. The first few times you might not mind, but eventually this retyping gets annoying. Wouldn't it be nicer to identify yourself just once and have ssh and scp remember your identity until further notice (for example, until you log out), not prompting for your passphrase? In fact, this is just what an SSH agent does for you.

An agent is a program that keeps private keys in memory and provides authentication services to SSH clients. If you preload an agent with private keys at the beginning of a login session, your SSH clients won't prompt for passphrases. Instead, they communicate with the agent as needed. The effects of the agent last until you terminate the agent, usually just before logging out. The agent program for both OpenSSH and Tectia is called ssh-agent.

Generally, you run a single ssh-agent in your local login session, before running any SSH clients. You can run the agent by hand, but people usually edit their login files (for example, ~/.login or ~/.xsession) to run the agent automatically. SSH clients communicate with the agent via a local socket or named pipe whose filename is stored in an environment variable, so all clients (and all other processes) within your login session have access to the agent. [6.3.4] To try the agent, type:

    $ ssh-agent $SHELL

where SHELL is the environment variable containing the name of your login shell. Alternatively, you could supply the name of any other shell, such as sh, bash, csh, tcsh, or ksh. The agent runs and then invokes the given shell as a child process. The visual effect is simply that another shell prompt appears, but this shell has access to the agent.

Once the agent is running, it's time to load private keys into it using the ssh-add program. By default, ssh-add loads the key from your default identity file:

    $ ssh-add

    Enter passphrase for /home/you/.ssh/id_dsa:

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

One of the most frequently asked questions about SSH is: "How can I connect to a remote machine without having to type a password or passphrase?" As you've seen, an SSH agent can make this possible, but there are other methods as well, each with different trade-offs. Here we list the available methods with pointers to the sections discussing each one.

To use SSH clients for interactive sessions without a password or passphrase, you have several options:

Public-key authentication with an agent [2.5] [6.3]
Hostbased authentication [3.4.3.6]
Kerberos authentication [11.4]

Another way to achieve passwordless logins is to use an unencrypted private key with no passphrase. Although this technique can be appropriate for automation purposes, never do this for interactive use. Instead, use the SSH agent, which provides the same benefits with much greater security. Don't use unencrypted keys for interactive SSH!

On the other hand, noninteractive, unattended programs such as cron jobs or batch scripts may also benefit from not having a password or passphrase. In this case, the different techniques raise some complex issues, and we discuss their relative merits and security issues later. [11.1]

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Several other clients are included in addition to ssh and scp :

sftp , an ftp-like client
slogin, a link to ssh, analogous to the rlogin program

The scp command is convenient and useful, but many users are already familiar with FTP (File Transfer Protocol), a more widely used technique for transferring files on the Internet. sftp is a separate file-transfer tool layered on top of SSH. The OpenSSH sftp can run over either SSH-1 or SSH-2, whereas the Tectia version runs over SSH-2 only due to implementation details.

sftp has several advantages:

It is secure, using an SSH-protected channel for data transfer.
Multiple commands for file copying and manipulation can be invoked within a single sftp session, whereas scp opens a new session each time it is invoked.
It can be scripted using the familiar ftp command language.
In other software applications that run an FTP client in the background, you can try substituting sftp, thus securing the file transfers of that application. You might need to run an agent, however, since programs that normally invoke ftp might not recognize the sftp passphrase prompt, or they might expect you to have suppressed FTP's password prompt (using a .netrc file, for example).

Anyone familiar with FTP will feel right at home with sftp, but sftp has some additional features of note:

Command-line editing using GNU Emacs-like keystrokes (Control-B for backward character, Control-E for end of line, and so forth).
Wildcards for matching filenames. OpenSSH uses the same "globbing" syntax that is supported by most common shells, while Tectia uses an extended regular expression syntax described in Appendix B.
Several useful command-line options:

-b filename (OpenSSH)
-B filename (Tectia): Read commands from the given file instead of the terminal.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

From the user's point of view, SSH consists of several client programs and some configuration files. The most commonly used clients are ssh for remote login, and scp and sftp for file transfer. Authentication to the remote host can be accomplished using existing login passwords or with public-key cryptographic techniques. Passwords are more immediately and easily used, but public-key authentication is more flexible and secure. The ssh-keygen, ssh-agent, and ssh-add programs generate and manage SSH keys.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

SSH secures your data while it passes over a network, but how exactly does it work? In this chapter, we move firmly onto technical ground and explain the inner workings of SSH. Let's roll up our sleeves and dive into the bits and bytes.

This chapter is written for system administrators, network administrators, and security professionals. Our goal is to teach you enough about SSH to make an intelligent, technically sound decision about using it. Mostly, we deal with SSH-2 as the current and recommended SSH protocol; our treatment of the old and deprecated SSH-1 is limited to a summary of its differences and limitations. When we refer to "the SSH protocol," we mean SSH-2.

Of course, the ultimate references on SSH are the protocol standards and the source code of an implementation. We don't completely analyze the protocols or recapitulate every step taken by the software. Rather, we summarize them to provide a solid, technical overview of their operation. If you need more specifics, you should refer to the standards documents. The SSH Version 2 protocol is in draft status on the IETF standards track; it is available at:

The older SSH-1 protocol is called Version 1.5 and is documented in a file named RFC included in the source package of the now-obsolete SSH1.

The major features and guarantees of the SSH protocol are:

Privacy of your data, via strong encryption
Integrity of communications, guaranteeing they haven't been altered
Authentication, i.e., proof of identity of senders and receivers
Authorization, i.e., access control to accounts
Forwarding or tunneling to encrypt other TCP/IP-based sessions

Privacy means protecting data from disclosure. Typical computer networks don't guarantee privacy ; anyone with access to the network hardware, or to hosts connected to the network, may be able to read (or sniff) all data passing over the network. Although modern switched networks have reduced this problem in local area networks, it is still a serious issue; passwords are easily stolen by such sniffing attacks.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

The major features and guarantees of the SSH protocol are:

Privacy of your data, via strong encryption
Integrity of communications, guaranteeing they haven't been altered
Authentication, i.e., proof of identity of senders and receivers
Authorization, i.e., access control to accounts
Forwarding or tunneling to encrypt other TCP/IP-based sessions

Privacy means protecting data from disclosure. Typical computer networks don't guarantee privacy ; anyone with access to the network hardware, or to hosts connected to the network, may be able to read (or sniff) all data passing over the network. Although modern switched networks have reduced this problem in local area networks, it is still a serious issue; passwords are easily stolen by such sniffing attacks.

SSH provides privacy by encrypting data that passes over the network. This end-to-end encryption is based on random keys that are securely negotiated for that session and then destroyed when the session is over. SSH supports a variety of encryption algorithms for session data, including such standard ciphers as AES, ARCFOUR, Blowfish, Twofish, IDEA, DES, and triple-DES (3DES).

Integrity means assuring that data transmitted from one end of a network connection arrives unaltered on the other end. The underlying transport of SSH, TCP/IP, does have integrity checking to detect alteration due to network problems (electrical noise, lost packets due to excessive traffic, etc.). Nevertheless, these methods are ineffective against deliberate tampering and can be fooled by a clever attacker. Even though SSH encrypts the data stream so that an attacker can't easily change selected parts to achieve a specific result, TCP/IP's integrity checking alone can't prevent, say, an attacker's deliberate injection of garbage into your session.

A more complex example is a replay attack. Imagine that Attila the Attacker is monitoring your SSH session and also simultaneously watching over your shoulder (either physically, or by monitoring your keystrokes at your terminal). In the course of your work, Attila sees you type the command

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

We've covered the basic properties of SSH. Now we focus on cryptography, introducing important terms and ideas regarding the technology in general. There are many good references on cryptographic theory and practice, and we make no attempt here to be comprehensive. (For more detailed information, check out Bruce Schneier's excellent book, Applied Cryptography, published by John Wiley & Sons.) We introduce encryption and decryption, plaintext and ciphertext, keys, secret-key and public-key cryptography, and hash functions, both in general and as they apply to SSH.

Encryption is the process of scrambling data so that it can't be read by unauthorized parties. An encryption algorithm (or cipher) is a particular method of performing the scrambling; examples of currently popular encryption algorithms are RSA, AES, DSA, and Blowfish. The original, readable data is called the plaintext , or data "in the clear," while the encrypted version is called the corresponding ciphertext.

The goal of an encryption algorithm is to convert plaintext to ciphertext. To do this, you pass two inputs to the encryption algorithm: the plaintext itself, and a key, a string that is typically a secret known only to you. From these inputs, the algorithm produces the ciphertext. An encryption algorithm is considered secure if it is infeasible for anyone to read (or decrypt) the encrypted ciphertext without the key. An attempt to decrypt data without its key is called cryptanalysis.

It's important to understand the word "infeasible" in the previous paragraph. Today's most popular and secure ciphers are vulnerable to brute-force attacks: if you try every possible key, you eventually succeed in decryption. However, when the number of possible keys is large, a brute-force search requires a great deal of time and computing power. Based on the state of the art in computer hardware and algorithms, it is possible to pick sufficiently large key sizes to render brute-force key-search unreasonable for your adversary. What counts as infeasible, though, depending on how valuable the data is, how long it must stay secure, and how motivated and well-funded your adversary is. Keeping something secret from your rival startup for a few days is one thing; keeping it secret from a major world government for 10 years is quite another.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

SSH has about a dozen distinct, interacting components that produce the features we've covered. [3.1] Figure 3-1 illustrates the major components and their relationships to one another.

Figure 3-1: SSH architecture

By "component" we don't necessarily mean "program": SSH also has keys, sessions, and other fun things. In this section we provide a brief overview of all the components, so you can begin to get the big picture of SSH:

Server

A program that allows incoming SSH connections to a machine, handling authentication, authorization, and so forth. In most Unix SSH implementations, the server is sshd.

Client

A program that connects to SSH servers and makes requests, such as "log me in" or "copy this file." In OpenSSH and Tectia, the major clients are ssh, scp, and sftp.

Session

An ongoing connection between a client and a server. It begins after the client successfully authenticates to a server and ends when the connection terminates. Sessions may be interactive or batch.

Key

A relatively small amount of data, generally from tens of to 1,000 or 2,000 bits, used as a parameter to cryptographic algorithms such as encryption or message authentication. The key binds the algorithm operation in some way to the key holder: in encryption, it ensures that only someone else holding that key (or a related one) can decrypt the message; in authentication, it allows you to verify later that the key holder actually signed the message. There are two kinds of keys : symmetric or secret key, and asymmetric or public key. [3.2.2] An asymmetric key has two parts: the public and private components. SSH has several types of keys, as summarized in Table 3-1.

Table 3-1: Keys, keys, keys
Name	Lifetime	Created by	Type	Purpose
User key	Persistent	User	Public	Identify a user to the server

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

The SSH protocol has two major, incompatible versions, called Version 1 and Version 2. [1.5] We refer to these as SSH-1 and SSH-2. The SSH-1 protocol is now a relic; it is less flexible than SSH-2, has unfixable security weaknesses, and has been deprecated for years. Its implementations see no real development aside from bug fixes, and the default protocol for most SSH software has been SSH-2 for some time now. In this chapter, as we describe "the SSH protocol," we are talking about SSH-2. We limit our treatment of SSH-1 to a summary of its design, its differences with SSH-2, and its weaknesses.

The SSH protocol is actually divided into four major pieces, formally described as four separate protocols in different IETF documents, and in principle independent of one another. In practice, they are layered together to provide the set of services most users associate with SSH as a whole. These are:

SSH Transport Layer Protocol (SSH-TRANS)
SSH Authentication Protocol (SSH-AUTH)
SSH Connection Protocol (SSH-CONN)
SSH File Transfer Protocol (SSH-SFTP)

There are other documents that describe other aspects of, or extensions to, the protocols, but the preceding ones represent the core of SSH. As of this writing, these documents are still "Internet-Drafts," but after much effort by the IETF SECSH working group, they have been submitted to the IESG for consideration as proposed standards and may soon be published as Internet RFCs.

Figure 3-2 outlines the division of labor between these protocols, and how they relate to each other, application programs, and the network. Elements in italics are protocol extensions defined in separate Internet-Draft documents, which have attained fairly widespread use.

Figure 3-2: SSH-2 protocol family

SSH is designed to be modular and extensible. All of the core protocols define abstract services they provide and requirements they must meet, but allow multiple mechanisms for doing so, as well as a way of easily adding new mechanisms. All the critical parameters of an SSH connection are negotiable, including the methods and algorithms used in:

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

With a solid understanding of the current SSH protocol behind us, we now quickly summarize SSH-1 in terms of its differences, weaknesses, and shortcomings in comparison with SSH-2:

Non-modular: SSH-1 is defined as a single monolithic protocol, rather than the modular approach taken with the SSH-2 suite.
Less negotiation: SSH-1 has more fixed parameters; in fact, only the bulk cipher is negotiated. The integrity algorithm, host key type, key-exchange methods, etc., are all fixed.
Ad hoc naming: SSH-1 lacks the well-defined naming syntax for SSH-2 entities which allows for smooth, implementation-specific extensions.
Single authentication: SSH-1's user authentication process allows only one method to succeed; the server can't require multiple methods.
RhostsRSA authentication: SSH-1's RhostsRSA authentication, analogous to hostbased, is in principle limited to using a network address as the client host identifier. This limits its usefulness in the face of network issues such as NAT, proxying, mobile clients, etc.
Less flexible remote forwarding: SSH-1 remote forwarding specifies only a port, not a full socket, so can't be bound to different addresses on multihomed servers, and the gatewayhosts option must be set globally for all remote forwardings rather than per port.
Weaker integrity checking: SSH-1 uses a weak integrity check, the CRC-32 algorithm. CRC-32 is not cryptographically strong, and its weakness is the basis of the Futoransky/Kargieman "insertion attack"; see http://seclists.org/lists/firewall-wizards/1998/Jun/0095.html.
Server keys: The fixed key exchange of SSH-1 employs an extra asymmetric key called the server key, not to be confused with a host key. [3.6.1] The server key is an ephemeral public/private key pair, regenerated once per hour and used to provide forward secrecy for the session key. Forward secrecy means that even if long-term secrets such as user or host private keys are compromised later, these can't be used to decrypt SSH sessions recorded earlier; the use of an extra key which is never written to disk assures this. The Diffie-Hellman algorithm which is the basis of all the SSH-2 key exchanges provides forward secrecy by itself, and so an extra "server key" is not needed.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

There are many differences among the current crop of SSH implementations: features that aren't dictated by the protocols, but are simply inclusions or omissions by the software authors. Here we discuss a few implementation-dependent features of various products:

Host keys
Authorization in hostbased authentication
SSH-1 backward compatibility
Randomness
Privilege separation

SSH host keys are long-term asymmetric keys that distinguish and identify hosts running SSH, or instances of the SSH server, depending on the SSH implementation. This happens in two places in the SSH protocol:

Server authentication verifying the server host's identity to connecting clients. This process occurs for every SSH connection.
Authentication of a client host to the server; used only during RhostsRSA or hostbased user authentication.

Unfortunately, the term "host key" is confusing. It implies that only one such key may belong to a given host. This is true for client authentication but not for server authentication, because multiple SSH servers may run on a single machine, each with a different identifying key. This so-called "host key" actually identifies a running instance of the SSH server program, not a machine.

OpenSSH maintains a single database serving both server authentication and client authentication. It is the union of the system's known_hosts file (/etc/ssh/ssh_known_hosts), together with the user's ~/.ssh/known_hosts file on either the source machine (for server authentication) or the target machine (for client authentication). The database maps a hostname or address to a set of keys acceptable for authenticating a host with that name or address. One name may be associated with multiple keys (more on this shortly).

Tectia, on the other hand, maintains two separate maps for these purposes:

The hostkeys map for authentication of the server host by the client
The knownhosts

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

The first thing to understand about SSH and file transfers is this: SSH doesn't really do file transfers. That is, the core SSH protocol as implemented by a program such as ssh (SSH-TRANS, SSH-AUTH, and SSH-CONN) has no file-transfer capability at all. Following good modular design, file transfer is simply one of many services that might be run over an SSH connection channel. In fact, the file-transfer programs bundled with most Unix-based SSH products, scp and sftp, typically don't even implement SSH in themselves; they simply run ssh in a subprocess to connect to the remote host, start the remote file-transfer agent, and talk to it.

Historically, the first file-transfer mechanism implemented with SSH was the program scp, included with the original SSH1 product. scp is simply an "ssh-ification" of the venerable Unix rcp program; just as rcp runs the rsh program to contact the remote host, scp runs ssh instead. If existing rsh software had supported a switch to select a different program than the default rsh (like scp -S), scp might never have been written; there would have been no need.

The rcp protocol used by scp is very limited. In a single session it can only transfer a set of whole files in one direction; there's no directory browsing, partial transfer, resumption of interrupted transfers, multiple transfer directions—in other words, it's nothing like FTP. When SSH Communications Security (SCS) defined the first version of the SSH-2 protocol and delivered its implementation, it wanted to include a much better file-transfer utility. To that end, it defined a completely new remote-filing protocol, designed to work easily over a single, reliable, secure, duplex byte-stream connection—that is, over SSH. The utility was called sftp. As with SSH-2, this initially undocumented and proprietary protocol was eventually moved onto the standards track of the IETF SECSH working group, as the "SSH File Transfer Protocol" (SSH-SFTP). Once that happened it began to appear in other implementations as well—for example, the

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

We now summarize each of the algorithms we have mentioned. Don't treat these summaries as complete analyses, however. You can't necessarily extrapolate from characteristics of individual algorithms (positive or negative) to whole systems without considering the other parts. Security is complicated that way.

Section 3.8.1.1: 3.8.1.1 Rivest-Shamir-Adleman (RSA)

The Rivest-Shamir-Adleman (RSA) public-key algorithm is the most widely used asymmetric cipher. It derives its security from the difficulty of factoring large integers

Figure 3-3: scp operation

that are the product of two large primes of roughly equal size. Factoring is widely believed to be intractable (i.e., infeasible, admitting no efficient, polynomial-time solution), although this isn't proven. RSA can be used for both encryption and signatures.

Until September 2000, RSA was claimed to be patented in the U.S. states by Public Key Partners, Inc., a company in which RSA Security, Inc. is a partner. (The algorithm is now in the public domain.) While the patent was in force, PKP claimed that it controlled the use of the RSA algorithm in the U.S., and that the use of unauthorized implementations was illegal. Until the mid-1990s, RSA Security provided a freely available reference implementation, RSAref, with a license allowing educational and broad commercial use (as long as the software itself was not sold for profit). Since RSA is now in the public domain, RSAref has disappeared.

The SSH-1 protocol specified use of RSA explicitly. SSH-2 can use multiple public-key algorithms, but originally defined only DSA. [3.8.1.2] The SECSH working group added the RSA algorithm to SSH-2 shortly after the patent expired.

Section 3.8.1.2: 3.8.1.2 Digital Signature Algorithm (DSA)

The Digital Signature Algorithm (DSA) was developed by the U.S. National Security Agency (NSA), and promulgated by the U.S. National Institute of Standards and Technology (NIST) as part of the Digital Signature Standard (DSS). The DSS was issued as a Federal Information Processing Standard, FIPS-186, in May 1994. It is a public-key algorithm, based on the Schnorr and ElGamal methods, and relies on the difficulty of computing discrete logarithms in a finite field. It is designed as a signature-only scheme that can't be used for encryption, although a fully general implementation may easily perform both RSA and ElGamal encryption.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Like any security tool, SSH has particular threats against which it is effective and others that it doesn't address. We'll discuss the former first.

An eavesdropper is a network snooper who reads network traffic without affecting it in any way. SSH's encryption prevents eavesdropping . The contents of an SSH session, even if intercepted, can't be decrypted by a snooper.

If an attacker subverts your naming service (DNS, NIS, etc.), network-related programs may be coerced to connect to the wrong machine. Similarly, an attacker can impersonate a host by stealing use of its IP address(es). In either case, you're in trouble: your client program can connect to a false server that steals your password when you supply it. SSH guards against this attack by cryptographically verifying the server host identity. When setting up a session, the SSH client validates the server's host key against a local list associating server names and addresses with their keys. If the supplied host key doesn't match the one on the list, SSH complains. This feature may be disabled in less security-conscious settings if the warning messages get annoying. [7.4.3.1]

The SSH-2 protocol allows for including PKI certificates along with keys. In the future, we hope that implementation of this feature in SSH products along with more common deployment of PKI will ease the burden of key management and reduce the need for this particular security trade-off.

An "active attacker"--one who not only can listen to network traffic, but also can inject his own—can hijack a TCP connection, literally stealing it away from one of its legitimate endpoints. This is obviously disastrous: no matter how good your authentication method is, the attacker can simply wait until you've logged in, then steal your connection and insert his own nefarious commands into your session. SSH can't prevent hijacking, since this is a weakness in TCP, which operates below SSH. However, SSH renders it ineffective (except as a denial-of-service attack). SSH's integrity checking detects if a session is modified in transit, and shuts down the connection immediately without using any of the corrupted data.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

SSH isn't a total security solution. We'll now present some examples of attacks that SSH wasn't designed to prevent.

SSH dramatically improves password security by encrypting your password as it passes over the network. Nevertheless, a password is still a weak form of authentication, and you must take care with it. You must choose a good password, memorable to you but not obvious to anyone else, and not easily guessable. You must also avoid having your password stolen, since possession alone is sufficient to grant access to your account. So, watch out: the guy at the next terminal might be surreptitiously "shoulder surfing" (watching as you type). That computer kiosk you're about to use may have been tricked up to log all keystrokes to Cracker Central Command. And the nice-sounding fellow who calls from Corporate IT and asks for your password to "fix your account" might not be who he claims.

Consider public-key authentication instead, since it is two-factor : a stolen passphrase is useless without the private-key file, so an attacker needs to steal both. Of course, the SSH client on the computer you're borrowing can be rigged to squirrel away your key after you blithely supply your passphrase to decrypt it. If you're that worried, you shouldn't use strange computers. In the future, one hopes, cryptographic smartcards and readers will be ubiquitous and supported by SSH so that you can carry your keys conveniently and use them in other computers without fear of disclosure.

If you must use password authentication because of its convenience, consider using a one-time password scheme such as S/Key to reduce risk. [5.4.5]

SSH operates on top of TCP, so it is vulnerable to some attacks against weaknesses in TCP and IP. The privacy, integrity, and authentication guarantees of SSH limit this vulnerability to denial-of-service attacks.

TCP/IP is resistant to network problems such as congestion and link failure. If the enemy blows up a router, IP can route around it. It wasn't designed to resist an adversary injecting bogus packets into the network, however. The origin of TCP or IP control messages isn't authenticated. As a result, TCP/IP has a number of inherent exploitable weaknesses, such as:

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

We can hear the chorus now..."What? I'm using SSH to improve security; what do you mean it causes threats!?" Calm down, we're just being complete here. There are no new threats that SSH causes per se, but there are existing issues that it perhaps exacerbates.

To employ SSH, your users must be able to make outbound TCP connections: and really, that gives them the power to do just about anything. Think you can restrict which Internet hosts they can contact? Think again: all they need is a proxy on a host they can reach to redirect their traffic. Think they can only use TCP because that's all the firewall lets through? Not at all: there are freely available tools that can operate a full-blown VPN over a TCP (e.g., OpenVPN). Think you're safe from inbound attacks because you allow only outbound connections? Don't be naive: that "outbound" connection is a two-way street once established and can be connected to anything at all.

The only things that keep people from violating your security policy with this access, aside from respecting the policy itself, are ignorance and inconvenience. Your users might not know how to play any of the preceding tricks, or it might be too much trouble if they do. SSH, however, makes some of these things very easy: tunneling outbound connections to "forbidden" TCP ports, reverse forwarding to tunnel back through your firewall and circumvent it, etc...and everything nicely encrypted so that you can't see what's happening!

The important lesson here is not that SSH is dangerous, but that truly limiting network access is a very difficult proposition: usually impossible, in fact, with any kind of reasonable effort (and if you want to get any other work done). When there are convenient tools like SSH lying around tempting people to get around annoying limitations, you can no longer rely on ignorance and inconvenience to enforce your security policy. Ultimately, you must gain the trust and cooperation of your users to have an effective security policy.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

The SSH protocol uses openly published, strong cryptographic tools to provide network connections with privacy, integrity, and mutual authentication. The original SSH-1 protocol (a.k.a. SSH 1.5) was wildly popular, despite being somewhat ad hoc: essentially a documentation of SSH1's program behavior. It had a number of shortcomings and flaws, of which the weak integrity check and resulting Futoransky/Kargieman insertion attack is perhaps the most egregious example. The current protocol version, SSH-2, is far superior, but was slow to take off due to the dearth of implementations, licensing restrictions, and the continued availability of the free SSH1 software for many commercial purposes. Thankfully, the tide has now turned, due primarily to the gargantuan and mostly unpaid efforts of the OpenSSH team in bringing forth a free implementation of the SSH-2 protocol.

SSH counters many network-related security threats, but not all. In particular, it is vulnerable to denial-of-service attacks based on weaknesses in TCP/IP, its underlying transport...though now that IPSec is widespread, these weaknesses can be addressed if need be. SSH also doesn't address attacks such as traffic analysis and covert channels, which may be of concern depending on the environment.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Now that you know what SSH is and how it works, where do you get it and how do you install it? This chapter surveys several popular and robust implementations of SSH and explains how to obtain, compile, and install them:

OpenSSH: A free implementation, originally part of OpenBSD, and available for many other operating systems including Linux, Solaris, Mac OS X, and Windows.
Tectia: A suite of commercial products from SSH Communications Security Corp., that run on a variety of platforms including Linux, Solaris, HP-UX, AIX, and Windows. Formerly known as SSH2 and SSH Secure Shell.

Non-Unix implementations of SSH are covered in Chapters 13,14,15,16,17,-18.

The first question to consider when installing any implementation of SSH is whether to use a binary or source distribution.

Binary distributions are already configured and compiled, and are therefore easy to use. They are available for popular SSH implementations like OpenSSH and Tectia on a variety of common platforms. The packaging technology and installation instructions vary according to the target system—consult the documentation provided by your vendor for details. For example, on Linux systems, binary distributions are usually shipped as RPM packages, and can be installed using a single command like:

    $ rpm -Uhv openssh-3.9p1-1.i386.rpm

Installation on Unix systems typically requires root access, to install files in system directories, and to update the databases that keep track of installed packages.

Binary distributions are often cryptographically signed, to ensure that no one has tampered with the files. Signatures can be provided as separate files, or (depending on the package format) embedded within the binary distribution files, and the technique to verify the signature depends on how the files were signed. For example, on RPM-based Linux systems, first import the vendor's public key, which is distributed by keyservers or the vendor's web site:

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

The first question to consider when installing any implementation of SSH is whether to use a binary or source distribution.

Binary distributions are already configured and compiled, and are therefore easy to use. They are available for popular SSH implementations like OpenSSH and Tectia on a variety of common platforms. The packaging technology and installation instructions vary according to the target system—consult the documentation provided by your vendor for details. For example, on Linux systems, binary distributions are usually shipped as RPM packages, and can be installed using a single command like:

    $ rpm -Uhv openssh-3.9p1-1.i386.rpm

Installation on Unix systems typically requires root access, to install files in system directories, and to update the databases that keep track of installed packages.

Binary distributions are often cryptographically signed, to ensure that no one has tampered with the files. Signatures can be provided as separate files, or (depending on the package format) embedded within the binary distribution files, and the technique to verify the signature depends on how the files were signed. For example, on RPM-based Linux systems, first import the vendor's public key, which is distributed by keyservers or the vendor's web site:

    $ rpm --import http://www.redhat.com/security/db42a60e.txt

Then use the public key to check the signature:

    $ rpm --checksig -v openssh-3.9p1-1.i386.rpm

Always check the signatures of binary distributions before installing. Imagine the havoc that could be caused if a maliciously hacked version of SSH was unwittingly used on your system.

Source distributions require more work to install, but allow many more configuration options. They can also be used on platforms for which no binary distributions are available.

To install from sources, perform the following general steps; we'll cover specific details for OpenSSH and Tectia in subsequent sections.

Some SSH implementations rely on other software packages; these must be obtained and installed first. The precise requirements sometimes depend on the configuration options chosen: e.g., support for hardware authentication devices (smartcards) might require special libraries.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

OpenSSH is a free implementation of the SSH-1 and SSH-2 protocols, obtained from the OpenSSH web site:

OpenSSH is a very complete implementation and includes:

Client programs for remote logins, remote command execution, and secure file copying across a network, all with many runtime options
A highly configurable SSH server
Command-line interfaces for all programs, facilitating scripting with standard Unix tools (shells, Perl, etc.)
Numerous, selectable encryption algorithms and authentication mechanisms
An SSH agent, which caches keys for ease of use
Support for SOCKS proxies
Support for TCP port forwarding and X11 forwarding
History and logging features to aid in debugging
Example configuration files /etc/ssh/ssh_config and /etc/ssh/sshd_config

Since it is developed by the OpenBSD Project, the main version of OpenSSH is specifically for the OpenBSD Unix operating system, and is in fact included in the base OpenBSD installation. As a separate but related effort, another team maintains a "portable" version that compiles on a variety of Unix flavors and tracks the main development effort. The supported platforms include Linux, Solaris AIX, IRIX, HP/UX, FreeBSD, NetBSD, and Windows via the Cygwin compatibility library. The portable version carries a "p" suffix. For example, 3.9p1 is the first release of the portable version of OpenSSH 3.9.

OpenSSH depends on two other software packages: OpenSSL and zlib. OpenSSL is a cryptographic library available at http://www.openssl.org/; all the cryptography used in OpenSSH is pulled from OpenSSL. zlib is a library of data-compression routines, available at http://www.gzip.org/zlib/. These packages must be on your system before you build OpenSSH.

Distributions are packaged in gzipped tar format and are extracted with the tar command in the usual way. [4.1.4] The results are stored in a directory with a name like openssh-3.9p1.

Section 4.2.2.1: 4.2.2.1 Verifying with GnuPG

Along with each OpenSSH distribution is a GnuPG (Gnu Privacy Guard) signature. The file

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Tectia is a commercial implementation of the SSH-2 protocol, with some limited support for compatibility with the older (and deprecated) SSH-1 protocol. Binary distributions can be downloaded for evaluation (with a limited license that is valid for 30 days) from the SSH Communications Security web site:

http://www.ssh.com/

Fully licensed Tectia products, with distribution media and documentation, can be purchased from the same web site.

Tectia is designed for deployment across large corporate networks, and offers tremendous flexibility, power, and reliability. The products include:

Client programs for remote logins, remote command execution, and secure file copying across a network, all with many runtime options
A highly configurable SSH server
Command-line interfaces for all programs, facilitating scripting with standard Unix tools (shells, Perl, etc.)
Numerous, selectable encryption algorithms and authentication mechanisms
An SSH agent, which caches keys for ease of use
Support for SOCKS proxies
Support for TCP port forwarding and X11 forwarding
History and logging features to aid in debugging
FIPS 140-2 certification for U.S. government applications

Tectia is fully self contained, and requires no other packages if installed on one of the supported platforms. Some configuration options require you to install other software packages, however; these are discussed below.

Binary distributions are packaged according to the target platform, and can be installed according to the documentation provided for each system.

Source distributions are packaged in gzipped tar format. For Version 4.1 and earlier, the sources are included with the distribution media for the Tectia Server for Unix product. Starting with Version 4.2, the sources are available only for commercial licenses and only upon request, via a protected area of the SSH Communications Security web site. No sources are provided for the Windows products.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Table 4-1 provides a reference to the many files and programs installed with SSH.

Table 4-1: Software inventory
Component	OpenSSH	Tectia
Server config	`/etc/ssh/sshd_config`	`/etc/ssh2/sshd2_config`
Global client config	`/etc/ssh/ssh_config`	`/etc/ssh2/ssh2_config`
Host private key	`/etc/ssh/ssh_host_dsa_key`	`/etc/ssh2/hostkey`
Host public key	`/etc/ssh/ssh_host_dsa_key.pub`	`/etc/ssh2/hostkey.pub`
Client host keys	`/etc/ssh/ssh_known_hosts` `~/.ssh/known_hosts`	`/etc/ssh2/hostkeys` `~/.ssh2/hostkeys/*`
Remote host keys	`~/.ssh/known_hosts`	`~/.ssh2/knownhosts/*`
libwrap control files	`/etc/hosts.allow` `/etc/hosts.deny`	`/etc/hosts.allow` `/etc/hosts.deny`
Authorization for login via public key	`~/.ssh/authorized_keys`	`~/.ssh2/authorization`
Authorization for login via trusted host	`/etc/hosts.equiv` `/etc/shosts.equiv` `~/.shosts` `~/.rhosts`	`/etc/hosts.equiv` `/etc/shosts.equiv` `~/.shosts` `~/.rhosts`
Default key pair for public-key authentication	`SSH-2/RSA:` `~/.ssh/id_rsa{.pub}` `SSH-2/DSA:` `~/.ssh/id_dsa{.pub}`	`(No default)`
Random seed	`~/.ssh/prng_seed`	`~/.ssh2/random_seed` `/etc/ssh2/random_seed`
Commands for generating randomness	`/etc/ssh/ssh_prng_cmds`	`-`
Terminal client	`ssh` `slogin link to ssh`	`ssh2`
Secure file copy client	`scp`	`scp2` ^b
Signer program	`ssh-keysign`	`ssh-signer2` ^b
sftp2/scp2 server	`sftp-server`	`sftp-server2` ^b
Authentication agent	`ssh-agent`	`ssh-agent2` ^b
Key generator	`ssh-keygen`	`ssh-keygen2` ^b
Key add/remove	`ssh-add`	`ssh-add2` ^b
Find SSH servers

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

SSH and the r-commands (rsh, rcp, rlogin) can coexist peacefully on the same machine. Since the r-commands are insecure, however, system administrators should replace them by their SSH counterparts (ssh, scp, slogin). This replacement has two parts:

Installing SSH and removing rsh, rcp, and rlogin; requires some user retraining
Modifying other programs or scripts that invoke the r-commands

The r-commands are so similar to their analogous SSH commands, you might be tempted to rename the SSH commands as the r-commands (e.g., rename ssh as rsh, etc.). After all, common commands like these are practically identical in syntax:

    $ rsh -l jones remote.example.com

    $ ssh -l jones remote.example.com



    $ rcp myfile remote.example.com:

    $ scp myfile remote.example.com:

Why not just rename? Well, the two sets of programs are incompatible in some ways. For example, some old versions of rcp use a different syntax for specifying remote filenames.

In the following sections, we discuss some common Unix programs that invoke the r-commands and how to adapt them to use SSH instead.

CVS is a version-control system. It maintains a history of changes to sets of files, and helps coordinate the work of multiple people on the same files. It can use rsh to connect to repositories on remote hosts. For example, when you check in a new version of a file:

    $ cvs commit myfile

if the repository is located on a remote machine, CVS can invoke rsh to access the remote repository. For a more secure solution, CVS can run ssh instead of rsh. Of course, the remote machine must be running an SSH server, and if you use public-key authentication, your remote account must contain your key in the appropriate place.

To make CVS use ssh, simply set the environment variable CVS_RSH to contain the path to your ssh client:

    # Bourne shell family

    # Put in ~/.profile to make permanent.

    CVS_RSH=/usr/bin/ssh

    export CVS_RSH



    # C shell family

    # Put in ~/.login to make permanent.

    setenv CVS_RSH /usr/bin/ssh

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

OpenSSH and Tectia can be tailored in various ways by compile-time configuration with the configure script. We've covered the SSH-specific flags, but remember that other operating-system-specific flags might also apply to your installation, so be sure to read the installation notes supplied with the software.

Once installed, SSH software can replace the insecure r-commands on your Unix system, not only when run directly, but also within other programs that invoke rsh, such as Emacs and Pine.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

After installing an SSH server (sshd), it's time to make informed decisions about your server's operation. Which authentication techniques should be permitted? How many bits should the server key contain? Should idle connections be dropped after a time limit or left connected indefinitely? These and other questions must be considered carefully. sshd has reasonable defaults, but don't accept them blindly. Your server should conform to a carefully planned security policy. Fortunately, sshd is highly configurable, so you can make it do all kinds of interesting tricks.

This chapter covers serverwide configuration, in which a system administrator controls the global runtime behavior of the SSH server. This includes a large, rich set of features, such as TCP/IP settings, encryption, authentication, access control, and error logging. Some features are controlled by modifying a serverwide configuration file, and others by command-line options passed to the server at invocation.

Serverwide configuration is just one of three levels for controlling the behavior of SSH servers. The other two levels are compile-time configuration (Chapter 4), in which the server is compiled with or without certain functionality; and per-account configuration (Chapter 8), in which the server's behavior is modified by end users for their accounts only. We'll discuss the distinction between the three levels in more detail later. [5.2]

This chapter covers only the OpenSSH and Tectia servers, focusing on the Unix implementations (including Unix variants such as Linux and OpenBSD). We've tried to indicate which features are present or absent in each flavor of sshd, but these will certainly change as new versions appear, so read each product's documentation for the latest information.

Ordinarily, an SSH server is invoked when the host computer is booted, and it is left running as a daemon. This works fine for most purposes. Alternatively, you can invoke the server manually. This is helpful when you're debugging a server, experimenting with server options, or running a server as a nonsuperuser. Manual invocation requires a bit more work and forethought but might be the only alternative for some situations.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Ordinarily, an SSH server is invoked when the host computer is booted, and it is left running as a daemon. This works fine for most purposes. Alternatively, you can invoke the server manually. This is helpful when you're debugging a server, experimenting with server options, or running a server as a nonsuperuser. Manual invocation requires a bit more work and forethought but might be the only alternative for some situations.

Most commonly, a computer has just one SSH server running on it. It handles multiple connections by spawning child processes, one per connection. You can run multiple servers if you like: for example, two copies of sshd listening on different TCP ports, or even several versions of sshd at once.

The SSH server is invoked by simply typing its name:

    $ sshd

The server automatically runs in the background, so no ampersand is required at the end of the line.

To invoke the server when the host computer boots, add appropriate lines to an appropriate startup file on your system, such as /etc/rc.local on Linux. For example:

    # Specify the path to sshd.

    SSHD=/usr/local/sbin/sshd

    # If sshd exists and is executable, run it and echo success to the system console.

    if [ -x "$SSHD" ]

    then

      $SSHD && echo 'Starting sshd'

    fi

Both OpenSSH and Tectia come with a startup or boot script (i.e., a System-V-style init control script) found in the appropriate directory for each Unix variant. For Linux, for example, the scripts are /etc/init.d/sshd for OpenSSH and /etc/init.d/sshd2 for Tectia.

Any user can run sshd if several steps are completed beforehand:

Get permission from your system administrator.
Generate a host key.
At first glance, Tectia's filenames might seem rather inconsistent, but actually they follow conventions designed for flexibility and ease of use:
- Most filenames contain a "2" suffix, e.g., sshd2. These filenames distinguish the SSH-2 protocol implementation provided by Tectia from other implementations (e.g., OpenSSH). As a result, you could install SSH-1 protocol programs (not provided by Tectia) with filenames containing a "1" suffix, even in the same directories used by Tectia, without conflicts.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

As mentioned at the beginning of the chapter, the behavior of the server, sshd, may be controlled at three levels:

Compile-time configuration (Chapter 4) is accomplished when sshd is built. For example, a server may be compiled with or without support for rhosts authentication.
Serverwide configuration, the subject of this chapter, is performed by a system administrator and applies to a running instance of the server. For instance, an administrator may deny SSH access by all hosts in a given domain or make the server listen on a particular port.
Serverwide configuration may depend on compile-time configuration. For example, a server's hostbased authentication options work only if the server is compiled with hostbased authentication support included. Otherwise, the options have no effect. We identify such dependencies throughout the book. Figure 5-1 highlights the serverwide configuration tasks.
Per-account configuration (Chapter 8) is performed by the end user, specifically, the owner of the account to which an SSH connection has been requested. For example, users may permit or deny access to their own accounts from particular hosts, overriding the serverwide configuration.

Suppose user deborah on the machine client.unc.edu invokes an SSH client. The client's behavior is determined by several factors:

The compile-time options selected when the software was built
The machinewide client configuration file on client.unc.edu
User deborah's own client configuration file
The command-line options used by deborah when invoking the client

An SSH server running on server.unc.edu accepts deborah's connection to the account charlie. The server's behavior is determined by the compile-time options used when

Figure 5-1: Serverwide configuration (highlighted parts)

sshd was built, the machinewide server configuration file on server.unc.edu, the command-line options used when the SSH server was run, and charlie's personal server configuration file (e.g., an

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

We now embark on a detailed discussion of SSH server configuration, using both keywords and command-line options. Please keep in mind that modern SSH products are actively developed and their features may change. Be sure to read their documentation for the latest information.

We begin with initial setup decisions, such as: where should important files be kept? What should their permissions be? What TCP/IP settings should be used? Which encryption algorithms should be supported?

sshd expects certain files to exist, containing the server's host key, the random seed, and other data. The server looks for these files in default locations, or you may override them with keywords and command-line options as described later.

Although you may place these files anywhere you like, we strongly recommend keeping them on a local disk on your server machine, not on a remotely mounted disk (e.g., via NFS). This is for security reasons, as NFS will gleefully transmit your sensitive files unencrypted across the network. This would be especially disastrous for the unencrypted private host key!

As a running example, we use an invented directory, /usr/local/ssh, as our preferred (nondefault) location for the SSH server's files.

Section 5.3.1.1: 5.3.1.1 Host key files

The host key of sshd uniquely identifies a server to SSH clients. The host key is stored in a pair of files, one containing the private key and the other the public key. OpenSSH has distinct host keys in DSA (/etc/ssh/ssh_host_dsa_key) and RSA (/etc/ssh/ssh_host_rsa_key) formats, as well as a legacy SSH-1 protocol key, /etc/ssh/ssh_host_key. These private keys are readable only by privileged programs such as the SSH server and clients. Their locations may be changed with the HostKey keyword:

    # OpenSSH

    HostKey /usr/local/ssh/my_dsa_key

    HostKey /usr/local/ssh/my_rsa_key

    HostKey /usr/local/ssh/my_old_ssh1_key

Each private key has a corresponding public key, stored in a second file with the same name but with

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

A large part of the SSH server's job is to grant or deny connection requests from clients. This is done at two levels: authentication and access control (a.k.a. authorization). We discuss the former here and the latter in the section "Access Control: Letting People In." [5.5] Authentication, as we've seen, means verifying the identity of the user requesting a connection.

sshd supports several different techniques for authentication that may be enabled or disabled. [3.1.3] [3.4.3] For example, if you don't trust password authentication, you can turn it off serverwide but still permit public-key authentication.

As SSH has evolved, the syntax for configuring authentication has changed several times, and OpenSSH and Tectia use entirely different syntaxes. In OpenSSH, different authentication techniques are turned on and off with keywords of the form:

<Name_Of_Technique>Authentication

For example, password authentication is controlled by the keyword PasswordAuthentication, public-key authentication by PubKeyAuthentication, and so forth, one keyword per technique. Values may be yes or no, as in:

    # OpenSSH

    PubKeyAuthentication yes

Table 5-1 lists all the authentication techniques supported by OpenSSH, and each is described in detail later.

Table 5-1: OpenSSH authentication keywords
Keyword	Meaning
`ChallengeResponseAuthentication`	One-time passwords.
`GSSAPIAuthentication`	Typically used for Kerberos.
`HostbasedAuthentication`	Host-based authentication.
`PasswordAuthentication`	Password authentication. Exactly what this means is determined by the `UsePAM` and `KerberosAuthentication` keywords.
`PubKeyAuthentication`	Public-key authentication.
`RhostsRSAAuthentication`	SSH-1 protocol only: avoid.
`RSAAuthentication`	SSH-1 protocol only: avoid.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Serverwide access control permits or denies connections from particular hosts or Internet domains, or to specific user accounts on the server machine. It's applied separately from authentication: for example, even if a user's identity is legitimate, you might still want to reject connections from her computer. Similarly, if a particular computer or Internet domain has poor security policies, you might want to reject all SSH connection attempts from that domain.

SSH access control is scantily documented and has many subtleties and "gotchas." The configuration keywords look obvious in meaning, but they aren't. Our primary goal in this section is to illuminate the murky corners so that you can develop a correct and effective access-control configuration.

Keep in mind that SSH access to an account is permitted only if both the server and the account are configured to allow it. If a server accepts SSH connections to all accounts it serves, individual users may still deny connections to their accounts. [8.2] Likewise, if an account is configured to permit SSH access, the SSH server on its host can nonetheless forbid access. This two-level system applies to all SSH access control, so we won't state it repeatedly. Figure 5-2 summarizes the two-level access control system.

Figure 5-2: Access control levels

Ordinarily, any account may receive SSH connections as long as it is set up correctly. This access may be overridden by the server keywords AllowUsers and DenyUsers. AllowUsers specifies that only a limited set of local accounts may receive SSH connections. For example, the line:

    AllowUsers smith

permits the local smith account, and only the smith account, to receive SSH connections. The configuration file may have multiple AllowUsers lines:

    AllowUsers smith

    AllowUsers jones

    AllowUsers oreilly

in which case the results are cumulative: the local accounts smith, jones, and oreilly, and only those accounts, may receive SSH connections. The SSH server maintains a list of all

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

When a login occurs, the SSH server can take special actions. Here, we discuss:

Printing welcome messages for the user
Setting environment variables
Taking arbitrary actions with initialization scripts

sshd can display custom messages for the user before and after authentication. Before authentication, the SSH server can optionally display the contents of any file you select with the Banner keyword (OpenSSH) or BannerMessageFile keyword (Tectia):

    # OpenSSH

    Banner /usr/local/etc/warning.txt



    # Tectia

    BannerMessageFile  /usr/local/etc/warning.txt

By default, OpenSSH displays no banner message, whereas Tectia displays the contents of /etc/ssh2/ssh_banner_message if the file exists. The banner message is often used for legal statements that forbid unauthorized access. Since the file is sent before authentication, be careful that it doesn't reveal sensitive information.

After authentication, both OpenSSH's and Tectia's sshd optionally prints the standard Unix "message of the day" file ( /etc/motd ). This output may be turned on and off with the PrintMotd keyword with the value yes (the default) or no:

    PrintMotd no

Since most Unix shells print /etc/motd on login, this SSH feature is often redundant and turned off.

For Tectia, a message about email (e.g., "You have mail") is printed on login if the CheckMail keyword has the value of yes (the default), or the message is skipped if the value is no:

    # Tectia

    CheckMail yes

In OpenSSH, the last login time is also printed if the PrintLastLog keyword has the value of yes (the default), or the message is skipped if the value is no:

 # OpenSSH

    PrintLastLog yes

Tectia has no separate keyword to control printing the last login time—it's always printed, if available.

The SSH server also obeys the Unix hushlogin convention, which allows each user to control whether these welcome messages are printed. If the file ~/.hushlogin

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Forwarding (or tunneling) is the use of SSH to protect another network service. We discuss it in detail in Chapter 9, but here we describe the available serverwide configuration options.

SSH's forwarding (or tunneling) features protect other TCP/IP-based applications by encrypting their connections. We cover forwarding in great detail in Chapter 9, but we introduce here the serverwide configuration keywords for controlling it.

TCP port forwarding can be enabled or disabled by the keyword AllowTcpForwarding, with the value yes (the default) or no:

    AllowTcpForwarding no

Tectia can specify this more selectively for particular users or Unix groups, with the keywords AllowTcpForwardingForUsers, AllowTcpForwardingForGroups, DenyTcpForwardingForUsers, and DenyTcpForwardingForGroups:

    # Tectia

    AllowTcpForwardingForUsers smith

    AllowTcpForwardingForGroups students

    DenyTcpForwardingForUsers evildoer

    DenyTcpForwardingForGroups badguys

The values for these keywords use the same syntax as for AllowUsers, AllowGroups, DenyUsers, and DenyGroups, respectively: [5.5.1] [5.5.2]

    # Tectia with zsh_fileglob or traditional regex syntax

    AllowTcpForwardingForUsers good*@*.friendly.org,*@\i10.1.2.*,12[[:digit:]]

    DenyTcpForwardingForGroups bad*,33[[:digit:]]



    # Tectia with egrep regex syntax

    AllowTcpForwardingForUsers good.*@.*\.friendly\.org,.*@\i10\.1\.2\.*,12[[:digit:]]

    DenyTcpForwardingForGroups bad.*,33[[:digit:]]

Tectia's ForwardACL keyword provides the most precise access control for specific forwardings. Its use is complicated but it provides great flexibility. It uses multiple values (separated by whitespace), with the general format:

    # Tectia

    ForwardACLaccess 

               direction 

               client 

               forward [originator]

The values stand for:

access: Either allow or deny, indicating the type of control to be applied.
direction: Either local or remote, specifying the kind of forwarding being controlled.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Subsystems are a layer of abstraction for defining and running remote commands via SSH. Normally remote commands are specified ad hoc on the client command line. For example, the following command runs a script to perform tape backups:

    $ ssh server.example.com /usr/local/sbin/tape-backups

Subsystems are a set of remote commands predefined on the server machine, with simple names so that they can be executed conveniently.

The syntax to define subsystems in the server configuration file is slightly different for OpenSSH and Tectia. A subsystem for the preceding backup command is:

    # OpenSSH

    Subsystem backups   /usr/local/sbin/tape-backups



    # Tectia

    Subsystem-backups   /usr/local/sbin/tape-backups

Note that OpenSSH uses the keyword Subsystem with a separate value for the subsystem name, whereas Tectia uses a keyword of the form Subsystem- name. This Tectia syntax is quite odd and unlike anything else in its configuration language; we don't know how it ended up that way.

To run this tape backup script on the server machine, use the ssh -s option:

    $ ssh server.example.com -s backups

This command behaves identically to the previous one in which the script was specified explicitly.

Subsystems are mainly a convenience feature to predefine commands for SSH clients to invoke easily. The additional level of abstraction is useful for system administrators, who can hide (and therefore easily change) details for the subsystem commands. For example, the backups subsystem could be changed to use a completely different script, without any changes in the ssh client command that operators run to perform tape backups.

System administrators can also define and advertise more generally useful subsystems. Suppose your users run the Pine email reader to connect to your IMAP server to secure the connection. [11.3] Instead of telling everyone to use the command:

    $ ssh server.example.com /usr/sbin/imapd

and revealing the path to the IMAP daemon,

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

As an SSH server runs, it optionally produces log messages to describe what it's doing. Log messages aid the system administrator in tracking the server's behavior and detecting and diagnosing problems. For example, if a server is mysteriously rejecting connections, one of the first places to look is the server's log output.

By default, the SSH server writes log messages to syslog , the standard Unix logging service (see the sidebar, "The Syslog Logging Service"). For example, an SSH server typically announces its startup with log messages like:

    Server listening on 0.0.0.0 port 22.

    Generating 768 bit RSA key.

    RSA key generation complete.

and a connection from a client is recorded with log messages like:

    session opened for user rebecca by (uid=9005)

    Accepted publickey for rebecca from 10.1.2.3 port 1265

    ssh2 session closed for user rebecca

The SyslogFacility keyword specifies how the SSH server tags log messages:

    SyslogFacility LOCAL3

The value is one of the (case-insensitive) syslog facility codes, and the default is AUTH.

Syslog is the standard Unix logging service. Programs send their log messages to the syslog daemon, syslogd, which forwards them to other destinations such as files, the system console, or even other machines. Destinations are specified in the syslog configuration file, /etc/syslog.conf.

Messages received by syslogd are processed according to their facility, which indicates their origin. Standard syslog facilities include AUTH (security and authorization), AUTHPRIV (similar, but for sensitive information), DAEMON (system daemons), LOCAL0 through LOCAL7 (reserved for local use), and USER (user processes).

Log messages are also assigned a priority level, which indicates their importance. The standard syslog priorities are, in order from most to least important, EMERG, ALERT, CRIT, ERR, WARNING, NOTICE, INFO, and DEBUG.

See the manpages for syslog, syslogd, and syslog.conf

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

OpenSSH supports both the SSH-1 and SSH-2 protocols within a single daemon accepting both types of connections. The Protocol keyword can be used to limit the support to either protocol exclusively. [5.3.7]

For Tectia, however, the story is more complicated. The Tectia server itself only supports the SSH-2 protocol, but it can accept connections from clients that request the older SSH-1 protocol. This backward compatibility is achieved by having the Tectia server run some other server program for the SSH-1 protocol instead, whenever an SSH-1 connection is requested. This feature is enabled and disabled with the Tectia Ssh1Compatibility keyword, given a value of yes or no (the default):

    # Tectia

    Ssh1Compatibility yes

When Ssh1Compatibility is enabled, and an SSH-1 client connects to the Tectia server, the two programs exchange strings indicating their versions. [3.6.3] sshd (also known as sshd2, see the sidebar "Tectia's File-Naming Conventions" [5.1]) then locates the sshd1 executable by examining the value of the Sshd1Path keyword:

    # Tectia

    Sshd1Path /usr/local/sbin/sshd1

and invokes sshd1. The Tectia server adds the -i option [5.3.3.2] to the sshd1 command line to indicate that the client connection has already been accepted by Tectia, and sshd1 should expect the socket to be attached to its standard input, output, and error streams. In addition, the Tectia server passes the client's version string using the (mostly undocumented) -V command-line option:

    # Tectia, invoked automatically by sshd

    /usr/local/sbin/sshd1 -i -V "client version string" <other arguments>

Although sshd2 can accept and reroute SSH-1 client connections, the reverse isn't true: sshd1 can't accept SSH-2 connections.

The -V command-line option is supported by sshd1 implementations for internal use only by sshd2. It is necessary because when sshd1 starts this way, the client has already sent its initial version announcement, which

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

As you can see, SSH servers have a tremendous number of configuration options, and in some cases, multiple ways to achieve the same results. All this power comes at a price, however. When setting up a secure system, it is vital to consider each option carefully and select appropriate values. Don't skimp on understanding: the security of your systems may depend on it. Chapter 10 lists configurations for OpenSSH and Tectia. In addition, all the keywords and options in this chapter appear in Appendix E.

Remember that serverwide configuration is only one avenue for affecting server behavior. We discuss compile-time configuration in Chapter 4 and per-account configuration in Chapter 8.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Your SSH private key is a precious thing. When you use public-key authentication, your key proves your identity to SSH servers. We've encountered several programs related to keys:

ssh-keygen: Creates key pairs
ssh-agent: Holds private keys in memory, saving you from typing your passphrase repeatedly
ssh-add: Loads private keys into the agent

However, we haven't gone into much depth, covering only the most basic operations with keys. Now it's time to examine these concepts and programs in detail.

We begin with an overview of SSH identities and the keys that represent them. After that, we thoroughly cover SSH agents and their many features. Finally, we extol the virtues of having multiple SSH identities. If you've been getting by with a single key and only light agent use, we have a lot of cool stuff in store for you. Figure 6-1 summarizes the role of key management in the overall configuration process.

This chapter is the first in a sequence on advanced SSH for end users, as opposed to system administrators. Once you've covered key management in this chapter, we'll take you through client configuration, server configuration, and forwarding in Chapters 7-9.

An SSH identity is a sequence of bits that says, "I am really me." It is a mathematical construct that permits an SSH client to prove itself to an SSH server, so the SSH server says, "Ah, I see, it's really you. You are hereby authenticated. Come in."

Figure 6-1: SSH user key and agent configuration (highlighted parts)

An identity consists of two parts, called the private key and the public key. Together, they are known as a key pair.

The private key represents your identity for outgoing SSH connections. When you run an SSH client in your account, such as ssh or scp, and it requests a connection with an SSH server, the client uses this private key to prove your identity to the server.

Private keys must be kept secret. An intruder with your private key can access your account as easily as you can.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

An SSH identity is a sequence of bits that says, "I am really me." It is a mathematical construct that permits an SSH client to prove itself to an SSH server, so the SSH server says, "Ah, I see, it's really you. You are hereby authenticated. Come in."

Figure 6-1: SSH user key and agent configuration (highlighted parts)

An identity consists of two parts, called the private key and the public key. Together, they are known as a key pair.

The private key represents your identity for outgoing SSH connections. When you run an SSH client in your account, such as ssh or scp, and it requests a connection with an SSH server, the client uses this private key to prove your identity to the server.

Private keys must be kept secret. An intruder with your private key can access your account as easily as you can.

The public key represents your identity for incoming connections to your account. When an SSH client requests access to your account, using a private key as proof of identity, the SSH server examines the corresponding public key. If the keys "match" (according to a cryptographic test), authentication succeeds and the connection proceeds. Public keys don't need to be secret; they can't be used to break into an account.

A key pair is typically stored in a pair of files with related names. In SSH, the public-key filename is the same as the private one, but with the suffix .pub added. For example, if the file mykey holds a private key, its corresponding public key is found in mykey.pub.

You may have as many SSH identities as you like. Most SSH implementations let you specify a default identity clients use unless told otherwise. To use an alternative identity, you must change a setting by command-line argument, configuration file, or some other configuration tool.

The structure of identity files differs for OpenSSH and Tectia, so we explain them separately. Their locations in the filesystem are shown in Figures 6-2 (private keys) and 6-3 (public keys).

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Most SSH implementations include a program for creating key pairs. We cover ssh-keygen from OpenSSH and Tectia.

OpenSSH uses the program ssh-keygen to create key pairs. [2.4.2] Let's go into more detail about this program for creating new keys or modifying existing keys.

Section 6.2.1.1: 6.2.1.1 Creating OpenSSH keys

When creating a new key, you must indicate the key type (DSA or RSA) using the -t flag:

    $ ssh-keygen -t dsa

You may also specify these options for creating keys:

The number of bits in the key, using -b; the default is 1024 bits:
```
    $ ssh-keygen -t dsa -b 2048
```
The name of the private-key file to be generated, using -f. The name is relative to your current directory. Recall that the public-key file is named after the private one with .pub appended.
```
    $ ssh-keygen -t dsa -f mykeyCreates mykey and mykey.pub
```
If you omit the -f option, you are prompted for the information:
```
    $ ssh-keygen -t dsa

    ...

    Enter file in which to save the key (/home/barrett/.ssh/id_dsa):mykey
```
The default filename for DSA keys is ~/.ssh/id_dsa, and for RSA keys it's ~/.ssh/id_rsa.

The passphrase to decode the key, using -N:

    $ ssh-keygen -t dsa -N secretword

If you omit this option, you'll be prompted for the information:

    $ ssh-keygen -t dsa

    ...

    Enter passphrase:[nothing is echoed]

    Enter the same passphrase again: [nothing is echoed]

A textual comment associated with the key, using -C. If you omit this option, the comment is username@host, where username is your username and host is the local hostname:
```
    $ ssh-keygen ... -C "my favorite key"
```

Before using any option that places your passphrase on the shell command line, such as the -N or -P options of ssh-keygen, carefully consider the security implications. Because the passphrase appears on your screen, it may be visible to onlookers, and while running, it may be visible to other users viewing the machine's process list via the

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

An SSH agent is a program that caches private keys and responds to authentication-related queries from SSH clients. [2.5] They are terrific labor-saving devices, handling all key-related operations and eliminating the need to retype your passphrase.

The programs related to agents are ssh-agent and ssh-add. ssh-agent runs an agent, and ssh-add inserts and removes keys from the agent's key cache. A typical use might look like this:

    # Start the agent

    $ ssh-agent $SHELL

    # Load your default identity

    $ ssh-add

    Need passphrase for /home/barrett/.ssh/identity (barrett@example.com).

    Enter passphrase:********

By typing your passphrase a single time, you decrypt the private key which is then stored in memory by the agent. From now on, until you terminate the agent or log out, SSH clients automatically contact the agent for all key-related operations. You needn't type your passphrase again.

We now briefly discuss how agents work. After that we get practical and illustrate different ways to start an agent, various configuration options, and several techniques for automatically loading your keys into the agent. Finally, we cover agent security and agent forwarding.

Agents perform two tasks:

Store your private keys in memory
Answer questions (from SSH clients) about those keys

Agents don't, however, send your private keys anywhere. This is important to understand. Once loaded, private keys remain within an agent, unseen by SSH clients. To access a key, a client says, "Hey agent! I need your help. Please perform a key-related operation for me." The agent obeys and sends the results to the client, as in Figure 6-4.

Figure 6-4: How an SSH agent works with its clients

For example, if ssh needs to sign an authenticator, it sends the agent a signing request containing the authenticator data and an indication of which key to use. The agent performs the cryptographic operation itself and returns the signature.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Until now, we've assumed you have a single SSH identity that uniquely identifies you to an SSH server. You do have a default identity—our earlier ssh-add examples operated on it—but you may create as many other identities as you like.

Why use several identities? After all, with a single SSH identity, you can connect to remote machines with a single passphrase. That's very simple and convenient. In fact, most people can survive perfectly well with just one identity. Multiple identities have important uses, however:

Additional security: If you use different SSH keys for different remote accounts, and one of your keys is cracked, only some of your remote accounts are vulnerable.
Secure batch processes: Using an SSH key with an empty passphrase, you can create secure, automated processes between interacting computers, such as unattended backups. [11.1.2.2] However, you definitely don't want your regular logins to use an unencrypted private key, so you should create a second key for this purpose.
Different account settings: You can configure your remote account to respond differently based on which key is used for connecting. For example, you can make your Unix login session run different startup files depending on which key is used.
Triggering remote programs: Your remote account can be set up to run specific programs when an alternative key is used, via forced commands. [8.2.3]

In order to use multiple identities, you need to know how to switch between them. There are two ways: manually, and automatically with an agent.

ssh and scp let you switch your identity with the -i command-line option and the IdentityFile configuration keyword. For either of these techniques, you provide the name of your desired private-key file (OpenSSH) or identification file (Tectia). [7.4.2] Table 6-3 displays a summary of the syntax.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Pretty Good Privacy (PGP) is another security product employing public-key authentication. [1.6.2] PGP keys and SSH keys are implemented differently and aren't interchangeable, however, Tectia can perform authentication by PGP key, following the OpenPGP standard. Yes, you can use your favorite PGP key to prove your identity to a Tectia server (as long as the key file is OpenPGP-compatible; some PGP keys, especially those produced by older software versions, aren't). At press time, this feature is only sketchily documented. Here's how to make it work.

First, you need Tectia installed on both the client and server machines. Also, both implementations must be compiled with PGP support included, using the compile-time flag --with-pgp. [4.3.5.7]

On the client machine, you need to make your PGP secret key ring and the desired secret key for authentication available to Tectia clients. Here's how:

Copy your PGP secret key ring to your account's Tectia directory, ~/.ssh2. Suppose it is called secring.pgp.
In an identification file, either ~/.ssh2/identification or another of your choice, indicate the secret key ring with the keyword PgpSecretKeyFile:
```
    # Tectia

    PgpSecretKeyFile secring.pgp
```
Identify the PGP key you wish to use for authentication. This may be done with any of three keywords:
- To identify the key by name, use IdPgpKeyName:
```
    # Tectia

    IdPgpKeyName mykey
```
- To identify the key by its PGP fingerprint, use IdPgpKeyFingerprint:
```
    # Tectia

    IdPgpKeyFingerprint 48 B5 EA 28 80 5E 29 4D 03 33 7D 17 5E 2E CD 20
```
- To identify the key by its key ID, use IdPgpKeyId:
```
    # Tectia

    IdPgpKeyId 0xD914738D
```

For IdPgpKeyId, the leading 0x is necessary, indicating that the value is in hexadecimal. You can give the value in decimal instead, without the leading 0x, but since PGP displays the value in hex already, it's unlikely you'd want to do this.

On the server machine, you need to make your PGP public-key ring and the desired public key for authentication available to the Tectia server:

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Tectia clients can use external key providers that distribute keys, somewhat like authentication agents. These are typically part of a more general solution for PKI (Public Key Infrastructure). The ssh -E command-line option identifies the name of the provider, and Tectia currently supports two of them:

entrust: Entrust products, such as the Entrust Authority Security Manager; see http://www.entrust.com/authority.
pkcs11: PKCS#11-compliant dynamic libraries.

An initialization string must be sent to the external key provider using the -I option. The format of this string depends on the provider. It typically includes authentication information and identifies the desired key. Sometimes you also need a DLL supplied by the provider. Consult the documentation for specific providers, and the ssh-externalkeys manpage, for details about the initialization string.

    # Tectia

    $ ENTRUST_INIT="dll(libentrust.so)"

    $ ENTRUST_INIT="$ENTRUST_INIT password(blartz)"

    $ ENTRUST_INIT="$ENTRUST_INIT ini-file($HOME/solo.ini)"

    $ ENTRUST_INIT="$ENTRUST_INIT profile-file($HOME/solo_user.epf)"

    $ ENTRUST_INIT="$ENTRUST_INIT login-options(entrust)""

    $ ssh -E entrust -I "$ENTRUST_INIT"

The external key provider and initialization string can also be specified in the client configuration file, using the keywords EkProvider and EkInitString, respectively:

    # Tectia

    EkProvider      pkcs11

    EkInitString    "lib=libpcks11.so password=blurfl key=laptop"

The keywords are usually more convenient than the command-line options, especially for long initialization strings, but beware of storing sensitive authentication information in configuration files. Be sure to quote the initialization string if it contains characters with special meaning to the shell (e.g., wildcards) or to the configuration file itself.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

In this chapter, we've seen how to create and use SSH identities, represented by key pairs, either individually (OpenSSH) or in collections (Tectia). Keys are created by ssh-keygen and are accessed by clients as needed. Tectia provides an additional layer of configuration, the identification file, which lets you use a set of identities as a single identity. You may have as many identities as you like. Be sure to read our case study on PKI and scalable authentication for another detailed look at identities. [11.5]

SSH agents are useful timesavers to avoid retyping passphrases. Their operation has numerous subtleties, but once you get the hang of it, running an agent should become second nature.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

SSH clients are marvelously configurable. Chapter 2 introduced remote logins and file copying but covered only the tip of the iceberg. You can also connect with multiple SSH identities, use a variety of authentication and encryption techniques, exercise control over TCP/IP settings, and generally tailor the feel and operation of SSH clients to your liking. You can even save common collections of SSH settings in configuration files for ease of use.

We'll be focusing on outgoing SSH use, running SSH clients to connect to remote hosts, using the components highlighted in Figure 7-1. A related topic, not covered in this chapter, is how to control incoming SSH connections to your account. That sort of access control is a function of the SSH server, not the clients, and is covered in Chapter 8.

The clients ssh and scp are quite configurable, with many settings that can be changed to suit your whim. If you want to modify the behavior of these clients, three general techniques are at your disposal:

Command-line options: For changing the behavior of ssh or scp for a single invocation
Configuration keywords: For changes that remain in force until you change them again; these are stored in a client configuration file
Environment variables: For a few miscellaneous features

We now present a general overview of these three methods.

Figure 7-1: Client configuration (highlighted parts)

Command-line options let you change a client's behavior just once, at invocation. For example, if you're using ssh over a slow modem connection, you can tell it to compress the data with the -C command-line option:

    $ ssh -C server.example.com

ssh, scp, and most of their support programs, when invoked with the --help option, will print a helpful summary describing all their command-line options. For example:

    $ ssh --help

    $ scp --help

    $ ssh-keygen -help

If you don't want to retype command-line options continually, configuration files let you change a client's behavior now and in the future, until you change the configuration file again. For example, you can enable compression for all clients you invoke by inserting this line into a client configuration file:

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

The clients ssh and scp are quite configurable, with many settings that can be changed to suit your whim. If you want to modify the behavior of these clients, three general techniques are at your disposal:

Command-line options: For changing the behavior of ssh or scp for a single invocation
Configuration keywords: For changes that remain in force until you change them again; these are stored in a client configuration file
Environment variables: For a few miscellaneous features

We now present a general overview of these three methods.

Figure 7-1: Client configuration (highlighted parts)

Command-line options let you change a client's behavior just once, at invocation. For example, if you're using ssh over a slow modem connection, you can tell it to compress the data with the -C command-line option:

    $ ssh -C server.example.com

ssh, scp, and most of their support programs, when invoked with the --help option, will print a helpful summary describing all their command-line options. For example:

    $ ssh --help

    $ scp --help

    $ ssh-keygen -help

If you don't want to retype command-line options continually, configuration files let you change a client's behavior now and in the future, until you change the configuration file again. For example, you can enable compression for all clients you invoke by inserting this line into a client configuration file:

    Compression yes

In a client configuration file, client settings are changed by specifying keywords and values. In the example, the keyword is Compression and the value is yes. You may also separate the keyword and value with an equals sign, with optional whitespace:

    Compression = yes

You may configure clients to behave differently for each remote host you visit. This can be done on the fly with command-line options, but for anything reasonably complex, you'll end up typing long, inconvenient command lines like:

    $ ssh -a -p 220 -c blowfish -l sally -i myself server.example.com

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Perhaps you are wondering: what happens if some configuration settings conflict? For instance, if you use the Compression keyword to turn compression off, and also the -C command-line option to turn it on, who wins? In other words, who has precedence ?

For OpenSSH and Tectia clients, the order of precedence is, from strongest to weakest:

Command-line options
The user's local client configuration file
The global client configuration file

Command-line options have the highest precedence, overriding any client configuration files. The user's local file has next highest precedence, and the global file has lowest precedence. So, in our compression example, -C takes precedence over the Compression keyword, and compression is enabled. If a setting isn't changed by any keyword or command-line option, the client's default setting is used.

Remember that we're speaking only of outgoing connections initiated by clients. Incoming connections, controlled by the SSH server, have other precedence rules. For servers, the user's local configuration file definitely does not override the global file; otherwise, users could override global server settings, creating security holes and wreaking other havoc. [8.1.1]

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Now that we've covered the generalities of command-line options and configuration files, we're about to launch into an extended discussion of configuration. Before we begin, let's practice some defense. As you try these options, occasionally you might see behavior that's not what you expected. Whenever this occurs, your first instinct should be: turn on verbose mode with the -v command-line option to track down the problem:

    $ ssh -v server.example.com

In verbose mode, the client prints messages as it proceeds, providing clues to the problem. New SSH users (and quite a few experienced ones) frequently forget or neglect to use verbose mode when problems arise. Don't hesitate! Many questions we've seen in the Usenet SSH newsgroup, comp.security.ssh [12.3], could have been answered immediately by running ssh -v and examining the output.

Suppose you just installed your public key on server.example.com and are trying to authenticate with it. Strangely, you are prompted for your login password instead of your public-key passphrase:

    $ ssh server.example.com

    barrett@server.example.com's password:

Don't just sit there scratching your head in wonder. Let verbose mode come to the rescue:

    $ ssh -v server.example.com

    OpenSSH_3.8p1, SSH protocols 1.5/2.0, OpenSSL 0.9.7d 17 Mar 2004

    debug1: Reading configuration data /etc/ssh/ssh_config

    debug1: Applying options for *

    debug1: Connecting to server.example.com [192.168.0.10] port 22.

    debug1: Connection established.

    debug1:  Remote: Bad file modes for /users/barrett/.sshUh oh!

    debug1: Server refused our key.

    debug1: Doing password authentication.

    barrett@server.example.com's password:

These messages (which are abbreviated for this example) confirm that the SSH connection is succeeding, but public-key authentication is failing. The reason is "bad file modes": the remote SSH directory, /home/barrett/.ssh, has incorrect permissions. A quick trip to the server and a well-placed

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

ssh and scp take their cues from command-line options, configuration-file keywords, and environment variables. OpenSSH and Tectia clients behave differently and obey different settings, but as usual, we cover them simultaneously. When a setting is supported by only some of these products, we'll say so.

Both OpenSSH and Tectia ssh will print a usage message briefly describing all its options:

    $ ssh --help

You can get the same effect if you omit all arguments (OpenSSH) or use -h (Tectia). Tectia will also print its version number on request, with the -V option:

    # Tectia

    $ ssh -V

    ssh: SSH Tectia Server 4.2.1 on i686-pc-linux-gnu

    Build: 1

    Released 2004-11-30 (YYYY-MM-DD).

    Crypto library version: SSH Cryptographic Library, version 1.2.4

    FIPS certification mode: DISABLED

    Product: SSH Tectia Server (T)

    License type: commercial

ssh and scp assume that your local and remote usernames are the same. If your local username is henry and you run:

    $ ssh server.example.com

ssh assumes your remote username is also henry and requests a connection to that account on server.example.com. If your remote account name differs from the local one, you must tell the SSH client your remote account name. For henry to connect to a remote account called sally, he can use the -l command-line option:

    $ ssh -l sally server.example.com

If copying files with scp, the syntax is different for specifying the remote account name, looking more like an email address. [7.5.1] To copy the file myfile to the remote account sally on server.example.com:

    $ scp myfile sally@server.example.com:

If you frequently connect to a remote machine using a different username, instead of monkeying with command-line options specify the remote username in your client configuration file. The User keyword serves this purpose, and both ssh and scp pay attention to it. Here's how to declare that your remote username is sally on a given remote host:

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

The secure copy program, scp, obeys keywords in your client configuration file just as ssh does. In addition, scp provides other features and options that we'll cover in this section. Remember that scp supports several options for logging and debugging, so you can watch what's going on when it runs. [7.3]

So far, we've described the syntax of scp only in general: [2.2.1]

    scpname-of-source 

               name-of-destination

Each of the two names, or path specifications, on the command line represents files or directories in the following manner (it is fairly consistent with the behavior of Unix cp or rcp):

If name-of-source is a file, name-of-destination may be a file (existing or not) or a directory (which must exist). In other words, a single file may be copied to another file or into a directory.
If name-of-source is two or more files, one or more directories, or a combination, name-of-destination must be an existing directory into which the copy takes place. In other words, multiple files and directories may be copied only into a directory.

Both name-of-source and name-of-destination may have the following form from left to right:

The username of the account containing the file or directory, followed by @. This part is optional, and if omitted, the value is the username of the user invoking scp.
The hostname of the host containing the file or directory, followed by a colon. This part is optional, if the path is present, and the username isn't; if omitted, the value is localhost. Tectia permits an optional TCP port number for the SSH connection to be inserted between the hostname and the colon, preceded by a hash sign.
The directory path to the file or directory. (Optional if the hostname is present.) Relative pathnames are assumed relative to the

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

The sftp client is an alternative to scp, though under the hood it does mostly the same thing: it copies files between SSH client and server machines securely. The main difference is that sftp is interactive, with an interface much like the old FTP programs. [2.7.1]

To get started, run sftp with a remote hostname:

    $ sftp server.example.com

or username and hostname:

    $ sftp smith@server.example.com

You'll get a prompt:

    sftp>

and now may type commands to transfer files between your local and remote machine. For example:

    sftp> cd remote_directoryChange to a particular remote directory

    sftp> ls                      List the names of available files

    sftp> get remotefile          Download the file "remotefile"

    sftp> get remotefile newname  Same as above, but the local file will be renamed as "newname"

    sftp> put localfile           Upload the file "localfile"

    sftp> put localfile othername Same as above, but the remote file will be renamed as "othername"

    sftp> quit                    Quit sftp

The basic use of sftp will feel familiar to anyone who's used an FTP program. Use the cd command to move around the remote filesystem (or lcd for the local filesystem), ls to list the available remote files, and the get and put commands to download and upload files, respectively. Table 7-4 lists the interactive commands available during an sftp connection.

Table 7-4: Interactive commands for sftp, grouped by function
Command	Meaning	Support
^a Not needed unless you run Tectia sftp with no arguments, so no initial connection is established.
^b On Tectia, `get` and `mget` are equivalent, and so are `put` and `mput`.
Basic commands
open	Open a connection to the remote machine ^a	Tectia
lopen	Open a connection to the local machine ^a	Tectia
close	Close the connection to the remote machine

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

SSH clients are highly configurable through environment variables, command-line options, and keywords in configuration files. Remember that command-line options have the highest precedence, followed by your local client configuration file, and finally the global client configuration file.

Client configuration files consist of sections that apply to individual hosts or groups of hosts. When you run an SSH client, remember that multiple sections can apply to it, according to the precedence rules we covered. If the same keyword is set multiple times, the earliest (OpenSSH) or latest (Tectia) value is the winner.

When experimenting with client configuration, remember verbose mode. If you experience unusual SSH behavior, your first instinct should be to add the -v option and run the client again, watching the debug output for clues.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

We've seen two techniques for controlling the SSH server's behavior globally: compile-time configuration (Chapter 4) and serverwide configuration (Chapter 5). These techniques affect all incoming SSH connections to a given server machine. Now it's time to introduce a third, finer-grained method of server control: per-account configuration .

As the name implies, per-account configuration controls the SSH server differently for each user account on the server machine. For example, a user account sandy can accept incoming SSH connections from any machine on the Internet, while rick permits connections only from the domain verysafe.com, and fraidycat refuses key-based connections. Each user configures his own account, using the facilities highlighted in Figure 8-1, without needing special privileges or assistance from the system administrator.

We have already seen a simple type of per-account configuration. A user may place a public key into her authorization file, instructing the SSH server to permit logins to her account by public-key authentication. But per-account configuration can go further, becoming a powerful tool for access control and playing some fun tricks with your account. Accepting or rejecting connections by particular keys or hosts is just the beginning. For instance, you can make an incoming SSH connection run a program of your choice, instead of the client's choice. This is called a forced command, and we'll cover quite a few interesting applications.

Per-account configuration may control only incoming SSH connections to your account. If you're interested in configuring outgoing SSH connections by running SSH clients, refer to Chapter 7.

Per-account configuration can do many interesting things, but it has some restrictions that we will discuss:

Figure 8-1: Per-account configuration (highlighted parts)

It can't defeat security measures put in place by compile-time or serverwide configuration. (Thank goodness.)

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Per-account configuration can do many interesting things, but it has some restrictions that we will discuss:

Figure 8-1: Per-account configuration (highlighted parts)

It can't defeat security measures put in place by compile-time or serverwide configuration. (Thank goodness.)
It is most flexible and secure if you use public-key authentication. Hostbased and password authentication provide a much narrower range of options.

SSH settings in a user's account may only restrict the authentication of incoming connections. They can't enable any SSH features that have been turned off more globally, and they can't permit a forbidden user or host to authenticate. For example, if your SSH server rejects all connections from the domain evil.org, you can't override this restriction within your account by per-account configuration.

This limitation makes sense. No end-user tool should be able to violate a server security policy. However, end users should be (and are) allowed to restrict incoming connections to their accounts.

A few features of the server may be overridden by per-account configuration. The most notable one is the server's idle timeout, which may be extended beyond the serverwide setting. But such features can't coerce the server to accept a connection it has been globally configured to reject.

If you are an end user, and per-account configuration doesn't provide enough flexibility, you can run your own instance of the SSH server, which you may configure to your heart's content. [5.1.2] Be cautious, though, since this is seldom the right thing to do. The restrictions you're trying to circumvent are part of the security policy defined for the machine by its administrators, and you shouldn't run a program that flouts this policy just because you can. If the machine in question is under your administrative control, simply configure the main SSH server as you wish. If not, then installing and running your own

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

To set up public-key authentication in your account on an SSH server machine, you create an authorization file, typically called authorized_keys (OpenSSH) or authorization (Tectia), and list the keys that provide access to your account. [2.4] Well, we've been keeping a secret. Your authorization file can contain not only keys, but also other keywords or options to control the SSH server in powerful ways. We will discuss:

The full format of an authorization file
Forced commands for limiting the set of programs that the client may invoke on the server
Restricting incoming connections from particular hosts
Setting environment variables for remote programs
Setting an idle timeout so that clients will be forcibly disconnected if they aren't sending data
Disabling or placing limits on certain features of the incoming SSH connection, such as port forwarding and tty allocation

As we demonstrate how to modify your authorization file, remember that the file is consulted by the SSH server only at authentication time. Therefore, if you change your authorization file, only new connections will use the new information. Any existing connections are already authenticated and won't be affected by the change.

Also remember that an incoming connection request won't reach your authorization file if the SSH server rejects it for other reasons, namely, failing to satisfy the serverwide configuration. If a change to your authorization file doesn't seem to be having an effect, make sure it doesn't conflict with a (more powerful) serverwide configuration setting.

Your OpenSSH authorization file, ~/.ssh/authorized_keys, is a secure doorway into your account via SSH. Each line of the file contains a public key and means the following: "I give permission for SSH clients to access my account, in a particular way, using this key as authentication." Notice the words "in a particular way." Until now, public keys have provided unlimited access to an account. Now we'll see the rest of the story.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

A limited type of per-account configuration is possible in OpenSSH if you use hostbased authentication rather than public-key authentication. Specifically, you can permit SSH access to your account based on the client's remote username and hostname via the system files /etc/shosts.equiv and /etc/hosts.equiv, and personal files ~/.rhosts and ~/.shosts. A line like:

    +client.example.com jones

permits hostbased SSH access by the user jones@client.example.com. Since we've already covered the details of these four files, we won't repeat the information in this chapter. [3.6.2]

Per-account configuration with hostbased authentication is similar to using host access control in your OpenSSH authorized_keys or Tectia authorization file. [8.2.4] Both methods may restrict SSH connections from particular hosts. The differences are shown in this table:

Feature	Hostbased access	Public-key host access
Authenticate by hostname	Yes	Yes
Authenticate by IP address	Yes	Yes
Authenticate by remote username	Yes	No
Wildcards in hostnames and IP	No	Yes
Passphrase required for logins	No	Yes
Use other public-key features	No	Yes
Security	Less	More

To use hostbased authentication for access control, all of the following conditions must be true:

Hostbased authentication is enabled in the server, both at compile time and in the serverwide configuration file.
Your desired client hosts aren't specifically excluded by serverwide configuration, e.g., by AllowHosts and DenyHosts.
For OpenSSH, the server configuration keyword EnableSSHKeysign must be set to yes.

Despite its capabilities, hostbased authentication is more complex than one might expect. For example, if your carefully crafted .shosts file denies access to sandy@trusted.example.com:

    # ~/.shosts

    -trusted.example.com sandy

but your .rhosts file inadvertently permits access:

    # ~/.rhosts

    +trusted.example.com

then sandy will have SSH access to your account. Worse, even if you don't have a

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

The shell script /etc/ssh/sshrc is invoked by the SSH server for each incoming SSH connection. [5.6.3] You may define a similar script in your account, ~/.ssh/rc (OpenSSH) or ~/.ssh2/rc (Tectia), to be invoked for every SSH connection to your account. If this file exists, /etc/ssh/sshrc isn't run.

The SSH rc file is much like a shell startup file (e.g., ~/.profile or ~/.cshrc), but it executes only when your account is accessed by SSH. It is run for both interactive logins and remote commands. Place any commands in this script that you would like executed when your account is accessed by SSH, rather than an ordinary login. For example, you can run and load your ssh-agent in this file:

    # ~/.ssh/rc, assuming your login shell is the C shell

    if ( ! $?SSH_AUTH_SOCK  ) then

      eval `ssh-agent`

      /usr/bin/tty | grep 'not a tty' > /dev/null

      if ( ! $status ) then

        ssh-add

      endif

    endif

Like /etc/ssh/sshrc, your personal rc file is executed just before the shell or remote command requested by the incoming connection. OpenSSH always uses the Bourne shell (/bin/sh) for ~/.ssh/rc, as it does for /etc/ssh/sshrc. In contrast, Tectia uses your login shell for ~/.ssh2/rc, unlike /etc/ssh2/sshrc.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Per-account configuration lets you instruct the SSH server to treat your account differently. Using public-key authentication, you can permit or restrict connections based on a client's key, hostname, or IP address. With forced commands, you can limit the set of programs that a client may run in your account. You can also disable unwanted features of SSH, such as port forwarding, agent forwarding, and tty allocation.

Using hostbased authentication, you can permit or restrict particular hosts or remote users from accessing your account. This uses the file ~/.shosts or (less optimally) ~/.rhosts. However, the mechanism is less secure and less flexible than public-key authentication.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

One of SSH's major benefits is transparency . A terminal session secured by SSH behaves like an ordinary, insecure one (e.g., created by telnet or rsh) once it has been established. Behind the scenes, however, SSH keeps the session secure with strong authentication, encryption, and integrity checking.

In some situations, however, transparency is hard to achieve. A network firewall might be in the way, interfering with certain network traffic you need. Corporate security policies might prohibit you from storing SSH keys on certain machines. Or you might need to use insecure network applications in a secure environment.

In this chapter, we'll discuss an important feature of SSH, called forwarding or tunneling, that addresses several concerns about transparency:

Securing other TCP/IP applications: SSH can transparently encrypt another application's data stream. This is called port forwarding .
Securing X Window applications: Using SSH, you can invoke X programs on a remote machine and have them appear, securely, on your local display. (This feature of X is insecure ordinarily.) This is called X forwarding , a special case of port forwarding for which SSH has extra support.

SSH forwarding isn't completely transparent, since it occurs at the application level, not the network level. Applications must be configured to participate in forwarding, and a few protocols are problematic to forward (FTP data channels are a notable example). But in most common situations, once a secure tunnel is set up, the participating applications appear to the user to operate normally. For complete application-level transparency, you need a network-level technique, such as IPSEC [1.6.4] or a proprietary Virtual Private Network (VPN) technology available from various vendors, in host software or dedicated routers. While VPNs provide a more complete solution, they require significantly more work and expense to set up compared to SSH forwarding.

So, when we say "transparent" in this chapter, we mean "transparent to the application, once a little configuration has been done."

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Forwarding is a type of interaction with another network application, as shown in Figure 9-1. SSH intercepts a service request from some other program on one side of an SSH connection, sends it across the encrypted connection, and delivers it to the intended recipient on the other side. This process is mostly transparent to both sides of the connection: each believes it is talking directly to its partner and has no knowledge that forwarding is taking place. Even more powerfully, SSH forwarding can achieve certain types of communication that are impossible without it.

Figure 9-1: SSH forwarding

Forwarding isn't a new concept. The basic operation of a terminal connection over a network (say, using telnet) is also a kind of forwarding. In a telnet connection, you sit on one end, your remote shell is on the other, and both sides operate as if directly connected by a serial cable. Nevertheless, sitting in the middle is a cooperating telnet client and server, forwarding bytes back and forth. SSH forwarding is much the same, except SSH plays fancy tricks with the data to add security.

We have also seen another type of SSH forwarding, agent forwarding . [6.3.5] This let us create SSH connections from one computer, through a second computer, and onto a third using public-key authentication, but without installing our private key on the second machine. To accomplish this, an SSH server pretended to be an SSH agent, while transparently forwarding data to and from a remote agent. This paradigm holds true for TCP port forwarding and X forwarding, as the SSH server transparently masquerades as another network application.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

SSH uses TCP/IP as its transport mechanism, usually TCP port 22 on the server machine, as it encrypts and decrypts the traffic passing over the connection. We now discuss a cool feature that encrypts and decrypts TCP/IP traffic belonging to other applications, on other TCP ports, using SSH. This process, called port forwarding, is largely transparent and quite powerful. Telnet, SMTP, NNTP, IMAP, and other insecure protocols running over TCP can be made secure by forwarding the connections through SSH. Port forwarding is sometimes called tunneling because the SSH connection provides a secure "tunnel" through which another TCP/IP connection may pass.

Suppose you have a home machine H that runs an IMAP-capable email reader, and you want to connect to an IMAP server on machine S to read and send mail. Normally, this connection is insecure, with your mail account password transmitted as plaintext between your mail program and the server. With SSH port forwarding, you can transparently reroute the IMAP connection (found on server S's TCP port 143) to pass through SSH, securely encrypting the data over the connection. The IMAP server machine must be running an SSH server for port forwarding to provide real protection.

In short, with minimal configuration changes to your programs, SSH port forwarding protects arbitrary TCP/IP connections by redirecting them through an SSH session. Port forwarding can even pass a connection safely through a firewall if you configure things properly. Once you start securing your communications with port forwarding, you'll wonder how you ever got along without it. Here are examples of what you can do:

Access various kinds of TCP servers (e.g., SMTP, IMAP, POP, LDAP, etc.) across a firewall that prevents direct access.
Provide protection for your sessions with these same TCP servers, preventing disclosure or alteration of passwords and other content that would otherwise be sent in the clear as part of the session.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

We are often asked, "How can I tunnel my web browsing over SSH?" The usual reasons are for privacy or for browsing across a firewall. The SSH port forwarding we've described so far doesn't meet this need very well, but there is another flavor called dynamic port forwarding which does. We'll call the previous technique "static forwarding" in contrast.

Suppose you're at home, using your home machine H, and need to access a web server W1 at work, but your employer's internal network is behind a firewall. You might attempt to do this through a bastion server at work (say, B) which you can log into via SSH; and then from B, you can reach whatever internal web servers you want. So you create a tunnel using the following port-forwarding command on home machine H:

    $  ssh -L 8080:W1:80 BThis runs into problems

and point your web browser on H at http://localhost:8080/. This is a reasonable try, based on forwarding as we've seen it so far, but there are lots of problems:

Problem 1: virtual hosts: Web servers can make decisions based on the hostname portion of the URL you request. For example, if the names foo and bar are aliases for the same host, then the URLs http://foo/ and http://bar/ may return different pages. A practical example is an ISP's web server, which could host content for dozens or hundreds of customers' web sites under different hostnames, all of which point to that same machine. This web server configuration is often called virtual hosts.
In our home/work example, we're trying to access web server W1 as "localhost," but it might not be configured to serve any content under this name; and even if it does, it might not be the content you want. To address this problem, you'd have to get the browser to recognize other names as aliases for localhost, e.g., by hacking /etc/hosts on a Unix box—not exactly a smooth solution.
Problem 2: absolute links

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Now that you've seen general TCP port forwarding, we move to a new topic: forwarding of X protocol connections. X is a popular window system for Unix workstations, and one of its best features is its transparency. Using X, you can run remote X applications that open their windows on your local display (and vice versa, running local applications on remote displays). Unfortunately, the inter-machine communication is insecure and wide open to snoopers. But there's good news: SSH X forwarding makes the communication secure by tunneling the X protocol.

X forwarding also addresses some firewall-related difficulties. Suppose you're a system administrator with a set of exposed production machines on the other side of a firewall from you. You log into one of these machines using SSH, and want to run a graphical performance-monitoring tool, such as Solaris's perfmon, that uses the X Window System. You can't, though, because to do that, the external machine needs to make a TCP connection back to the internal machine you started on, and the firewall blocks it (as it should, since X is quite insecure). X forwarding solves this problem, permitting X protocol connections to pass through the firewall, securely tunneled via SSH.

Our discussion begins with a brief overview, then explains the details of X forwarding. In addition to explaining how to use X forwarding, we also expose the internals of X authentication and how it interacts with SSH, as well as other technical topics.

The X Window System, or X, is the most widely used graphical display system for Unix machines. Like SSH, X has clients and servers. X clients are windowing application programs, such as terminal emulators, paint programs, graphical clocks, and so forth. An X server is the underlying display engine that processes requests from X clients, communicating via a network protocol called the X protocol. A machine typically runs a single X server but possibly many X clients.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

At several points in this chapter, we have talked about security issues and limitations of forwarding. So far, we've seen very little control over who can connect to a forwarded port. The OpenSSH default is to allow connections only from the local host, which is reasonably secure for a single-user machine. But if you need to allow connections from elsewhere, you have a problem, since it's all or nothing: to allow connections from elsewhere (using -g or GatewayPorts yes), you must allow them from anywhere. And with Tectia it's worse: forwarded ports always accept connections from anywhere. X forwarding is in a slightly better position, since the X protocol has its own authentication, but you might still prefer to restrict access, preventing intruders from exploiting an unknown security flaw or performing a denial-of-service attack. SSH on the Unix platform provides an optional feature for access control based on the client address, called "TCP-wrappers."

The term "TCP-wrappers" refers to software written by Wietse Venema. If it isn't already installed in your Unix distribution, you can get it at:

ftp://ftp.porcupine.org/pub/security/index.html

TCP-wrappers are a global access control mechanism that integrates with other TCP-based servers, such as sshd or telnetd. Access control is based on the source address of incoming TCP connections. That is, a TCP-wrapper permits or denies connections based on their origin, as specified in the configuration files /etc/hosts.allow and /etc/hosts.deny. Figure 9-12 shows where TCP-wrappers fit into the scheme of SSH configuration.

There are two ways to use TCP-wrappers. The most common method, wrapping, is applied to TCP servers that are normally invoked by inetd. You "wrap" the server by editing /etc/inetd.conf and modifying the server's configuration line. Instead of invoking the server directly, you invoke the TCP-wrapper daemon, tcpd, which in turn invokes the original server. Then, you edit the TCP-wrapper configuration files to specify your desired access control.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

In this chapter, we discussed SSH port forwarding and X forwarding. Port forwarding is a general TCP proxying feature that tunnels TCP connections through an SSH session. This is useful for securing otherwise insecure protocols running on top of TCP or for tunneling TCP connections through firewalls that would otherwise forbid access. X forwarding is a special case of port forwarding for X Window System connections, for which SSH has extra support. This makes it easy to secure X connections with SSH, which is good because X, while popular and useful, is notoriously insecure. Access control on forwarded ports is normally coarse, but you can achieve finer control with the TCP-wrappers feature.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

We've just covered a pile of chapters on SSH configuration: is your head spinning yet? With so many choices, you might be wondering which options you should use. How can system administrators secure their systems most effectively with SSH?

When set up properly, SSH works well and invisibly, but sometimes a good setup takes a few tries. In addition, there are some ways to configure the software that are simply wrong. If you're not careful, you can introduce security holes into your system.

In this chapter we present a recommended set of options for compilation, server configuration, key management, and client configuration. We assume:

You're running SSH on a Unix machine.
You want a secure system, sometimes at the expense of flexibility. For instance, rather than tell you to maintain your .rhosts files carefully, we recommend disabling Rhosts authentication altogether.

Of course, no single configuration covers all the possibilities; that is, after all, the point of configuration. This is just a sample setup, more on the secure side, to give you a starting point and cover some of the issues involved.

Before you start configuring, make sure you're running an up-to-date SSH version. Some older versions have known security holes that are easily exploited. Always run the latest stable version, and apply updates or patches in a timely manner. (The same goes for your other security software.)

Always keep important SSH-related files and directories protected. The server's host key should be readable only by root. Each user's home directory, SSH configuration directory, and .rhosts and .shosts files should be owned by the user and protected against all others.

Also, remember that SSH doesn't and can't protect against all threats. It can secure your network connections but does nothing against other types of attacks, such as dictionary attacks against your password database. SSH should be an important part, but not the only part, of a robust security policy. [3.10]

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Before you start configuring, make sure you're running an up-to-date SSH version. Some older versions have known security holes that are easily exploited. Always run the latest stable version, and apply updates or patches in a timely manner. (The same goes for your other security software.)

Always keep important SSH-related files and directories protected. The server's host key should be readable only by root. Each user's home directory, SSH configuration directory, and .rhosts and .shosts files should be owned by the user and protected against all others.

Also, remember that SSH doesn't and can't protect against all threats. It can secure your network connections but does nothing against other types of attacks, such as dictionary attacks against your password database. SSH should be an important part, but not the only part, of a robust security policy. [3.10]

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

In Chapter 4, we covered many compile-time flags for building SSH distributions. Several flags should be carefully set to make your server machine maximally secure:

--sysconfdir=... (OpenSSH, Tectia): Make sure your etc directory is on a local disk, not an NFS-mounted partition. If the SSH server reads a file via NFS, the contents are transmitted in the clear across the network, violating security. This is especially true of the host key, which is stored unencrypted in this directory.
--bindir=... (OpenSSH, Tectia)
--sbindir=... (OpenSSH, Tectia): Likewise, make sure your SSH executables are installed on a local disk, as they can be spoofed if loaded over NFS.
--disable-suid-ssh-signer (Tectia): Our recommended serverwide configuration disables hostbased authentication, so there's no need for setuid permissions for ssh-signer.
--with-tcp-wrappers (OpenSSH)
--with-libwrap (Tectia): libwrap affords more precise control over which client machines are allowed to connect to your server. It also makes port and X forwarding more flexible, since otherwise local forwardings are available either only to the local host or from anywhere at all. With GatewayPorts (or ssh -g) and libwrap, you can limit forwarding access to specific hosts. [9.2.1.1]

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Chapter 5 provided a detailed discussion of sshd and how to configure its runtime behavior. Now let's determine which configuration options are most important for security.

SSH can provide a secure front door into your system, but don't forget to close the back doors. If your system allows access via the infamous r-commands, disable them. This means:

Remove the file /etc/hosts.equiv, or make it a read-only empty file.
Disable rshd, rlogind, and rexecd by removing or commenting out their lines in the inetd or xinetd configuration file. For example, in /etc/inetd.conf you might do:
```
    # turned off -- don't use!

    #shell   stream  tcp   nowait  root  /usr/sbin/in.rshd     in.rshd
```
Make sure you restart inetd or xinetd after doing this so that the change takes effect.
Educate users not to create .rhosts files.

You might also consider disabling telnetd and other insecure avenues for logging in, permitting logins only via SSH.

We'll now discuss our recommended sshd_config settings for OpenSSH. We have omitted some keywords that aren't particularly security-related, such as PrintMotd, which simply prints a message after login. For any remaining keywords, use your judgment based on your system and needs.

Section 10.3.2.1: 10.3.2.1 Choice of protocol

We recommend disabling the SSH-1 protocol altogether:

    # OpenSSH

    Protocol 2

Section 10.3.2.2: 10.3.2.2 Important files

Important files containing your host key, PID, and so on, may be located anywhere on the machine's local disk. For security's sake, don't put them on an NFS-mounted partition. If you do, each time the files are accessed by the SSH server, their contents are transmitted in the clear over the network.

    # OpenSSH

    HostKey /etc/ssh/ssh_host_key

    PidFile /var/run/sshd.pid

Section 10.3.2.3: 10.3.2.3 File and directory permissions

The StrictModes value requires users to protect their SSH-related files and directories, or else they can't authenticate.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Users should be instructed not to create .rhosts files. If hostbased authentication is enabled in the local SSH server, advise users to create .shosts files instead of .rhosts files.

For OpenSSH, each key in ~/.ssh/authorized_keys should be restricted by appropriate options. First, use the from option to restrict access to particular keys by particular hosts when appropriate. For example, suppose your authorized_keys file contains a public key for your home PC, myhome.isp.net. No other machine will ever authenticate using this key, so make the relationship explicit:

    from="myhome.isp.net" ...key...

Also set idle timeouts for appropriate keys:

    from="myhome.isp.net",idle-timeout=5m ...key...

Finally, for each key, consider whether port forwarding, agent forwarding, and tty allocation are ever necessary for incoming connections. If not, disable these features with no-port-forwarding, no-agent-forwarding, and no-pty, respectively:

    from="myhome.isp.net",idle-timeout=5m,no-agent-forwarding ...key...

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

We recommend creating user keys at least 1024 bits long. Protect your key with a good passphrase. Make it lengthy and use a mixture of lowercase, uppercase, numeric, and symbolic characters. Don't use words found in a dictionary.

Empty passphrases should be avoided unless you absolutely need to use one—for example, in an automated batch script. [11.1.2.2]

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Most SSH security pertains to the server, but SSH clients have security-related settings too. Here are a few tips:

Whenever you leave a computer while SSH clients are running, lock the computer's display with a password-protected screen locker. This is particularly important if you're running an agent that permits an intruder to access your remote accounts without a passphrase.
In your client configuration file, turn on some safety features as mandatory values:
```
    # OpenSSH

    # Put at the top of your configuration file

    Host *

      GatewayPorts no

      StrictHostKeyChecking ask

     ForwardX11Trusted no



    # Tectia

    # Put at the bottom of your configuration file

    *:

     GatewayPorts no

     StrictHostKeyChecking ask

     TrustX11Applications no
```
The GatewayPorts value forbids remote clients from connecting to locally forwarded ports. Finally, rather than blindly connect, the StrictHostKeyChecking value warns you of any changed host keys and asks what you want to do. For X11 forwarding we elect to generate a new, untrusted xauth key rather than inherit the trust already in effect. [9.4.5.3]

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

We've mentioned NFS several times as a potential security risk for SSH installations. Now we delve into more detail on this topic.

In today's world of ubiquitous networking, it is common for your home directory to be shared among many machines via a network file-sharing protocol, such as SMB for Windows machines or NFS and AFS for Unix. This is convenient, but it does raise some issues with SSH, both technical and security-related.

SSH examines files in the target account's home directory in order to make critical decisions about authentication and authorization. For every form of authentication except password, the various control files in your home directory (authorized_keys, .shosts, .k5login, etc.) enable SSH access to your account. Two things are therefore important:

Your home directory needs to be safe from tampering.
SSH must have access to your home directory.

The security of shared home directories is often not very high. Although the NFS protocol has versions and implementations that afford greater security, it is woefully insecure in most installations. Often, it employs no reliable form of authentication whatsoever, but rather, uses the same scheme as rsh: the source IP address and DNS identify clients, and a privileged source port is proof of trustworthiness. It then simply believes the uid number encoded in NFS requests and grants access as that user. Breaking into a home directory can be as simple as:

Discover the uid, and create an account with that uid on a laptop running Unix.
Connect that machine to the network, borrowing the IP address of a trusted host.
Issue a mount command, su to the account with the uid, and start rifling through the files.

At this point, an intruder can easily add another public key to authorized_keys, and the account is wide open. The moral is that when designing a system, keep in mind that the security of SSH is no stronger than that of the home directories involved. You need at least to be aware of the trade-off between security and convenience involved here. If you are using an insecure NFS and want to avoid this weakness, you can:

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

OpenSSH and Tectia are complex and have many options. It is vitally important to understand all options when installing and running SSH servers and clients, so their behavior will conform to your local security policy.

We have presented our recommended options for a high security setting. Your needs may vary. For instance, you might want the flexibility of other authentication methods that we have forbidden in our configuration.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

In this chapter we'll delve deeply into some advanced topics: complex port forwarding, integration of SSH with other applications, and more. Some interesting features of SSH don't come to the surface unless examined closely, so we hope you get a lot out of these case studies. Roll up your sleeves, dive in, and have fun.

SSH isn't only a great interactive tool, but also a resource for automation. Batch scripts, cron jobs, and other automated tasks can benefit from the security provided by SSH, but only if implemented properly. The major challenge is authentication: how can a client prove its identity when no human is available to type a password or passphrase? (We'll just write "password" from now on to mean both.) You must carefully select an authentication method, and then equally carefully make it work. Once this infrastructure is established, you must invoke ssh properly to avoid prompting the user. In this case study, we discuss the pros and cons of different authentication methods for operating an SSH client unattended.

Note that any kind of unattended authentication presents a security problem and requires compromise, and SSH is no exception. Without a human present when needed to provide credentials (type a password, provide a thumbprint, etc.), those credentials must be stored persistently somewhere on the host system. Therefore, an attacker who compromises the system badly enough can use those credentials to impersonate the program and gain whatever access it has. Selecting a technique is a matter of understanding the pros and cons of the available methods, and picking your preferred poison.

Rule number 1: forget password authentication if you care about the security of your batch jobs. As we mentioned, authentication for any unattended process will require some kind of persistent secret lying around, so it might seem that a password in a protected file will do as well as anything else, and password authentication is simple. In a strict sense that's correct, but it's a bad idea both practically and securitywise. Embedding a password in a command line is unwise: it may be exposed to other users by simple commands such as

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

SSH isn't only a great interactive tool, but also a resource for automation. Batch scripts, cron jobs, and other automated tasks can benefit from the security provided by SSH, but only if implemented properly. The major challenge is authentication: how can a client prove its identity when no human is available to type a password or passphrase? (We'll just write "password" from now on to mean both.) You must carefully select an authentication method, and then equally carefully make it work. Once this infrastructure is established, you must invoke ssh properly to avoid prompting the user. In this case study, we discuss the pros and cons of different authentication methods for operating an SSH client unattended.

Note that any kind of unattended authentication presents a security problem and requires compromise, and SSH is no exception. Without a human present when needed to provide credentials (type a password, provide a thumbprint, etc.), those credentials must be stored persistently somewhere on the host system. Therefore, an attacker who compromises the system badly enough can use those credentials to impersonate the program and gain whatever access it has. Selecting a technique is a matter of understanding the pros and cons of the available methods, and picking your preferred poison.

Rule number 1: forget password authentication if you care about the security of your batch jobs. As we mentioned, authentication for any unattended process will require some kind of persistent secret lying around, so it might seem that a password in a protected file will do as well as anything else, and password authentication is simple. In a strict sense that's correct, but it's a bad idea both practically and securitywise. Embedding a password in a command line is unwise: it may be exposed to other users by simple commands such as ps, end up in shell history files (e.g. ~/.bash_history) or system logs, etc. In fact, most SSH clients deliberately require terminal input (a "tty") for a password, precisely to discourage this. You can use a tool like Expect to get around this limitation, but that will be awkward. Another practical limitation is that more methods tend to be available on the server side to restrict logins with public-key authentication, e.g., the "command" parameters in

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

One of the most frequently asked questions about SSH is, "How can I use port forwarding to secure FTP?" If the forwarding in question is the traditional sort of static port forwarding provided by SSH clients such as OpenSSH, then the short answer is that you usually can't, at least not completely, as we will explain in detail in this section. Such port forwarding can protect your account password, but usually not the files being transferred. Still, protecting your password is a big win, since the most egregious problem with FTP is that it usually reveals your password to network snoopers.

It's worth noting that FTP can in fact be used securely on its own. Both FTP and Telnet are famously considered "insecure," but it's more accurate to say that they are simply used insecurely most of the time. Both protocols allow the use of strong authentication and encryption methods, such as SSL or Kerberos. However, the vast majority of FTP and Telnet servers in the world do not provide these features, and so we are left trying to secure them as best we can with other tools, such as SSH.

Before trying to figure out how to forward FTP over SSH, you should first ask yourself whether you really need to use FTP at all. If possible, it's far less trouble to simply use a file-transfer method that works easily over SSH, such as scp, sftp, rsync, etc. (and remember that SFTP and FTP have nothing to do with one another, save the acronym). If you're going to secure FTP end-to-end with SSH, then the FTP server must already be running an SSH server—which means it shouldn't be hard to make the requisite files available via SSH as well. But the real world is messy, and you might be stuck with FTP.

As we will describe, the FTP protocol is not amenable to standard SSH port forwarding. There are SSH clients, however, with features tailored specifically for dealing with FTP. We describe two of them here.

Section 11.2.1.1: 11.2.1.1 VanDyke's SecureFX

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Pine is a popular, Unix-based email program from the University of Washington (http://www.washington.edu/pine/). In addition to handling mail stored and delivered in local files, Pine also supports IMAP for accessing remote mailboxes and SMTP for posting mail.

In this case study, we integrate Pine and SSH to solve two common problems:

IMAP authentication: In many cases, IMAP permits a password to be sent in the clear over the network. We discuss how to protect your password using SSH, but (surprisingly) not by port forwarding.
Restricted mail relaying: Many ISPs permit their mail and news servers to be accessed only by their customers. In some circumstances, this restriction may prevent you from legitimately relaying mail through your ISP. Once again, SSH comes to the rescue.

We also discuss techniques to avoid Pine connection delays and facilitate access to multiple servers and mailboxes, including the use of a Pine-specific SSH connection script. This discussion will delve into more detail than the previous one on Pine/SSH integration. [4.5.3]

Like SSH, IMAP is a client/server protocol. Your email program (e.g., Pine) is the client, and an IMAP server process (e.g., imapd ) runs on a remote machine, the IMAP host, to control access to your remote mailbox. Also like SSH, IMAP generally requires you to authenticate before accessing your mailbox, typically by password. Unfortunately, in some cases this password is sent to the IMAP host in the clear over the network; this represents a security risk (see Figure 11-8).

Figure 11-8: A normal IMAP connection

There's no longer any good reason for this. Years ago, security options were rarely available in IMAP software; these days, however, they're common and should be used! There are standard ways to secure IMAP traffic using SSL or Kerberos. With SSL, the entire IMAP session is protected, so even plain password authentication can be used relatively securely. Kerberos can provide secure authentication and single-signon with or without session encryption; for example, the Apple Mail client implements both. Pine uses Kerberos only for authentication, not encryption—but you can combine Kerberos with SSL to get both single-signon and privacy. Note the power of having multiple independent and standards-based options available!

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

All along we've assumed that your outgoing connectivity is unlimited: that you can establish any outgoing TCP connection you desire. Even our discussions of firewalls have assumed that they restrict only incoming traffic. In more secure (or simply more regimented) environments, this might not be the case: in fact, you might not have direct IP connectivity at all to the outside world.

In the corporate world, companies commonly require all outgoing connections to pass through a proxy server or gateway host : a machine connected to both the company network and the outside. Although connected to both networks, a gateway host doesn't act as a router, and the networks remain separated. Rather, it allows limited, application-level access between the two networks.

In this case study, we discuss issues of SSH in this environment:

Connecting transparently to external hosts using chained SSH commands
Making scp connections to these hosts
Running SSH-within-SSH by port forwarding
Running SSH-within-SSH by ProxyCommand

These gateway techniques apply equally well when the situation is reversed: you're on an external machine, and need to access various internal hosts through a single SSH gateway.

Suppose your company has a gateway host, G, which is your only gateway to the Internet. You are logged into a client host, C, and want to reach a server host, S, outside the company network, as shown in Figure 11-11. We assume that all three machines have SSH installed.

Figure 11-11: Proxy gateway

To make a connection from client C to server S now requires two steps:

Connect from C to gateway G:
```
    # Execute on client C

    $ ssh G
```
Connect from G to server S:
```
    # Execute on gateway G

    $ ssh S
```

This works, and using agent forwarding and public-key authentication on both hosts, you can avoid a second authentication prompt on gateway G.

Now, an obvious simplification would be this single command:

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

One of the main strengths of SSH is easy setup. Install an SSH server on one host and a client on another, and you immediately have secure login via password. Generate a key pair and put the public key on the server, and you immediately have even better authentication, and single-signon. This lightweight approach is one of the main reasons for the initial popularity of SSH.

No solution fits all situations, however, and this simplicity becomes a liability as the number of users and hosts grows. In large installations, managing both server and user authentication becomes difficult. Every time you add an SSH server host, or change its name, or add an alias for it, you must update the global known-hosts list. This by itself may be a practically impossible task, because there are no standards for representing these lists. OpenSSH uses one format, Tectia another; some Windows-based clients keep them in a file, some in the registry. Even if you had a means to generate lists for all your SSH clients in their various native formats, many of the actual client machines may be unreachable for updates (remote machines, laptops, etc.).

At all too many companies, the difficulty of managing SSH server keys leads to a very lax approach to server verification. Users frequently see warning messages about missing or changed keys, and the IT staff tells them to "just accept the new key." Very soon, these messages are completely ignored by everyone—or worse, just made to go away entirely! We've actually encountered an SSH installation with this configuration:

    # /etc/ssh/ssh_config

    GlobalKnownHostsFile   /dev/null

    UserKnownHostsFile     /dev/null

    StrictHostKeyChecking  no

Scary, but understandable; SSH had cried wolf one too many times. Unfortunately, effectively skipping server authentication disables a vital part of SSH security: resistance to server host spoofing and man-in-the-middle attacks! This situation also makes it impractical to replace server keys periodically, as should be done, or to revoke a key in case it is known to be compromised (i.e., tell clients to no longer trust it).

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

In Chapter 5, we described the server configuration files in detail, including OpenSSH's sshd_config and Tectia's sshd2_config. Tectia provides several levels of configuration not found in OpenSSH, called metaconfiguration and subconfiguration, and also some unusual rules for quoted values. We now cover them in detail.

Tectia recognizes specially structured comments at the beginning of configuration files. These lines determine the syntax rules for the rest of the file, and are therefore called metaconfiguration information.

Configuration files distributed with Tectia all start with lines of the form:

    ## SSH CONFIGURATION FILE FORMAT VERSION 1.1

    ## REGEX-SYNTAX egrep

    ## end of metaconfig

    ## (leave above lines intact!)

The first line specifies the syntax version number, and defines the start of the metaconfiguration information. Increasing syntax version numbers allow the syntax rules to be extended, possibly in incompatible ways. As long as older configuration files explicitly specify their syntax versions, they can still be correctly understood by newer versions of the Tectia server.

The default syntax version (used if there is no metaconfiguration information) is 1.0. This refers to the "traditional" syntax rules understood by Tectia versions before Version 3.0.0 (when the metaconfiguration information syntax was introduced). The latest syntax version at press time is 1.1.

Syntax rules are further refined by lines that immediately follow the syntax version. These lines contain pairs of metaconfiguration parameter names and values, and look similar to the keyword lines in the rest of the configuration file, with two important differences:

The pairs occur within comment lines.
The metaconfiguration parameter names must always be uppercase.

Syntax Version 1.1 adds support for the REGEX-SYNTAX parameter, which determines how regular expressions are interpreted. The three standards are:

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

The Tectia server can use external programs, known as plugins , for flexible handling of tasks like changing passwords [5.4.2.3], driving the process for keyboard-interactive authentication [5.4.5.2], or performing arbitrary checks for access control. [5.5.6] We'll demonstrate how to use plugins with several examples:

Handling expired passwords
Extending keyboard-interactive authentication
Authorization

Remember our discussion of expired passwords in Chapter 5? [5.4.2.3] We showed how Tectia's SSH server can detect an expired password at authentication time, and prompt the user to change it:

    $ ssh server.example.com

    rebecca's password:< ... old, expired password ... >

    Authentication successful.

    < ... the following output is from running the passwd forced command ... >

    Changing password for user rebecca.



    Changing password for rebecca

    (current) UNIX password: < ... old, expired password, again ... >

    New password: < ... new password ... >

    Retype new password: < ... new password, again ... >

    passwd: all authentication tokens updated successfully.

    Connection to server.example.com closed.

The SSH server accomplishes this by calling either the system password-change program (e.g., passwd) or an alternative program specified by the PasswdPath configuration keyword. This technique, which is the default, uses a forced command to change the password. This method is conceptually simple but has several drawbacks:

No explicit indication is given that the password is expired, or that a forced command is being used. Of course, the prompts from the password-change program are a clue, but a user might be (understandably!) suspicious about prompts that demand passwords for no apparent reason. Furthermore, if the user intends to run some other command with similar prompts for unrelated passwords, she might be confused by unexpected interactions with the password-change program.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

OpenSSH and Tectia are complex products. When a problem occurs, your plan of action should be, in order:

Run the client and server in debug mode.
Consult archives of questions and answers to see if anyone else has encountered and solved this problem.
Seek help.

Many people jump immediately to Step 3, posting questions in public forums and waiting hours or days for a reply, when a simple ssh -v or FAQ can clarify the problem in moments. Be a smart and efficient technologist, and use your available resources before seeking help from the community. (Although the SSH community is eager to help if you've done your homework.)

SSH clients and servers have debugging built in. When invoked with appropriate options, these programs emit messages about their progress and failures. You can use these messages to isolate problems.

Most clients print debug messages when invoked with the -v (verbose mode) option: [7.4.17]

    $ ssh -v server.example.com

    $ scp -v myfile server.example.com:otherfile

So many problems can be identified in verbose mode. This should be your first instinct whenever you encounter a problem.

Please take a deep breath and repeat after us:

    "ssh -v is my friend...."

    "ssh -v is my friend...."

    "ssh -v is my friend...."

The OpenSSH and Tectia servers also print debug messages when asked: [5.9]

    # OpenSSH

    $ sshd -d -e



    # Tectia

    $ sshd -v

    $ sshd -ddebug_spec

In either case, the server enters a special debugging mode. It accepts a single connection, operates normally until the connection terminates, and then exits. It doesn't go into the background or create a child process to handle the connection, and it prints information on its progress to the screen (that is, to the standard error stream).

Tectia has a more complicated system for debugging: numeric debugging levels, specified with the -d option, where a higher number means more information. [5.9] In fact, -v for verbose mode is actually just a shorthand for

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

SSH clients and servers have debugging built in. When invoked with appropriate options, these programs emit messages about their progress and failures. You can use these messages to isolate problems.

Most clients print debug messages when invoked with the -v (verbose mode) option: [7.4.17]

    $ ssh -v server.example.com

    $ scp -v myfile server.example.com:otherfile

So many problems can be identified in verbose mode. This should be your first instinct whenever you encounter a problem.

Please take a deep breath and repeat after us:

    "ssh -v is my friend...."

    "ssh -v is my friend...."

    "ssh -v is my friend...."

The OpenSSH and Tectia servers also print debug messages when asked: [5.9]

    # OpenSSH

    $ sshd -d -e



    # Tectia

    $ sshd -v

    $ sshd -ddebug_spec

In either case, the server enters a special debugging mode. It accepts a single connection, operates normally until the connection terminates, and then exits. It doesn't go into the background or create a child process to handle the connection, and it prints information on its progress to the screen (that is, to the standard error stream).

Tectia has a more complicated system for debugging: numeric debugging levels, specified with the -d option, where a higher number means more information. [5.9] In fact, -v for verbose mode is actually just a shorthand for -d2. At higher debug levels, the output is so huge that only SSH developers will likely find it of use in tracking down obscure problems. But you may need to crank up the level beyond 2 to see the information you need. For example, to have it report which algorithms are negotiated for a connection, use -d3. If you get the error message "TCP/IP Failure," turning up to -d5 shows the more specific OS-level error message returned from the connection attempt.

When debugging a server, remember to avoid port conflicts with any other running SSH server. Either terminate the other server, or use an alternative port number for debugging via the

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

In this section, we cover a wide range of difficulties, organized by category. The sidebar "The Top 10 SSH Questions" lists what, in our experience, are the most frequently asked of the frequently asked questions. We focus on problems that may occur in many versions of the SSH software on diverse operating systems. We don't address the sorts of questions shown next that rapidly become obsolete.

Compilation problems specific to one operating system, such as "HyperLinux beta 0.98 requires the --with-woozle flag"
Problems and bugs that are specific to one version of SSH, particularly older versions

In all questions, we will assume you have already used debug or verbose mode (e.g., ssh -v) to isolate the problem. (If you haven't, you should!)

Q:

The commands ssh, scp, ssh-agent, ssh-keygen, etc., aren't doing what I expect. Even the help messages look weird.

A:

Maybe they are Tectia programs when you are expecting OpenSSH, or vice versa. Try running these commands to find out:

    $ ssh -V

    $ ssh --help

Q:

When I try to connect to an SSH server, I get the error "Connection refused."

A:

No SSH server is running where you tried to connect. Double-check the hostname and TCP port number: perhaps the server is running on a port different from the default?

Q:

When I log in, the message of the day (/etc/motd) prints twice.

A:

Both sshd and the login program are printing it. Disable sshd's printing by setting the serverwide configuration keyword PrintMotd to no.

Q:

When I log in, I see two messages about email, such as "No mail" or "You have mail."

A:

Both sshd and the login program are checking for mail. Prevent sshd from checking by setting the serverwide configuration keyword CheckMail to no.

Section 12.2.2.1: 12.2.2.1 General authentication problems

Q:

The SSH server says "Permission denied" and exits.

A:

This occurs if all authentication techniques have failed. Run your client in debug mode and read the diagnostic messages, looking for clues. Also read our solutions to specific authentication problems in the rest of this section.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

If we haven't answered your questions in this chapter, try the following good sources of help available on the Internet.

The SSH home page, maintained by SSH Communications Security, is also a good resource of general information and links to related content:

http://www.ssh.com/

Information on OpenSSH can be found at:

http://www.openssh.com/

And of course, check out this book's web sites:

http://www.oreilly.com/catalog/sshtdg/
http://www.snailbook.com/

On Usenet, the newsgroup comp.security.ssh discusses technical issues about SSH. If you don't have Usenet access, you can read and search for its articles on the Web at Google Groups:

http://groups.google.com/

or any other site that archives Usenet posts.

Before posting a troubleshooting question, run the SSH client and server in debug or verbose mode and include the full text of the debug messages in your note.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

SSH products are available not only for Unix, but also for Windows, Macintosh, Amiga, OS/2, VMS, BeOS, PalmOS, Windows CE, and Java. Some programs are original, finished products, and others are ports of OpenSSH or of Tectia ancestors, undertaken by volunteers and in various stages of completion.

In the remaining chapters of this book, we cover several robust implementations of SSH for Windows and the Macintosh. But first, in this chapter, we quickly survey SSH products for many platforms.

We have set up a web page pointing to SSH-related products that we know. From this book's catalog page:

http://www.oreilly.com/catalog/sshtdg/

follow the link labeled Author's Online Resources, or visit us directly at:

http://www.snailbook.com/

Also check out this third-party page listing many free SSH implementations:

http://www.freessh.org/

Every SSH implementation has a different set of features, but virtually all have one thing in common: a client program for logging into remote systems securely. Some clients are command line-based, and others operate like graphical terminal emulators, opening windows with dozens of configurable settings.

The remaining features vary widely across implementations. Secure file copy (scp and sftp), remote batch command execution, SSH servers, SSH agents, and particular authentication and encryption algorithms are found in only some of the products. Most include a generator of public and private keys.

For Microsoft Windows, we cover in full chapters:

OpenSSH, ported to Windows using the Cygwin library (Chapter 14)
Tectia's commercial products for Windows (Chapter 16)
SecureCRT, a commercial SSH client by VanDyke Software (Chapter 17)
PuTTY, a small, free suite of SSH clients (Chapter 18)

For Macintosh OS X, we cover in a full chapter:

OpenSSH, as included with Macintosh OS X (Chapter 15)

Unfortunately we can't cover every SSH implementation, but here are summaries to aid your explorations. Because SSH products need to remain secure, we list only products that are in active development (or at least have been updated in the past year or two) and that support the SSH-2 protocol. This means we've intentionally left out dozens of older SSH products with respected histories, like NiftyTelnet SSH for the Mac, Top Gun SSH for Palm, FISH for VMS, and Sergey Okhapkin's classic Windows port of the original SSH1. Old-timers like these have their place in history, but have been supplanted by more modern implementations.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Every SSH implementation has a different set of features, but virtually all have one thing in common: a client program for logging into remote systems securely. Some clients are command line-based, and others operate like graphical terminal emulators, opening windows with dozens of configurable settings.

The remaining features vary widely across implementations. Secure file copy (scp and sftp), remote batch command execution, SSH servers, SSH agents, and particular authentication and encryption algorithms are found in only some of the products. Most include a generator of public and private keys.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

For Microsoft Windows, we cover in full chapters:

OpenSSH, ported to Windows using the Cygwin library (Chapter 14)
Tectia's commercial products for Windows (Chapter 16)
SecureCRT, a commercial SSH client by VanDyke Software (Chapter 17)
PuTTY, a small, free suite of SSH clients (Chapter 18)

For Macintosh OS X, we cover in a full chapter:

OpenSSH, as included with Macintosh OS X (Chapter 15)

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Unfortunately we can't cover every SSH implementation, but here are summaries to aid your explorations. Because SSH products need to remain secure, we list only products that are in active development (or at least have been updated in the past year or two) and that support the SSH-2 protocol. This means we've intentionally left out dozens of older SSH products with respected histories, like NiftyTelnet SSH for the Mac, Top Gun SSH for Palm, FISH for VMS, and Sergey Okhapkin's classic Windows port of the original SSH1. Old-timers like these have their place in history, but have been supplanted by more modern implementations.

We've organized the products by platform. Some products are free and others are shareware or commercial, usually quite inexpensive. Additionally, many of the commercial products have free evaluation versions available, so you can try before you buy.

At press time, we have found no modern SSH clients for BeOS. There are a bunch of ancient ones (2000-2002) supporting the old SSH-1 protocol: search http://www.bebits.com/ to find them.

At press time, we have found no modern SSH clients for the Amiga. The closest is an Amiga port of OpenSSH (http://www.chernoff.org/amiga/, free). However, it's a port of Version 3.0.2, which is several years out of date.

ssh.el (http://www.splode.com/~friedman/software/emacs-lisp/src/ssh.e l, free) is an Emacs interface for SSH client connections. It does not implement SSH itself, but invokes an external client (e.g., ssh from OpenSSH or Tectia) within Emacs.

JavaSSH (http://javassh.org/, free), a.k.a. Java Telnet/SSH Applet, is just what it sounds like: an SSH client applet.

JSch (http://www.jcraft.com/jsch/, free), a.k.a. Java Secure Channel, is an implementation of the SSH-2 protocol.

MindTerm (http://www.mindbright.se/, commercial, but free for personal or limited commercial use) is an SSH client and terminal emulator. The same company sells Appgate Security Server, an enterprise-level security product with SSH capabilities.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

OpenSSH, though originally written for Unix-like operating systems, runs well under Windows too. If you prefer command-line programs rather than a GUI, OpenSSH is probably your best bet for a free SSH implementation.

In order to run OpenSSH on Windows, you must install the Cygwin library (http://www.cygwin.com/) and associated programs. The installation is pretty simple but large: some users complain about the added "bloat" of Cygwin's many programs. If this concerns you, check out OpenSSH For Windows (http://sshwindows.sourceforge.net/), a minimal installation of OpenSSH and Cygwin. Our perspective, however, is that Cygwin comes with so many mind-bogglingly useful tools (ported from Unix) that you might as well do a full install.

In most cases, OpenSSH operates the same way under Windows as it does under Unix. In this chapter we'll cover only the differences; in Chapter 15 we will cover OpenSSH on the Macintosh similarly.

Like Unix, Cygwin uses the term "directory" to refer to a folder. We will use the Cygwin terminology.

Cygwin is available from http://www.cygwin.com/. Download the installation program and run it. Make sure to install the following packages:

openssh: The full suite of programs and support files
cygrunsrv: A program needed to run sshd as a Windows service

Once Cygwin is installed, complete the setup:

Make sure that c:\cygwin\bin is in your search path.
Create an environment variable called CYGWIN, and give it the value ntsec tty.

The client programs ssh, scp, and sftp work just as they do on Unix:

    # Log into server.example.com as user smith

    $ ssh -l smith server.example.com



    # Copy myfile from your local machine to server.example.com

    $ scp myfile server.example.com:



    # Run an interactive file-copy session with sftp

    $ sftp server.example.com

The only bit of trickiness is locating your ~/.ssh directory via Windows. On Unix platforms, your home directory is located in an obvious place, usually /home/

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Cygwin is available from http://www.cygwin.com/. Download the installation program and run it. Make sure to install the following packages:

openssh: The full suite of programs and support files
cygrunsrv: A program needed to run sshd as a Windows service

Once Cygwin is installed, complete the setup:

Make sure that c:\cygwin\bin is in your search path.
Create an environment variable called CYGWIN, and give it the value ntsec tty.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

The client programs ssh, scp, and sftp work just as they do on Unix:

    # Log into server.example.com as user smith

    $ ssh -l smith server.example.com



    # Copy myfile from your local machine to server.example.com

    $ scp myfile server.example.com:



    # Run an interactive file-copy session with sftp

    $ sftp server.example.com

The only bit of trickiness is locating your ~/.ssh directory via Windows. On Unix platforms, your home directory is located in an obvious place, usually /home/ yourname. And in fact, if you run a Cygwin shell, you can literally refer to /home/ yourname as well. But what if you're using a standard Windows command shell (e.g., cmd) or browsing files with Windows Explorer: how can you find your ~/.ssh directory? Simply type this command from a Windows command shell:

    C:\> cygpath -w ~

    C:\cygwin\home\smith

The cygpath command converts Cygwin paths into Windows paths, and the lone tilde (~) represents your Cygwin home directory. In this example, cygpath reveals your home directory to be C:\cygwin\home\smith. Thus, your SSH-related client files will be stored in the directory C:\cygwin\home\smith\.ssh.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

The SSH server, sshd, runs under Cygwin as a standard Windows service, called (not surprisingly) Cygwin SSH Service. Cygwin provides a script, called ssh-host-config, to set this up. Here's what to do:

The Cygwin SSH Service (a.k.a. sshd) runs only on flavors of Windows that support services: NT, 2000, XP, 2003, etc.

Make sure you've set up the path and environment variables for OpenSSH and Cygwin. [14.1]
From an account with administrative privileges, run:
```
    C:\> ssh-host-config
```
Answer yes to all questions.
When ssh-host-config completes, your service should be ready to run. Open your Services control panel, look for Cygwin SSHD Service, and start the service. Alternatively, use the command line:
```
    C:\> net start sshd
```
You might also want to set the service startup to Automatic, so it runs whenever you boot the computer. To stop the service, again use the Services control panel or type:
```
    C:\> net stop sshd
```

If the service refuses to run, here are some things to try:

Make sure the file /var/log/sshd.log is writable by the SYSTEM account.
Read /var/log/sshd.log for error messages.

To test the server, connect to yourself:

    C:\> ssh localhost

You should be prompted for your password and be able to log in.

Serverwide configuration files are found in /etc, such as /etc/sshd_config. This is in contrast to Unix-like systems that usually keep these files in /etc/ssh.

If you want to run graphical applications via ssh that open windows, such as notepad or regedit:

    C:\> ssh my-pc-name notepad

this will not work unless you grant sshd permission to do so. Here's how to do it on Windows XP and 2000:

Open the Services control panel.
Stop the Cygwin sshd service.
Double-click the Cygwin sshd service to view its properties.
Select the Log On tab.
Under "Log on as," select the Local System account and check the box "Allow service to interact with desktop."
Click OK and restart the Cygwin sshd service.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

The OpenSSH clients--ssh, scp, and sftp--and the key-related programs--ssh-keygen, ssh-agent, and ssh-add (covered in Chapter 6)--use public-key authentication just as they do under Unix. You might need to know where your ~/.ssh folder is to refer to keys. [14.2]

When connecting to the Cygwin SSHD Service (sshd) from the outside world, there are a few things to think about:

Make sure your ~/.ssh/authorized_keys file contains the appropriate public keys. [6.1.1]
Check the Cygwin SSHD Service in the Services control panel, and note the NT user account under which it is running. Then make sure that this account:
- Has read access to your ~/.ssh directory and your ~/.ssh/authorized_keys file.
- Has read access to the host keys in the Cygwin /etc directory.
- Has write access to the log file /var/log/sshd.log.
- Is in the local Administrators group, if you plan to invoke operations by SSH that require administrative privileges. Then authenticate using this account. (For more flexible credentials, consider a PKI solution. [11.5] Cygwin includes a Kerberos package.)
- Is listed in the Cygwin /etc/passwd file. Use the Cygwin mkpasswd program to generate this file if you need; for example, in the Cygwin shell:
```
    $ mkpasswd -l > /etc/passwd
```
  but make sure you understand what you're doing so that you don't wipe out vital accounts! Run man mkpasswd to learn more.

An agent is a program that keeps private keys in memory and provides authentication services to SSH clients. If you preload an agent with private keys at the beginning of a login session, your SSH clients won't prompt for passphrases. Instead, they communicate with the agent as needed. [2.5] The OpenSSH agent program is ssh-agent.

In order for ssh-agent to work, it communicates via environment variables. [6.3.2] If you're using the Cygwin shell (bash), you can start the agent via the same methods as on Unix. Unfortunately, these methods don't work immediately on Windows if you're using the command shell (

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

The following lists some ideas for troubleshooting :

If /var/log/sshd.log says "Privilege separation user sshd does not exist," then either turn off privilege separation in /etc/sshd_config, or create the "sshd" account (e.g., with Cygwin's useradd command).
Run filemon from the command line, and look for accesses to the ~/.ssh directory.
In the Local Security Policy administrative tool, turn on auditing for object access: this is found under Local Policies/Audit Policy. Set it to audit both success and failure. Then select the ~/.ssh folder and enable this auditing for all accesses to the folder and its contents (Properties/Security/Advanced/Auditing).

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

The full-featured OpenSSH suite runs on Windows for free. What could be better?

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

OpenSSH is supplied with Macintosh OS X and runs much like it does for other Unix-like operating systems. The primary differences and distinguishing features are:

Some extra setup before the OpenSSH server, sshd, can be accessed by the outside world
The software, which is a modified version of OpenSSH maintained by Apple
Some important differences in the way sshd is configured by default, such as invocation and Kerberos support

The usual OpenSSH clients, ssh, scp, and sftp, work normally without any extra effort on your part:

    # Log into server.example.com as user smith

    $ ssh -l smith server.example.com



    # Copy myfile from your local machine to server.example.com

    $ scp myfile server.example.com:



    # Run an interactive file-copy session with sftp

    $ sftp server.example.com

Before you can use sshd on Mac OS X, you'll need to enable the server and possibly open up the Mac's firewall. In addition, you'll want to know about some configuration differences as compared to most other OpenSSH installations.

SSH server startup is controlled from the Sharing pane in System Preferences, under Services, as in Figure 15-1. To enable sshd, select Remote Login and click the Start button.

Figure 15-1: Enabling the SSH server in System Preferences

By default, the Mac OS X personal firewall will block SSH connections from the outside world. If you have this firewall enabled, you must manually permit SSH traffic through it. This is done from the Sharing pane in System Preferences, under Firewall, as in Figure 15-2.

Figure 15-2: Opening a firewall hole for SSH in System Preferences

In most Unix-like operating systems, the OpenSSH server runs as a daemon, listening for SSH connections. On Mac OS X, however, sshd is controlled by the super-server daemon, xinetd. [5.3.3.2] Whenever an SSH client attempts to contact sshd on TCP port 22, xinetd notices the attempt and invokes a single instance of

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

The usual OpenSSH clients, ssh, scp, and sftp, work normally without any extra effort on your part:

    # Log into server.example.com as user smith

    $ ssh -l smith server.example.com



    # Copy myfile from your local machine to server.example.com

    $ scp myfile server.example.com:



    # Run an interactive file-copy session with sftp

    $ sftp server.example.com

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Before you can use sshd on Mac OS X, you'll need to enable the server and possibly open up the Mac's firewall. In addition, you'll want to know about some configuration differences as compared to most other OpenSSH installations.

SSH server startup is controlled from the Sharing pane in System Preferences, under Services, as in Figure 15-1. To enable sshd, select Remote Login and click the Start button.

Figure 15-1: Enabling the SSH server in System Preferences

By default, the Mac OS X personal firewall will block SSH connections from the outside world. If you have this firewall enabled, you must manually permit SSH traffic through it. This is done from the Sharing pane in System Preferences, under Firewall, as in Figure 15-2.

Figure 15-2: Opening a firewall hole for SSH in System Preferences

In most Unix-like operating systems, the OpenSSH server runs as a daemon, listening for SSH connections. On Mac OS X, however, sshd is controlled by the super-server daemon, xinetd. [5.3.3.2] Whenever an SSH client attempts to contact sshd on TCP port 22, xinetd notices the attempt and invokes a single instance of sshd (specifically, sshd -i) to serve that connection.

The xinetd configuration file for sshd is /etc/xinetd.d/ssh:

    # /etc/xinetd.d/ssh:

    service ssh

    {

            disable = no



            socket_type     = stream

            wait            = no

            user            = root

            server          = /usr/libexec/sshd-keygen-wrapper

            server_args     = -i

            groups          = yes

            flags           = REUSE IPv6

            session_create  = yes

    }

Note the use of the wrapper script sshd-keygen-wrapper: it will generate new host keys if they are missing, as after a fresh OS install.

On Mac OS X, the serverwide configuration files are found in the /etc directory instead of the more common /etc/ssh: for example, the serverwide configuration file is

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Our treatment of Tectia in previous chapters has focused on Unix implementations, but Tectia is fully supported on Microsoft Windows platforms. It's packaged as a suite of products, including:

Tectia Client: A GUI application that initiates outgoing SSH connections, with a terminal emulator, supporting key-management functionality, port forwarding, and file transfers using SFTP, plus command-line programs for scripting
Accession Lite: An authentication agent
Tectia Connector: Transparent, dynamic port forwarding for selected applications
Tectia Server: A service to accept incoming SSH connections

At press time, the Tectia products can be installed on the versions of Windows listed in Table 16-1. Consult the latest documentation for a complete list of supported platforms.

Table 16-1: Supported Microsoft Windows platforms for SSH Tectia
Program	95	98	Me	NT	2000	XP	Server 2003
Tectia Client	-	any	any	4.0SP6	SP2	any	any
Accession Lite	-	any	any	4.0SP6	SP2	any	any
Tectia Connector	-	-	-	4.0SP6	SP2	SP1	-
Tectia Server	-	-	-	4.0SP6	SP2	any	any

Tectia products are shipped as Windows Installer Packages. The easiest way to install is to use Windows Explorer to double-click on the included .msi files:

TectiaClient-version.msi
TectiaConnector-version.msi
TectiaServer-version.msi

These files can be found in the install/windows folder on your distribution media, or downloaded from the ssh.com web site, depending on how you purchased the products. The installers must be run by a user with administrative privileges. Installing the Connector package requires a reboot.

During interactive installation, you'll see a series of dialogs; use these to specify the install directory if the default location is not appropriate. By default, Tectia products are installed within the Program Files folder in a Tectia subfolder named SSH Communications Security. Files for each product are collected in separate subfolders under the Tectia subfolder:

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Tectia products are shipped as Windows Installer Packages. The easiest way to install is to use Windows Explorer to double-click on the included .msi files:

TectiaClient-version.msi
TectiaConnector-version.msi
TectiaServer-version.msi

These files can be found in the install/windows folder on your distribution media, or downloaded from the ssh.com web site, depending on how you purchased the products. The installers must be run by a user with administrative privileges. Installing the Connector package requires a reboot.

During interactive installation, you'll see a series of dialogs; use these to specify the install directory if the default location is not appropriate. By default, Tectia products are installed within the Program Files folder in a Tectia subfolder named SSH Communications Security. Files for each product are collected in separate subfolders under the Tectia subfolder:

SSH Secure Shell
SSH Accession Lite
SSH Tectia Connector
SSH Secure Shell Server

We'll refer to these as the "installation folders." The installers also create entries in the Start/Programs menu, under the program groups:

SSH Tectia Client
SSH Tectia Connector
SSH Tectia Server

The installer for the Client package optionally creates desktop icons for the GUI client application:

SSH Tectia Client
SSH Tectia Client - File Transfer

The PATH environment variable is updated to include the installation folder for the Client package, so scripts can easily access command-line programs.

The Server installer generates host key files by running ssh-keygen2 in a command window: this can take several minutes to complete. The server is added as a service that starts automatically whenever the system boots.

Tectia products can also be installed silently, using the msiexec command-line tool:

    C:\> msiexec /q /i Tectia<Product>-<version>.msi INSTALLDIR="<path>"

If the INSTALLDIR argument is omitted, the default locations are used. Silent installation is handy for rolling out products to a large number of systems.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

When you run the GUI client application (typically via the desktop icon or the Start menu), it displays a terminal window. To initiate an outgoing connection, do one of the following:

Click on the Connect toolbar icon.
Use the File/Connect menu item.
Press the Enter key or space bar within an unconnected terminal window.

This brings up the Connect To Remote Host dialog shown in Figure 16-1. Fill out the values for the server's hostname, the remote username (on the server), and the port number (if different from the default 22); select an authentication method from the drop-down menu; and finally click Connect. If the host key for the server has not been seen before, the client prompts for confirmation before saving it, as in Figure 16-2. Respond to the prompts demanded by subsequent dialogs, which depend on the authentication method chosen.

Figure 16-1: The Connect to Remote Host dialog

Figure 16-2: Encountering a previously unknown host key

If authentication succeeds and the server grants access, you can work within the terminal window in Figure 16-3.

You can create additional sessions on the same server by using the New Terminal Window toolbar icon or the Window/New Terminal menu item. These sessions run in separate terminal windows, and are tunneled through different channels within the existing SSH connection, so no additional authentication is required.

The client disconnects automatically when the last session terminates. If you need to disconnect manually for some reason, use the Disconnect toolbar icon or the File/Disconnect menu item.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

To manage the key pairs that are used for public-key authentication, use the Keys page (Figure 16-4) of the Settings dialog, which is accessed by either the Settings toolbar icon or the Edit/Settings menu item. The Settings dialog is a GUI-based interface to the functionality provided by the ssh-keygen2 command-line program.

Click Generate New Keypair to start the Key Generation Wizard, which presents a dialog that prompts for the key type (DSA or RSA) and key length, generates the key (this can run for several minutes, which provides plenty of time to appreciate an animated display of random bits), and finally prompts for a filename to store the key, an optional comment, and the passphrase.

To copy a key pair from files in some other location to the user profile folder, click Import. If an existing key is selected, click Export to copy the key pair from the user

Figure 16-3: Terminal window

profile folder to some other folder, or Delete to remove the key pair, or Change Passphrase to present a dialog that prompts for the old and new passphrases.

Click Upload to conveniently transfer a selected public key to a server using sftp, and automatically add an entry in the authorization file so that the key will be used. This assumes you have already authenticated using some other mechanism. A dialog allows the destination folder and authorization filename to be changed if the default locations on the server are not appropriate.

To view the contents of the public-key file (using the Notepad editor), double-click on a key in the list, or select a key and click View.

Finally, click Configure to update the identification file that is used by the ssh2 command-line program. All keys in the list are included; the identification file must be edited manually if some keys should be excluded.

Figure 16-4: Keys page of the Settings dialog

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Accession Lite is started automatically when each user logs in; it acts as an authentication agent. The GUI application provides the same functionality as the ssh-agent and ssh-add programs that are used on Unix systems.

The easiest way to access the Accession Lite GUI, shown in Figure 16-5, is to double-click the icon in the tool tray on the taskbar. The Tectia Client and Connector applications also have icons and menus for Accession Lite. Normally, Accession Lite stops automatically when the user logs out (or the system is shut down), but if it needs to be stopped manually for some reason, use the File /Quit menu item.

Figure 16-5: Accession Lite

The main Accession Lite window displays information about the loaded keys and a log of its operations in separate panes.

The toolbar icons or equivalent items in the Tools menu can be used to perform actions:

Add a key to the agent: a series of dialogs prompt for the filename and a passphrase.
Delete a selected key from the agent.
Lock or unlock a selected key: dialogs prompt for a passphrase.
Edit attributes for a selected key: this presents the Key Attributes page (Figure 16-6) of the Settings dialog, which can also be obtained via the Settings toolbar icon or the Edit/Settings menu item.

The default attributes apply to all of the keys, unless overridden for specific keys. Keys can be set to expire after a specified time, and can be limited to a maximum number of uses. Forwarding can be restricted to a limited number of hops, or more

Figure 16-6: Key Attributes page of Accession Lite

generally according to a constraint string, which uses the same syntax as the ssh-add -F option. [6.3.3]

A short alias can be assigned to each key; these are optionally displayed by the GUI instead of the more verbose descriptions according to settings on the Appearance page.

"Enable key compatibility" means that SSH-1 keys can be used by SSH-2 clients, and vice versa. Support for SSH-1 and SSH-2 client connections is controlled independently by checkboxes on the Compatibility page.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Most of the time, the Tectia GUI applications effectively act as configuration editors, allowing users and administrators to change and save the configuration without worrying about the location or format of configuration files. In some other circumstances, however, an understanding of these details is useful, so we'll provide a brief guided tour through the internal structure of Tectia's configuration on Windows.

The system client configuration file ssh2_config is stored in the Tectia client installation folder. This file has the same format and function as the /etc/ssh2/ssh2_config file on Unix systems.[7.1.2.2]

Most other parts of the configuration are separately maintained for each user, and are stored in the user profile folder in the application data subfolder. Tectia configuration files are collected in a subfolder named SSH. This folder is analogous to the user configuration folder on Unix systems (typically ~/.ssh2, but ultimately determined by the UserConfigDirectory keyword), although the specific files and folder layout are different for Windows, as we'll see. [5.3.1.5]

If roaming profiles are used, then the user profile folder is replicated on a server, and files are transmitted to client machines via the network, where they can be seen by anyone who is able to sniff traffic en route. To prevent this, either disable roaming profiles for Tectia users, or store the Tectia configuration files in a different, local folder. If the SSHCLIENT_USERPROFILE environment variable is set, its value specifies an alternate location to be used for the Tectia configuration files, instead of the user profile folder.

The Tectia user configuration folder contains:

RandomSeed: A pool of random data. [7.4.18]
HostKeys: A subfolder to store public keys for known hosts. [7.4.3]
UserKeys: A subfolder for storing user identities.
identification: A list of keys used by the command-line client, ssh2.exe. This file can be produced automatically by the GUI client. [16.3] If the

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Port forwarding allows Tectia to tunnel TCP connections through multiplexed channels within an existing SSH connection. [9.2] To set up forwarding, use the Tunneling page (Figure 16-7) of the Settings dialog which is accessed by either the Settings toolbar icon or the Edit/Settings menu item. Local and remote forwarding (specified by the -L and -R options for the ssh2 command-line client) correspond to outgoing and incoming tunnels, respectively, for the GUI client.

Figure 16-7: Tunneling page

Configure forwarding by first selecting the Outgoing or Incoming tab. Click Add to define settings for a new port forwarding, using a separate dialog (Figure 16-8), or click Edit to redefine settings for a selected existing forwarding, using a similar dialog. Click Remove to destroy a selected forwarding.

Figure 16-8: Defining settings for a new port forwarding

Settings for each forwarding include:

A descriptive name, for the displayed list
The port on which to listen, either on the client side (for local forwarding or outgoing connections) or on the server side (for remote forwarding or incoming connections)
The destination host and port, to which connections should be forwarded on the opposite side
A checkbox to allow only local connections (only for local forwarding or outgoing connections), which is usually left enabled
The type of forwarding: usually TCP to indicate no special processing, or FTP to create temporary forwarding in the reverse direction for FTP data channels in active mode

Forwarding changes are effective only for the next session, except for removals, which happen immediately.

X forwarding is controlled by a checkbox. This is used with a separate X server running on the same system as the Tectia client.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

We have previously seen how static port forwarding can be extended for SOCKS-aware applications to provide dynamic port forwarding. [9.3] SOCKS is fully supported by the Tectia client, but you have to reconfigure each application to use the SOCKS proxy, which can be annoying.

Tectia Connector extends this concept further to achieve complete transparency: applications can use dynamic port forwarding without any reconfiguration whatsoever, because the applications are entirely unaware that the forwarding is happening.

To accomplish this feat, Connector worms its way into the Windows TCP/IP protocol stack (which includes hostname lookup functionality). This allows it to intercept networking operations by applications and reroute them to its own Connector engine, which then initiates SSH connections to servers on behalf of the applications. The capture and forward mechanism also allows the Connector engine to exercise precise control over network connections, and to enforce security policies that require certain kinds of connections to use secure protocols, like SSH.

As of Version 4.2, Connector requires functionality provided only by "Tectia Server (T)." [16.11] "Tectia Server (A)" can't be used with Connector, and other non-Tectia servers are unsupported.

Connector only affects outgoing TCP connections. Applications can still accept incoming connections directly, and other protocols (like UDP, ICMP, etc.) are completely ignored by Connector. Note, however, that all applications can be affected by Connector's interception of hostname lookups.

Connector uses only the SSH-2 protocol, never SSH-1. It is fully self-contained, and does not rely on the Tectia client. Instead, Connector implements the SSH-2 protocol and initiates its own connections.

The Connector engine starts automatically when each user logs in. If it has been stopped for some reason, it can be restarted manually using the SSH Tectia Connector item from the Start/Programs/SSH Tectia Connector menu, or by running the

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

The Tectia client supports file transfers using sftp. The File Transfer window (Figure 16-12) for the GUI client is obtained by using the New File Transfer Window toolbar icon or the Window/New File Transfer menu item, and operates similarly to Windows Explorer.

To transfer files, use any of the following methods:

Simply drag and drop files or folders between the Local and Remote views.
Select the files or folders to be transferred in the Local or Remote views, and then click the download or upload icons in the toolbar.
Right-click on a file or folder in the Local or Remote view to produce a menu, and then use the Upload or Download menu items. If the Upload Dialog or Download Dialog menu items are used instead, then a separate dialog allows selection of files to be transferred.
Select the files or folders to be transferred in the Local or Remote views, and then use the same menu items in the Operation menu.

Most other file operations can be performed within the Local or Remote views using the Operation menu, or familiar Windows Explorer gestures. These include opening files, running programs, deleting or renaming files and folders, creating new folders, etc. Some restrictions on the operations may be imposed by the remote system.

The sftp file transfer mode can be set to ASCII, Binary, or Auto Select using icons on the toolbar, or the Operation/File Transfer Mode menu items.

The transfer view at the bottom of the window shows progress information and statistics for each transfer.

Figure 16-12: File transfer window

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

The GUI client can be launched from the command line. This is useful for creating customized shortcuts, or other wrapper scripts (e.g., *.bat files).

The program is named SSHClient, and supports the following options:

-r: Reset all customizations made to the user interface (toolbars and menus). The client asks for confirmation before doing this.
-u [username]: Specify the remote username.
-h [hostname]: Specify the remote hostname (where the SSH server runs).
-p [port]: Specify the port number.
-f: Start using the file-transfer window instead of the terminal window.

A profile settings file (*.ssh2) can also be specified as the last argument on the command line.

The GUI client immediately initiates an outgoing connection if any of the -u, -h, or -p options, or a profile settings file, are specified. If no remote hostname is given (either by the -h option or a profile settings file), then the client prompts for connection parameters, with any other supplied values as defaults. Otherwise, the client starts in an unconnected state and waits for outgoing connections to be initiated manually.

The precedence for settings is (from strongest to weakest):

Command-line options
A profile settings file specified on the command line
Default profile settings files: either default.ssh2 or defaultsftp.ssh2 (if the -f option is used)
Hardwired default settings, if the default profile settings files do not exist

The Tectia Client package also supplies a set of command-line programs, including ssh2, scp2, sftp2, and ssh-keygen2. These programs are intended for scripting, and function almost exactly as they do for Unix implementations, except that they are aware of the Windows conventions for configuration file locations. In fact, ssh2 -h is an easy way to list the location of the configuration files for the client (in the user profile folder). The programs understand both Windows and Unix filename conventions using backslashes and (forward) slashes, respectively. Wildcards are case-insensitive, in accordance with Windows filesystem conventions.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

The Help menu offers two items that are useful for identifying problems.

The Troubleshooting dialog (Figure 16-13) displays a collection of useful information, including:

Local client version
License details
Operating system
Remote server version
Algorithms used
Connection settings
Error messages

Figure 16-13: The Troubleshooting dialog

The Debugging dialog (Figure 16-14) collects diagnostic output messages from the client. A checkbox enables or disables debugging. The debug level is specified according to the syntax described for the ssh2 -d command-line option [7.3]; it can restrict output to specific modules. A log file must be specified to store the debug messages, which are also displayed in a scrollable view. A checkbox allows the log file to be automatically cleared when the client starts; it can also be cleared manually at any time using the Clear File button.

Figure 16-14: The Debugging dialog

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Two distinct flavors of the Tectia server are available (as of Version 4.2). The full-featured Tectia Server (T) is intended for application tunneling, and supports extra functionality needed by Tectia Connector, while the slightly encumbered Tectia Server (A) is intended only for remote system administration. All the programs that make up these products are identical; the only difference is the license file that enables or disables the additional features.

The Tectia server is implemented by a program, ssh2master, that runs as a daemon and listens for incoming connections. A separate program, ssh2server, is run to handle each connection when it is accepted. The sftp server is implemented by the program sftp_server2.

If you run a Tectia server on a Windows system configured with a firewall, be sure to allow access to the port(s) used to accept SSH connections, typically port 22.

Stopping the ssh2master program doesn't affect existing connections, since ssh2server continues to run. The Tectia server can even be restarted by a session that uses an SSH connection!

Normally, the Tectia server is run as a Windows service that is automatically started whenever the system boots. Several mechanisms can be used to start or stop the service manually:

Use the Tectia server administration program (discussed shortly).
Select either the Start Server or Stop Server item within the menu Start/Programs/SSH Tectia Server/Tools.
Access the Control Panel, and use the dialogs for Administrative Tools/Services to select the display name SSH Tectia Server, and then click Start, Stop, or Restart the service.
Run the start-ssh.bat or stop-ssh.bat scripts in the installation folder.
Start or stop the service using the command net start SSHSecureShell2Server or net stop SSHSecureShell2Server, respectively.
Run ssh2master -start or ssh2master -stop

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

SecureCRT, created by VanDyke Software, is a commercial SSH client for Microsoft Windows 95 through Windows 2003. It is structured as a terminal program; in fact, it started life as the terminal program CRT, another VanDyke product. As a result, SecureCRT's terminal capabilities are quite configurable. It includes emulation of several terminal types, logins via Telnet as well as SSH, a scripting language, a keymap editor, SOCKS firewall support, chat features, and much more. We will focus only on its SSH capabilities, however.

SecureCRT supports both SSH-1 and SSH-2 in a single program. Other important features include port forwarding, X11 packet forwarding, support for multiple SSH identities, and an agent. Secure file copy is accomplished not only by an scp-type program, vcp, but also by ZModem, an old protocol for uploading and downloading files. (The remote machine must have ZModem installed.) If ZModem is used while you're logged in via SSH, these file transfers are secure.

We've organized this chapter to mirror the first part of the book covering Unix SSH implementations. When appropriate, we refer you to the earlier material for more detailed information.

Our discussion of SecureCRT is based on a prerelease of Version 5.0, dated December 2004.

SecureCRT may be purchased and downloaded from VanDyke Software:

A free evaluation version is available, expiring 30 days after installation, so you can try before you buy. If you do purchase the program, VanDyke will provide a serial number and license key.

Installation is straightforward and glitch-free. The software is distributed as a single .exe file; simply run it to install the program. Follow the onscreen instructions, installing the software in any folder you like. We accepted the default choices.

Once you've installed the program, it's time to set up a new session, which is SecureCRT's word for a collection of settings. Choose "Quick Connect..." from the File menu, and in the window that appears (see Figure 17-1), enter the following information:

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

SecureCRT may be purchased and downloaded from VanDyke Software:

A free evaluation version is available, expiring 30 days after installation, so you can try before you buy. If you do purchase the program, VanDyke will provide a serial number and license key.

Installation is straightforward and glitch-free. The software is distributed as a single .exe file; simply run it to install the program. Follow the onscreen instructions, installing the software in any folder you like. We accepted the default choices.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Once you've installed the program, it's time to set up a new session, which is SecureCRT's word for a collection of settings. Choose "Quick Connect..." from the File menu, and in the window that appears (see Figure 17-1), enter the following information:

Protocol: Select ssh2 for the SSH-2 protocol.
Hostname: Enter the hostname of the remote SSH server, such as server.example.com.
Port: Leave it at the default port number, 22, unless your server uses a nonstandard port.
Username: Enter your username on the remote machine.
Authentication: Select Password, unless you have another method set up already.

Also put a checkmark in the "Save session" checkbox if you plan to return to this SSH server regularly.

Now click the Connect button. You should be prompted for your login password on the remote machine, and then you'll be logged in via SSH. SecureCRT operates just like a normal terminal program. SSH's end-to-end encryption is transparent to the user, as it should be.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

SecureCRT supports public-key authentication using DSA or RSA keys. It can generate keys with a built-in wizard (in SECSH format, compatible with Tectia [6.1.2]), or you can import existing keys. It also distinguishes between two different types of SSH identities: global and session-specific. Finally, SecureCRT includes an SSH agent and supports OpenSSH-style agent forwarding.

Figure 17-1: SecureCRT Quick Connect window

SecureCRT's Key Generation Wizard creates key pairs for public-key authentication. The utility is run in the Tools menu by selecting Create Public Key. Equivalently, from the Global Options window, under SSH2 or SSH1, click Create Identity File.

Operation is straightforward. All you need to supply are the passphrase, the number of bits in the key, and some random data by moving your mouse around the screen. The RSA Key Generation Wizard then creates a key pair and stores it in two files. As with the Unix SSH implementations, the private key filename is anything you choose (say, mykey), and its corresponding public-key filename is the same with .pub added (e.g., mykey.pub).

Once your key pair is generated, you need to copy the public key to the SSH server machine, storing it in your account's authorization file. [6.1] SecureCRT can do this automatically, or you can do it manually.

Section 17.3.1.1: 17.3.1.1 Automatic installation of keys

SecureCRT can upload your public keys to an SSH server with the click of a button, but there's a catch: your remote SSH server must support the publickey subsystem, described in technical detail at:

http://www.vandyke.com/technology/draft-ietf-secsh-publickey-subsystem.txt

VanDyke's own VShell server supports it, and VanDyke makes available a patched OpenSSH server with similar support at:

http://www.vandyke.com/download/os/pks_ossh.html

Assuming you're running one of these servers:

Open the Session Options window, either for an existing session or to create a new session.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

SecureCRT lets you change settings for its SSH features and its terminal features. We will cover only the SSH-related ones. The others (and more details on the SSH features) are found in SecureCRT's online help.

SecureCRT calls a set of configuration parameters a session. It also distinguishes between session options that affect only the current session and global options that affect all sessions.

You can change session options before starting an SSH connection or while you are connected. Some options can't be changed while connected, naturally, such as the name of the remote SSH server machine. View the Session Options window (Figure 17-3) by selecting Session Options from the Options menu or clicking the Properties button on the button bar.

Figure 17-3: SecureCRT session options

To establish any SSH connection, fill in the Connection fields in the Session Options window. These include:

Name: A memorable name for your collection of settings. This can be anything, but it defaults to the name of the SSH server.
Protocol: Either SSH-1 or SSH-2.

Then fill in the following fields under Connection/SSH2:

Hostname: The name of the remote SSH server machine to which you want to connect.
Port: The TCP port for SSH connections. Virtually all SSH clients and servers operate on port 22. Unless you plan to connect to a nonstandard SSH server, you won't need to change this. [7.4.5.1]
Username: Your username on the remote SSH server machine. If you're using public-key authentication, this username must belong to an account that contains your public key.
Authentication: How you identify yourself to the SSH server. This can be password (i.e., your remote login password), public key, keyboard-interactive authentication (a.k.a. challenge-response or one-time password), or GSSAPI authentication. [5.4]

SecureCRT can transparently compress and uncompress the data traveling over an SSH connection. This can speed up your connection. [7.4.14]

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

SecureCRT supports the SSH feature called forwarding (Chapter 9), in which another network connection can be passed through SSH to encrypt it. It is also called tunneling because the SSH connection provides a secure "tunnel" through which another connection may pass. Both TCP port forwarding and X forwarding are supported. (As well as agent forwarding, as we mentioned earlier.)

Port forwarding permits an arbitrary TCP connection to be routed through an SSH connection, transparently encrypting its data. [9.2] This turns an insecure TCP connection, such as Telnet, IMAP, or NNTP (Usenet news), into a secure one. SecureCRT supports local port forwarding, meaning that your local SSH client (SecureCRT) forwards the connection to a remote SSH server.

Each SecureCRT session you create may have different port forwardings set up. To set up forwarding to a particular remote host, open the Session Options window and select Connection/Port Forwarding.

To create a new forwarding, first click the Add button to display the Local Port Forwarding Properties window, as in Figure 17-4. Then enter:

Name: Any descriptive name for your forwarding, to help you remember what it does.
Local: The port number on your local machine to connect to the secure tunnel. This can be just about any number, but for tradition's sake, make it 1024 or higher. Choose a local port number that's not being used by any other SSH client on your PC. If you want to restrict the local IP address that allows connections (i.e., if your PC has multiple network addresses), check the associated checkbox ("Manually select local IP addresses...") and fill in the address.
Remote: The port number of the remote service, such as 119 for NNTP or 143 for IMAP. The remote machine, by default, is the same one used for your SecureCRT session, but you can change this by checking "Destination host is different from the SSH server" and entering the hostname where the remote service is found. But beware: you can produce a non-secured tunnel with this kind of third-party forwarding if you're not careful.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Although SecureCRT is a graphical terminal program, it also comes with a few command-line programs very similar to the ssh, scp, and sftp programs supplied with OpenSSH and Tectia. They are called vsh, vcp, and vsftp.

vsh is a remote login and command-execution program similar to ssh. Type vsh by itself for full usage information. Here are some notable examples:

    # Log into server.example.com as smith

    C:\> vsh -l smith server.example.com



    # Invoke the remote command "who"

    C:\> vsh -l smith server.example.com who

vcp is a file-transfer program similar to scp: we discuss it in the next section. vsftp is an interactive file-transfer program similar to sftp and ftp.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

SecureCRT offers three ways to transfer files securely between systems via SSH:

vcp and vsftp
Xmodem or Zmodem
SecureFX

SecureCRT comes with a command-line program, vcp, for transferring files securely. It has syntax almost identical to scp. For example, to copy the local file myfile to the remote SSH server server.example.com, authenticating as smith, and naming the copy newfile:

    C:\> vcp myfile smith@server.example.com:newfile

Many of vcp's options are the same as scp's:

-r	Recursive copy
-i	Specify a public-key identity for authentication
-v	Verbose flag for debugging

However, other options are different. Type vcp by itself for full usage information.

vsftp is an FTP-like client provided with SecureCRT; it should feel familiar to anyone who has used an FTP client. Run vsftp -h for full usage information.

SecureCRT supports file transfer using the old Xmodem and Zmodem protocols, secured via SSH. To use these protocols, your SSH server machine will need Xmodem or Zmodem programs installed, such as sz and rz (send and receive Zmodem, respectively) or sx and rx (send and receive Xmodem, respectively), often found on Linux machines. For example, to send a file from the remote server machine to your local client machine via Zmodem:

On the remote system, run:
```
    $ sz myfile
```
SecureCRT will automatically detect the Zmodem connection and perform the download, displaying the file-transfer status in a window.

Similarly, to upload a file:

On the remote system, run:
```
    $ rz
```
In SecureCRT, choose Transfer/Zmodem Upload List, and select the files you want to transfer. Then select Transfer/Start Zmodem Upload.

If you want a graphical file transfer with a Windows Explorer-like interface, plus integration with SecureCRT, consider VanDyke's commercial product, SecureFX. Once you've authenticated and connected to a remote SSH server, you can drag and drop files between the machines with your mouse.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

SecureCRT, like any other SSH client, can run into unexpected difficulties interacting with an SSH server. In this section we cover problems specific to SecureCRT. For more general problems, see also Chapter 12.

Q:

When I try to upload my public key, I get the message, "Unable to open publickey subsystem" and the upload fails.

A:

SecureCRT can upload public keys only to SSH servers supporting the publickey subsystem, an open standard created by VanDyke. If you get this message, your remote server doesn't have this support.

Q:

I can't do port forwarding. I get a message that the port is already in use.

A:

Do you have another SecureCRT window open and connected with the same port-forwarding setup? You can't have two connections forwarding the same local port. As a workaround, create a second session that duplicates the first, but with a different local port number. Now you can use both sessions simultaneously.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

VanDyke Software also sells an SSH server product, VShell, that runs on Windows and various Unix platforms, including Red Hat Linux, Solaris, FreeBSD, OS X, and HP-UX. VShell has interesting features to recommend it:

File and notification triggers: VShell can execute arbitrary commands in response to events such as SFTP file transfers or failed authentication attempts.
Flexible SFTP configuration: VShell's SFTP server has an access control list (ACL) language that can assign access to individual server directories by any combination of account name or group membership. It can conveniently use the Unix chroot mechanism to restrict users to given directories, as well as define virtual directories that hide details of server file organization from clients.
Fine-grained access control: Again using ACLs, the VShell server can restrict access to services by individual accounts. One account might be allowed full access while another may use only SFTP. One group may do local port forwarding and get interactive sessions with their defined shells, but not remote forwarding or arbitrary remote command execution, except for one user in that group, who still gets full access.
Of course, the efficacy of such measures depends on further work: it does little good to restrict remote commands, for example, if any program can be started by the user's shell. But VShell provides these restrictions at the right place: in terms of the basic SSH channel types used to invoke the services. Other SSH products often do not have this level of control, and require awkward and fragile combinations of special shells or specific authentication methods to achieve the same goal.
GSSAPI: Support for emerging GSSAPI/Kerberos SSH standards for both client and server authentication.
Very understandable debug messages: Don't underestimate the value of readable verbose messages! There will always be problems, and logging is your main tool for solving them. Reading the verbose output of some SSH products can be an art in itself. VShell's messages are particularly well done.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

VanDyke's SSH products are mature, stable, and well rounded, and have good vendor support. The GUI clients SecureCRT and SecureFX both work well. The command-line clients are not as flexible as OpenSSH and Tectia's, but they cover the basics and get the job done. The VShell server supports some interesting features and is well worth checking out.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

The world is full of rich, hyper-powerful SSH implementations, but sometimes simplicity is best. Enter PuTTY, a tiny, uncomplicated, free SSH client for Microsoft Windows. There's no installation procedure, no steep learning curve, and in many cases, no configuration needed.

At press time, PuTTY was still labeled as "beta" software, but don't be discouraged: it's a robust and just plain useful SSH client. Thanks to Simon Tatham for creating the PuTTY suite of programs, releasing them as free software, and writing a detailed manual on his web site. Because PuTTY's manual is very good, we'll focus on the most common uses. This chapter covers PuTTY Version 0.56.

Installation of PuTTY is as easy as it gets. Just download the putty.exe executable from:

and run it. This simplicity is especially handy if you're traveling and need an SSH client; PuTTY is just a quick download away.

To get started, just run (or double-click) putty.exe. The PuTTY Configuration dialog shown in Figure 18-1 will appear:

For a quick start, locate the box labeled "Host Name (or IP address)," enter the hostname of your remote server machine, and click the Open button. A terminal window then appears and prompts you for your login name and password. Assuming

Figure 18-1: PuTTY Configuration dialog

there's nothing unusual about your SSH server, you're done: PuTTY establishes a secure login session with the server.

PuTTY supports not only SSH, but also insecure protocols like Telnet and Rlogin. Make sure your connections are using the SSH protocol by selecting SSH on the initial PuTTY Configuration dialog. SSH is the default protocol for the other programs in the suite, such as Plink, PSFTP, and PSCP.

PuTTY comes with a second SSH terminal client, Plink, which is reminiscent of the ssh client of OpenSSH and Tectia. For a quick start, open a command window and type:

    C:\> plink smith@server.example.com

This command connects you via SSH to

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Installation of PuTTY is as easy as it gets. Just download the putty.exe executable from:

and run it. This simplicity is especially handy if you're traveling and need an SSH client; PuTTY is just a quick download away.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

To get started, just run (or double-click) putty.exe. The PuTTY Configuration dialog shown in Figure 18-1 will appear:

For a quick start, locate the box labeled "Host Name (or IP address)," enter the hostname of your remote server machine, and click the Open button. A terminal window then appears and prompts you for your login name and password. Assuming

Figure 18-1: PuTTY Configuration dialog

there's nothing unusual about your SSH server, you're done: PuTTY establishes a secure login session with the server.

PuTTY supports not only SSH, but also insecure protocols like Telnet and Rlogin. Make sure your connections are using the SSH protocol by selecting SSH on the initial PuTTY Configuration dialog. SSH is the default protocol for the other programs in the suite, such as Plink, PSFTP, and PSCP.

PuTTY comes with a second SSH terminal client, Plink, which is reminiscent of the ssh client of OpenSSH and Tectia. For a quick start, open a command window and type:

    C:\> plink smith@server.example.com

This command connects you via SSH to server.example.com, logging in as remote user smith.

Plink is most appropriate for noninteractive use: for example, setting up tunnels for port forwarding, or running inside batch jobs. It can also handle interactive logins, but PuTTY is a better choice, particularly for screen-based programs like text editors. The Windows command line is not a particularly good terminal emulator.

The plink client has many command-line options, similar to those of ssh. Run plink by itself to see a list of valid options, as shown in Table 18-1.

Table 18-1: plink command-line options
Option	Meaning
1	Use SSH-1 protocol.
2	Use SSH-2 protocol.
C	Use compression for the SSH connection. [7.4.14]
-i keyname	Use the private key keyname.
-l username	Specify the remote username (if omitted, it defaults to your local username).

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

The PuTTY suite includes two programs for copying your files securely between machines. PSCP is a noninteractive program much like scp, and PSFTP is an interactive program inspired by ftp.

PuTTY's pscp client is for copying files securely between machines, just like scp from OpenSSH and Tectia. Also like scp, pscp is noninteractive. (For an interactive client, see psftp. [18.3.2])

The syntax for PSCP is almost identical to that of scp. [7.5] Remote files are referenced by:

[user@]host:path

where user is the remote username, host is the remote hostname, and path is the folder path to the file in question.

PSCP can copy files securely between computers, but the user interface is noninteractive. If you prefer a familiar FTP-like interface, try PSFTP, PuTTY's interactive file-transfer program. To start a file copying session with remote computer server.example.com, run:

    C:\> psftp server.example.com

    login as: smith

    Using username "smith".

    smith@server.example.com's password:

    Remote working directory is /home/smith

    psftp>

The prompt psftp> indicates that PSFTP is ready to accept commands. If you're familiar with FTP, the PSFTP commands will make you feel right at home. To transfer a file from your local machine to the remote server, use:

    psftp> put myfile

or to copy a local file, myfile, as remote file remotefile:

    psftp> put myfile remotefile

This is equivalent to the PSCP command:

    C:\> scp myfile server.example.com:remotefile

In the other direction, to transfer files from the remote server to your local machine, use get:

    psftp> get remotefile

    psftp> get remotefile myfile

To traverse the directory (folder) hierarchy of the remote machine, use the cd command as in DOS or Unix:

    psftp> cd my_remote_subfolder

    psftp> cd ..

To change your working directory on the local machine, use lcd:

    psftp> lcd my_local_subfolder

    psftp> lcd ..

For a full list of commands, type

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

If you'd like to use public-key authentication to connect to remote hosts [2.4], PuTTY includes a key generator program, called PuTTYgen. It has a simple graphical user interface for creating and editing RSA and DSA keys, as shown in Figure 18-2.

Figure 18-2: PuTTYgen, the key generator

To create a new key, simply click the Generate button. You'll be asked to waggle your mouse around to supply random numbers to the generator, then to supply a passphrase. To edit an existing key, just click the Load button.

You might remember that OpenSSH and Tectia use different file formats for their keys. PuTTYgen uses the SECSH format for public keys [6.1.2], but its own unique format for private keys. The private key is stored in a file with the suffix .ppk and looks like this:

    PuTTY-User-Key-File-2: ssh-rsa

    Encryption: aes256-cbc

    Comment: Your comment here

    Public-Lines: 4

    AAAAB3NzaC1yc2EAAAABJQAAAIBltDpO1wC9qJ98peVr5y9C7N9vdOh+OrCNwbIh

    lba1oSf94rrDl1TQXKXxgIHSd1ICgh7wkdxFWbyDRXSuWdur6kreTGRaw9XgCzQt

    LyANMtKAPpDYVE1g8jb6jA1bOMtK8b+pGPmetbvdyBDmFcQ/oPwYyrZIjfbd8IdK

    FxxJvw==

    Private-Lines: 8

    3ryAyuTLEnYuLGsetfNvazRYOhxQmzBWSyMLyT2i+zt7QqArlPglY1Um3NBJlYgS

    caHDiLyH95tV2onEeBThJzYFAvgrr7UlXVjQTDLr29fe2FTS/bNm4OahTaKzTNV4

    0EojvG1yafCucaZMVwsndB4djpm4otJja+xDVLN7Wj3ibzUT+SfodSJyazMAjB0y

    Q3ndbcqcIPPg4OM3sL8c09KTVdcuLkkyKMSV5yEgTAP0RG0M+T8/ChHLFLHswwV+

    /tlb0GLZRa1w3KsnzHHFKxMsM2zOdHXnSG8TX0kecdpT2p8PT3UGw2+SMESD8umc

    GLai7g/o03lMJVSOezrooDC06p8J8OXk8h84gYeJbBIyXdELh10E3fnDSkTy5jS4

    w2SCNzXX67ggWjIFtsefsx6VJ4WwJUYtNbKY35M59xMug/GRBL07QPLu+xSh8/RB

    yM/rWtUvGwXG3ygW/TVm7A==

    Private-MAC: a0f9fa2204172fc6df9e0f6d5b918c8790d88611

But never fear: PuTTYgen can read and write public and private keys for both OpenSSH and Tectia:

To read an OpenSSH or Tectia key, simply click the Load button and select the key file. (In the file dialog, be sure to set the file type to "All Files (*.*)" so that your non-PuTTY keys show up.)

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

PuTTY is simple to use in its most basic form. Nevertheless, its clients have many options that are worth trying out. We will cover the ones relating to SSH. Other terminal-related features, like settings for the window, keyboard, and mouse, we encourage you to explore on your own.

If you have a habit of connecting to the same remote machines often, set up a Saved Session, which remembers the settings for that connection so that you can reuse them. This is similar to the OpenSSH and Tectia feature of configuration files, but with a GUI. [7.1.2] Simply configure PuTTY the way you like it, then save that configuration under a name, such as "My Favorite Settings" or "office."

When you create and name a Saved Session, it becomes available not only to PuTTY, but also to the other programs in PuTTY's suite, such as PSCP and Plink. Just provide the saved session's name in place of a hostname. For example, if you created a Saved Session called "office" to stand for employer.example.com, you could run:

    C:\> plink office

and it will connect to employer.example.com.

Saved Sessions are stored in the Windows registry under the key \HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\Sessions.

Like other SSH implementations, PuTTY records the host keys of SSH servers it encounters. They are stored in the Windows registry under the key \HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\SshHostKeys.

We always recommend you use the SSH-2 protocol, since it is more secure and robust than the original SSH-1. Nevertheless, PuTTY does support both protocols, and you can choose your preferred protocol on the PuTTY Configuration dialog, under Connection/SSH. The choices are:

1 only: Require SSH-1, or else fail.
1: Try SSH-1 first, then SSH-2.
2: Try SSH-2 first, then SSH-1.
2 only: Require SSH-2, or else fail (recommended).

With Plink, you can force the protocol version with the -1 (SSH-1 only) and -2 (SSH-2) options:

    C:\> plink -2 smith@server.example.com

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Forwarding or tunneling is the use of SSH to secure another network application, covered fully in Chapter 9. Both PuTTY and Plink can set up secure tunnels for this purpose.

Forwarding is set up with the PuTTY Configuration dialog. For local port forwarding, which is the most common type, select Tunnels. Then fill in these fields:

Source port: Any unused TCP/IP port on your local machine.
Destination: The remote SSH server name, followed by a colon, followed by the remote port number.
Local/Remote/Dynamic: Choose Local.

For example, to connect to a remote VNC server (port 5900) on server.example.com, you'd provide a destination of server.example.com:5900, and any unused source port (say, 12345). This example demonstrates local forwarding [9.2.1], but PuTTY can also do remote [9.2.1.2] and dynamic [9.3] port forwarding.

To turn on X forwarding [9.4] for secure connections with an X Window server, simply choose Tunnels again and select the checkbox Enable X11 Forwarding.

To turn on agent forwarding [6.3.5] to allow your SSH agent to communicate with clients on other machines, navigate to Connection/SSH/Auth and select the checkbox Allow Agent Forwarding.

To enable the various kinds of forwarding with the command-line program Plink:

Local port forwarding [9.2.1]

Use the -L option, supplying the source port, remote server name, and remote port. For example, to forward local port 12345 to remote port 5900 on server.example.com, run:

    C:\> plink server.example.com -L 12345:server.example.com:5900

Remote port forwarding [9.2.1.2]

Use the -R option, supplying the remote source port, local server name, and local port. For example, to forward remote port 12345 on outerspace.example.com to your local port 5900, run:

    C:\> plink outerspace.example.com -R 12345:localhost:5900

Dynamic port forwarding [9.3]

Use the -D option. For example, to perform dynamic port forwarding via proxy on port 12345, run:

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

PuTTY is a small, useful SSH client for Windows (and available for Linux if you don't already have another SSH client installed). Its major benefit is its simplicity—just download and start using it—but under the hood it has additional powerful features for the inquisitive user. For more information, see the PuTTY manual at:

http://www.chiark.greenend.org.uk/~sgtatham/putty/

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Stop the presses! Just before this book was printed, OpenSSH 4.0 was released by those fine folks at openssh.com. While compatible with Version 3.9, it has several important new features that we discuss briefly. (We cover just features, not bug fixes.)

Server Features: sshd

Client Features: ssh, scp, and sftp

ssh-keygen

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

The OpenSSH server has new features pertaining to logging, listening addresses, and password and account expiration warnings.

When authentication attempts are rejected by user-level access control (AllowUsers, DenyUsers) or group-level access control (AllowGroups, DenyGroups), sshd will log an informative message about it.

The AddressFamily configuration keyword, previously available to clients only, can now be configured for the SSH server as well. If your server supports both IPv4 and IPv6, this lets you control on which sort of addresses sshd will listen.

If your password or account is going to expire (on operating systems that support expiration), sshd will now warn you in advance when you authenticate—for example.:

    Your password will expire in 6 days

    Your account will expire in 11 days

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

OpenSSH clients have new features pertaining to keyboard-interactive authentication, connection sharing, known-hosts handling, port forwarding, and command-line editing and history.

The KbdInteractiveDevices keyword was undocumented in OpenSSH 3.9, but now it's officially supported. It determines the devices that the client will try for keyboard-interactive authentication.

    KbdInteractiveDevices = pam,skey,bsdauth

If you're using the connection-sharing feature of ssh, you can now control the master process of that connection with the -O option. To check whether you're using connection sharing, run the following:

    $ ssh -O check server.example.com

To request the master process to exit, run the following:

    $ ssh -O exit server.example.com

In previous versions of OpenSSH, known_host files contain the hostnames and IP addresses of the computer's you've visited via SSH. If you'd like to keep this information more private, use the new HashKnownHosts configuration keyword in your client configuration file:

    HashKnownHosts yes

SSH clients will now hash the hostnames so they look like random strings—for example:

    |1|Un5Q61BdVPCq65Yj3ec/HH6r+zI=|2pPQE/qjP7rrPLblvS1epjYbUOs=

This feature is experimental at the moment, so use it at your own risk.

When you construct a port forwarding, you can now specify a bind address: the address on which the accepting side of the forwarding will listen. This is useful either for controlling whether a forwarding is available off-host (not listening on only on the loopback), or distinguishing among multiple addresses if the listening host is multi-homed. You give the bind address on the command line, preceding the usual -L or -R value. For example, to set up a local forwarding from local port 2001 to remote server port 143 (IMAP), listening on 192.168.100.66:

    $ ssh -L 192.168.100.66:2001:localhost:143 server.example.com

or for a remote forwarding:

    $ ssh -R 192.168.100.66:2001:localhost:143 server.example.com

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

If you're using the experimental hostname hashing feature described earlier, ssh-keygen has some new command-line options to support it.

ssh-keygen can convert your known_hosts file to use hashes with the -H option:

    $ ssh-keygen -H

The ssh-keygen manpage claims that the results of ssh-keygen -H are written to standard output, but this is not true. The command modifies your ~/.ssh/known_hosts file directly. It also stashes a copy of the old file in ~/.ssh/known_hosts.old for safety, but don't depend on this: running ssh-keygen -H twice obliterates the safe copy.

Once you've hashed your hostnames, it's hard to edit the known_hosts file because you can't read which line corresponds to which host. ssh-keygen provides new commands for locating and removing hosts from the file. To locate a particular host in the file, use the -F option:

    $ ssh-keygen -F server.example.com

    # Host server.example.com found: line 3 type RSA1

    server.example.com 1024 35 1301302858553510086.....

To remove a known host, use the -R option and provide the original hostname:

    $ ssh-keygen -R server.example.com

    /home/smith/.ssh/known_hosts updated.

    Original contents retained as /home/smith/.ssh/known_hosts.old

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

This document describes the regular expressions (or globbing patterns) used in filename globbing with scp2 and sftp2 and in the configuration files ssh2_config and sshd2_config.

Regex syntax used with scp2 and sftp2 is ZSH_FILEGLOB.

Regex Syntax: Egrep Patterns

Regex Syntax: ZSH_FILEGLOB (or Traditional) Patterns

Character Sets for Egrep and ZSH_FILEGLOB

Regex Syntax: SSH Patterns

Authors

Example

    [[:xdigit:]XY]

is typically equivalent to:

    [0123456789ABCDEFabcdefXY] .

It is also possible to include the predefined escaped character sets into a newly defined one, so:

    [\d\s]

matches digits and whitespace characters.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

The escape character is a tilde ~. With this you can escape metacharacters to use them in their plain character form.

In configuration the backslash (\) is used to escape the list separator (',').

In the following examples literal E and F denote any expression, whether a pattern or a character.

(: Start a capturing subexpression.
): End a capturing subexpression.
{: Start an anonymous, noncapturing subexpression.
}: End an anonymous, noncapturing subexpression.
E|F: Disjunction, match either E or F (inclusive). E is preferred if both match.
E*: Act as Kleene star, match E zero or more times.
E*?: Act as Kleene star, but match nongreedily (lazy match).
E+: Closure, match E one or more times.
E+?: Closure, but match non-greedily (lazy match).
E?: Option, match E optionally once.
E??: Option, but match non-greedily (lazy match).
.: Match ANY character, including possibly the NULL byte and the newline characters.
E/ n /: Match E exactly n times.
E/ n ,/ or E/ n ,0/: Match E n or more times.
E/, n / or E/0, n /: Match E at most n times.
E/ n , m /: Match E no less than n times and no more than m times.
E/n,/?, E/ n ,0/?, E/, n /?, E/0, n /?, E/ n , m /?: The lazy versions of above.
[: Start a character set. See the section "Escaped Tokens for Regex Syntax SSH."
>C: One-character lookahead. 'C' must be either a literal character or parse as a character set. Match the empty string anywhere provided that the next character is 'C' or belongs to it.
<C: One-character lookback. As above, but examine the previous character instead of the next character.
$: Match the empty string at the end of the input.
^: Match the empty string at the start of the input.

The following list describes the tokens:

~0 n .. n: The literal byte with octal value n .. n.
~0: The NULL byte.
~[1-9].. x: The literal byte with decimal value ~[1-9]..

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

SSH Communications Security Corp.

For more information, see http://www.ssh.com/.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

ssh2_config(5), sshd2_config(5), scp2(1), sftp2(1)

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

AnsiX962Rand
ArcFour
CmiStress
CryptoRandomPoll
DUMMY_ACC
GenHash
GenMac
GenPasswdPlugin
GenRand
GenTestCipher
GenTestMac
GenTestMain
GenTestMisc
GenTestPkcs
GenTestRand
GetOptCompat
Hash_Test
ModuleName
Pkcs1
PkcsImportExport
Scp2
Sftp2
SftpCwd
SftpPager
ssh-certview
Ssh-F-ConfigD
Ssh-F-ConfigD-Log
Ssh-F-ConfigD-Ssh-Configure
Ssh-F-ConfigD-SshD-Conf
Ssh1KeyDecode
Ssh1Protocol
Ssh2
Ssh2AuthCommonServer
Ssh2AuthGSSAPI
Ssh2AuthGSSAPICommon
Ssh2AuthHostBasedClient
Ssh2AuthHostBasedRhosts
Ssh2AuthHostBasedServer
Ssh2AuthKbdInteractiveClient
Ssh2AuthKbdInteractiveServer
Ssh2AuthKbdIntPAM
Ssh2AuthKbdIntPasswd
Ssh2AuthKbdIntPlugin
Ssh2AuthKbdIntRadius
Ssh2AuthKbdIntSecurID
Ssh2AuthKbdIntSubmethods
Ssh2AuthKerberosClient
Ssh2AuthKerberosServer
Ssh2AuthKerberosTgtClient
Ssh2AuthKerberosTgtServer
Ssh2AuthPAMClient
Ssh2AuthPAMCommon
Ssh2AuthPAMServer
Ssh2AuthPasswdClient
Ssh2AuthPasswdServer
Ssh2AuthPubKeyClient
Ssh2AuthPubKeyServer
Ssh2AuthSecurIDClient
Ssh2AuthSecurIDServer
Ssh2ChannelAgent
Ssh2ChannelSession
Ssh2ChannelSsh1Agent
Ssh2ChannelTcpFwd
Ssh2ChannelX11
Ssh2Client
Ssh2Common
Ssh2KeyBlob
Ssh2PgpPublic
Ssh2PgpSecret
Ssh2PgpUtil
Ssh2SftpServer
SshAdd
SshADT
SshADTArray
SshADTAssoc
SshADTAvlTree
SshADTConv
SshADTList
SshADTMap
SshADTPriorityHeap
SshADTRanges
SshAgent
SshAgentClient
SshAgentPath
SshAppCommon
SshAskPass
SshAsn1
SshAsn1Ber
SshAsn1Create
SshAsn1OidDB
SshAsn1VM
SshAuthMethodClient
SshAuthMethodServer
SshAuthServerPasswdChange
SshBuffer
SshBufferAux
SshBufZIP
SshCAEK
SshCert
SshCertCheck
SshCertClient
SshCertCMi
SshCertCMiKey
SshCertCMiTrust
SshCertCMiUtil
SshCertCrmf
SshCertd
SshCertDB
SshCertDNDer
SshCertDNEncode
SshCertDNLdap
SshCertEdb
SshCertEdbHttp
SshCertEdbLdap
SshCertEdbOcsp
SshCertEncode
SshCertEval
SshCertIDCheck
SshCertMap
SshCertOid
SshCertReqEncode
SshCertServer
SshCertX509
SshCipherAlias
SshCipherRabbit
SshCipherRijndael
SshClientExternalKey
SshCmiPolicyTree
SshCmpClient
SshConfig
SshConfigParse
SshCopyStream
SshCryptHmac
SshCryptoAuxInit
SshCryptoAuxKeyExpand
SshCryptoAuxOldImport
SshCryptoGenpkcs
SshCryptoInit
SshCryptoPKGroup
SshCryptoPKPrivate
SshCryptoRGF
SshCryptoRSA
SshCryptoSSL3MAC
SshCryptoTests
SshCryptTwofish
Sshd2
SshdCheckConf
SshDebug
SshDecay
SshDirectory
SshDLib
SshDumpCert

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

This appendix describes the SSH-1 protocol features of OpenSSH and Tectia. Since we recommend against using SSH-1, you might never encounter these features, but we mention them for completeness.

OpenSSH Features

Tectia Features

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

KeyRegenerationInterval (or sshd -k): Set the number of seconds between generations of the SSH-1 server key. This temporary key is used only for SSH-1 connections. The default is 3600 seconds (1 hour), and a value of zero disables regeneration.
RhostsRSAAuthentication: Permit or deny authentication by the RSA key together with authentication by rhosts files.
RSAAuthentication: Permit or deny authentication by the RSA key.
ServerKeyBits (or sshd -b): Set the number of bits in the SSH-1 server key: see KeyRegenerationInterval above. The default is 768 bits, and the fewest allowable is 512 bits.

Cipher: Replaced by Ciphers for SSH-2 protocol connections
RhostsRSAAuthentication: Same as for serverwide configuration
RSAAuthentication: Same as for serverwide configuration

~/.ssh/identity, ~/.ssh/identity.pub: These files contain your default private and public keys, respectively, for public-key authentication.
/etc/ssh/ssh_host_key: This system file contains the SSH-1 protocol (RSA) host key.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Tectia provides limited support for SSH-1, mostly by running programs from some older implementation whenever the SSH-1 protocol is required. Some of the Tectia programs do have built-in support for SSH-1, however.

The Tectia server has no built-in support for SSH-1, but it can be configured to run a separate SSH-1 server for SSH-1 clients. See "Compatibility Between SSH-1 and SSH-2 Servers" in Chapter 5.

The following keywords in the /etc/ssh2/sshd2_config file control SSH-1 compatibility mode:

Ssh1Compatibility: Run the SSH-1 server when SSH-1 clients connect (if yes).
Sshd1Path: The pathname for the SSH-1 server.
Sshd1ConfigFile: An alternate configuration file for the SSH-1 server, replacing the one specified for the Tectia server by the -f command-line option.

The ssh -1t option runs an SSH-1 client program, and ssh -1i uses built-in SSH-1 emulation. See "Choosing a protocol version" in Chapter 7.

The following keywords in the /etc/ssh2/ssh2_config file control SSH-1 compatibility mode:

Ssh1Compatibility

Use SSH-1 if the server supports only supports the older protocol (if yes), or otherwise fail (if no).

Ssh1InternalEmulation

Use the Tectia client's built-in SSH-1 functionality (if yes), or otherwise run an external SSH-1 program (if no).

Ssh1Path

The pathname for the external SSH-1 program.

Ssh1MaskPasswordLength

Send SSH_MSG_IGNORE packets with SSH-1 sessions to obscure the length of the password (if yes, the default). Otherwise, the unencrypted length fields used by SSH-1 can be easily intercepted.

Ssh1AgentCompatibility

Specifies whether and how to do agent forwarding. The value is one of:

none: Don't forward SSH-1 agent connections (the default).
traditional: Forward SSH-1 agent connections with no information about the forwarding path.
ssh2: Forward SSH-1 agent connections, and add information about the forwarding path as for SSH-2. This requires using the Tectia agent in SSH-1 compatibility mode.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Identity and Authorization Files, OpenSSH

Identity and Authorization Files, Tectia

Environment Variables

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Mark	Meaning
✓	Yes: feature is supported/included
1	SSH-1 protocol only, not SSH-2
2	SSH-2 protocol only, not SSH-1

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

OpenSSH	Tectia	Option	Meaning
✓		-4	Use IPv4 addresses only
✓		-6	Use IPv6 addresses only
✓		-b bits	# of bits in server key
✓		-d	Verbose mode
	✓	-d debug_spec	Enable debug messages
	✓	-D debug_spec	Enable debug messages, keep listening
✓		-D	Don't detach into background
✓		-e	Send error messages to stderr
✓	✓	-f filename	Use other configuration file
✓	✓	-g time	Set login grace time
✓	✓	-h filename	Use other host key file
✓	✓	-i	Use inetd for invocation
1		-k time	Regeneration interval for SSH-1 server key
✓	✓	-o "keyword value"	Set configuration keyword
✓	✓	-p port	Select TCP port number
✓	✓	-q	Quiet mode
✓		-Q	Quiet if RSA support is missing
✓		-t	Test mode
✓		-u length	Set length of `utmp` structure
	✓	-v	Verbose mode
	✓	-V	Print version number

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

OpenSSH	Tectia	Keyword	Value	Meaning
✓	✓	#	Any text	Comment line
✓		`AcceptEnv`	Variables	Copy client environment variables to server
	✓	`AllowAgentForwarding`	Yes/no	Same as `ForwardAgent`
	✓	`AllowedAuthentications`	Auth types	Permitted authentication techniques
✓	✓	`AllowGroups`	Group list	Access control by Unix group
	✓	`AllowHosts`	Host list	Access control by hostname
	✓	`AllowSHosts`	Host list	Access control via .shosts
✓	✓	`AllowTcpForwarding`	Yes/no	Enable TCP port forwarding
	✓	`AllowTcpForwardingForUsers`	User list	Per user forwarding
	✓	`AllowTcpForwardingForGroups`	Group list	Per group forwarding
✓	✓	`AllowUsers`	User list	Access control by username
	✓	`AllowX11Forwarding`	Yes/no	Same as `ForwardX11`
	✓	`AuthInteractiveFailureTimeout`	Seconds
	✓	`AuthKbdInt.NumOptional`	# submethods	Set number of optional submethods required for authentication
	✓	`AuthKbdInt.Optional`	Auth methods	Set optional authentication submethods for keyboard-interactive auth
	✓	`AuthKbdInt.Plugin`	Filename	Path to plugin for keyboard-interactive auth
	✓	`AuthKbdInt.RADIUS.NASIdentifier`		Client identifier for RADIUS keyboard-interactive authentication
	✓	`AuthKbdInt.RADIUS.Server`	Server spec	RADIUS server for keyboard-interactive auth
	✓	`AuthKbdInt.Required`	Auth methods	Set required authentication submethods for keyboard-interactive auth
	✓	`AuthKbdInt.Retries`	# retries	Permitted retries for keyboard-interactive auth
	✓	`AuthorizationFile`	Filename	Location of authorization file
✓		`AuthorizedKeysFile`	Filename	Location of authorization file
	✓	`AuthPassword.ChangePlugin`	Filename	Location of password-change plugin program
	✓	`AuthPublicKey.MaxSize`	# bytes	Max size of public key
	✓	`AuthPublicKey.MinSize`	# bytes	Min size of public key
2		`Banner`	Filename	Location of banner file
	✓	`BannerMessageFile`	Filename	Location of banner file

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

OpenSSH	Tectia	Option	Meaning
✓		-1	Use SSH-1 protocol only
	✓	-1(t \|i)	Use SSH-1 protocol via ssh1 executable (`t`) or internal emulation (`i`)
✓		-2	Use SSH-2 protocol only
✓	✓	-4	Use IPv4 addresses only
✓	✓	-6	Use IPv6 addresses only
✓	✓	-a	Disable agent forwarding
	✓	+a	Enable agent forwarding
✓		-b bind_address	Select a network interface
✓		-A	Enable agent forwarding
✓	✓	-c cipher	Select encryption cipher
✓		-C	Enable compression
	✓	-C	Disable compression
	✓	+C	Enable compression
	✓	-d debug_spec	Enable debug messages
✓		-D port	Do dynamic port forwarding
✓	✓	-e character	Set escape character
	✓	-E name	Use external key-provider name
✓	✓	-f	Fork into background
	✓	-fo	Fork into background once
✓	✓	-F filename	Use other configuration file
✓	✓	-g	Gateway locally forwarded ports
	✓	+g	Don't gateway locally forwarded ports
	✓	-h	Print help message
✓	✓	-i filename	Select identity file
	✓	-I string	Initialization string for external-key provider
✓		-I device	Choose smartcard device
✓		-k	Disable Kerberos ticket forwarding
✓	✓	-l username	Remote username
✓	✓	-L port1:host2: port2	Local port forwarding
✓	✓	-m algorithm	Select MAC algorithm
✓		-M	Do not execute remote command
✓	✓	-n	Redirect stdin from /dev/null
2		-N	Execute no remote command
✓	✓	-o "keyword value"	Set configuration keyword
✓	✓	-p port	Select TCP port number

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

OpenSSH	Tectia	Option	Meaning
✓	✓	-1	Use SSH-1 protocol
✓		-2	Use SSH-2 protocol
✓		-4	Use IPv4 addresses only
✓		-6	Use IPv6 addresses only
	✓	-a [src: \|dest:[unix \|mac \|dos]]	Transfer files in ASCII mode
✓		-a	No file-by-file statistics
✓		-A	Print file-by-file statistics
✓	✓	-B	Batch mode: disable prompting
✓	✓	-c cipher	Select encryption cipher
✓		-C	Enable compression
✓		--checksum (yes \|no)	Compare files by checksum (optimization)
✓	✓	-d	Require target to be a directory when copying a single file
	✓	-D debug_spec	Enable debug messages
✓	✓	-f	Specify copy FROM (internal use)
✓		-F filename	Specify alternative configuration file
	✓	--force-lower-case	Rename destination files in all lowercase
	✓	-h	Print help message
✓	✓	-i filename	Select identity file
	✓	-I	Interactive mode: prompt before overwriting
✓		-l kilobits_per_second	Limit bandwidth
	✓	-M num	Set maximum number of requests to num
	✓	-n	Print actions, but don't copy
✓	✓	-o "keyword value"	Set configuration keyword
	✓	--overwrite (yes \|no)	Do/don't overwrite existing files
✓	✓	-p	Preserve file attributes
✓	✓	-P port	Select TCP port number
✓	✓	-q	Quiet mode
	✓	-Q	Don't print statistics
✓	✓	-r	Recursive copy
✓	✓	-S filename	Path to ssh executable
	✓	--statistics (yes \|no \|simple)	Verbosity level for statistics
✓	✓	-t	Specify copy TO (internal use)
	✓	-u	Remove original file after copying

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

OpenSSH	Tectia	Keyword	Value	Meaning
✓	✓	#	Any text	Comment line
✓		`AddressFamily`	any \| inet \| inet6	Set IP address type
	✓	`AllowAgentForwarding`	Yes/no	Same as `ForwardAgent`
	✓	`AllowedAuthentications`	Auth types	Permitted authentication techniques
	✓	`AuthenticationNotify`	Yes/no	Print message on stdout on successful authentication
	✓	`AuthenticationSuccessMsg`	Yes/no	Print message on stderr on successful authentication
✓	✓	`BatchMode`	Yes/no	Disable prompting
✓		`BindAddress`	Interface	Select a network interface
	✓	`Cert.DODPKI`	Yes/no	Certificates must be DoD PKI-compliant
	✓	`Cert.EndpointIdentityCheck`	Yes/no	Verify server hostname versus certificate
	✓	`Cert.RSA.Compat.HashScheme`	md5/sha1	Set hash compatibility
✓		`ChallengeResponseAuthentication`	Yes/no	Enable challenge-response authentication
✓		`CheckHostIP`	Yes/no	Detect DNS spoofing
1		`Cipher`	Cipher	Request encryption cipher
2	✓	`Ciphers`	Cipher_ list	Supported encryption ciphers
✓	✓	`ClearAllForwardings`	Yes/no	Ignore any specified forwarding
✓	✓	`Compression`	Yes/no	Enable data compression
✓		`CompressionLevel`	0-9	Select compression algorithm
✓		`ConnectionAttempts`	# attempts	# of retries by client
✓		`ConnectTimeout`	Time	Timeout for connecting to SSH server
✓		`ControlMaster`	Yes/no/ask	Enable connection sharing
✓		`ControlPath`	Socket	Location of socket for connection sharing
	✓	`DebugLogFile`	Filename	File for debug messages
	✓	`DefaultDomain`	Domain	Specify domain name
	✓	`DisableVersionFallback`	Yes/no	Compatibility with old versions of software
	✓	`DontReadStdin`	Yes/no	Redirect stdin from /dev/ null
✓		`DynamicForward`	Port, socket	Set up a dynamic forwarding
	✓	`EkInitString`	Init string	Initialization string for external host key provider
	✓	`EkProvider`	Provider	External host key provider
✓		`EnableSSHKeysign`	Yes/no	Enable ssh-keysign

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

OpenSSH	Tectia	Option	Meaning
^a The output filename is given as the final argument to ssh-keygen.
^b You may need to escape the question mark in your shell, e.g.,`-\?`
	✓	-1 filename	Convert SSH1 key file to Tectia
	✓	-7 filename	Convert PKCS #7 key file to Tectia
	✓	-a trials	DH-GEX: number of primality
✓	✓	-b bits	# of bits in generated key
	✓	-B positive_integer	Specify numeric base for displaying key
✓		-B	Print fingerprint of key in BubbleBabble format
✓		-c	Change comment (with -C )
	✓	-c comment	Change comment
✓		-C comment	Specify new comment (with -c)
✓		-d	Generate DSA key
	✓	-D filename	Derive public key from private-key file
✓		-D reader	Download public key from smartcard reader
	✓	-e filename	Edit key file interactively
✓		-e	Export OpenSSH public key to Tectia format
✓		-f filename ^a	Output filename
	✓	-F filename	Print fingerprint of public key
✓		-G filename	DH-GEX: output file to generate candidate primes
	✓	-h	Print help and exit
	✓	-i	Display key information
✓		-i	Convert Tectia public key to OpenSSH
✓		-k	Convert PKCS #12 key file to Tectia
✓		-l	Print fingerprint of public key
✓		-M memory	DH-GEX: set amount of memory to use
	✓	-N passphrase	Specify new passphrase
	✓	-o filename	Output filename
✓		--overwrite (yes \|no)	Overwrite output file or not
✓		-p	Change passphrase (with -P and -N)
	✓	-P passphrase	Specify old passphrase (with

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

OpenSSH	Tectia	Option	Meaning
	✓	-1	SSH1 compatibility mode
✓		-a socket	Bind to given socket
✓		-d	Debug mode
	✓	-d debug_spec	Debug mode
✓	✓	-c	Print C-shell-style commands
✓		-k	Kill existing agent
✓	✓	-s	Print sh-style commands
✓		-t time	Set maximum lifetime of identities

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

OpenSSH	Tectia	Option	Meaning
	✓	-1	Limit SSH-1 compatibility
✓		-c	Confirm identities before loading them
✓	✓	-d	Unload key
✓	✓	-D	Unload all keys
✓		-e reader	Remove key in smartcard reader
	✓	-f step	Limit agent-forwarding hops
	✓	-F host_list	Limit agent-forwarding hosts
	✓	-I	PGP keys are identified by ID
	✓	-l	List loaded keys
✓		-l	List fingerprints of loaded keys
	✓	-L	Lock agent
✓		-L	List loaded keys
	✓	-N	PGP keys are identified by name
	✓	-p	Read passphrase from stdin
	✓	-P	PGP keys are identified by fingerprint
	✓	-R filename	Specify PGP keyring file
	✓	-s reader	Add key in smartcard reader
✓	✓	-t timeout	Expire key after timeout
	✓	-u	Read key from URL
	✓	-U	Unlock agent
✓		-x	Lock agent
✓		-X	Unlock agent

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

~/.ssh/authorized_keys key options: use one public key per line, preceded by options.

Option	Meaning
`command`="Unix shell command"	Specify a forced command
`environment`="variable = value"	Set environment variable
`from`=host_ or_ ip_address_specification	Limit incoming hosts
`no-agent-forwarding`	Disable agent forwarding
`no-port-forwarding`	Disable port forwarding
`no-pty`	Don't allocate TTY
`no-x11-forwarding`	Disable X Window forwarding
`permitopen ="H:P"`	Permit forwarding to local port P from remote host H

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

~/.ssh2/authorization keywords: use one keyword/value pair per line.

Keyword	Meaning
`Command` Unix_command	Old way to specify a forced command; now obsolete, use `Options`
`Key` filename.pub	Location of public-key file
`Options` comma-separated-list-of-options	Options for the key immediately preceding it; see Options table below
`PgpPublicKeyFile` filename	Location of PGP public-key file
`PgpKeyFingerprint` fingerprint	Select PGP key by fingerprint
`PgpKeyId` id	Select PGP key by ID
`PgpKeyName` name	Select PGP key by name

~/.ssh2/authorization key options: one or more options separated by commas.

Option	Meaning
`allow-from`=host_ or_ ip_address_specification	Accept connections from incoming hosts
`command`="Unix shell command"	Specify a forced command
`deny-from`=host_ or_ ip_address_specification	Reject connections from incoming hosts
`environment`="variable = value"	Set environment variable
`idle-timeout`=time	Set idle timeout
`no-agent-forwarding`	Disable agent forwarding
`no-port-forwarding`	Disable port forwarding
`no-pty`	Don't allocate TTY
`no-x11-forwarding`	Disable X Window forwarding

~/.ssh2/identification keywords: one keyword/value pair per line.

Keyword	Meaning
`IdKey` filename	Location of private-key file
`IdPgpKeyFingerprint` fingerprint	Select PGP key by fingerprint
`IdPgpKeyId` id	Select PGP key by ID
`IdPgpKeyName` name	Select PGP key by name
`PgpSecretKeyFile` filename	Location of PGP private-key file

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Variable	Set by	In	Meaning
SSH_ASKPASS	ssh user	OpenSSH	Path to askpass program
SSH_AUTH_SOCK	ssh-agent	OpenSSH	Path to socket
SSH2_AUTH_SOCK	ssh-agent	Tectia	Path to socket
SSH_CLIENT	sshd	OpenSSH	Client socket info
SSH2_CLIENT	sshd	Tectia	Client socket info
SSH_CONNECTION	sshd	OpenSSH	Client and server socket info
SSH_ORIGINAL_COMMAND	sshd	OpenSSH	Client's remote command string
SSH_ORIGINAL_COMMAND2	sshd	Tectia	Client's remote command string
SSH_SOCKS_SERVER	ssh user	Tectia	SOCKS firewall information
SSH_TTY	sshd	OpenSSH	Name of allocated TTY
SSH2_TTY	sshd	Tectia	Name of allocated TTY

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.