mirror of
git://anongit.mindrot.org/openssh.git
synced 2024-12-17 23:54:35 +00:00
1781 lines
71 KiB
Plaintext
1781 lines
71 KiB
Plaintext
.\" -*- nroff -*-
|
|
.\"
|
|
.\" $Id: RFC.nroff,v 1.1 1999/10/27 03:42:43 damien Exp $
|
|
.\"
|
|
.pl 10.0i
|
|
.po 0
|
|
.ll 7.2i
|
|
.lt 7.2i
|
|
.nr LL 7.2i
|
|
.nr LT 7.2i
|
|
.ds LF Ylonen
|
|
.ds RF FORMFEED[Page %]
|
|
.ds CF
|
|
.ds LH Internet-Draft
|
|
.ds RH 15 November 1995
|
|
.ds CH SSH (Secure Shell) Remote Login Protocol
|
|
.na
|
|
.hy 0
|
|
.in 0
|
|
Network Working Group T. Ylonen
|
|
Internet-Draft Helsinki University of Technology
|
|
draft-ylonen-ssh-protocol-00.txt 15 November 1995
|
|
Expires: 15 May 1996
|
|
|
|
.in 3
|
|
|
|
.ce
|
|
The SSH (Secure Shell) Remote Login Protocol
|
|
|
|
.ti 0
|
|
Status of This Memo
|
|
|
|
This document is an Internet-Draft. Internet-Drafts are working
|
|
documents of the Internet Engineering Task Force (IETF), its areas,
|
|
and its working groups. Note that other groups may also distribute
|
|
working documents as Internet-Drafts.
|
|
|
|
Internet-Drafts are draft documents valid for a maximum of six
|
|
months and may be updated, replaced, or obsoleted by other docu-
|
|
ments at any time. It is inappropriate to use Internet-Drafts as
|
|
reference material or to cite them other than as ``work in pro-
|
|
gress.''
|
|
|
|
To learn the current status of any Internet-Draft, please check the
|
|
``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow
|
|
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
|
|
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
|
|
ftp.isi.edu (US West Coast).
|
|
|
|
The distribution of this memo is unlimited.
|
|
|
|
.ti 0
|
|
Introduction
|
|
|
|
SSH (Secure Shell) is a program to log into another computer over a
|
|
network, to execute commands in a remote machine, and to move files
|
|
from one machine to another. It provides strong authentication and
|
|
secure communications over insecure networks. Its features include
|
|
the following:
|
|
.IP o
|
|
Closes several security holes (e.g., IP, routing, and DNS spoofing).
|
|
New authentication methods: .rhosts together with RSA [RSA] based host
|
|
authentication, and pure RSA authentication.
|
|
.IP o
|
|
All communications are automatically and transparently encrypted.
|
|
Encryption is also used to protect integrity.
|
|
.IP o
|
|
X11 connection forwarding provides secure X11 sessions.
|
|
.IP o
|
|
Arbitrary TCP/IP ports can be redirected over the encrypted channel
|
|
in both directions.
|
|
.IP o
|
|
Client RSA-authenticates the server machine in the beginning of every
|
|
connection to prevent trojan horses (by routing or DNS spoofing) and
|
|
man-in-the-middle attacks, and the server RSA-authenticates the client
|
|
machine before accepting .rhosts or /etc/hosts.equiv authentication
|
|
(to prevent DNS, routing, or IP spoofing).
|
|
.IP o
|
|
An authentication agent, running in the user's local workstation or
|
|
laptop, can be used to hold the user's RSA authentication keys.
|
|
.RT
|
|
|
|
The goal has been to make the software as easy to use as possible for
|
|
ordinary users. The protocol has been designed to be as secure as
|
|
possible while making it possible to create implementations that
|
|
are easy to use and install. The sample implementation has a number
|
|
of convenient features that are not described in this document as they
|
|
are not relevant for the protocol.
|
|
|
|
|
|
.ti 0
|
|
Overview of the Protocol
|
|
|
|
The software consists of a server program running on a server machine,
|
|
and a client program running on a client machine (plus a few auxiliary
|
|
programs). The machines are connected by an insecure IP [RFC0791]
|
|
network (that can be monitored, tampered with, and spoofed by hostile
|
|
parties).
|
|
|
|
A connection is always initiated by the client side. The server
|
|
listens on a specific port waiting for connections. Many clients may
|
|
connect to the same server machine.
|
|
|
|
The client and the server are connected via a TCP/IP [RFC0793] socket
|
|
that is used for bidirectional communication. Other types of
|
|
transport can be used but are currently not defined.
|
|
|
|
When the client connects the server, the server accepts the connection
|
|
and responds by sending back its version identification string. The
|
|
client parses the server's identification, and sends its own
|
|
identification. The purpose of the identification strings is to
|
|
validate that the connection was to the correct port, declare the
|
|
protocol version number used, and to declare the software version used
|
|
on each side (for debugging purposes). The identification strings are
|
|
human-readable. If either side fails to understand or support the
|
|
other side's version, it closes the connection.
|
|
|
|
After the protocol identification phase, both sides switch to a packet
|
|
based binary protocol. The server starts by sending its host key
|
|
(every host has an RSA key used to authenticate the host), server key
|
|
(an RSA key regenerated every hour), and other information to the
|
|
client. The client then generates a 256 bit session key, encrypts it
|
|
using both RSA keys (see below for details), and sends the encrypted
|
|
session key and selected cipher type to the server. Both sides then
|
|
turn on encryption using the selected algorithm and key. The server
|
|
sends an encrypted confirmation message to the client.
|
|
|
|
The client then authenticates itself using any of a number of
|
|
authentication methods. The currently supported authentication
|
|
methods are .rhosts or /etc/hosts.equiv authentication (disabled by
|
|
default), the same with RSA-based host authentication, RSA
|
|
authentication, and password authentication.
|
|
|
|
After successful authentication, the client makes a number of requests
|
|
to prepare for the session. Typical requests include allocating a
|
|
pseudo tty, starting X11 [X11] or TCP/IP port forwarding, starting
|
|
authentication agent forwarding, and executing the shell or a command.
|
|
|
|
When a shell or command is executed, the connection enters interactive
|
|
session mode. In this mode, data is passed in both directions,
|
|
new forwarded connections may be opened, etc. The interactive session
|
|
normally terminates when the server sends the exit status of the
|
|
program to the client.
|
|
|
|
|
|
The protocol makes several reservations for future extensibility.
|
|
First of all, the initial protocol identification messages include the
|
|
protocol version number. Second, the first packet by both sides
|
|
includes a protocol flags field, which can be used to agree on
|
|
extensions in a compatible manner. Third, the authentication and
|
|
session preparation phases work so that the client sends requests to
|
|
the server, and the server responds with success or failure. If the
|
|
client sends a request that the server does not support, the server
|
|
simply returns failure for it. This permits compatible addition of
|
|
new authentication methods and preparation operations. The
|
|
interactive session phase, on the other hand, works asynchronously and
|
|
does not permit the use of any extensions (because there is no easy
|
|
and reliable way to signal rejection to the other side and problems
|
|
would be hard to debug). Any compatible extensions to this phase must
|
|
be agreed upon during any of the earlier phases.
|
|
|
|
.ti 0
|
|
The Binary Packet Protocol
|
|
|
|
After the protocol identification strings, both sides only send
|
|
specially formatted packets. The packet layout is as follows:
|
|
.IP o
|
|
Packet length: 32 bit unsigned integer, coded as four 8-bit bytes, msb
|
|
first. Gives the length of the packet, not including the length field
|
|
and padding. The maximum length of a packet (not including the length
|
|
field and padding) is 262144 bytes.
|
|
.IP o
|
|
Padding: 1-8 bytes of random data (or zeroes if not encrypting). The
|
|
amount of padding is (8 - (length % 8)) bytes (where % stands for the
|
|
modulo operator). The rationale for always having some random padding
|
|
at the beginning of each packet is to make known plaintext attacks
|
|
more difficult.
|
|
.IP o
|
|
Packet type: 8-bit unsigned byte. The value 255 is reserved for
|
|
future extension.
|
|
.IP o
|
|
Data: binary data bytes, depending on the packet type. The number of
|
|
data bytes is the "length" field minus 5.
|
|
.IP o
|
|
Check bytes: 32-bit crc, four 8-bit bytes, msb first. The crc is the
|
|
Cyclic Redundancy Check, with the polynomial 0xedb88320, of the
|
|
Padding, Packet type, and Data fields. The crc is computed before
|
|
any encryption.
|
|
.RT
|
|
|
|
The packet, except for the length field, may be encrypted using any of
|
|
a number of algorithms. The length of the encrypted part (Padding +
|
|
Type + Data + Check) is always a multiple of 8 bytes. Typically the
|
|
cipher is used in a chained mode, with all packets chained together as
|
|
if it was a single data stream (the length field is never included in
|
|
the encryption process). Details of encryption are described below.
|
|
|
|
When the session starts, encryption is turned off. Encryption is
|
|
enabled after the client has sent the session key. The encryption
|
|
algorithm to use is selected by the client.
|
|
|
|
|
|
.ti 0
|
|
Packet Compression
|
|
|
|
If compression is supported (it is an optional feature, see
|
|
SSH_CMSG_REQUEST_COMPRESSION below), the packet type and data fields
|
|
of the packet are compressed using the gzip deflate algorithm [GZIP].
|
|
If compression is in effect, the packet length field indicates the
|
|
length of the compressed data, plus 4 for the crc. The amount of
|
|
padding is computed from the compressed data, so that the amount of
|
|
data to be encrypted becomes a multiple of 8 bytes.
|
|
|
|
When compressing, the packets (type + data portions) in each direction
|
|
are compressed as if they formed a continuous data stream, with only the
|
|
current compression block flushed between packets. This corresponds
|
|
to the GNU ZLIB library Z_PARTIAL_FLUSH option. The compression
|
|
dictionary is not flushed between packets. The two directions are
|
|
compressed independently of each other.
|
|
|
|
|
|
.ti 0
|
|
Packet Encryption
|
|
|
|
The protocol supports several encryption methods. During session
|
|
initialization, the server sends a bitmask of all encryption methods
|
|
that it supports, and the client selects one of these methods. The
|
|
client also generates a 256-bit random session key (32 8-bit bytes) and
|
|
sends it to the server.
|
|
|
|
The encryption methods supported by the current implementation, and
|
|
their codes are:
|
|
.TS
|
|
center;
|
|
l r l.
|
|
SSH_CIPHER_NONE 0 No encryption
|
|
SSH_CIPHER_IDEA 1 IDEA in CFB mode
|
|
SSH_CIPHER_DES 2 DES in CBC mode
|
|
SSH_CIPHER_3DES 3 Triple-DES in CBC mode
|
|
SSH_CIPHER_TSS 4 An experimental stream cipher
|
|
SSH_CIPHER_RC4 5 RC4
|
|
.TE
|
|
|
|
All implementations are required to support SSH_CIPHER_DES and
|
|
SSH_CIPHER_3DES. Supporting SSH_CIPHER_IDEA, SSH_CIPHER_RC4, and
|
|
SSH_CIPHER_NONE is recommended. Support for SSH_CIPHER_TSS is
|
|
optional (and it is not described in this document). Other ciphers
|
|
may be added at a later time; support for them is optional.
|
|
|
|
For encryption, the encrypted portion of the packet is considered a
|
|
linear byte stream. The length of the stream is always a multiple of
|
|
8. The encrypted portions of consecutive packets (in the same
|
|
direction) are encrypted as if they were a continuous buffer (that is,
|
|
any initialization vectors are passed from the previous packet to the
|
|
next packet). Data in each direction is encrypted independently.
|
|
.IP SSH_CIPHER_DES
|
|
The key is taken from the first 8 bytes of the session key. The least
|
|
significant bit of each byte is ignored. This results in 56 bits of
|
|
key data. DES [DES] is used in CBC mode. The iv (initialization vector) is
|
|
initialized to all zeroes.
|
|
.IP SSH_CIPHER_3DES
|
|
The variant of triple-DES used here works as follows: there are three
|
|
independent DES-CBC ciphers, with independent initialization vectors.
|
|
The data (the whole encrypted data stream) is first encrypted with the
|
|
first cipher, then decrypted with the second cipher, and finally
|
|
encrypted with the third cipher. All these operations are performed
|
|
in CBC mode.
|
|
|
|
The key for the first cipher is taken from the first 8 bytes of the
|
|
session key; the key for the next cipher from the next 8 bytes, and
|
|
the key for the third cipher from the following 8 bytes. All three
|
|
initialization vectors are initialized to zero.
|
|
|
|
(Note: the variant of 3DES used here differs from some other
|
|
descriptions.)
|
|
.IP SSH_CIPHER_IDEA
|
|
The key is taken from the first 16 bytes of the session key. IDEA
|
|
[IDEA] is used in CFB mode. The initialization vector is initialized
|
|
to all zeroes.
|
|
.IP SSH_CIPHER_TSS
|
|
All 32 bytes of the session key are used as the key.
|
|
|
|
There is no reference available for the TSS algorithm; it is currently
|
|
only documented in the sample implementation source code. The
|
|
security of this cipher is unknown (but it is quite fast). The cipher
|
|
is basically a stream cipher that uses MD5 as a random number
|
|
generator and takes feedback from the data.
|
|
.IP SSH_CIPHER_RC4
|
|
The first 16 bytes of the session key are used as the key for the
|
|
server to client direction. The remaining 16 bytes are used as the
|
|
key for the client to server direction. This gives independent
|
|
128-bit keys for each direction.
|
|
|
|
This algorithm is the alleged RC4 cipher posted to the Usenet in 1995.
|
|
It is widely believed to be equivalent with the original RSADSI RC4
|
|
cipher. This is a very fast algorithm.
|
|
.RT
|
|
|
|
|
|
.ti 0
|
|
Data Type Encodings
|
|
|
|
The Data field of each packet contains data encoded as described in
|
|
this section. There may be several data items; each item is coded as
|
|
described here, and their representations are concatenated together
|
|
(without any alignment or padding).
|
|
|
|
Each data type is stored as follows:
|
|
.IP "8-bit byte"
|
|
The byte is stored directly as a single byte.
|
|
.IP "32-bit unsigned integer"
|
|
Stored in 4 bytes, msb first.
|
|
.IP "Arbitrary length binary string"
|
|
First 4 bytes are the length of the string, msb first (not including
|
|
the length itself). The following "length" bytes are the string
|
|
value. There are no terminating null characters.
|
|
.IP "Multiple-precision integer"
|
|
First 2 bytes are the number of bits in the integer, msb first (for
|
|
example, the value 0x00012345 would have 17 bits). The value zero has
|
|
zero bits. It is permissible that the number of bits be larger than the
|
|
real number of bits.
|
|
|
|
The number of bits is followed by (bits + 7) / 8 bytes of binary data,
|
|
msb first, giving the value of the integer.
|
|
.RT
|
|
|
|
|
|
.ti 0
|
|
TCP/IP Port Number and Other Options
|
|
|
|
The server listens for connections on TCP/IP port 22.
|
|
|
|
The client may connect the server from any port. However, if the
|
|
client wishes to use any form of .rhosts or /etc/hosts.equiv
|
|
authentication, it must connect from a privileged port (less than
|
|
1024).
|
|
|
|
For the IP Type of Service field [RFC0791], it is recommended that
|
|
interactive sessions (those having a user terminal or forwarding X11
|
|
connections) use the IPTOS_LOWDELAY, and non-interactive connections
|
|
use IPTOS_THROUGHPUT.
|
|
|
|
It is recommended that keepalives are used, because otherwise programs
|
|
on the server may never notice if the other end of the connection is
|
|
rebooted.
|
|
|
|
|
|
.ti 0
|
|
Protocol Version Identification
|
|
|
|
After the socket is opened, the server sends an identification string,
|
|
which is of the form
|
|
"SSH-<protocolmajor>.<protocolminor>-<version>\\n", where
|
|
<protocolmajor> and <protocolminor> are integers and specify the
|
|
protocol version number (not software distribution version).
|
|
<version> is server side software version string (max 40 characters);
|
|
it is not interpreted by the remote side but may be useful for
|
|
debugging.
|
|
|
|
The client parses the server's string, and sends a corresponding
|
|
string with its own information in response. If the server has lower
|
|
version number, and the client contains special code to emulate it,
|
|
the client responds with the lower number; otherwise it responds with
|
|
its own number. The server then compares the version number the
|
|
client sent with its own, and determines whether they can work
|
|
together. The server either disconnects, or sends the first packet
|
|
using the binary packet protocol and both sides start working
|
|
according to the lower of the protocol versions.
|
|
|
|
By convention, changes which keep the protocol compatible with
|
|
previous versions keep the same major protocol version; changes that
|
|
are not compatible increment the major version (which will hopefully
|
|
never happen). The version described in this document is 1.3.
|
|
|
|
The client will
|
|
|
|
.ti 0
|
|
Key Exchange and Server Host Authentication
|
|
|
|
The first message sent by the server using the packet protocol is
|
|
SSH_SMSG_PUBLIC_KEY. It declares the server's host key, server public
|
|
key, supported ciphers, supported authentication methods, and flags
|
|
for protocol extensions. It also contains a 64-bit random number
|
|
(cookie) that must be returned in the client's reply (to make IP
|
|
spoofing more difficult). No encryption is used for this message.
|
|
|
|
Both sides compute a session id as follows. The modulus of the server
|
|
key is interpreted as a byte string (without explicit length field,
|
|
with minimum length able to hold the whole value), most significant
|
|
byte first. This string is concatenated with the server host key
|
|
interpreted the same way. Additionally, the cookie is concatenated
|
|
with this. Both sides compute MD5 of the resulting string. The
|
|
resulting 16 bytes (128 bits) are stored by both parties and are
|
|
called the session id.
|
|
|
|
The client responds with a SSH_CMSG_SESSION_KEY message, which
|
|
contains the selected cipher type, a copy of the 64-bit cookie sent by
|
|
the server, client's protocol flags, and a session key encrypted
|
|
with both the server's host key and server key. No encryption is used
|
|
for this message.
|
|
|
|
The session key is 32 8-bit bytes (a total of 256 random bits
|
|
generated by the client). The client first xors the 16 bytes of the
|
|
session id with the first 16 bytes of the session key. The resulting
|
|
string is then encrypted using the smaller key (one with smaller
|
|
modulus), and the result is then encrypted using the other key. The
|
|
number of bits in the public modulus of the two keys must differ by at
|
|
least 128 bits.
|
|
|
|
At each encryption step, a multiple-precision integer is constructed
|
|
from the data to be encrypted as follows (the integer is here
|
|
interpreted as a sequence of bytes, msb first; the number of bytes is
|
|
the number of bytes needed to represent the modulus).
|
|
|
|
The most significant byte (which is only partial as the value must be
|
|
less than the public modulus, which is never a power of two) is zero.
|
|
|
|
The next byte contains the value 2 (which stands for public-key
|
|
encrypted data in the PKCS standard [PKCS#1]). Then, there are
|
|
non-zero random bytes to fill any unused space, a zero byte, and the
|
|
data to be encrypted in the least significant bytes, the last byte of
|
|
the data in the least significant byte.
|
|
|
|
This algorithm is used twice. First, it is used to encrypt the 32
|
|
random bytes generated by the client to be used as the session key
|
|
(xored by the session id). This value is converted to an integer as
|
|
described above, and encrypted with RSA using the key with the smaller
|
|
modulus. The resulting integer is converted to a byte stream, msb
|
|
first. This byte stream is padded and encrypted identically using the
|
|
key with the larger modulus.
|
|
|
|
After the client has sent the session key, it starts to use the
|
|
selected algorithm and key for decrypting any received packets, and
|
|
for encrypting any sent packets. Separate ciphers are used for
|
|
different directions (that is, both directions have separate
|
|
initialization vectors or other state for the ciphers).
|
|
|
|
When the server has received the session key message, and has turned
|
|
on encryption, it sends a SSH_SMSG_SUCCESS message to the client.
|
|
|
|
The recommended size of the host key is 1024 bits, and 768 bits for
|
|
the server key. The minimum size is 512 bits for the smaller key.
|
|
|
|
|
|
.ti 0
|
|
Declaring the User Name
|
|
|
|
The client then sends a SSH_CMSG_USER message to the server. This
|
|
message specifies the user name to log in as.
|
|
|
|
The server validates that such a user exists, checks whether
|
|
authentication is needed, and responds with either SSH_SMSG_SUCCESS or
|
|
SSH_SMSG_FAILURE. SSH_SMSG_SUCCESS indicates that no authentication
|
|
is needed for this user (no password), and authentication phase has
|
|
now been completed. SSH_SMSG_FAILURE indicates that authentication is
|
|
needed (or the user does not exist).
|
|
|
|
If the user does not exist, it is recommended that this returns
|
|
failure, but the server keeps reading messages from the client, and
|
|
responds to any messages (except SSH_MSG_DISCONNECT, SSH_MSG_IGNORE,
|
|
and SSH_MSG_DEBUG) with SSH_SMSG_FAILURE. This way the client cannot
|
|
be certain whether the user exists.
|
|
|
|
|
|
.ti 0
|
|
Authentication Phase
|
|
|
|
Provided the server didn't immediately accept the login, an
|
|
authentication exchange begins. The client sends messages to the
|
|
server requesting different types of authentication in arbitrary order as
|
|
many times as desired (however, the server may close the connection
|
|
after a timeout). The server always responds with SSH_SMSG_SUCCESS if
|
|
it has accepted the authentication, and with SSH_SMSG_FAILURE if it has
|
|
denied authentication with the requested method or it does not
|
|
recognize the message. Some authentication methods cause an exchange
|
|
of further messages before the final result is sent. The
|
|
authentication phase ends when the server responds with success.
|
|
|
|
The recommended value for the authentication timeout (timeout before
|
|
disconnecting if no successful authentication has been made) is 5
|
|
minutes.
|
|
|
|
The following authentication methods are currently supported:
|
|
.TS
|
|
center;
|
|
l r l.
|
|
SSH_AUTH_RHOSTS 1 .rhosts or /etc/hosts.equiv
|
|
SSH_AUTH_RSA 2 pure RSA authentication
|
|
SSH_AUTH_PASSWORD 3 password authentication
|
|
SSH_AUTH_RHOSTS_RSA 4 .rhosts with RSA host authentication
|
|
.TE
|
|
.IP SSH_AUTH_RHOSTS
|
|
|
|
This is the authentication method used by rlogin and rsh [RFC1282].
|
|
|
|
The client sends SSH_CMSG_AUTH_RHOSTS with the client-side user name
|
|
as an argument.
|
|
|
|
The server checks whether to permit authentication. On UNIX systems,
|
|
this is usually done by checking /etc/hosts.equiv, and .rhosts in the
|
|
user's home directory. The connection must come from a privileged
|
|
port.
|
|
|
|
It is recommended that the server checks that there are no IP options
|
|
(such as source routing) specified for the socket before accepting
|
|
this type of authentication. The client host name should be
|
|
reverse-mapped and then forward mapped to ensure that it has the
|
|
proper IP-address.
|
|
|
|
This authentication method trusts the remote host (root on the remote
|
|
host can pretend to be any other user on that host), the name
|
|
services, and partially the network: anyone who can see packets coming
|
|
out from the server machine can do IP-spoofing and pretend to be any
|
|
machine; however, the protocol prevents blind IP-spoofing (which used
|
|
to be possible with rlogin).
|
|
|
|
Many sites probably want to disable this authentication method because
|
|
of the fundamental insecurity of conventional .rhosts or
|
|
/etc/hosts.equiv authentication when faced with spoofing. It is
|
|
recommended that this method not be supported by the server by
|
|
default.
|
|
.IP SSH_AUTH_RHOSTS_RSA
|
|
|
|
In addition to conventional .rhosts and hosts.equiv authentication,
|
|
this method additionally requires that the client host be
|
|
authenticated using RSA.
|
|
|
|
The client sends SSH_CMSG_AUTH_RHOSTS_RSA specifying the client-side
|
|
user name, and the public host key of the client host.
|
|
|
|
The server first checks if normal .rhosts or /etc/hosts.equiv
|
|
authentication would be accepted, and if not, responds with
|
|
SSH_SMSG_FAILURE. Otherwise, it checks whether it knows the host key
|
|
for the client machine (using the same name for the host that was used
|
|
for checking the .rhosts and /etc/hosts.equiv files). If it does not
|
|
know the RSA key for the client, access is denied and SSH_SMSG_FAILURE
|
|
is sent.
|
|
|
|
If the server knows the host key of the client machine, it verifies
|
|
that the given host key matches that known for the client. If not,
|
|
access is denied and SSH_SMSG_FAILURE is sent.
|
|
|
|
The server then sends a SSH_SMSG_AUTH_RSA_CHALLENGE message containing
|
|
an encrypted challenge for the client. The challenge is 32 8-bit
|
|
random bytes (256 bits). When encrypted, the highest (partial) byte
|
|
is left as zero, the next byte contains the value 2, the following are
|
|
non-zero random bytes, followed by a zero byte, and the challenge put
|
|
in the remaining bytes. This is then encrypted using RSA with the
|
|
client host's public key. (The padding and encryption algorithm is
|
|
the same as that used for the session key.)
|
|
|
|
The client decrypts the challenge using its private host key,
|
|
concatenates this with the session id, and computes an MD5 checksum
|
|
of the resulting 48 bytes. The MD5 output is returned as 16 bytes in
|
|
a SSH_CMSG_AUTH_RSA_RESPONSE message. (MD5 is used to deter chosen
|
|
plaintext attacks against RSA; the session id binds it to a specific
|
|
session).
|
|
|
|
The server verifies that the MD5 of the decrypted challenge returned by
|
|
the client matches that of the original value, and sends SSH_SMSG_SUCCESS if
|
|
so. Otherwise it sends SSH_SMSG_FAILURE and refuses the
|
|
authentication attempt.
|
|
|
|
This authentication method trusts the client side machine in that root
|
|
on that machine can pretend to be any user on that machine.
|
|
Additionally, it trusts the client host key. The name and/or IP
|
|
address of the client host is only used to select the public host key.
|
|
The same host name is used when scanning .rhosts or /etc/hosts.equiv
|
|
and when selecting the host key. It would in principle be possible to
|
|
eliminate the host name entirely and substitute it directly by the
|
|
host key. IP and/or DNS [RFC1034] spoofing can only be used
|
|
to pretend to be a host for which the attacker has the private host
|
|
key.
|
|
.IP SSH_AUTH_RSA
|
|
|
|
The idea behind RSA authentication is that the server recognizes the
|
|
public key offered by the client, generates a random challenge, and
|
|
encrypts the challenge with the public key. The client must then
|
|
prove that it has the corresponding private key by decrypting the
|
|
challenge.
|
|
|
|
The client sends SSH_CMSG_AUTH_RSA with public key modulus (n) as an
|
|
argument.
|
|
|
|
The server may respond immediately with SSH_SMSG_FAILURE if it does
|
|
not permit authentication with this key. Otherwise it generates a
|
|
challenge, encrypts it using the user's public key (stored on the
|
|
server and identified using the modulus), and sends
|
|
SSH_SMSG_AUTH_RSA_CHALLENGE with the challenge (mp-int) as an
|
|
argument.
|
|
|
|
The challenge is 32 8-bit random bytes (256 bits). When encrypted,
|
|
the highest (partial) byte is left as zero, the next byte contains the
|
|
value 2, the following are non-zero random bytes, followed by a zero
|
|
byte, and the challenge put in the remaining bytes. This is then
|
|
encrypted with the public key. (The padding and encryption algorithm
|
|
is the same as that used for the session key.)
|
|
|
|
The client decrypts the challenge using its private key, concatenates
|
|
it with the session id, and computes an MD5 checksum of the resulting
|
|
48 bytes. The MD5 output is returned as 16 bytes in a
|
|
SSH_CMSG_AUTH_RSA_RESPONSE message. (Note that the MD5 is necessary
|
|
to avoid chosen plaintext attacks against RSA; the session id binds it
|
|
to a specific session.)
|
|
|
|
The server verifies that the MD5 of the decrypted challenge returned
|
|
by the client matches that of the original value, and sends
|
|
SSH_SMSG_SUCCESS if so. Otherwise it sends SSH_SMSG_FAILURE and
|
|
refuses the authentication attempt.
|
|
|
|
This authentication method does not trust the remote host, the
|
|
network, name services, or anything else. Authentication is based
|
|
solely on the possession of the private identification keys. Anyone
|
|
in possession of the private keys can log in, but nobody else.
|
|
|
|
The server may have additional requirements for a successful
|
|
authentiation. For example, to limit damage due to a compromised RSA
|
|
key, a server might restrict access to a limited set of hosts.
|
|
.IP SSH_AUTH_PASSWORD
|
|
|
|
The client sends a SSH_CMSG_AUTH_PASSWORD message with the plain text
|
|
password. (Note that even though the password is plain text inside
|
|
the message, it is normally encrypted by the packet mechanism.)
|
|
|
|
The server verifies the password, and sends SSH_SMSG_SUCCESS if
|
|
authentication was accepted and SSH_SMSG_FAILURE otherwise.
|
|
|
|
Note that the password is read from the user by the client; the user
|
|
never interacts with a login program.
|
|
|
|
This authentication method does not trust the remote host, the
|
|
network, name services or anything else. Authentication is based
|
|
solely on the possession of the password. Anyone in possession of the
|
|
password can log in, but nobody else.
|
|
.RT
|
|
|
|
.ti 0
|
|
Preparatory Operations
|
|
|
|
After successful authentication, the server waits for a request from
|
|
the client, processes the request, and responds with SSH_SMSG_SUCCESS
|
|
whenever a request has been successfully processed. If it receives a
|
|
message that it does not recognize or it fails to honor a request, it
|
|
returns SSH_SMSG_FAILURE. It is expected that new message types might
|
|
be added to this phase in future.
|
|
|
|
The following messages are currently defined for this phase.
|
|
.IP SSH_CMSG_REQUEST_COMPRESSION
|
|
Requests that compression be enabled for this session. A
|
|
gzip-compatible compression level (1-9) is passed as an argument.
|
|
.IP SSH_CMSG_REQUEST_PTY
|
|
Requests that a pseudo terminal device be allocated for this session.
|
|
The user terminal type and terminal modes are supplied as arguments.
|
|
.IP SSH_CMSG_X11_REQUEST_FORWARDING
|
|
Requests forwarding of X11 connections from the remote machine to the
|
|
local machine over the secure channel. Causes an internet-domain
|
|
socket to be allocated and the DISPLAY variable to be set on the server.
|
|
X11 authentication data is automatically passed to the server, and the
|
|
client may implement spoofing of authentication data for added
|
|
security. The authentication data is passed as arguments.
|
|
.IP SSH_CMSG_PORT_FORWARD_REQUEST
|
|
Requests forwarding of a TCP/IP port on the server host over the
|
|
secure channel. What happens is that whenever a connection is made to
|
|
the port on the server, a connection will be made from the client end
|
|
to the specified host/port. Any user can forward unprivileged ports;
|
|
only the root can forward privileged ports (as determined by
|
|
authentication done earlier).
|
|
.IP SSH_CMSG_AGENT_REQUEST_FORWARDING
|
|
Requests forwarding of the connection to the authentication agent.
|
|
.IP SSH_CMSG_EXEC_SHELL
|
|
Starts a shell (command interpreter) for the user, and moves into
|
|
interactive session mode.
|
|
.IP SSH_CMSG_EXEC_CMD
|
|
Executes the given command (actually "<shell> -c <command>" or
|
|
equivalent) for the user, and moves into interactive session mode.
|
|
.RT
|
|
|
|
|
|
.ti 0
|
|
Interactive Session and Exchange of Data
|
|
|
|
During the interactive session, any data written by the shell or
|
|
command running on the server machine is forwarded to stdin or
|
|
stderr on the client machine, and any input available from stdin on
|
|
the client machine is forwarded to the program on the server machine.
|
|
|
|
All exchange is asynchronous; either side can send at any time, and
|
|
there are no acknowledgements (TCP/IP already provides reliable
|
|
transport, and the packet protocol protects against tampering or IP
|
|
spoofing).
|
|
|
|
When the client receives EOF from its standard input, it will send
|
|
SSH_CMSG_EOF; however, this in no way terminates the exchange. The
|
|
exchange terminates and interactive mode is left when the server sends
|
|
SSH_SMSG_EXITSTATUS to indicate that the client program has
|
|
terminated. Alternatively, either side may disconnect at any time by
|
|
sending SSH_MSG_DISCONNECT or closing the connection.
|
|
|
|
The server may send any of the following messages:
|
|
.IP SSH_SMSG_STDOUT_DATA
|
|
Data written to stdout by the program running on the server. The data
|
|
is passed as a string argument. The client writes this data to
|
|
stdout.
|
|
.IP SSH_SMSG_STDERR_DATA
|
|
Data written to stderr by the program running on the server. The data
|
|
is passed as a string argument. The client writes this data to
|
|
stderr. (Note that if the program is running on a tty, it is not
|
|
possible to separate stdout and stderr data, and all data will be sent
|
|
as stdout data.)
|
|
.IP SSH_SMSG_EXITSTATUS
|
|
Indicates that the shell or command has exited. Exit status is passed
|
|
as an integer argument. This message causes termination of the
|
|
interactive session.
|
|
.IP SSH_SMSG_AGENT_OPEN
|
|
Indicates that someone on the server side is requesting a connection
|
|
to the authentication agent. The server-side channel number is passed
|
|
as an argument. The client must respond with either
|
|
SSH_CHANNEL_OPEN_CONFIRMATION or SSH_CHANNEL_OPEN_FAILURE.
|
|
.IP SSH_SMSG_X11_OPEN
|
|
Indicates that a connection has been made to the X11 socket on the
|
|
server side and should be forwarded to the real X server. An integer
|
|
argument indicates the channel number allocated for this connection on
|
|
the server side. The client should send back either
|
|
SSH_MSG_CHANNEL_OPEN_CONFIRMATION or SSH_MSG_CHANNEL_OPEN_FAILURE with
|
|
the same server side channel number.
|
|
.IP SSH_MSG_PORT_OPEN
|
|
Indicates that a connection has been made to a port on the server side
|
|
for which forwarding has been requested. Arguments are server side
|
|
channel number, host name to connect to, and port to connect to. The
|
|
client should send back either
|
|
SSH_MSG_CHANNEL_OPEN_CONFIRMATION or SSH_MSG_CHANNEL_OPEN_FAILURE with
|
|
the same server side channel number.
|
|
.IP SSH_MSG_CHANNEL_OPEN_CONFIRMATION
|
|
This is sent by the server to indicate that it has opened a connection
|
|
as requested in a previous message. The first argument indicates the
|
|
client side channel number, and the second argument is the channel number
|
|
that the server has allocated for this connection.
|
|
.IP SSH_MSG_CHANNEL_OPEN_FAILURE
|
|
This is sent by the server to indicate that it failed to open a
|
|
connection as requested in a previous message. The client-side
|
|
channel number is passed as an argument. The client will close the
|
|
descriptor associated with the channel and free the channel.
|
|
.IP SSH_MSG_CHANNEL_DATA
|
|
This packet contains data for a channel from the server. The first
|
|
argument is the client-side channel number, and the second argument (a
|
|
string) is the data.
|
|
.IP SSH_MSG_CHANNEL_CLOSE
|
|
This is sent by the server to indicate that whoever was in the other
|
|
end of the channel has closed it. The argument is the client side channel
|
|
number. The client will let all buffered data in the channel to
|
|
drain, and when ready, will close the socket, free the channel, and
|
|
send the server a SSH_MSG_CHANNEL_CLOSE_CONFIRMATION message for the
|
|
channel.
|
|
.IP SSH_MSG_CHANNEL_CLOSE_CONFIRMATION
|
|
This is send by the server to indicate that a channel previously
|
|
closed by the client has now been closed on the server side as well.
|
|
The argument indicates the client channel number. The client frees
|
|
the channel.
|
|
.RT
|
|
|
|
The client may send any of the following messages:
|
|
.IP SSH_CMSG_STDIN_DATA
|
|
This is data to be sent as input to the program running on the server.
|
|
The data is passed as a string.
|
|
.IP SSH_CMSG_EOF
|
|
Indicates that the client has encountered EOF while reading standard
|
|
input. The server will allow any buffered input data to drain, and
|
|
will then close the input to the program.
|
|
.IP SSH_CMSG_WINDOW_SIZE
|
|
Indicates that window size on the client has been changed. The server
|
|
updates the window size of the tty and causes SIGWINCH to be sent to
|
|
the program. The new window size is passed as four integer arguments:
|
|
row, col, xpixel, ypixel.
|
|
.IP SSH_MSG_PORT_OPEN
|
|
Indicates that a connection has been made to a port on the client side
|
|
for which forwarding has been requested. Arguments are client side
|
|
channel number, host name to connect to, and port to connect to. The
|
|
server should send back either SSH_MSG_CHANNEL_OPEN_CONFIRMATION or
|
|
SSH_MSG_CHANNEL_OPEN_FAILURE with the same client side channel number.
|
|
.IP SSH_MSG_CHANNEL_OPEN_CONFIRMATION
|
|
This is sent by the client to indicate that it has opened a connection
|
|
as requested in a previous message. The first argument indicates the
|
|
server side channel number, and the second argument is the channel
|
|
number that the client has allocated for this connection.
|
|
.IP SSH_MSG_CHANNEL_OPEN_FAILURE
|
|
This is sent by the client to indicate that it failed to open a
|
|
connection as requested in a previous message. The server side
|
|
channel number is passed as an argument. The server will close the
|
|
descriptor associated with the channel and free the channel.
|
|
.IP SSH_MSG_CHANNEL_DATA
|
|
This packet contains data for a channel from the client. The first
|
|
argument is the server side channel number, and the second argument (a
|
|
string) is the data.
|
|
.IP SSH_MSG_CHANNEL_CLOSE
|
|
This is sent by the client to indicate that whoever was in the other
|
|
end of the channel has closed it. The argument is the server channel
|
|
number. The server will allow buffered data to drain, and when ready,
|
|
will close the socket, free the channel, and send the client a
|
|
SSH_MSG_CHANNEL_CLOSE_CONFIRMATION message for the channel.
|
|
.IP SSH_MSG_CHANNEL_CLOSE_CONFIRMATION
|
|
This is send by the client to indicate that a channel previously
|
|
closed by the server has now been closed on the client side as well.
|
|
The argument indicates the server channel number. The server frees
|
|
the channel.
|
|
.RT
|
|
|
|
Any unsupported messages during interactive mode cause the connection
|
|
to be terminated with SSH_MSG_DISCONNECT and an error message.
|
|
Compatible protocol upgrades should agree about any extensions during
|
|
the preparation phase or earlier.
|
|
|
|
|
|
.ti 0
|
|
Termination of the Connection
|
|
|
|
Normal termination of the connection is always initiated by the server
|
|
by sending SSH_SMSG_EXITSTATUS after the program has exited. The
|
|
client responds to this message by sending SSH_CMSG_EXIT_CONFIRMATION
|
|
and closes the socket; the server then closes the socket. There are
|
|
two purposes for the confirmation: some systems may lose previously
|
|
sent data when the socket is closed, and closing the client side first
|
|
causes any TCP/IP TIME_WAIT [RFC0793] waits to occur on the client side, not
|
|
consuming server resources.
|
|
|
|
If the program terminates due to a signal, the server will send
|
|
SSH_MSG_DISCONNECT with an appropriate message. If the connection is
|
|
closed, all file descriptors to the program will be closed and the
|
|
server will exit. If the program runs on a tty, the kernel sends it
|
|
the SIGHUP signal when the pty master side is closed.
|
|
|
|
.ti 0
|
|
Protocol Flags
|
|
|
|
Both the server and the client pass 32 bits of protocol flags to the
|
|
other side. The flags are intended for compatible protocol extension;
|
|
the server first announces which added capabilities it supports, and
|
|
the client then sends the capabilities that it supports.
|
|
|
|
The following flags are currently defined (the values are bit masks):
|
|
.IP "1 SSH_PROTOFLAG_SCREEN_NUMBER"
|
|
This flag can only be sent by the client. It indicates that the X11
|
|
forwarding requests it sends will include the screen number.
|
|
.IP "2 SSH_PROTOFLAG_HOST_IN_FWD_OPEN"
|
|
If both sides specify this flag, SSH_SMSG_X11_OPEN and
|
|
SSH_MSG_PORT_OPEN messages will contain an additional field containing
|
|
a description of the host at the other end of the connection.
|
|
.RT
|
|
|
|
.ti 0
|
|
Detailed Description of Packet Types and Formats
|
|
|
|
The supported packet types and the corresponding message numbers are
|
|
given in the following table. Messages with _MSG_ in their name may
|
|
be sent by either side. Messages with _CMSG_ are only sent by the
|
|
client, and messages with _SMSG_ only by the server.
|
|
|
|
A packet may contain additional data after the arguments specified
|
|
below. Any such data should be ignored by the receiver. However, it
|
|
is recommended that no such data be stored without good reason. (This
|
|
helps build compatible extensions.)
|
|
.IP "0 SSH_MSG_NONE"
|
|
This code is reserved. This message type is never sent.
|
|
.IP "1 SSH_MSG_DISCONNECT"
|
|
.TS
|
|
;
|
|
l l.
|
|
string Cause of disconnection
|
|
.TE
|
|
This message may be sent by either party at any time. It causes the
|
|
immediate disconnection of the connection. The message is intended to
|
|
be displayed to a human, and describes the reason for disconnection.
|
|
.IP "2 SSH_SMSG_PUBLIC_KEY"
|
|
.TS
|
|
;
|
|
l l.
|
|
8 bytes anti_spoofing_cookie
|
|
32-bit int server_key_bits
|
|
mp-int server_key_public_exponent
|
|
mp-int server_key_public_modulus
|
|
32-bit int host_key_bits
|
|
mp-int host_key_public_exponent
|
|
mp-int host_key_public_modulus
|
|
32-bit int protocol_flags
|
|
32-bit int supported_ciphers_mask
|
|
32-bit int supported_authentications_mask
|
|
.TE
|
|
Sent as the first message by the server. This message gives the
|
|
server's host key, server key, protocol flags (intended for compatible
|
|
protocol extension), supported_ciphers_mask (which is the
|
|
bitwise or of (1 << cipher_number), where << is the left shift
|
|
operator, for all supported ciphers), and
|
|
supported_authentications_mask (which is the bitwise or of (1 <<
|
|
authentication_type) for all supported authentication types). The
|
|
anti_spoofing_cookie is 64 random bytes, and must be sent back
|
|
verbatim by the client in its reply. It is used to make IP-spoofing
|
|
more difficult (encryption and host keys are the real defense against
|
|
spoofing).
|
|
.IP "3 SSH_CMSG_SESSION_KEY"
|
|
.TS
|
|
;
|
|
l l.
|
|
1 byte cipher_type (must be one of the supported values)
|
|
8 bytes anti_spoofing_cookie (must match data sent by the server)
|
|
mp-int double-encrypted session key
|
|
32-bit int protocol_flags
|
|
.TE
|
|
Sent by the client as the first message in the session. Selects the
|
|
cipher to use, and sends the encrypted session key to the server. The
|
|
anti_spoofing_cookie must be the same bytes that were sent by the
|
|
server. Protocol_flags is intended for negotiating compatible
|
|
protocol extensions.
|
|
.IP "4 SSH_CMSG_USER"
|
|
.TS
|
|
;
|
|
l l.
|
|
string user login name on server
|
|
.TE
|
|
Sent by the client to begin authentication. Specifies the user name
|
|
on the server to log in as. The server responds with SSH_SMSG_SUCCESS
|
|
if no authentication is needed for this user, or SSH_SMSG_FAILURE if
|
|
authentication is needed (or the user does not exist). [Note to the
|
|
implementator: the user name is of arbitrary size. The implementation
|
|
must be careful not to overflow internal buffers.]
|
|
.IP "5 SSH_CMSG_AUTH_RHOSTS"
|
|
.TS
|
|
;
|
|
l l.
|
|
string client-side user name
|
|
.TE
|
|
Requests authentication using /etc/hosts.equiv and .rhosts (or
|
|
equivalent mechanisms). This authentication method is normally
|
|
disabled in the server because it is not secure (but this is the
|
|
method used by rsh and rlogin). The server responds with
|
|
SSH_SMSG_SUCCESS if authentication was successful, and
|
|
SSH_SMSG_FAILURE if access was not granted. The server should check
|
|
that the client side port number is less than 1024 (a privileged
|
|
port), and immediately reject authentication if it is not. Supporting
|
|
this authentication method is optional. This method should normally
|
|
not be enabled in the server because it is not safe. (However, not
|
|
enabling this only helps if rlogind and rshd are disabled.)
|
|
.IP "6 SSH_CMSG_AUTH_RSA"
|
|
.TS
|
|
;
|
|
l l.
|
|
mp-int identity_public_modulus
|
|
.TE
|
|
Requests authentication using pure RSA authentication. The server
|
|
checks if the given key is permitted to log in, and if so, responds
|
|
with SSH_SMSG_AUTH_RSA_CHALLENGE. Otherwise, it responds with
|
|
SSH_SMSG_FAILURE. The client often tries several different keys in
|
|
sequence until one supported by the server is found. Authentication
|
|
is accepted if the client gives the correct response to the challenge.
|
|
The server is free to add other criteria for authentication, such as a
|
|
requirement that the connection must come from a certain host. Such
|
|
additions are not visible at the protocol level. Supporting this
|
|
authentication method is optional but recommended.
|
|
.IP "7 SSH_SMSG_AUTH_RSA_CHALLENGE"
|
|
.TS
|
|
;
|
|
l l.
|
|
mp-int encrypted challenge
|
|
.TE
|
|
Presents an RSA authentication challenge to the client. The challenge
|
|
is a 256-bit random value encrypted as described elsewhere in this
|
|
document. The client must decrypt the challenge using the RSA private
|
|
key, compute MD5 of the challenge plus session id, and send back the
|
|
resulting 16 bytes using SSH_CMSG_AUTH_RSA_RESPONSE.
|
|
.IP "8 SSH_CMSG_AUTH_RSA_RESPONSE"
|
|
.TS
|
|
;
|
|
l l.
|
|
16 bytes MD5 of decrypted challenge
|
|
.TE
|
|
This message is sent by the client in response to an RSA challenge.
|
|
The MD5 checksum is returned instead of the decrypted challenge to
|
|
deter known-plaintext attacks against the RSA key. The server
|
|
responds to this message with either SSH_SMSG_SUCCESS or
|
|
SSH_SMSG_FAILURE.
|
|
.IP "9 SSH_CMSG_AUTH_PASSWORD"
|
|
.TS
|
|
;
|
|
l l.
|
|
string plain text password
|
|
.TE
|
|
Requests password authentication using the given password. Note that
|
|
even though the password is plain text inside the packet, the whole
|
|
packet is normally encrypted by the packet layer. It would not be
|
|
possible for the client to perform password encryption/hashing,
|
|
because it cannot know which kind of encryption/hashing, if any, the
|
|
server uses. The server responds to this message with
|
|
SSH_SMSG_SUCCESS or SSH_SMSG_FAILURE.
|
|
.IP "10 SSH_CMSG_REQUEST_PTY"
|
|
.TS
|
|
;
|
|
l l.
|
|
string TERM environment variable value (e.g. vt100)
|
|
32-bit int terminal height, rows (e.g., 24)
|
|
32-bit int terminal width, columns (e.g., 80)
|
|
32-bit int terminal width, pixels (0 if no graphics) (e.g., 480)
|
|
32-bit int terminal height, pixels (0 if no graphics) (e.g., 640)
|
|
n bytes tty modes encoded in binary
|
|
.TE
|
|
Requests a pseudo-terminal to be allocated for this command. This
|
|
message can be used regardless of whether the session will later
|
|
execute the shell or a command. If a pty has been requested with this
|
|
message, the shell or command will run on a pty. Otherwise it will
|
|
communicate with the server using pipes, sockets or some other similar
|
|
mechanism.
|
|
|
|
The terminal type gives the type of the user's terminal. In the UNIX
|
|
environment it is passed to the shell or command in the TERM
|
|
environment variable.
|
|
|
|
The width and height values give the initial size of the user's
|
|
terminal or window. All values can be zero if not supported by the
|
|
operating system. The server will pass these values to the kernel if
|
|
supported.
|
|
|
|
Terminal modes are encoded into a byte stream in a portable format.
|
|
The exact format is described later in this document.
|
|
|
|
The server responds to the request with either SSH_SMSG_SUCCESS or
|
|
SSH_SMSG_FAILURE. If the server does not have the concept of pseudo
|
|
terminals, it should return success if it is possible to execute a
|
|
shell or a command so that it looks to the client as if it was running
|
|
on a pseudo terminal.
|
|
.IP "11 SSH_CMSG_WINDOW_SIZE"
|
|
.TS
|
|
;
|
|
l l.
|
|
32-bit int terminal height, rows
|
|
32-bit int terminal width, columns
|
|
32-bit int terminal width, pixels
|
|
32-bit int terminal height, pixels
|
|
.TE
|
|
This message can only be sent by the client during the interactive
|
|
session. This indicates that the size of the user's window has
|
|
changed, and provides the new size. The server will update the
|
|
kernel's notion of the window size, and a SIGWINCH signal or
|
|
equivalent will be sent to the shell or command (if supported by the
|
|
operating system).
|
|
.IP "12 SSH_CMSG_EXEC_SHELL"
|
|
|
|
(no arguments)
|
|
|
|
Starts a shell (command interpreter), and enters interactive session
|
|
mode.
|
|
.IP "13 SSH_CMSG_EXEC_CMD"
|
|
.TS
|
|
;
|
|
l l.
|
|
string command to execute
|
|
.TE
|
|
Starts executing the given command, and enters interactive session
|
|
mode. On UNIX, the command is run as "<shell> -c <command>", where
|
|
<shell> is the user's login shell.
|
|
.IP "14 SSH_SMSG_SUCCESS"
|
|
|
|
(no arguments)
|
|
|
|
This message is sent by the server in response to the session key, a
|
|
successful authentication request, and a successfully completed
|
|
preparatory operation.
|
|
.IP "15 SSH_SMSG_FAILURE"
|
|
|
|
(no arguments)
|
|
|
|
This message is sent by the server in response to a failed
|
|
authentication operation to indicate that the user has not yet been
|
|
successfully authenticated, and in response to a failed preparatory
|
|
operation. This is also sent in response to an authentication or
|
|
preparatory operation request that is not recognized or supported.
|
|
.IP "16 SSH_CMSG_STDIN_DATA"
|
|
.TS
|
|
;
|
|
l l.
|
|
string data
|
|
.TE
|
|
Delivers data from the client to be supplied as input to the shell or
|
|
program running on the server side. This message can only be used in
|
|
the interactive session mode. No acknowledgement is sent for this
|
|
message.
|
|
.IP "17 SSH_SMSG_STDOUT_DATA"
|
|
.TS
|
|
;
|
|
l l.
|
|
string data
|
|
.TE
|
|
Delivers data from the server that was read from the standard output of
|
|
the shell or program running on the server side. This message can
|
|
only be used in the interactive session mode. No acknowledgement is
|
|
sent for this message.
|
|
.IP "18 SSH_SMSG_STDERR_DATA"
|
|
.TS
|
|
;
|
|
l l.
|
|
string data
|
|
.TE
|
|
Delivers data from the server that was read from the standard error of
|
|
the shell or program running on the server side. This message can
|
|
only be used in the interactive session mode. No acknowledgement is
|
|
sent for this message.
|
|
.IP "19 SSH_CMSG_EOF"
|
|
|
|
(no arguments)
|
|
|
|
This message is sent by the client to indicate that EOF has been
|
|
reached on the input. Upon receiving this message, and after all
|
|
buffered input data has been sent to the shell or program, the server
|
|
will close the input file descriptor to the program. This message can
|
|
only be used in the interactive session mode. No acknowledgement is
|
|
sent for this message.
|
|
.IP "20 SSH_SMSG_EXITSTATUS"
|
|
.TS
|
|
;
|
|
l l.
|
|
32-bit int exit status of the command
|
|
.TE
|
|
Returns the exit status of the shell or program after it has exited.
|
|
The client should respond with SSH_CMSG_EXIT_CONFIRMATION when it has
|
|
received this message. This will be the last message sent by the
|
|
server. If the program being executed dies with a signal instead of
|
|
exiting normally, the server should terminate the session with
|
|
SSH_MSG_DISCONNECT (which can be used to pass a human-readable string
|
|
indicating that the program died due to a signal) instead of using
|
|
this message.
|
|
.IP "21 SSH_MSG_CHANNEL_OPEN_CONFIRMATION"
|
|
.TS
|
|
;
|
|
l l.
|
|
32-bit int remote_channel
|
|
32-bit int local_channel
|
|
.TE
|
|
This is sent in response to any channel open request if the channel
|
|
has been successfully opened. Remote_channel is the channel number
|
|
received in the initial open request; local_channel is the channel
|
|
number the side sending this message has allocated for the channel.
|
|
Data can be transmitted on the channel after this message.
|
|
.IP "22 SSH_MSG_CHANNEL_OPEN_FAILURE"
|
|
.TS
|
|
;
|
|
l l.
|
|
32-bit int remote_channel
|
|
.TE
|
|
This message indicates that an earlier channel open request by the
|
|
other side has failed or has been denied. Remote_channel is the
|
|
channel number given in the original request.
|
|
.IP "23 SSH_MSG_CHANNEL_DATA"
|
|
.TS
|
|
;
|
|
l l.
|
|
32-bit int remote_channel
|
|
string data
|
|
.TE
|
|
Data is transmitted in a channel in these messages. A channel is
|
|
bidirectional, and both sides can send these messages. There is no
|
|
acknowledgement for these messages. It is possible that either side
|
|
receives these messages after it has sent SSH_MSG_CHANNEL_CLOSE for
|
|
the channel. These messages cannot be received after the party has
|
|
sent or received SSH_MSG_CHANNEL_CLOSE_CONFIRMATION.
|
|
.IP "24 SSH_MSG_CHANNEL_CLOSE"
|
|
.TS
|
|
;
|
|
l l.
|
|
32-bit int remote_channel
|
|
.TE
|
|
When a channel is closed at one end of the connection, that side sends
|
|
this message. Upon receiving this message, the channel should be
|
|
closed. When this message is received, if the channel is already
|
|
closed (the receiving side has sent this message for the same channel
|
|
earlier), the channel is freed and no further action is taken;
|
|
otherwise the channel is freed and SSH_MSG_CHANNEL_CLOSE_CONFIRMATION
|
|
is sent in response. (It is possible that the channel is closed
|
|
simultaneously at both ends.)
|
|
.IP "25 SSH_MSG_CHANNEL_CLOSE_CONFIRMATION"
|
|
.TS
|
|
;
|
|
l l.
|
|
32-bit int remote_channel
|
|
.TE
|
|
This message is sent in response to SSH_MSG_CHANNEL_CLOSE unless the
|
|
channel was already closed. When this message is sent or received,
|
|
the channel is freed.
|
|
.IP "26 (OBSOLETED; was unix-domain X11 forwarding)
|
|
.IP "27 SSH_SMSG_X11_OPEN"
|
|
.TS
|
|
;
|
|
l l.
|
|
32-bit int local_channel
|
|
string originator_string (see below)
|
|
.TE
|
|
This message can be sent by the server during the interactive session
|
|
mode to indicate that a client has connected the fake X server.
|
|
Local_channel is the channel number that the server has allocated for
|
|
the connection. The client should try to open a connection to the
|
|
real X server, and respond with SSH_MSG_CHANNEL_OPEN_CONFIRMATION or
|
|
SSH_MSG_CHANNEL_OPEN_FAILURE.
|
|
|
|
The field originator_string is present if both sides
|
|
specified SSH_PROTOFLAG_HOST_IN_FWD_OPEN in the protocol flags. It
|
|
contains a description of the host originating the connection.
|
|
.IP "28 SSH_CMSG_PORT_FORWARD_REQUEST"
|
|
.TS
|
|
;
|
|
l l.
|
|
32-bit int server_port
|
|
string host_to_connect
|
|
32-bit int port_to_connect
|
|
.TE
|
|
Sent by the client in the preparatory phase, this message requests
|
|
that server_port on the server machine be forwarded over the secure
|
|
channel to the client machine, and from there to the specified host
|
|
and port. The server should start listening on the port, and send
|
|
SSH_MSG_PORT_OPEN whenever a connection is made to it. Supporting
|
|
this message is optional, and the server is free to reject any forward
|
|
request. For example, it is highly recommended that unless the user
|
|
has been authenticated as root, forwarding any privileged port numbers
|
|
(below 1024) is denied.
|
|
.IP "29 SSH_MSG_PORT_OPEN"
|
|
.TS
|
|
;
|
|
l l.
|
|
32-bit int local_channel
|
|
string host_name
|
|
32-bit int port
|
|
string originator_string (see below)
|
|
.TE
|
|
Sent by either party in interactive session mode, this message
|
|
indicates that a connection has been opened to a forwarded TCP/IP
|
|
port. Local_channel is the channel number that the sending party has
|
|
allocated for the connection. Host_name is the host the connection
|
|
should be be forwarded to, and the port is the port on that host to
|
|
connect. The receiving party should open the connection, and respond
|
|
with SSH_MSG_CHANNEL_OPEN_CONFIRMATION or
|
|
SSH_MSG_CHANNEL_OPEN_FAILURE. It is recommended that the receiving
|
|
side check the host_name and port for validity to avoid compromising
|
|
local security by compromised remote side software. Particularly, it
|
|
is recommended that the client permit connections only to those ports
|
|
for which it has requested forwarding with SSH_CMSG_PORT_FORWARD_REQUEST.
|
|
|
|
The field originator_string is present if both sides
|
|
specified SSH_PROTOFLAG_HOST_IN_FWD_OPEN in the protocol flags. It
|
|
contains a description of the host originating the connection.
|
|
.IP "30 SSH_CMSG_AGENT_REQUEST_FORWARDING"
|
|
|
|
(no arguments)
|
|
|
|
Requests that the connection to the authentication agent be forwarded
|
|
over the secure channel. The method used by clients to contact the
|
|
authentication agent within each machine is implementation and machine
|
|
dependent. If the server accepts this request, it should arrange that
|
|
any clients run from this session will actually contact the server
|
|
program when they try to contact the authentication agent. The server
|
|
should then send a SSH_SMSG_AGENT_OPEN to open a channel to the agent,
|
|
and the client should forward the connection to the real
|
|
authentication agent. Supporting this message is optional.
|
|
.IP "31 SSH_SMSG_AGENT_OPEN"
|
|
.TS
|
|
;
|
|
l l.
|
|
32-bit int local_channel
|
|
.TE
|
|
Sent by the server in interactive session mode, this message requests
|
|
opening a channel to the authentication agent. The client should open
|
|
a channel, and respond with either SSH_MSG_CHANNEL_OPEN_CONFIRMATION
|
|
or SSH_MSG_CHANNEL_OPEN_FAILURE.
|
|
.IP "32 SSH_MSG_IGNORE"
|
|
.TS
|
|
;
|
|
l l.
|
|
string data
|
|
.TE
|
|
Either party may send this message at any time. This message, and the
|
|
argument string, is silently ignored. This message might be used in
|
|
some implementations to make traffic analysis more difficult. This
|
|
message is not currently sent by the implementation, but all
|
|
implementations are required to recognize and ignore it.
|
|
.IP "33 SSH_CMSG_EXIT_CONFIRMATION"
|
|
|
|
(no arguments)
|
|
|
|
Sent by the client in response to SSH_SMSG_EXITSTATUS. This is the
|
|
last message sent by the client.
|
|
.IP "34 SSH_CMSG_X11_REQUEST_FORWARDING"
|
|
.TS
|
|
;
|
|
l l.
|
|
string x11_authentication_protocol
|
|
string x11_authentication_data
|
|
32-bit int screen number (if SSH_PROTOFLAG_SCREEN_NUMBER)
|
|
.TE
|
|
Sent by the client during the preparatory phase, this message requests
|
|
that the server create a fake X11 display and set the DISPLAY
|
|
environment variable accordingly. An internet-domain display is
|
|
preferable. The given authentication protocol and the associated data
|
|
should be recorded by the server so that it is used as authentication
|
|
on connections (e.g., in .Xauthority). The authentication protocol
|
|
must be one of the supported X11 authentication protocols, e.g.,
|
|
"MIT-MAGIC-COOKIE-1". Authentication data must be a lowercase hex
|
|
string of even length. Its interpretation is protocol dependent.
|
|
The data is in a format that can be used with e.g. the xauth program.
|
|
Supporting this message is optional.
|
|
|
|
The client is permitted (and recommended) to generate fake
|
|
authentication information and send fake information to the server.
|
|
This way, a corrupt server will not have access to the user's terminal
|
|
after the connection has terminated. The correct authorization codes
|
|
will also not be left hanging around in files on the server (many
|
|
users keep the same X session for months, thus protecting the
|
|
authorization data becomes important).
|
|
|
|
X11 authentication spoofing works by initially sending fake (random)
|
|
authentication data to the server, and interpreting the first packet
|
|
sent by the X11 client after the connection has been opened. The
|
|
first packet contains the client's authentication. If the packet
|
|
contains the correct fake data, it is replaced by the client by the
|
|
correct authentication data, and then sent to the X server.
|
|
.IP "35 SSH_CMSG_AUTH_RHOSTS_RSA"
|
|
.TS
|
|
;
|
|
l l.
|
|
string clint-side user name
|
|
32-bit int client_host_key_bits
|
|
mp-int client_host_key_public_exponent
|
|
mp-int client_host_key_public_modulus
|
|
.TE
|
|
Requests authentication using /etc/hosts.equiv and .rhosts (or
|
|
equivalent) together with RSA host authentication. The server should
|
|
check that the client side port number is less than 1024 (a privileged
|
|
port), and immediately reject authentication if it is not. The server
|
|
responds with SSH_SMSG_FAILURE or SSH_SMSG_AUTH_RSA_CHALLENGE. The
|
|
client must respond to the challenge with the proper
|
|
SSH_CMSG_AUTH_RSA_RESPONSE. The server then responds with success if
|
|
access was granted, or failure if the client gave a wrong response.
|
|
Supporting this authentication method is optional but recommended in
|
|
most environments.
|
|
.IP "36 SSH_MSG_DEBUG"
|
|
.TS
|
|
;
|
|
l l.
|
|
string debugging message sent to the other side
|
|
.TE
|
|
This message may be sent by either party at any time. It is used to
|
|
send debugging messages that may be informative to the user in
|
|
solving various problems. For example, if authentication fails
|
|
because of some configuration error (e.g., incorrect permissions for
|
|
some file), it can be very helpful for the user to make the cause of
|
|
failure available. On the other hand, one should not make too much
|
|
information available for security reasons. It is recommended that
|
|
the client provides an option to display the debugging information
|
|
sent by the sender (the user probably does not want to see it by default).
|
|
The server can log debugging data sent by the client (if any). Either
|
|
party is free to ignore any received debugging data. Every
|
|
implementation must be able to receive this message, but no
|
|
implementation is required to send these.
|
|
.IP "37 SSH_CMSG_REQUEST_COMPRESSION"
|
|
.TS
|
|
;
|
|
l l.
|
|
32-bit int gzip compression level (1-9)
|
|
.TE
|
|
This message can be sent by the client in the preparatory operations
|
|
phase. The server responds with SSH_SMSG_FAILURE if it does not
|
|
support compression or does not want to compress; it responds with
|
|
SSH_SMSG_SUCCESS if it accepted the compression request. In the
|
|
latter case the response to this packet will still be uncompressed,
|
|
but all further packets in either direction will be compressed by gzip.
|
|
.RT
|
|
|
|
|
|
.ti 0
|
|
Encoding of Terminal Modes
|
|
|
|
Terminal modes (as passed in SSH_CMSG_REQUEST_PTY) are encoded into a
|
|
byte stream. It is intended that the coding be portable across
|
|
different environments.
|
|
|
|
The tty mode description is a stream of bytes. The stream consists of
|
|
opcode-argument pairs. It is terminated by opcode TTY_OP_END (0).
|
|
Opcodes 1-127 have one-byte arguments. Opcodes 128-159 have 32-bit
|
|
integer arguments (stored msb first). Opcodes 160-255 are not yet
|
|
defined, and cause parsing to stop (they should only be used after any
|
|
other data).
|
|
|
|
The client puts in the stream any modes it knows about, and the server
|
|
ignores any modes it does not know about. This allows some degree of
|
|
machine-independence, at least between systems that use a POSIX-like
|
|
[POSIX] tty interface. The protocol can support other systems as
|
|
well, but the client may need to fill reasonable values for a number
|
|
of parameters so the server pty gets set to a reasonable mode (the
|
|
server leaves all unspecified mode bits in their default values, and
|
|
only some combinations make sense).
|
|
|
|
The following opcodes have been defined. The naming of opcodes mostly
|
|
follows the POSIX terminal mode flags.
|
|
.IP "0 TTY_OP_END"
|
|
Indicates end of options.
|
|
.IP "1 VINTR"
|
|
Interrupt character; 255 if none. Similarly for the other characters.
|
|
Not all of these characters are supported on all systems.
|
|
.IP "2 VQUIT"
|
|
The quit character (sends SIGQUIT signal on UNIX systems).
|
|
.IP "3 VERASE"
|
|
Erase the character to left of the cursor.
|
|
.IP "4 VKILL"
|
|
Kill the current input line.
|
|
.IP "5 VEOF "
|
|
End-of-file character (sends EOF from the terminal).
|
|
.IP "6 VEOL "
|
|
End-of-line character in addition to carriage return and/or linefeed.
|
|
.IP "7 VEOL2"
|
|
Additional end-of-line character.
|
|
.IP "8 VSTART"
|
|
Continues paused output (normally ^Q).
|
|
.IP "9 VSTOP"
|
|
Pauses output (^S).
|
|
.IP "10 VSUSP"
|
|
Suspends the current program.
|
|
.IP "11 VDSUSP"
|
|
Another suspend character.
|
|
.IP "12 VREPRINT"
|
|
Reprints the current input line.
|
|
.IP "13 VWERASE"
|
|
Erases a word left of cursor.
|
|
.IP "14 VLNEXT"
|
|
More special input characters; these are probably not supported on
|
|
most systems.
|
|
.IP "15 VFLUSH"
|
|
.IP "16 VSWTCH"
|
|
.IP "17 VSTATUS"
|
|
.IP "18 VDISCARD"
|
|
|
|
.IP "30 IGNPAR"
|
|
The ignore parity flag. The next byte should be 0 if this flag is not
|
|
set, and 1 if it is set.
|
|
.IP "31 PARMRK"
|
|
More flags. The exact definitions can be found in the POSIX standard.
|
|
.IP "32 INPCK"
|
|
.IP "33 ISTRIP"
|
|
.IP "34 INLCR"
|
|
.IP "35 IGNCR"
|
|
.IP "36 ICRNL"
|
|
.IP "37 IUCLC"
|
|
.IP "38 IXON"
|
|
.IP "39 IXANY"
|
|
.IP "40 IXOFF"
|
|
.IP "41 IMAXBEL"
|
|
|
|
.IP "50 ISIG"
|
|
.IP "51 ICANON"
|
|
.IP "52 XCASE"
|
|
.IP "53 ECHO"
|
|
.IP "54 ECHOE"
|
|
.IP "55 ECHOK"
|
|
.IP "56 ECHONL"
|
|
.IP "57 NOFLSH"
|
|
.IP "58 TOSTOP"
|
|
.IP "59 IEXTEN"
|
|
.IP "60 ECHOCTL"
|
|
.IP "61 ECHOKE"
|
|
.IP "62 PENDIN"
|
|
|
|
.IP "70 OPOST"
|
|
.IP "71 OLCUC"
|
|
.IP "72 ONLCR"
|
|
.IP "73 OCRNL"
|
|
.IP "74 ONOCR"
|
|
.IP "75 ONLRET"
|
|
|
|
.IP "90 CS7"
|
|
.IP "91 CS8"
|
|
.IP "92 PARENB"
|
|
.IP "93 PARODD"
|
|
|
|
.IP "192 TTY_OP_ISPEED"
|
|
Specifies the input baud rate in bits per second.
|
|
.IP "193 TTY_OP_OSPEED"
|
|
Specifies the output baud rate in bits per second.
|
|
.RT
|
|
|
|
|
|
.ti 0
|
|
The Authentication Agent Protocol
|
|
|
|
The authentication agent is a program that can be used to hold RSA
|
|
authentication keys for the user (in future, it might hold data for
|
|
other authentication types as well). An authorized program can send
|
|
requests to the agent to generate a proper response to an RSA
|
|
challenge. How the connection is made to the agent (or its
|
|
representative) inside a host and how access control is done inside a
|
|
host is implementation-dependent; however, how it is forwarded and how
|
|
one interacts with it is specified in this protocol. The connection
|
|
to the agent is normally automatically forwarded over the secure
|
|
channel.
|
|
|
|
A program that wishes to use the agent first opens a connection to its
|
|
local representative (typically, the agent itself or an SSH server).
|
|
It then writes a request to the connection, and waits for response.
|
|
It is recommended that at least five minutes of timeout are provided
|
|
waiting for the agent to respond to an authentication challenge (this
|
|
gives sufficient time for the user to cut-and-paste the challenge to a
|
|
separate machine, perform the computation there, and cut-and-paste the
|
|
result back if so desired).
|
|
|
|
Messages sent to and by the agent are in the following format:
|
|
.TS
|
|
;
|
|
l l.
|
|
4 bytes Length, msb first. Does not include length itself.
|
|
1 byte Packet type. The value 255 is reserved for future extensions.
|
|
data Any data, depending on packet type. Encoding as in the ssh packet
|
|
protocol.
|
|
.TE
|
|
|
|
The following message types are currently defined:
|
|
.IP "1 SSH_AGENTC_REQUEST_RSA_IDENTITIES"
|
|
|
|
(no arguments)
|
|
|
|
Requests the agent to send a list of all RSA keys for which it can
|
|
answer a challenge.
|
|
.IP "2 SSH_AGENT_RSA_IDENTITIES_ANSWER"
|
|
.TS
|
|
;
|
|
l l.
|
|
32-bit int howmany
|
|
howmany times:
|
|
32-bit int bits
|
|
mp-int public exponent
|
|
mp-int public modulus
|
|
string comment
|
|
.TE
|
|
The agent sends this message in response to the to
|
|
SSH_AGENTC_REQUEST_RSA_IDENTITIES. The answer lists all RSA keys for
|
|
which the agent can answer a challenge. The comment field is intended
|
|
to help identify each key; it may be printed by an application to
|
|
indicate which key is being used. If the agent is not holding any
|
|
keys, howmany will be zero.
|
|
.IP "3 SSH_AGENTC_RSA_CHALLENGE
|
|
.TS
|
|
;
|
|
l l.
|
|
32-bit int bits
|
|
mp-int public exponent
|
|
mp-int public modulus
|
|
mp-int challenge
|
|
16 bytes session_id
|
|
32-bit int response_type
|
|
.TE
|
|
Requests RSA decryption of random challenge to authenticate the other
|
|
side. The challenge will be decrypted with the RSA private key
|
|
corresponding to the given public key.
|
|
|
|
The decrypted challenge must contain a zero in the highest (partial)
|
|
byte, 2 in the next byte, followed by non-zero random bytes, a zero
|
|
byte, and then the real challenge value in the lowermost bytes. The
|
|
real challenge must be 32 8-bit bytes (256 bits).
|
|
|
|
Response_type indicates the format of the response to be returned.
|
|
Currently the only supported value is 1, which means to compute MD5 of
|
|
the real challenge plus session id, and return the resulting 16 bytes
|
|
in a SSH_AGENT_RSA_RESPONSE message.
|
|
.IP "4 SSH_AGENT_RSA_RESPONSE"
|
|
.TS
|
|
;
|
|
l l.
|
|
16 bytes MD5 of decrypted challenge
|
|
.TE
|
|
Answers an RSA authentication challenge. The response is 16 bytes:
|
|
the MD5 checksum of the 32-byte challenge.
|
|
.IP "5 SSH_AGENT_FAILURE"
|
|
|
|
(no arguments)
|
|
|
|
This message is sent whenever the agent fails to answer a request
|
|
properly. For example, if the agent cannot answer a challenge (e.g.,
|
|
no longer has the proper key), it can respond with this. The agent
|
|
also responds with this message if it receives a message it does not
|
|
recognize.
|
|
.IP "6 SSH_AGENT_SUCCESS"
|
|
|
|
(no arguments)
|
|
|
|
This message is sent by the agent as a response to certain requests
|
|
that do not otherwise cause a message be sent. Currently, this is
|
|
only sent in response to SSH_AGENTC_ADD_RSA_IDENTITY and
|
|
SSH_AGENTC_REMOVE_RSA_IDENTITY.
|
|
.IP "7 SSH_AGENTC_ADD_RSA_IDENTITY"
|
|
.TS
|
|
;
|
|
l l.
|
|
32-bit int bits
|
|
mp-int public modulus
|
|
mp-int public exponent
|
|
mp-int private exponent
|
|
mp-int multiplicative inverse of p mod q
|
|
mp-int p
|
|
mp-int q
|
|
string comment
|
|
.TE
|
|
Registers an RSA key with the agent. After this request, the agent can
|
|
use this RSA key to answer requests. The agent responds with
|
|
SSH_AGENT_SUCCESS or SSH_AGENT_FAILURE.
|
|
.IP "8 SSH_AGENT_REMOVE_RSA_IDENTITY"
|
|
.TS
|
|
;
|
|
l l.
|
|
32-bit int bits
|
|
mp-int public exponent
|
|
mp-int public modulus
|
|
.TE
|
|
Removes an RSA key from the agent. The agent will no longer accept
|
|
challenges for this key and will not list it as a supported identity.
|
|
The agent responds with SSH_AGENT_SUCCESS or SSH_AGENT_FAILURE.
|
|
.RT
|
|
|
|
If the agent receives a message that it does not understand, it
|
|
responds with SSH_AGENT_FAILURE. This permits compatible future
|
|
extensions.
|
|
|
|
It is possible that several clients have a connection open to the
|
|
authentication agent simultaneously. Each client will use a separate
|
|
connection (thus, any SSH connection can have multiple agent
|
|
connections active simultaneously).
|
|
|
|
|
|
.ti 0
|
|
References
|
|
|
|
.IP "[DES] "
|
|
FIPS PUB 46-1: Data Encryption Standard. National Bureau of
|
|
Standards, January 1988. FIPS PUB 81: DES Modes of Operation.
|
|
National Bureau of Standards, December 1980. Bruce Schneier: Applied
|
|
Cryptography. John Wiley & Sons, 1994. J. Seberry and J. Pieprzyk:
|
|
Cryptography: An Introduction to Computer Security. Prentice-Hall,
|
|
1989.
|
|
.IP "[GZIP] "
|
|
The GNU GZIP program; available for anonymous ftp at prep.ai.mit.edu.
|
|
Please let me know if you know a paper describing the algorithm.
|
|
.IP "[IDEA] "
|
|
Xuejia Lai: On the Design and Security of Block Ciphers, ETH Series in
|
|
Information Processing, vol. 1, Hartung-Gorre Verlag, Konstanz,
|
|
Switzerland, 1992. Bruce Schneier: Applied Cryptography, John Wiley &
|
|
Sons, 1994. See also the following patents: PCT/CH91/00117, EP 0 482
|
|
154 B1, US Pat. 5,214,703.
|
|
.IP [PKCS#1]
|
|
PKCS #1: RSA Encryption Standard. Version 1.5, RSA Laboratories,
|
|
November 1993. Available for anonymous ftp at ftp.rsa.com.
|
|
.IP [POSIX]
|
|
Portable Operating System Interface (POSIX) - Part 1: Application
|
|
Program Interface (API) [C language], ISO/IEC 9945-1, IEEE Std 1003.1,
|
|
1990.
|
|
.IP [RFC0791]
|
|
J. Postel: Internet Protocol, RFC 791, USC/ISI, September 1981.
|
|
.IP [RFC0793]
|
|
J. Postel: Transmission Control Protocol, RFC 793, USC/ISI, September
|
|
1981.
|
|
.IP [RFC1034]
|
|
P. Mockapetris: Domain Names - Concepts and Facilities, RFC 1034,
|
|
USC/ISI, November 1987.
|
|
.IP [RFC1282]
|
|
B. Kantor: BSD Rlogin, RFC 1258, UCSD, December 1991.
|
|
.IP "[RSA] "
|
|
Bruce Schneier: Applied Cryptography. John Wiley & Sons, 1994. See
|
|
also R. Rivest, A. Shamir, and L. M. Adleman: Cryptographic
|
|
Communications System and Method. US Patent 4,405,829, 1983.
|
|
.IP "[X11] "
|
|
R. Scheifler: X Window System Protocol, X Consortium Standard, Version
|
|
11, Release 6. Massachusetts Institute of Technology, Laboratory of
|
|
Computer Science, 1994.
|
|
.RT
|
|
|
|
|
|
.ti 0
|
|
Security Considerations
|
|
|
|
This protocol deals with the very issue of user authentication and
|
|
security.
|
|
|
|
First of all, as an implementation issue, the server program will have
|
|
to run as root (or equivalent) on the server machine. This is because
|
|
the server program will need be able to change to an arbitrary user
|
|
id. The server must also be able to create a privileged TCP/IP port.
|
|
|
|
The client program will need to run as root if any variant of .rhosts
|
|
authentication is to be used. This is because the client program will
|
|
need to create a privileged port. The client host key is also usually
|
|
stored in a file which is readable by root only. The client needs the
|
|
host key in .rhosts authentication only. Root privileges can be
|
|
dropped as soon as the privileged port has been created and the host
|
|
key has been read.
|
|
|
|
The SSH protocol offers major security advantages over existing telnet
|
|
and rlogin protocols.
|
|
.IP o
|
|
IP spoofing is restricted to closing a connection (by encryption, host
|
|
keys, and the special random cookie). If encryption is not used, IP
|
|
spoofing is possible for those who can hear packets going out from the
|
|
server.
|
|
.IP o
|
|
DNS spoofing is made ineffective (by host keys).
|
|
.IP o
|
|
Routing spoofing is made ineffective (by host keys).
|
|
.IP o
|
|
All data is encrypted with strong algorithms to make eavesdropping as
|
|
difficult as possible. This includes encrypting any authentication
|
|
information such as passwords. The information for decrypting session
|
|
keys is destroyed every hour.
|
|
.IP o
|
|
Strong authentication methods: .rhosts combined with RSA host
|
|
authentication, and pure RSA authentication.
|
|
.IP o
|
|
X11 connections and arbitrary TCP/IP ports can be forwarded securely.
|
|
.IP o
|
|
Man-in-the-middle attacks are deterred by using the server host key to
|
|
encrypt the session key.
|
|
.IP o
|
|
Trojan horses to catch a password by routing manipulation are deterred
|
|
by checking that the host key of the server machine matches that
|
|
stored on the client host.
|
|
.RT
|
|
|
|
The security of SSH against man-in-the-middle attacks and the security
|
|
of the new form of .rhosts authentication, as well as server host
|
|
validation, depends on the integrity of the host key and the files
|
|
containing known host keys.
|
|
|
|
The host key is normally stored in a root-readable file. If the host
|
|
key is compromised, it permits attackers to use IP, DNS and routing
|
|
spoofing as with current rlogin and rsh. It should never be any worse
|
|
than the current situation.
|
|
|
|
The files containing known host keys are not sensitive. However, if an
|
|
attacker gets to modify the known host key files, it has the same
|
|
consequences as a compromised host key, because the attacker can then
|
|
change the recorded host key.
|
|
|
|
The security improvements obtained by this protocol for X11 are of
|
|
particular significance. Previously, there has been no way to protect
|
|
data communicated between an X server and a client running on a remote
|
|
machine. By creating a fake display on the server, and forwarding all
|
|
X11 requests over the secure channel, SSH can be used to run any X11
|
|
applications securely without any cooperation with the vendors of the
|
|
X server or the application.
|
|
|
|
Finally, the security of this program relies on the strength of the
|
|
underlying cryptographic algorithms. The RSA algorithm is used for
|
|
authentication key exchange. It is widely believed to be secure. Of
|
|
the algorithms used to encrypt the session, DES has a rather small key
|
|
these days, probably permitting governments and organized criminals to
|
|
break it in very short time with specialized hardware. 3DES is
|
|
probably safe (but slower). IDEA is widely believed to be secure.
|
|
People have varying degrees of confidence in the other algorithms.
|
|
This program is not secure if used with no encryption at all.
|
|
|
|
|
|
.ti 0
|
|
Additional Information
|
|
|
|
Additional information (especially on the implementation and mailing
|
|
lists) is available via WWW at http://www.cs.hut.fi/ssh.
|
|
|
|
Comments should be sent to Tatu Ylonen <ylo@cs.hut.fi> or the SSH
|
|
Mailing List <ssh@clinet.fi>.
|
|
|
|
.ti 0
|
|
Author's Address
|
|
|
|
.TS
|
|
;
|
|
l.
|
|
Tatu Ylonen
|
|
Helsinki University of Technology
|
|
Otakaari 1
|
|
FIN-02150 Espoo, Finland
|
|
|
|
Phone: +358-0-451-3374
|
|
Fax: +358-0-451-3293
|
|
EMail: ylo@cs.hut.fi
|
|
.TE
|