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-.