Per-Account Server Configuration

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 or her own account, using the facilities highlighted in Figure 8-1, without
needing special privileges or assistance from the system administrator.
Figure 8.1. Per-account configuration (highlighted parts)

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.

Book: SSH, The Secure Shell: The Definitive Guide Section: Chapter 8. Per-Account Server Configuration
8.1 Limits of This Technique
Per-account configuration can do many interesting things, but it has some restrictions that we will discuss:

• ●  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. Trusted-host and password authentication provide a much narrower range of options.
  8.1.1 Overriding Serverwide Settings
  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
  [1]
  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. [Section 5.2.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 sshd might violate your usage agreement and/or certainly annoy your sysadmin. And that's never a wise thing to do.
  8.1.2 Authentication Issues
  

To make the best use of per-account configuration, use public-key authentication.

Password authentication is too limited, since the only way to control access is with the password itself. Trusted-host authentication permits a small amount of flexibility, but not nearly as much as public-key authentication.
If you're still stuck in the password-authentication dark ages, let this be another reason to switch to public keys. Even though passwords and public-key passphrases might seem similar (you type a secret word, and voilà, you're logged in), public keys are far more flexible for permitting or denying access to your account. Read on and learn how.
[1]
There is one exception to this rule: trusted-host authentication. A user's ~/.shosts file may
override a restriction placed by the system administrator in /etc/shosts.equiv. [Section 8.3][Section 3.4.2.3]

Book: SSH, The Secure Shell: The Definitive Guide Section: Chapter 8. Per-Account Server Configuration
8.2 Public Key-Based Configuration
To set up public-key authentication in your account on an SSH server machine, you create an authorization file, typically called authorized_keys (SSH1, OpenSSH/1), authorized_keys2 (OpenSSH/2), or authorization (SSH2), and list the keys that provide access to your account. [Section 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 clients will be forcibly disconnected if they aren't sending data Disabling certain features of the incoming SSH connection, such as port forwarding and tty allocation

As we
server
will use the new information. Any existing connections are already authenticated and won't be affected by the change.

demonstrate how to modify your authorization file, remember that the file is consulted by the SSH only at authentication time. Therefore, if you change your authorization file, only new connections

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.
8.2.1 SSH1 Authorization Files
Your SSH1 authorized_keys file, generally found in ~/.ssh/authorized_keys, is a secure doorway into your account via the SSH-1 protocol. Each line of the file contains a public key and means the following: "I give permission for SSH-1 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.
Each line of authorized_keys contains up to three items in order, some optional and some required:

• ●  A set of options (optional, surprise, surprise).
  
• ●  The public key (required). This appears in three parts: [Section 3.4.2.2]
  
  • ❍  The number of bits in the key, typically a small integer such as 1024
    
  • ❍  The exponent of the key: an integer
    
  • ❍  The modulus of the key: a very large integer, typically several hundred digits long
    
• ●  A descriptive comment (optional). This can be any text, such as "Bob's public key" or "My home PC using SecureCRT 3.1."
  

Public keys and comments are generated by ssh-keygen in .pub files, you may recall, and you typically insert

them into authorized_keys by copying. [Section 2.4.3] Options, however, are usually typed into
[2]
An option may take two forms. It may be a keyword, such as:

# SSH1, OpenSSH: Turn off port forwarding
no-port-forwarding

or it may be a keyword followed by an equals sign and a value, such as:

# SSH1, OpenSSH: Set idle timeout to five minutes
idle-timeout=5m

Multiple options may be given together, separated by commas, with no whitespace between the options:

# SSH1, OpenSSH
no-port-forwarding,idle-timeout=5m

If you mistakenly include whitespace:

# THIS IS ILLEGAL: whitespace between the options
no-port-forwarding, idle-timeout=5m

your connection by this key won't work properly. If you connect with debugging turned on (ssh1 -v), you will see a "syntax error" message from the SSH server.
Many SSH users aren't aware of options or neglect to use them. This is a pity because options provide extra security and convenience. The more you know about the clients that access your account, the more options you can use to control that access.
8.2.2 SSH2 Authorization Files
[3]
An SSH2 authorization file, typically found in ~/.ssh2/authorization,
ancestor. Instead of public keys, it contains keywords and values, much like other SSH configuration files we've seen. Each line of the file contains one keyword followed by its value. The most commonly used keywords are Key and Command.
Public keys are indicated using the Key keyword. Key is followed by whitespace, and then the name of a file containing a public key. Relative filenames refer to files in ~/.ssh2. For example:

# SSH2 only
Key myself.pub

means that an SSH-2 public key is contained in ~/.ssh2/myself.pub. Your authorization file must contain at least one Key line for public-key authentication to occur.
Each Key line may optionally be followed immediately by a Command keyword and its value. Command specifies a forced command, i.e., a command to be executed whenever the key immediately above is used

authorized_keys with a text editor.

has a different format from its SSH1

for access. We discuss forced commands later in great detail. [Section 8.2.4] For now, all you need to know is this: a forced command begins with the keyword Command, is followed by whitespace, and ends with a shell command line. For example:

# SSH2 only
Key somekey.pub
Command "/bin/echo All logins are disabled"

Remember that a Command line by itself is an error. The following examples are illegal:

# THIS IS ILLEGAL: no Key line
Command "/bin/echo This line is bad."
# THIS IS ILLEGAL: no Key line precedes the second Command
Key somekey.pub
Command "/bin/echo All logins are disabled"
Command "/bin/echo This line is bad."

8.2.2.1 SSH2 PGP key authentication
SSH2 Version 2.0.13 introduced support for PGP authentication. [Section 5.5.1.6] Your authorization file may also include PgpPublicKeyFile, PgpKeyName, PgpKey Fingerprint, and PgpKeyId
lines. A Command line may follow PgpKeyName, PgpKeyFingerprint, or PgpKeyId, just as it may follow Key:

# SSH2 only
PgpKeyName my-key
Command "/bin/echo PGP authentication was detected"

8.2.3 OpenSSH Authorization Files
For SSH-1 protocol connections, OpenSSH/1 uses the same authorized_keys file as SSH1. All configuration that's possible with SSH1 is available within OpenSSH/1.
For SSH-2 connections, OpenSSH/2 takes a new approach unlike SSH2's: a new authorization file, ~/.ssh/ authorized_keys2, with a format similar to that of authorized_keys. Each line may contain:

• ●  Key authorization options (optional)
  
• ●  The string "ssh-dss" (required)
  
• ●  The DSA public key, represented as a long string (required)
  
• ●  A descriptive comment (optional)
  Here's an example with the long public key abbreviated:
  

  host=192.168.10.1 ssh-dss AAAAB3NzaC1kc3MA... My OpenSSH key
  

  8.2.4 Forced Commands
  

Ordinarily, an SSH connection invokes a remote command chosen by the client:

# Invoke a remote login shell
$ ssh server.example.com
# Invoke a remote directory listing
$ ssh server.example.com /bin/ls

A forced command transfers this control from the client to the server. Instead of the client's deciding which command will run, the owner of the server account decides. In Figure 8-2, the client has requested the command /bin/ls, but the server-side forced command runs /bin/who instead.
Figure 8.2. Forced command substituting /bin/who for /bin/ls
Forced commands can be quite useful. Suppose you want to give your assistant access to your account but only to read your email. You could associate a forced command with your assistant's SSH key to run only your email program and nothing else.
In SSH1 and OpenSSH, a forced command may be specified in authorized_keys with the "command" option preceding the desired key. For example, to run the email program pine whenever your assistant connects:
# SSH1, OpenSSH
command="/usr/local/bin/pine" ...secretary's public key...
In SSH2, a forced command appears on the line immediately following the desired Key, using the Command keyword. The previous example would be represented:

# SSH2 only
Key secretary.pub
Command "/usr/local/bin/pine"

You may associate at most one forced command with a given key. To associate multiple commands with a key, put them in a script on the remote machine and run the script as the forced command. (We demonstrate this in [Section 8.2.4.3].) 

Precedence

7.4.7 Forwarding
Port forwarding and X forwarding are covered in Chapter 9 and agent forwarding in Chapter 6. We mention them here only for completeness, since forwarding can be controlled in the client configuration file and on the command line.
7.4.8 Encryption Algorithms
When establishing a connection, an SSH client and server have a little conversation about encryption. The server says, "Hello client, here are the encryption algorithms I support." In return, the client says, "Hi there server, I'd like to choose this particular algorithm, please." Normally, they reach agreement, and the connection proceeds. If they can't agree on an encryption algorithm, the connection fails.
Most users let the client and server work things out themselves. But if you like, you may instruct the client to request particular encryption algorithms in its conversation with the server. In SSH1 and OpenSSH, this is done with the Cipher keyword followed by your encryption algorithm of choice:

# SSH1, OpenSSH
Cipher blowfish

or the -c command-line option:

# SSH1, SSH2, OpenSSH
$ ssh -c blowfish server.example.com
$ scp -c blowfish myfile server.example.com:

SSH2 is almost the same, but the keyword is Ciphers (note the final "s") and is followed by one or more encryption algorithms, separated by commas, indicating that any of these algorithms is acceptable:

# SSH2, OpenSSH/2
Ciphers blowfish,3des

SSH2 also supports the -c command-line option as previously, but it may appear multiple times to specify several acceptable ciphers:

# SSH2 only
$ ssh2 -c blowfish -c 3des -c idea server.example.com
$ scp2 -c blowfish -c 3des -c idea myfile server.example.com:

OpenSSH/2 permits multiple algorithms to follow a single -c, separated by commas, to achieve the same effect: # OpenSSH/2 only

$ ssh -c 3des-cbc,blowfish-cbc,arcfour server.example.com

All ciphers acceptable by a server may be specified for the client. [Section 5.4.5] Check the latest SSH documentation for a current list of supported ciphers.
7.4.8.1 MAC algorithms
The -m command-line option lets you select the integrity-checking algorithm, known as the MAC (Message Authentication Code), used by ssh2 : [Section 3.9.3]

# SSH2 only
$ ssh2 -m hmac-sha1 server.example.com

You can specify multiple algorithms on the command line, each preceded by a separate -m option: # SSH2 only

$ ssh2 -m hmac-sha1 -m another-one server.example.com

and the SSH2 server selects one to use.
7.4.9 Session Rekeying
The RekeyIntervalSeconds keyword specifies how often (in seconds) the SSH2 client performs key exchange with the server to [15]
replace the session data-encryption and integrity keys. The default is 3600 seconds (one hour), and a zero value disables rekeying:

# SSH2 only
RekeyIntervalSeconds 7200

7.4.10 Authentication
In a typical SSH setup, clients try to authenticate by the strongest methods first. If a particular method fails or isn't set up, the next one is tried, and so on. This default behavior should work fine for most needs.
Nevertheless, your clients may request specific types of authentication if they need to do so. For example, you might want to use public- key authentication only, and if it fails, no other methods should be tried.
7.4.10.1 Requesting an authentication technique
SSH1 and OpenSSH clients can request specific authentication methods by keyword. The syntax is the same as the server's in /etc/ sshd_config. [Section 5.5.1] You can specify:

     PasswordAuthentication
     RhostsAuthentication
     RhostsRSAAuthentication
     RSAAuthentication
     TISAuthentication
     KerberosAuthentication

(The latter two keywords require TIS or Kerberos support compiled in, respectively.) Any or all of these keywords may appear with the value yes or no.
For SSH2, the AllowedAuthentications keyword selects one or more authentication techniques. Again, the keyword has the same use here as for the SSH2 server. [Section 5.5.1]
OpenSSH accepts the same keywords as SSH1 except for TISAuthentication, and it adds SkeyAuthentication for one-time passwords. [Section 5.5.1.10]
7.4.10.2 The server is the boss

When a client specifies an authentication technique, this is just a request, not a requirement. For example, the configuration:

PasswordAuthentication yes

informs the SSH server that you, the client, agree to participate in password authentication. It doesn't guarantee that you will authenticate by password, just that you are willing to do it if the server agrees. The server makes the decision and might still authenticate you by another method.
If a client wants to require an authentication technique, it must tell the server that one, and only one, technique is acceptable. To do this, the client must deselect every other authentication technique. For example, to force password authentication in SSH1 or OpenSSH:
# SSH1, OpenSSH
# This guarantees password authentication, if the server supports it. PasswordAuthentication yes
RSAAuthentication no
RhostsRSAAuthentication no
RhostsAuthentication no
KerberosAuthentication no
# ... Add any other authentication methods, with value "no"
If the server doesn't support password authentication, however, this connection attempt will fail.
SSH2 has a better system: the AllowedAuthentications keyword, which has the same syntax and meaning as the server keyword of the same name: [Section 5.5.1]

# SSH2 only
AllowedAuthentications password

7.4.10.3 Detecting successful authentication
SSH2 provides two keywords for reporting whether authentication is successful: AuthenticationSuccessMsg and AuthenticationNotify. Each of these causes SSH2 clients to print a message after attempting authentication.
AuthenticationSuccessMsg controls the appearance of the message "Authentication successful" after authentication, which is printed on standard error. Values may be yes (the default, to display the message) or no:

$ ssh2 server.example.com
Authentication successful.
Last login: Sat Jun 24 2000 14:53:28 -0400
...
$ ssh2 -p221 -o 'AuthenticationSuccessMsg no' server.example.com
Last login: Sat Jun 24 2000 14:53:28 -0400
...

AuthenticationNotify, an undocumented keyword, causes ssh2 to print a different message, this time on standard output. If the authentication is successful, the message is "AUTHENTICATED YES", otherwise it's "AUTHENTICATED NO". Values may be yes (print the message) or no (the default):

$ ssh2 -q -o 'AuthenticationNotify yes' server.example.com
AUTHENTICATED YES
Last login: Sat Jun 24 2000 14:53:35 -0400
...

The behavior of these two keywords differs in the following ways:

• ●  AuthenticationSuccessMsg writes to stderr; AuthenticationNotify writes to stdout.
  
• ●  The -q command-line option [Section 7.4.15] silences AuthenticationSuccessMsg but not AuthenticationNotify.
  This makes AuthenticationNotify better for scripting (for example, to find out if an authentication can succeed or not). Notice that exit is used as a remote command so the shell terminates immediately:
  

       #!/bin/csh
       # Get the AUTHENTICATION line
       set line = `ssh2 -q -o 'AuthenticationNotify yes' server.example.com exit`
       # Capture the second word
       set result = `echo $line | awk '{print $2}'`
  

     if ( $result == "YES" ) then
       ...

In fact, AuthenticationNotify is used precisely in this manner by scp2 and sftp, then these programs run ssh2 in the background to connect to the remote host for file transfers. They wait for the appearance of the "AUTHENTICATED YES" message to know that the connection was successful, and they can now start speaking to the sftp-server.
AuthenticationSuccessMsg provides an additional safety feature: a guarantee that authentication has occurred. Suppose you invoke ssh2 and are prompted for your passphrase:

$ ssh2 server.example.com
Passphrase for key "mykey": ********

You then see, to your surprise, a second passphrase prompt:

Passphrase for key "mykey":

You might conclude that you mistyped your passphrase the first time and type it again. But what if the second prompt came not from your ssh2 client, but from the server, which has been hacked by a evil intruder? Your passphrase has just been stolen! To counteract this potential threat, ssh2 prints "Authentication successful" after authentication, so the previous session actually looks like this:

$ ssh2 server.example.com
Passphrase for key "mykey": ********
Authentication successful.
Passphrase for key "mykey":

The second passphrase prompt is now revealed as a fraud.
7.4.11 Data Compression
SSH connections may be compressed. That is, data sent over an SSH connection may be compressed automatically before it is encrypted and sent, and automatically uncompressed after it is received and decrypted. If you're running SSH software on fast, modern processors, compression is generally a win. In an informal test between two Sun SPARCstation 10 workstations connected by Ethernet, we transmitted 12 MB of text from server to client over compressed and uncompressed SSH connections. With compression enabled at an appropriate level (explained later), the transmission time was halved.
To enable compression for a single session, use command-line options. Unfortunately, the implementations have incompatible syntax. For SSH1 and OpenSSH, compression is disabled by default, and the -C command-line option turns it on:

# SSH1, OpenSSH: turn compression ON
$ ssh1 -C server.example.com
$ scp1 -C myfile server.example.com:

For SSH2, however, -C means the opposite, turning compression off: # SSH2 only: turn compression OFF

$ ssh2 -C server.example.com

and +C turns it on:
# SSH2 only: turn compression ON
$ ssh2 +C server.example.com
(There is no compression option for scp2.) To enable or disable compression for all sessions, use the Compression keyword, given a
value of yes or no (the default): # SSH1, SSH2, OpenSSH

Compression yes

SSH1 and OpenSSH may also set an integer compression level to indicate how much the data should be compressed. Higher levels mean
better compression but slower performance. Levels may be from to 9 inclusive, and the default level is 6.[16] The CompressionLevel keyword modifies the level:

# SSH1, OpenSSH
CompressionLevel 2

Changing the CompressionLevel can have a drastic effect on performance. Our earlier 12-MB test was run with the default compression level, 6, and took 42 seconds. With compression at various levels, the time ranged from 25 seconds to nearly two minutes (see Table 7-2). With fast processors and network connections, CompressionLevel 1 seems an obvious win. Experiment with CompressionLevel to see which value yields the best performance for your setup. 

Level	Bytes Sent	Time Spent (sec.)	Size Reduced (%)	Time Reduced (%)
None	12112880	55	0	0
1	2116435	25	82.5	55
2	2091292	25	82.5	55
3	2079467	27	82.8	51
4	1881366	33	84.4	40
5	1833850	36	84.8	35
6	1824180	42	84.9	24
7	1785725	48	85.2	13
8	1756048	102	85.5	-46
9	1755636	118	85.5	-53

7.4.12 Program Locations
The auxiliary program ssh-signer2 is normally located in SSH2's installation directory, along with the other SSH2 binaries. [Section 3.5.2.3] You can change this location with the undocumented keyword SshSignerPath:

# SSH2 only
SshSignerPath /usr/alternative/bin/ssh-signer2

If you use this keyword, be sure to set it to the fully qualified path of the program. If you use a relative path, hostbased authentication works only for users who have ssh-signer2 in their search path, and cron jobs fail without ssh-signer2 in their path.
7.4.13 Subsystems
Subsystems are predefined commands supported by an SSH2 server. [Section 5.7] Each installed server can implement different [17]
subsystems, so check with the system administrator of the server machine for a list.
The -s option of ssh2, undocumented at press time, invokes a subsystem on a remote machine. For example, if the SSH2 server running on server.example.com has a "backups" subsystem defined, you run it as:

$ ssh2 -s backups server.example.com

7.4.14 SSH1/SSH2 Compatibility
SSH2 has a few keywords relating to SSH1 compatibility. If compatibility is enabled, when ssh2 is asked to connect to an SSH-1 server, it invokes ssh1 (assuming it is available).
The keyword Ssh1Compatibility turns on SSH1 compatibility, given the value yes or no. The default is yes if compatibility is compiled in; otherwise it is no:

# SSH2 only
Ssh1Compatibility yes

The keyword Ssh1Path locates the executable for ssh1, which by default is set during compile-time configuration: # SSH2 only
Ssh1Path /usr/local/bin/ssh1
If you want SSH2 agents to store and retrieve SSH1 keys, turn on agent compatibility with the keyword Ssh1AgentCompatibility:
[Section 6.3.2.4]

# SSH2 only
Ssh1AgentCompatibility yes

Finally, scp2 invokes scp1 if the -1 command-line option is present: # SSH2 only

scp2 -1 myfile server.example.com:

In this case, scp2 -1 simply invokes scp1, passing along all its arguments (except for the -1 of course). We don't see much point to this option: if scp1 is available, why not invoke it directly? But the option is there if you need it.
7.4.15 Logging and Debugging
Earlier in the chapter, we introduced the -v command-line option which causes SSH clients to print debugging messages. Verbose mode works for ssh and scp :

# SSH1, OpenSSH
$ ssh -v server.example.com
SSH Version 1.2.27 [sparc-sun-solaris2.5.1], protocol version 1.5.
client: Connecting to server.example.com [128.9.176.249] port 22.
client: Connection established.
...

Verbose mode can also be turned on for SSH2 with the (surprise!) VerboseMode keyword: # SSH2 only

VerboseMode yes

If you ever encounter problems or strange behavior from SSH, your first instinct should be to turn on verbose mode.
SSH2 has multiple levels of debug messages; verbose mode corresponds to level 2. You can specify greater or less debugging with the -d command-line option, followed by an integer from to 99:

$ ssh2 -d0
$ ssh2 -d1
debugging

$ ssh2 -d2
$ ssh2 -d3
$ ssh2 -d#

No debugging messages
Just a little

Same as-v
A little more detailed
And so on...

The analogous feature in OpenSSH is the LogLevel directive, which takes one of six levels as an argument: QUIET, FATAL, ERROR, INFO, VERBOSE, and DEBUG (in order of increasing verbosity). So for example:

# OpenSSH
$ ssh -o LogLevel=DEBUG

is equivalent to ssh -v.
The -d option may also use the same module-based syntax as for server debugging: [Section 5.8.2.2]

$ ssh2 -d Ssh2AuthPasswdServer=2 server.example.com

scp2 also supports this level of debugging, but the option is -D instead of -d since scp -d is already used to mean something else:

$ scp2 -D Ssh2AuthPasswdServer=2 myfile server.example.com

To disable all debug messages, use -q:

# SSH1, SSH2, OpenSSH
$ ssh -q server.example.com

# SSH2 only
$ scp2 -q myfile server.example.com:

or the QuietMode keyword: # SSH2 only

QuietMode yes

Finally, to print the program version number, use -V: # SSH1, SSH2, OpenSSH
$ ssh -V

# SSH2 only
$ scp2 -V

7.4.16 Random Seeds
SSH2 lets you change the location of your random seed file, which is ~/.ssh2/random_seed by default: [Section 5.4.1.2]

# SSH2 only
RandomSeedFile /u/smith/.ssh2/new_seed

[5] In SSH2 2.0.13 and earlier, the -i option and IdentityFile require the identity file to be in your SSH2 directory, ~/.ssh2. SSH2 2.1.0 and later accept absolute pathnames; any path that doesn't begin with a slash ( /) is treated as relative to ~/.ssh2.
[6]
SSH2 accomplishes the same thing with identification files, which may contain multiple keys.
[7]
OpenSSH additionally keeps SSH-2 known host keys in the file ~/.ssh/known_hosts2.
[8]
scp also has a -p option with the same meaning as for rcp : "preserve file permissions."
[9]
Yes, it's counterintuitive for -P to mean nonprivileged, but that's life.
[10]
The -P option was already taken for setting the port number. The source code suggests that -L can mean "large local port numbers."
[11]
The upper limit of five prompts is enforced by the SSH server.
[12] In SSH1 and OpenSSH, the no-pty option in authorized_keys can override this request for a tty. [Section 8.2.9]
[13] Only if ssh is compiled with support for rsh, using the compile-time flag --with-rsh. [Section 4.1.5.12] If not, Scenario 2, fail and stop, is the only possibility.
[14] Again, only if ssh is compiled with -with-rsh.
[15]
Note that at press time, you must disable session rekeying in the SSH2 client if you wish to use it with the OpenSSH server, because the latter
doesn't yet support session rekeying. The connection dies with an error once the rekeying interval expires. This feature will likely be implemented soon, however.
[16]
SSH's compression functionality comes from GNU Zip, a.k.a., gzip, a compression utility popular in the Unix world. The nine
CompressionLevel values correspond to the nine methods supported by gzip.

[17]
Or examine the server machine's configuration file /etc/ssh2/sshd2_config yourself for lines beginning with subsystem-.