Remote command - in SSH, you don't have to run a general shell
session on the server. Instead, you can choose to run a single specific command
(such as a mail user agent, for example).
Don't allocate a pseudo-terminal - when connecting to a Unix
system, most interactive shell sessions are run in a pseudo-terminal,
which allows the Unix system to pretend it's talking to a real physical terminal
device but allows the SSH server to catch all the data coming from that fake device
and send it back to the client. Occasionally you might find you have a need to run
a session not in a pseudo-terminal.
Don't start a shell or command - will not
attempt to run a shell or command after connecting to the remote server. You might
want to use this option if you are only using the SSH connection for port forwarding, and your user account on the server does not have the ability
to run a shell. This feature is only available in SSH protocol
version 2 (since the version 1 protocol assumes you will always want to run a shell).
Enable compression - enables data compression in the SSH connection:
data sent by the server is compressed before sending, and decompressed at the client
end. Likewise, data sent from PC to the server is compressed first and the server
decompresses it at the other end. This can help make the most of a low-bandwidth
connection.
SSH version - allows you to select whether you would like to use SSH protocol
version 1 or version 2.
Encryption options - allows you to choose which one you prefer to use. You can do this by moving
the algorithms up and down in the list box to specify a preference order.
Single-DES is not recommended in the SSH-2 draft protocol standards, but one or
two server implementations do support it. You can use single-DES to interoperate
with these servers if you enable the ‘Enable legacy use of single-DES in SSH-2’
option.
SSH key exchange - allows you to configure
options related to SSH-2 key exchange.
Key exchange occurs at the start of an SSH connection (and occasionally thereafter);
it establishes a shared secret that is used as the basis for
all of SSH's security features. It is therefore very important for the security
of the connection that the key exchange is secure.
Key exchange is a cryptographically intensive process; if either the client or the
server is a relatively slow machine, the slower methods may take several tens of
seconds to complete.
If connection startup is too slow, or the connection hangs periodically, you may
want to try changing these settings.
If you don't understand what any of this means, it's safe to leave these settings
alone.
This entire panel is only relevant to SSH protocol version 2; none of these settings
affect SSH-1 at all.
‘Group 14’: a well-known 2048-bit group. ‘Group 1’: a well-known 1024-bit group. This is less secure than group 14, but may
be faster with slow client or server machines, and may be the only method supported
by older server software. ‘Group exchange’: with this method, instead of using a fixed
group, requests that the server suggest a group to use for key exchange, the
server can avoid groups known to be weak, and possibly invent new ones over time,
without any changes required to configuration. We recommend use of this
method, if possible.
Max minutes before rekey - if the session key negotiated at connection startup is used too much or for too
long, it may become feasible to mount attacks against the SSH connection. Therefore,
the SSH-2 protocol specifies that a new key exchange should take place every so
often; this can be initiated by either the client or the server.
While this renegotiation is taking place, no data can pass through the SSH connection,
so it may appear to ‘freeze’.
Usually the same algorithm is used as at the start of the connection, with a similar
overhead. Max minutes before rekey
specifies the amount of time that is allowed to elapse
before a rekey is initiated. If this is set to zero, then will not rekey due to
elapsed time. The SSH-2 protocol specification recommends a timeout of at most 60
minutes.
Max data before rekey -
You might have a need to disable time-based rekeys completely for the same reasons
that keepalives aren't always helpful. If you anticipate suffering
a network dropout of several hours in the middle of an SSH connection, but were
not actually planning to send data down that connection during those hours,
then an attempted rekey in the middle of the dropout will probably cause the connection
to be abandoned, whereas if rekeys are disabled then the connection should in principle
survive (in the absence of interfering firewalls). For these purposes,
rekeys have much the same properties as keepalives. (Except that rekeys have cryptographic
value in themselves, so you should bear that in mind when deciding whether to turn
them off.) Note, however, the the SSH server can still initiate rekeys. Max data before rekey specifies the amount of data (in bytes) that is permitted
to flow in either direction before a rekey is initiated. If this is set to zero, then will not rekey due to transferred data. The SSH-2 protocol specification recommends
a limit of at most 1 gigabyte.
Disabling data-based rekeys entirely is a bad idea. The integrity,
and to a lesser extent, confidentiality of the SSH-2 protocol
depend in part on rekeys occuring before a 32-bit packet sequence number wraps around.
Unlike time-based rekeys, data-based rekeys won't occur when the SSH connection
is idle, so they shouldn't cause the same problems. The SSH-1 protocol, incidentally,
has even weaker integrity protection than SSH-2 without rekeys.
Attempt
TIS or CryptoCard authentication -
TIS and CryptoCard authentication are simple challenge/response
forms of authentication available in SSH protocol version 1 only. You might use
them if you were using S/Key one-time passwords,
for example, or if you had a physical security token that generated
responses to authentication challenges.
With this switch enabled, then will attempt these forms of authentication if the
server is willing to try them. You will be presented with a challenge string (which
will be different every time) and must supply the correct response in order to log
in. If your server supports this, you should talk to your system administrator about
precisely what form these challenges and responses take.
Attempt
keyboard-interactive authentication - the SSH-2 equivalent of TIS authentication is called ‘keyboard-interactive’. It
is a flexible authentication method using an arbitrary sequence of requests and
responses; so it is not only useful for challenge/response mechanisms
such as S/Key, but it can also be used for (for example) asking
the user for a new password when the old one has expired.
Allow attempted
changes of username - in the SSH-1 protocol, it is impossible to change username after failing to authenticate.
So if you mis-type your username at the ‘login as:’ prompt, you will not be
able to change it except by restarting.
The SSH-2 protocol does allow changes of username, in principle, but does
not make it mandatory for SSH-2 servers to accept them. In particular, OpenSSH does not accept a change of username; once you have sent one username,
it will reject attempts to try to authenticate as another user. (Depending on the
version of OpenSSH, it may quietly return failure for all login attempts, or it
may send an error message.)
Private
key file for authentication - this box is where you enter the name of your private key file if you are using public key authentication.
