wdiff draft-ietf-secsh-filexfer-00.txt draft-ietf-secsh-filexfer-01.txt

Network Working Group T. Ylonen and S. Lehtinen
INTERNET-DRAFT SSH Communications Security

Expires: 9 July, 2 September, 2001

SSH

Secure Shell File Transfer Protocol

Status of This Memo

This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026.

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
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as
"work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

Abstract

The SSH Secure Shell File Transfer Protocol provides secure file transfer functional-
ity
functionality over any reliable data stream. It is the standard file
transfer protocol for use with the SSH2 protocol. Secure Shell Remote Login Protocol.
This document describes the file transfer protocol and its interface to
the SSH2 Secure Shell protocol suite.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Use with the SSH Secure Shell Connection Protocol . . . . . . . . . . . . . . 3
3. General Packet Format . . . . . . . . . . . . . . . . . . . . . 3
4. Protocol Initialization . . . . . . . . . . . . . . . . . . . . 4
5. File Attributes . . . . . . . . . . . . . . . . . . . . . . . . 5
6. Responses from the Server to the Client . . . . . . . . . . . . 6
7. Requests From the Client to the Server . . . . . . . . . . . . . 6
6.1. 9
7.1. Request Synchronization and Reordering . . . . . . . . . . . 7
6.2. 10
7.2. File Names . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.3. 10
7.3. Opening, Creating, and Closing Files . . . . . . . . . . . . 8
6.4. 11
7.4. Reading and Writing . . . . . . . . . . . . . . . . . . . . 9
6.5. 12
7.5. Removing and Renaming Files . . . . . . . . . . . . . . . . 10
6.6. 13
7.6. Creating and Deleting Directories . . . . . . . . . . . . . 10
6.7. 14
7.7. Scanning Directories . . . . . . . . . . . . . . . . . . . . 11
6.8. 14
7.8. Retrieving File Attributes . . . . . . . . . . . . . . . . . 12
6.9. 15
7.9. Setting File Attributes . . . . . . . . . . . . . . . . . . 12
6.10. Canonicalizing the Server-Side Path Name 16
7.10. Dealing with Symbolic links . . . . . . . . . . 13
7. Responses from the Server to the Client . . . . . . 16
7.11. Canonicalizing the Server-Side Path Name . . . . . . 13 . . . 17
8. Vendor-Specific Extensions . . . . . . . . . . . . . . . . . . . 16 17
9. Security Considerations . . . . . . . . . . . . . . . . . . . . 17 18
10. Changes from previous protocol versions . . . . . . . . . . . . 18
10.1. Changes between versions 3 and 2 . . . . . . . . . . . . . 18
10.2. Changes between versions 2 and 1 . . . . . . . . . . . . . 18
10.3. Changes between versions 1 and 0 . . . . . . . . . . . . . 18
11. Trademark Issues . . . . . . . . . . . . . . . . . . . . . . . 17
11. 18
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
12. 19
13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18 19

1. Introduction

This protocol provides secure file transfer (and more generally file
system access) functionality over a reliable data stream, such as a
channel in the SSH2 protocol [SSH-ARCH]. Secure Shell Remote Login Protocol [SECSH-ARCH].

This protocol is designed so that it could be used to implement a secure
remote file system service, as well as a secure file transfer service.

This protocol assumes that it runs over a secure channel, and that the
server has already authenticated the user at the client end, and that
the identity of the client user is externally available to the server
implementation.

In general, this protocol follows a simple request-response model. Each
request and response contains a sequence number and multiple requests
may be pending simultaneously. There are a relatively large number of
different request messages, but a small number of possible response
messages. Each request has one or more response messages that may be
returned in result (e.g., a read either returns data or reports error
status).

The packet format descriptions in this specification follow the notation
presented in [SSH-ARCH]. [SECSH-ARCH].

Even though this protocol is described in the context of the SSH2

protocol, Secure
Shell Remote Login Protocol, this protocol is general and independent of
the rest of the
SSH2 Secure Shell protocol suite. It could be used in a
number of different applications, such as secure file transfer over TLS
[RFC-2246] and transfer of management information in VPN applications.

2. Use with the SSH Secure Shell Connection Protocol

When used with the SSH2 Protocol Secure Shell protocol suite, this protocol is
intended to be used from the SSH Secure Shell Connection Protocol as a
subsystem, as described in
[SSH-CONN], [SECSH-CONN], Section ``Starting a Shell or a
Command''. The subsystem name used with this protocol is "sftp".

3. General Packet Format

All packets transmitted over the secure connection are of the following
format:

uint32 length
byte type
byte[length - 1] data payload

That is, they are just data preceded by 32-bit length and 8-bit type
fields. The `length' is the length of the data area, and does not
include the `length' field itself. The format and interpretation of the
data area depends on the packet type.

All packet descriptions below only specify the packet type and the data
that goes into the data field. Thus, they should be prefixed by the
`length' and `type' fields.

The maximum size of a packet is in practise determined by the client
(the maximum size of read or write requests that it sends, plus a few
bytes of packet overhead). All servers SHOULD support packets of at
least 34000 bytes (where the packet size refers to the full length,
including the header above). This should allow for reads and writes of
at most 32768 bytes.

There is no limit on the number of outstanding (non-acknowledged)
requests that the client may send to the server. In practise this is
limited by the buffering available on the data stream and the queuing
performed by the server. If the server's queues are full, it should not
read any more data from the stream, and flow control will prevent the
client from sending more requests. Note, however, that while there is
no restriction on the protocol level, the client's API may provide a
limit in order to prevent infinite queueing of outgoing requests at the
client.

The following values are defined for packet types.

#define SSH_FXP_INIT 1
#define SSH_FXP_VERSION 2
#define SSH_FXP_OPEN 3
#define SSH_FXP_CLOSE 4
#define SSH_FXP_READ 5
#define SSH_FXP_WRITE 6
#define SSH_FXP_LSTAT 7
#define SSH_FXP_FSTAT 8
#define SSH_FXP_SETSTAT 9
#define SSH_FXP_FSETSTAT 10
#define SSH_FXP_OPENDIR 11
#define SSH_FXP_READDIR 12
#define SSH_FXP_REMOVE 13
#define SSH_FXP_MKDIR 14
#define SSH_FXP_RMDIR 15
#define SSH_FXP_REALPATH 16
#define SSH_FXP_STAT 17
#define SSH_FXP_RENAME 18
#define SSH_FXP_READLINK 19
#define SSH_FXP_SYMLINK 20
#define SSH_FXP_STATUS 101
#define SSH_FXP_HANDLE 102
#define SSH_FXP_DATA 103
#define SSH_FXP_NAME 104
#define SSH_FXP_ATTRS 105
#define SSH_FXP_EXTENDED 200
#define SSH_FXP_EXTENDED_REPLY 201

Additional packet types should only be defined if the protocol version
number (see Section ``Protocol Initialization'') is incremented, and
their use MUST be negotiated using the version number. However, the
SSH_FXP_EXTENDED and SSH_FXP_EXTENDED_REPLY packets can be used to
implement vendor-specific extensions. See Section ``Vendor-Specific
Extensions'' for more details.

4. Protocol Initialization

When the file transfer protocol starts, it first sends a SSH_FXP_INIT
(including its version number) packet to the server. The server
responds with a SSH_FXP_VERSION packet, supplying the lowest of its own
and the client's version number. Both parties should from then on
adhere to particular version of the protocol.

The SSH_FXP_INIT packet (from client to server) has the following data:

uint32 version
<extension data>

The SSH_FXP_VERSION packet (from server to client) has the following
data:

uint32 version
<extension data>

The version number of the protocol specified in this document is 3. The
version number should be incremented for each incompatible revision of
this protocol.

The extension data in the above packets may be empty, or may be a
sequence of

string extension_name
string extension_data

pairs (both strings MUST always be present if one is, but the `exten-
sion_data' string may be of zero length). If present, these strings
indicate extensions to the baseline protocol. The `extension_name'
field(s) identify the name of the extension. The name should be of the
form "name@domain", where the domain is the DNS domain name of the orga-
nization defining the extension. Additional names that are not of this
format may be defined later by the IETF. Implementations MUST silently
ignore any extensions whose name they do not recognize.

5. File Attributes

A new compound data type is defined for encoding file attributes. It is
basically just a combination of elementary types, but is defined once
because of the non-trivial description of the fields and to ensure
maintainability.

The same encoding is used both when returning file attributes from the
server and when sending file attributes to the server. When sending it
to the server, the flags field specifies which attributes are included,
and the server will use default values for the remaining attributes (or
will not modify the values of remaining attributes). When receiving
attributes from the server, the flags specify which attributes are
included in the returned data. The server normally returns all
attributes it knows about.

uint32 flags
uint64 size present only if flag SSH_FILEXFER_ATTR_SIZE
uint32 uid present only if flag SSH_FILEXFER_ATTR_UIDGID
uint32 gid present only if flag SSH_FILEXFER_ATTR_UIDGID
uint32 permissions present only if flag
SSH_FILEXFER_ATTR_PERMISSIONS
uint32 atime present only if flag SSH_FILEXFER_ACMODTIME
uint32 mtime present only if flag SSH_FILEXFER_ACMODTIME
uint32 extended_count present only if flag
SSH_FILEXFER_ATTR_EXTENDED
string extended_type
string extended_data
... more extended data (extended_type - extended_data pairs),
so that number of pairs equals extended_count

The `flags' specify which of the fields are present. Those fields for
which the corresponding flag is not set are not present (not included in
the packet). New flags can only be added by incrementing the protocol

version number (or by using the extension mechanism described below).

The `size' field specifies the size of the file in bytes.

The `uid' and `gid' fields contain numeric Unix-like user and group
identifiers, respectively.

The `permissions' field contains a bit mask of file permissions as
defined by [POSIX].

The `atime' and `mtime' contain the access and modification times of the
files, respectively. They are represented as seconds from Jan 1, 1970. 1970
in UTC.

The SSH_FILEXFER_ATTR_EXTENDED flag provides a general extension
mechanism for vendor-specific extensions. If the flag is specified,
then the `extended_count' field is present. It specifies the number of
extended_type-extended_data pairs that follow. Each of these pairs
specifies an extended attribute. For each of the attributes, the
extended_type field should be a string of the format "name@domain",
where "domain" is a valid, registered domain name and "name" identifies
the method. The IETF may later standardize certain names that deviate
from this format (e.g., that do not contain the "@" sign). The
interpretation of `extended_data' depends on the type. Implementations
SHOULD ignore extended data fields that they do not understand.

Additional fields can be added to the attributes by either defining
additional bits to the flags field to indicate their presence, or by
defining extended attributes for them. The extended attributes
mechanism is recommended for most purposes; additional flags bits should
only be defined by an IETF standards action that also increments the
protocol version number. The use of such new fields MUST be negotiated
by the version number in the protocol exchange. It is a protocol error
if a packet with unsupported protocol bits is received.

The flags bits are defined to have the following values:

#define SSH_FILEXFER_ATTR_SIZE 0x00000001
#define SSH_FILEXFER_ATTR_UIDGID 0x00000002
#define SSH_FILEXFER_ATTR_PERMISSIONS 0x00000004
#define SSH_FILEXFER_ATTR_ACMODTIME 0x00000008
#define SSH_FILEXFER_ATTR_EXTENDED 0x80000000

6. Requests From the Client to the Server

Requests Responses from the client Server to the server represent the various file system
operations. Each request begins with an `id' field, which is a 32-bit
identifier identifying the request (selected by the client). Client

The same
identifier will be returned in the response server responds to the request. One
possible implementation client using one of it is a monotonically increasing request
sequence number (modulo 2^32).

Many operations in the protocol operate on open files. The SSH_FXP_OPEN
request few response packets.
All requests can return a file handle (which SSH_FXP_STATUS response upon failure. When
the operation is an opaque variable-length
string) which successful, any of the responses may be used to access returned
(depending on the file later (e.g. in a read operation). The client MUST NOT send requests If no data needs to be returned to the server with bogus or
closed handles. However,
client, the server MUST perform adequate checks on SSH_FXP_STATUS response with SSH_FX_OK status is
appropriate. Otherwise, the
handle in order to avoid security risks due SSH_FXP_HANDLE message is used to fabricated handles.

This design allows either stateful and stateless server implementation,
as well as an implementation which caches state between requests but may
also flush it. The contents of the return a
file handle string are entirely up
to the server (for SSH_FXP_OPEN and its design. The client should not modify or attempt SSH_FXP_OPENDIR requests),
SSH_FXP_DATA is used to interpret the file handle strings.

The return data from SSH_FXP_READ, SSH_FXP_NAME is

used to return one or more file handle strings MUST NOT be longer than 256 bytes.

6.1. Request Synchronization and Reordering

The protocol names from a SSH_FXP_READDIR or
SSH_FXP_REALPATH request, and implementations MUST process requests relating SSH_FXP_ATTRS is used to the
same return file in the order in
attributes from SSH_FXP_STAT, SSH_FXP_LSTAT, and SSH_FXP_FSTAT requests.

Exactly one response will be returned for each request. Each response
packet contains a request identifier which they are received. In other words, if
an application submits multiple requests can be used to match each
response with the server, corresponding request. Note that it is legal to have
several requests outstanding simultaneously, and the results server is allowed
to send responses to them in a different order from the responses will be order in which
the same requests were sent (the result of their execution, however, is
guaranteed to be as if it they had sent the requests been processed one at a time and waited for the response in each case. For example, the server
may process non-overlapping read/write requests to the same file in
parallel, but overlapping reads and writes cannot be reordered or
parallelized. However, there are no ordering restrictions on the server
for processing requests from two different file transfer connections.
The server may interleave and parallelize them at will.

There are no restrictions on the
order in which responses to outstanding the requests were sent).

Response packets are delivered to of the client, except that same general format as request packets.
Each response packet begins with the server must ensure
fairness in request identifier.

The format of the sense that processing data portion of no request will be indefinitely
delayed even if the client SSH_FXP_STATUS response is sending other requests so that there are
multiple outstanding requests all the time.

6.2. File Names

This protocol represents file names as strings. File names are assumed
to use
follows:

uint32 id
uint32 error/status code
string error message (ISO-10646 UTF-8 [RFC-2279])
string language tag (as defined in [RFC-1766])

where `id' is the slash ('/') character as a directory separator.

File names starting with a slash are "absolute", request identifier, and are relative to `error/status code' indicates
the
root result of the file system. Names starting with any requested operation. The value SSH_FX_OK indicates
success, and all other character are
relative to the user's default values indicate failure. Currently, the follow-
ing values are defined (other values may be defined by future versions
of this protocol):

#define SSH_FX_OK 0
#define SSH_FX_EOF 1
#define SSH_FX_NO_SUCH_FILE 2
#define SSH_FX_PERMISSION_DENIED 3
#define SSH_FX_FAILURE 4
#define SSH_FX_BAD_MESSAGE 5
#define SSH_FX_NO_CONNECTION 6
#define SSH_FX_CONNECTION_LOST 7
#define SSH_FX_OP_UNSUPPORTED 8

SSH_FX_OK
Indicates successful completion of the operation.

SSH_FX_EOF
indicates end-of-file condition; for SSH_FX_READ it means that no
more data is available in the file, and for SSH_FX_READDIR it
indicates that no more files are contained in the directory.

SSH_FX_NO_SUCH_FILE
is returned when a reference is made to a file which should exist
but doesn't.

SSH_FX_PERMISSION_DENIED
is returned when the authenticated user does not have sufficient
permissions to perform the operation.

SSH_FX_FAILURE
is a generic catch-all error message; it should be returned if an
error occurs for which there is no more specific error code
defined.

SSH_FX_BAD_MESSAGE
may be returned if a badly formatted packet or protocol
incompatibility is detected.

SSH_FX_NO_CONNECTION
is a pseudo-error which indicates that the client has no
connection to the server (it can only be generated locally by the
client, and MUST NOT be returned by servers).

SSH_FX_CONNECTION_LOST
is a pseudo-error which indicates that the connection to the
server has been lost (it can only be generated locally by the
client, and MUST NOT be returned by servers).

SSH_FX_OP_UNSUPPORTED
indicates that an attempt was made to perform an operation which
is not supported for the server (it may be generated locally by
the client if e.g. the version number exchange indicates that a
required feature is not supported by the server, or it may be
returned by the server if the server does not implement an
operation).

The SSH_FXP_HANDLE response has the following format:

uint32 id
string handle

where `id' is the request identifier, and `handle' is an arbitrary
string that identifies an open file or directory (home directory). Note on the server. The
handle is opaque to the client; the client MUST NOT attempt to interpret
or modify it in any way. The length of the handle string MUST NOT
exceed 256 data bytes.

The SSH_FXP_DATA response has the following format:

uint32 id
string data

where `id' is the request identifier, and `data' is an arbitrary byte
string containing the requested data. The data string may be at most
the number of bytes requested in a SSH_FXP_READ request, but may also be
shorter if end of file is reached or if the read is from something other
than a regular file.

The SSH_FXP_NAME response has the following format:

uint32 id
uint32 count
repeats count times:
string filename
string longname
ATTRS attrs

where `id' is the request identifier, `count' is the number of names
returned in this response, and the remaining fields repeat `count' times
(so that
identifying all three fields are first included for the user first file, then
for the second file, etc). In the repeated part, `filename' is assumed a file
name being returned (for SSH_FXP_READDIR, it will be a relative name
within the directory, without any path components; for SSH_FXP_REALPATH
it will be an absolute path name), `longname' is an expanded format for
the file name, similar to take place outside what is returned by "ls -l" on Unix systems,
and `attrs' is the attributes of the file as described in Section ``File
Attributes''.

The format of the `longname' field is unspecified by this protocol.

Servers SHOULD interpret It
MUST be suitable for use in the output of a path name component ".." as referring directory listing command
(in fact, the recommended operation for a directory listing command is
to simply display this data). However, clients SHOULD NOT attempt to
parse the
parent directory, longname field for file attributes; they SHOULD use the attrs
field instead.

The recommended format for the longname field is as follows:

-rwxr-xr-x 1 mjos staff 348911 Mar 25 14:29 t-filexfer
1234567890 123 12345678 12345678 12345678 123456789012

Here, the first line is sample output, and the second field indicates
widths of the various fields. Fields are separated by spaces. The
first field lists file permissions for user, group, and "." as referring to others; the current directory. If sec-
ond field is link count; the
server implementation limits access to certain parts of third field is the file system,
it must be extra careful in parsing file names when enforcing such
restrictions. There have been numerous reported security bugs where a
".." in a path name has allowed access outside of the intended area.

An empty path name is valid, and it refers to user who
owns the user's default
directory (usually file; the user's home directory).

Otherwise, no syntax fourth field is defined for file names by this specification.
Clients should not make any other assumptions; however, they can splice
path the name components returned by SSH_FXP_READDIR together using a slash
('/') as of the separator, and group that will work as expected.

It owns the
file; the fifth field is understood that the lack size of well-defined semantics for the file names in bytes; the sixth field
(which actually may cause interoperability problems between clients and servers using
radically different operating systems. However, this approach contain spaces, but is known fixed to work acceptably with most systems, 12 characters) is
the file modification time, and alternative approaches that
e.g. treat the seventh field is the file names as sequences name.
Each field is specified to be a minimum of structured components are quite
complicated.

6.3. Opening, Creating, and Closing Files

Files are opened and created using certain number of character
positions (indicated by the second line above), but may also be longer
if the SSH_FXP_OPEN message, whose data
part is as follows: does not fit in the specified length.

The SSH_FXP_ATTRS response has the following format:

uint32 id
string filename
uint32 pflags
ATTRS attrs

The

where `id' field is the request identifier as for all requests.

The `filename' field specifies identifier, and `attrs' is the returned file name. See
attributes as described in Section ``File
Names'' for more information.
The `pflags' field is a bitmask. The following bits have been defined.

#define SSH_FXF_READ 0x00000001
#define SSH_FXF_WRITE 0x00000002
#define SSH_FXF_APPEND 0x00000004
#define SSH_FXF_CREAT 0x00000008
#define SSH_FXF_TRUNC 0x00000010
#define SSH_FXF_EXCL 0x00000020

These have Attributes''.

7. Requests From the following meanings:

SSH_FXF_READ
Open Client to the file for reading.

SSH_FXF_WRITE
Open Server

Requests from the file for writing. If both this and SSH_FXF_READ are
specified, client to the server represent the various file system

operations. Each request begins with an `id' field, which is opened for both reading and writing.

SSH_FXF_APPEND
Force all writes a 32-bit
identifier identifying the request (selected by the client). The same
identifier will be returned in the response to append data at the end request. One
possible implementation of the file.

SSH_FXF_CREAT
If this flag it is specified, then a new monotonically increasing request
sequence number (modulo 2^32).

Many operations in the protocol operate on open files. The SSH_FXP_OPEN
request can return a file will be created if one
does not alread exist (if O_TRUNC handle (which is specified, an opaque variable-length
string) which may be used to access the file later (e.g. in a read
operation). The client MUST NOT send requests the server with bogus or
closed handles. However, the server MUST perform adequate checks on the
handle in order to avoid security risks due to fabricated handles.

SSH_FXF_TRUNC
Forces an existing file with the same name to be truncated server and its design. The client should not modify or attempt
to zero
length when creating a interpret the file by specifying SSH_FXF_CREAT.
SSH_FXF_CREAT handle strings.

The file handle strings MUST also NOT be specified if this flag is used.

SSH_FXF_EXCL
Causes the request longer than 256 bytes.

7.1. Request Synchronization and Reordering

The protocol and implementations MUST process requests relating to fail if the named
same file already exists.

SSH_FXF_CREAT MUST also be specified in the order in which they are received. In other words, if this flag is used.

The `attrs' field specifies
an application submits multiple requests to the initial attributes for server, the file.
Default values results in
the responses will be used for those attributes that are not specified.
See Section ``File Attributes'' for more information.

Regardless the server operating system, same as if it had sent the file will always be opened
in "binary" mode (i.e., no translations between different character sets requests one at a
time and newline encodings).

The waited for the response to this message will be either SSH_FXP_HANDLE (if in each case. For example, the
operation is successful) or SSH_FXP_STATUS (if server
may process non-overlapping read/write requests to the operation fails).

A same file is closed by using the SSH_FXP_CLOSE request. Its data field has
the following format:

uint32 id
string handle

where `id' is in
parallel, but overlapping reads and writes cannot be reordered or
parallelized. However, there are no ordering restrictions on the request identifier, server
for processing requests from two different file transfer connections.
The server may interleave and `handle' is a handle previ-
ously returned in parallelize them at will.

There are no restrictions on the response order in which responses to SSH_FXP_OPEN or SSH_FXP_OPENDIR. The
handle becomes invalid immediately after this request has been sent.
The response outstanding
requests are delivered to this the client, except that the server must ensure
fairness in the sense that processing of no request will be a SSH_FXP_STATUS message. One
should note that on some server platforms indefinitely
delayed even a close can fail. This
can happen e.g. if the server operating system caches writes, and an
error occurs while flushing cached writes during client is sending other requests so that there are
multiple outstanding requests all the close.

6.4. Reading and Writing

Once a time.

7.2. File Names

This protocol represents file has been opened, it can be read using names as strings. File names are assumed
to use the SSH_FXP_READ
message, which has slash ('/') character as a directory separator.

File names starting with a slash are "absolute", and are relative to the following format:

uint32 id
string handle
uint64 offset
uint32 len

where `id' is
root of the request identifier, `handle' is an open file handle
returned by SSH_FXP_OPEN, `offset' is the offset (in bytes) system. Names starting with any other character are
relative to the beginning of the file from where to start reading, user's default directory (home directory). Note that
identifying the user is assumed to take place outside of this protocol.

Servers SHOULD interpret a path name component ".." as referring to the
parent directory, and `len' is the
maximum number of bytes to read.

In response "." as referring to this request, the current directory. If the
server will read as many bytes as it
can from implementation limits access to certain parts of the file (up to `len'), and return them system,

it must be extra careful in parsing file names when enforcing such
restrictions. There have been numerous reported security bugs where a
".." in a SSH_FXP_DATA
message. If an error occurs or EOF is encountered before reading any
data, path name has allowed access outside the server will respond with SSH_FXP_STATUS. For normal disk
files, it intended area.

An empty path name is guaranteed that this will read the specified number of
bytes, or up to end of file. For e.g. device files this may return
fewer bytes than requested.

Writing valid, and it refers to a file is achieved using the SSH_FXP_WRITE message, which has user's default
directory (usually the following format:

uint32 id
string handle
uint64 offset
string data

where `id' is a request identifier, `handle' user's home directory).

Otherwise, no syntax is a defined for file handle names by this specification.
Clients should not make any other assumptions; however, they can splice
path name components returned by SSH_FXP_OPEN, `offset' is the offset (in bytes) from the beginning of SSH_FXP_READDIR together using a slash
('/') as the file where to start writing, separator, and `data' is the data to be written.

The write that will extend the file if writing beyond the end of the file.
It is legal to write way beyond work as expected.

It is understood that the end lack of the file; the well-defined semantics are
to write zeroes from the end of the for file to the specified offset names
may cause interoperability problems between clients and
then the data. On most servers using
radically different operating systems, such writes do not allocate
disk space but instead leave "holes" in the file.

The server responds systems. However, this approach is known
to a write request work acceptably with a SSH_FXP_STATUS message.

6.5. Removing most systems, and Renaming alternative approaches that
e.g. treat file names as sequences of structured components are quite
complicated.

7.3. Opening, Creating, and Closing Files

Files can be removed are opened and created using the SSH_FXP_REMOVE message. It has the
following format: SSH_FXP_OPEN message, whose data
part is as follows:

uint32 id
string filename

where
uint32 pflags
ATTRS attrs

The `id' field is the request identifier and as for all requests.

The `filename' is the name of field specifies the file to be removed. name. See Section ``File
Names'' for more information.
This request cannot be used to remove directories.

The server will respond to this request with a SSH_FXP_STATUS message.

Files (and directories) can be renamed using the SSH_FXP_RENAME message.
Its data is as follows:

uint32 id
string oldpath
string newpath

where `id' `pflags' field is a bitmask. The following bits have been defined.

#define SSH_FXF_READ 0x00000001
#define SSH_FXF_WRITE 0x00000002
#define SSH_FXF_APPEND 0x00000004
#define SSH_FXF_CREAT 0x00000008
#define SSH_FXF_TRUNC 0x00000010
#define SSH_FXF_EXCL 0x00000020

These have the request identifier, `oldpath' is following meanings:

SSH_FXF_READ
Open the name of an exist-
ing file or directory, and `newpath' is the new name for reading.

SSH_FXF_WRITE
Open the file or
directory. It is an error if there already exists a file with for writing. If both this and SSH_FXF_READ are
specified, the name
specified by newpath. The server may also fail rename requests in other
situations, file is opened for example if `oldpath' both reading and `newpath' point writing.

SSH_FXF_APPEND
Force all writes to different
file systems on append data at the server.

The server will respond to end of the file.

SSH_FXF_CREAT
If this request with flag is specified, then a SSH_FXP_STATUS message.

6.6. Creating and Deleting Directories

New directories can new file will be created using the SSH_FXP_MKDIR request. It has
the following format:

uint32 id
string path

where `id' if one
does not alread exist (if O_TRUNC is specified, the request identifier and `path' specifies the directory
to be created. See Section ``File Names'' for more information on new file
names. An error will
be returned truncated to zero length if a it previously exists).

SSH_FXF_TRUNC
Forces an existing file or directory with the speci-
fied path already exists. The server will respond same name to this request with be truncated to zero
length when creating a SSH_FXP_STATUS message.

Directories can file by specifying SSH_FXF_CREAT.
SSH_FXF_CREAT MUST also be removed using the SSH_FXP_RMDIR request, which has
the following format:

uint32 id
string path

where `id' specified if this flag is used.

SSH_FXF_EXCL
Causes the request identifier, and `path' to fail if the named file already exists.
SSH_FXF_CREAT MUST also be specified if this flag is used.

The `attrs' field specifies the directory
to initial attributes for the file.
Default values will be removed. used for those attributes that are not specified.
See Section ``File Names'' Attributes'' for more information on file
names. An error will be returned if no directory with the specified
path exists, or if the specified directory is not empty, or if information.

Regardless the server operating system, the path
specified a file system object other than a directory. will always be opened
in "binary" mode (i.e., no translations between different character sets
and newline encodings).

The server
responds response to this request with a SSH_FXP_STATUS message.

6.7. Scanning Directories

The files in a directory can message will be listed using the SSH_FXP_OPENDIR and
SSH_FXP_READDIR requests. Each SSH_FXP_READDIR request returns one or
more file names with full file attributes for each file. The client
should call SSH_FXP_READDIR repeatedly until it has found either SSH_FXP_HANDLE (if the file it
operation is
looking for successful) or until the server responds with a SSH_FXP_STATUS message
indicating an error (normally SSH_FX_EOF if there are no more files in
the directory). The client should then close (if the handle operation fails).

A file is closed by using the SSH_FXP_CLOSE request.

The SSH_FXP_OPENDIR opens a directory for reading. It Its data field has
the following format:

uint32 id
string path handle

where `id' is the request identifier identifier, and `path' `handle' is a handle previ-
ously returned in the path name of the
directory response to be listed (without any trailing slash). See Section ``File
Names'' for more information on file names. This will return an error
if the path does not specify a directory SSH_FXP_OPEN or if the directory is not
readable. SSH_FXP_OPENDIR. The server will respond
handle becomes invalid immediately after this request has been sent.

The response to this request with either a
SSH_FXP_HANDLE or will be a SSH_FXP_STATUS message.

Once One
should note that on some server platforms even a close can fail. This
can happen e.g. if the directory server operating system caches writes, and an
error occurs while flushing cached writes during the close.

7.4. Reading and Writing

Once a file has been successfully opened, files (and directories)
contained in it can be listed read using SSH_FXP_READDIR requests. These are
of the format SSH_FXP_READ
message, which has the following format:

uint32 id
string handle
uint64 offset
uint32 len

where `id' is the request identifier, and `handle' is a handle returned

by SSH_FXP_OPENDIR. (It is a protocol error to attempt to use an ordi-
nary open file handle

returned by SSH_FXP_OPEN.)

The server responds to this request with either a SSH_FXP_NAME or a
SSH_FXP_STATUS message. One or more names may be returned at a time.
Full status information SSH_FXP_OPEN, `offset' is returned for each name in order to speed up
typical directory listings.

When the client no longer wishes offset (in bytes) relative to read more names from the directory,
it SHOULD call SSH_FXP_CLOSE for
the handle. The handle should be
closed regardless beginning of whether an error has occurred or not.

6.8. Retrieving File Attributes

Very often, the file attributes are automatically returned by
SSH_FXP_READDIR. However, sometimes there from where to start reading, and `len' is need the
maximum number of bytes to specifically
retrieve read.

In response to this request, the attributes for a named file. This server will read as many bytes as it
can be done using from the
SSH_FXP_STAT, SSH_FXP_LSTAT and SSH_FXP_FSTAT requests.

SSH_FXP_STAT file (up to `len'), and SSH_FXP_LSTAT only differ return them in a SSH_FXP_DATA
message. If an error occurs or EOF is encountered before reading any
data, the server will respond with SSH_FXP_STATUS. For normal disk
files, it is guaranteed that SSH_FXP_STAT follows
symbolic links on this will read the server, whereas SSH_FXP_LSTAT does not follow
symbolic links. Both have specified number of
bytes, or up to end of file. For e.g. device files this may return
fewer bytes than requested.

Writing to a file is achieved using the same SSH_FXP_WRITE message, which has
the following format:

uint32 id
string path handle
uint64 offset
string data

where `id' is the a request identifier, and `path' spefifies `handle' is a file handle returned
by SSH_FXP_OPEN, `offset' is the offset (in bytes) from the beginning of
the file sys-
tem object for which status where to start writing, and `data' is the data to be returned. written.

The write will extend the file if writing beyond the end of the file.
It is legal to write way beyond the end of the file; the semantics are
to write zeroes from the end of the file to the specified offset and
then the data. On most operating systems, such writes do not allocate
disk space but instead leave "holes" in the file.

The server responds to
this a write request with either SSH_FXP_ATTRS or SSH_FXP_STATUS.

SSH_FXP_FSTAT differs from a SSH_FXP_STATUS message.

7.5. Removing and Renaming Files

Files can be removed using the others in that it returns status
information for an open file (identified by SSH_FXP_REMOVE message. It has the file handle). Its
format is as follows:
following format:

uint32 id
string handle filename

where `id' is the request identifier and `handle' `filename' is a the name of the
file handle
returned by SSH_FXP_OPEN. to be removed. See Section ``File Names'' for more information.
This request cannot be used to remove directories.

The server responds will respond to this request with
SSH_FXP_ATTRS or SSH_FXP_STATUS.

6.9. Setting File Attributes

File attributes may be modified using the SSH_FXP_SETSTAT and
SSH_FXP_FSETSTAT requests. These requests are used for operations such
as changing the ownership, permissions or access times, as well as for
truncating a file.

The SSH_FXP_SETSTAT request is of SSH_FXP_STATUS message.

Files (and directories) can be renamed using the following format: SSH_FXP_RENAME message.
Its data is as follows:

uint32 id
string path
ATTRS attrs oldpath
string newpath

where `id' is the request identifier, `path' specifies `oldpath' is the file system
object (e.g. name of an exist-
ing file or directory) whose attributes are to be modified, directory, and
`attrs' specifies `newpath' is the modifications to be made to its attributes.
Attributes are discussed in more detail in Section ``File Attributes''.

An error will be returned if new name for the specified file system object does not
exist or
directory. It is an error if there already exists a file with the user does not have sufficient rights name
specified by newpath. The server may also fail rename requests in other
situations, for example if `oldpath' and `newpath' point to modify different
file systems on the
specified attributes. server.

The server responds will respond to this request with a SSH_FXP_STATUS message.

The SSH_FXP_FSETSTAT request modifies

7.6. Creating and Deleting Directories

New directories can be created using the attributes of a file which is
already open. SSH_FXP_MKDIR request. It has
the following format:

uint32 id
string handle path
ATTRS attrs

where `id' is the request identifier, `handle' (MUST be returned by
SSH_FXP_OPEN) identifies the file whose attributes are to be modified,
and `path'and `attrs' specifies the
modifications to be made to its attributes. See Section ``File Names''
for more information on file names. Attributes are discussed in more
detail in Section ``File Attributes''. specifies the directory to be
created. An error will be returned if a file or directory with the
specified path already exists. The server will respond to this request
with SSH_FXP_STATUS.

6.10. Canonicalizing the Server-Side Path Name

The SSH_FXP_REALPATH request a SSH_FXP_STATUS message.

Directories can be used to have the server canonicalize
any given path name to an absolute path. This is useful for converting
path names containing ".." components or relative pathnames without a
leading slash into absolute paths. The format of removed using the request is as
follows: SSH_FXP_RMDIR request, which has
the following format:

uint32 id
string path

where `id' is the request identifier identifier, and `path' specifies the path name directory
to be canonicalized. The server will respond with a SSH_FXP_NAME packet
containing only one name and a dummy attributes value. The name is the
returned packet removed. See Section ``File Names'' for more information on file
names. An error will be in canonical form. If an error occurs, the
server may also respond returned if no directory with SSH_FXP_STATUS.

7. Responses from the Server to specified
path exists, or if the Client specified directory is not empty, or if the path
specified a file system object other than a directory. The server
responds to the client using one of a few response packets.
All requests can return this request with a SSH_FXP_STATUS response upon failure. When
the operation is successful, any of the responses may be returned
(depending on the operation). If no data needs to message.

7.7. Scanning Directories

The files in a directory can be returned to the
client, the SSH_FXP_STATUS response with SSH_FX_OK status is
appropriate. Otherwise, listed using the SSH_FXP_HANDLE message is used to return a
file handle (for SSH_FXP_OPEN and SSH_FXP_OPENDIR requests),
SSH_FXP_DATA is used to return data from SSH_FXP_READ, SSH_FXP_NAME is
used to return and
SSH_FXP_READDIR requests. Each SSH_FXP_READDIR request returns one or
more file names from a SSH_FXP_READDIR or
SSH_FXP_REALPATH request, and SSH_FXP_ATTRS is used to return with full file attributes from SSH_FXP_STAT, SSH_FXP_LSTAT, and SSH_FXP_FSTAT requests.

Exactly one response will be returned for each request. Each response
packet contains a request identifier which can be used to match each
response with file. The client
should call SSH_FXP_READDIR repeatedly until it has found the corresponding request. Note that file it is legal to have
several requests outstanding simultaneously, and
looking for or until the server is allowed
to send responses to them in responds with a different order from the order in which
the requests were sent (the result of their execution, however, is
guaranteed to be as SSH_FXP_STATUS message
indicating an error (normally SSH_FX_EOF if they had been processed one at a time in the
order there are no more files in which
the requests were sent).

Response packets are of directory). The client should then close the same general format as request packets.
Each response packet begins with handle using the request identifier.
SSH_FXP_CLOSE request.

The format of the data portion of SSH_FXP_OPENDIR opens a directory for reading. It has the SSH_FXP_STATUS response is as
follows: following
format:

uint32 id
uint32 error/status code
string path

where `id' is the request identifier, identifier and `error/status code' indicates `path' is the result path name of the requested operation.
directory to be listed (without any trailing slash). See Section ``File
Names'' for more information on file names. This will return an error
if the path does not specify a directory or if the directory is not
readable. The value SSH_FX_OK indicates
success, and all other values indicate failure. Currently, server will respond to this request with either a
SSH_FXP_HANDLE or a SSH_FXP_STATUS message.

Once the follow-
ing values are defined (other values may directory has been successfully opened, files (and directories)
contained in it can be defined by future versions
of this protocol):

SSH_FX_OK
Indicates successful completion listed using SSH_FXP_READDIR requests. These are
of the operation.

SSH_FX_EOF
indicates end-of-file condition; for SSH_FX_READ it means that no
more data format

uint32 id
string handle

where `id' is available in the file, request identifier, and for SSH_FX_READDIR it
indicates that no more files are contained in the directory.

SSH_FX_NO_SUCH_FILE `handle' is returned when a reference handle returned
by SSH_FXP_OPENDIR. (It is made to a protocol error to attempt to use an ordi-
nary file which should exist
but doesn't.

SSH_FX_PERMISSION_DENIED
is handle returned when the authenticated user does not have sufficient
permissions by SSH_FXP_OPEN.)

The server responds to perform the operation.
SSH_FX_FAILURE
is this request with either a generic catch-all error message; it should be returned if an
error occurs for which there is no SSH_FXP_NAME or a
SSH_FXP_STATUS message. One or more specific error code
defined.

SSH_FX_BAD_MESSAGE names may be returned if at a badly formatted packet or protocol
incompatibility is detected.

SSH_FX_NO_CONNECTION time.
Full status information is a pseudo-error which indicates that returned for each name in order to speed up
typical directory listings.

When the client has no
connection longer wishes to read more names from the server (it can only be generated locally by directory,
it SHOULD call SSH_FXP_CLOSE for the
client, and MUST NOT handle. The handle should be returned by servers).

SSH_FX_CONNECTION_LOST
is a pseudo-error which indicates that the connection to the
server
closed regardless of whether an error has been lost (it can only be generated locally by the
client, and MUST NOT be occurred or not.

7.8. Retrieving File Attributes

Very often, file attributes are automatically returned by servers).

SSH_FX_OP_UNSUPPORTED
indicates that an attempt was made to perform an operation which
is not supported for the server (it may be generated locally by
the client if e.g. the version number exchange indicates that a
required feature
SSH_FXP_READDIR. However, sometimes there is not supported by need to specifically
retrieve the server, or it may attributes for a named file. This can be
returned by done using the server if
SSH_FXP_STAT, SSH_FXP_LSTAT and SSH_FXP_FSTAT requests.

SSH_FXP_STAT and SSH_FXP_LSTAT only differ in that SSH_FXP_STAT follows
symbolic links on the server server, whereas SSH_FXP_LSTAT does not implement an
operation).

The SSH_FXP_HANDLE response has follow
symbolic links. Both have the following same format:

uint32 id
string handle path

where `id' is the request identifier, and `handle' is an arbitrary
string that identifies an open file or directory on `path' spefifies the server. The
handle file sys-
tem object for which status is opaque to the client; the client MUST NOT attempt be returned. The server responds to interpret
this request with either SSH_FXP_ATTRS or modify it in any way. The length of SSH_FXP_STATUS.

SSH_FXP_FSTAT differs from the handle string MUST NOT
exceed 256 data bytes.

The SSH_FXP_DATA response has others in that it returns status
information for an open file (identified by the following format: file handle). Its
format is as follows:

uint32 id
string data handle

where `id' is the request identifier, identifier and `data' `handle' is an arbitrary byte
string containing the requested data. a file handle
returned by SSH_FXP_OPEN. The data string server responds to this request with
SSH_FXP_ATTRS or SSH_FXP_STATUS.

7.9. Setting File Attributes

File attributes may be at most modified using the number of bytes requested in a SSH_FXP_READ request, but may also be
shorter if end of file is reached or if SSH_FXP_SETSTAT and
SSH_FXP_FSETSTAT requests. These requests are used for operations such
as changing the read is from something other
than ownership, permissions or access times, as well as for
truncating a regular file.

The SSH_FXP_NAME response has SSH_FXP_SETSTAT request is of the following format:

uint32 id
uint32 count
repeats count times:
string filename
string longname path
ATTRS attrs

where `id' is the request identifier, `count' is `path' specifies the number of names
returned in this response, file system
object (e.g. file or directory) whose attributes are to be modified, and
`attrs' specifies the remaining fields repeat `count' times
(so that all three fields modifications to be made to its attributes.
Attributes are first included for discussed in more detail in Section ``File Attributes''.

An error will be returned if the first file, then
for specified file system object does not
exist or the second file, etc). In user does not have sufficient rights to modify the repeated part, `filename' is a file
name being returned (for SSH_FXP_READDIR, it will be
specified attributes. The server responds to this request with a relative name
within
SSH_FXP_STATUS message.

The SSH_FXP_FSETSTAT request modifies the directory, without any path components; for SSH_FXP_REALPATH
it will be an absolute path name), `longname' attributes of a file which is an expanded format for
already open. It has the file name, similar to what following format:

uint32 id
string handle
ATTRS attrs

where `id' is the request identifier, `handle' (MUST be returned by "ls -l" on Unix systems,
and `attrs' is the attributes of
SSH_FXP_OPEN) identifies the file as described in Section ``File
Attributes''.

The format of whose attributes are to be modified,
and `attrs' specifies the `longname' field is unspecified by this protocol. It
MUST modifications to be suitable for use made to its attributes.
Attributes are discussed in the output of a directory listing command
(in fact, the recommended operation for a directory listing command is more detail in Section ``File Attributes''.
The server will respond to simply display this data). However, clients SHOULD NOT attempt to
parse the longname field for file attributes; they SHOULD use the attrs
field instead. request with SSH_FXP_STATUS.

7.10. Dealing with Symbolic links

The recommended format for SSH_FXP_READLINK request may be used to read the longname field is target of a
symbolic link. It would have a data part as follows:

-rwxr-xr-x 1 mjos staff 348911 Mar 25 14:29 t-filexfer
1234567890 123 12345678 12345678 12345678 123456789012

Here, the first line

uint32 id
string path

where `id' is sample output, the request identifier and `path' specifies the second field indicates
widths path name
of the various fields. Fields are separated by spaces. symlink to be read.

The
first field lists file permissions for user, group, server will respond with a SSH_FXP_NAME packet containing only one
name and others; the sec-
ond field is link count; the third field is the a dummy attributes value. The name of the user who
owns the file; in the fourth field is returned packet
contains the name target of the group that owns link. If an error occurs, the
file; server may
respond with SSH_FXP_STATUS.

The SSH_FXP_SYMLINK request will create a symbolic link on the fifth field server.
It is the size of the file in bytes; the sixth field
(which actually may contain spaces, but is fixed to 12 characters) following format

uint32 id
string linkpath
string targetpath

where `id' is the file modification time, and request identifier, `linkpath' specifies the seventh field is path name
of the file name.
Each file is specified symlink to be a minimum of certain number created and `targetpath' specifies the target of character
positions (indicated by
the second line above), but may also be longer
if symlink. The server shall respond with a SSH_FXP_STATUS indicating
either success (SSH_FX_OK) or an error condition.

7.11. Canonicalizing the data does not fit in Server-Side Path Name

The SSH_FXP_REALPATH request can be used to have the specified length. server canonicalize
any given path name to an absolute path. This is useful for converting
path names containing ".." components or relative pathnames without a
leading slash into absolute paths. The SSH_FXP_ATTRS response has format of the following format: request is as
follows:

uint32 id
ATTRS attrs
string path

where `id' is the request identifier, identifier and `attrs' `path' specifies the path name
to be canonicalized. The server will respond with a SSH_FXP_NAME packet
containing only one name and a dummy attributes value. The name is the
returned file
attributes as described packet will be in Section ``File Attributes''. canonical form. If an error occurs, the
server may also respond with SSH_FXP_STATUS.

8. Vendor-Specific Extensions

The SSH_FXP_EXTENDED request provides a generic extension mechanism for
adding vendor-specific commands. The request has the following format:

uint32 id
string extended-request
... any request-specific data ...

where `id' is the request identifier, and `extended-request' is a string
of the format "name@domain", where domain is an internet domain name of
the vendor defining the request. The rest of the request is completely
vendor-specific, and servers should only attempt to interpret it if they
recognize the `extended-request' name.

The server may respond to such requests using any of the response
packets defined in Section ``Responses from the Server to the Client''.
Additionally, the server may also respond with a SSH_FXP_EXTENDED_REPLY
packet, as defined below. If the server does not recognize the

`extended-request' name, then the server MUST respond with
SSH_FXP_STATUS with error/status set to SSH_FX_OP_UNSUPPORTED.

The SSH_FXP_EXTENDED_REPLY packet can be used to carry arbitrary
extension-specific data from the server to the client. It is of the
following format:

uint32 id
... any request-specific data ...

9. Security Considerations

This protocol assumes that it is run over a secure channel and that the
endpoints of the channel have been authenticated. Thus, this protocol
assumes that it is externally protected from network-level attacks.

This protocol provides file system access to arbitrary files on the
server (only constrained by the server implementation). It is the
responsibility of the server implementation to enforce any access
controls that may be required to limit the access allowed for any
particular user (the user being authenticated externally to this
protocol, typically using the SSH Secure Shell User Authentication Protocol [SSH-
USERAUTH].
[SECSH-USERAUTH].

Care must be taken in the server implementation to check the validity of
received file handle strings. The server should not rely on them
directly; it MUST check the validity of each handle before relying on
it.

10. Trademark Issues

SSH is a registered trademark and Changes from previous protocol versions

The Secure Shell File Transfer Protocol has changed over time, before
it's standardization. The following is a trademark of SSH
Communications Security Corp. SSH Communications Security Corp permits
the use description of these trademarks as the name of this standard
incompatible changes between different versions.

10.1. Changes between versions 3 and protocol, 2

o The SSH_FXP_READLINK and permits their use to describe that a product conforms SSH_FXP_SYMLINK mesages were added.

o The SSH_FXP_EXTENDED and SSH_FXP_EXTENDED_REPLY messages were added.

o The SSH_FXP_STATUS message was changed to this
standard, provided that the following acknowledgement is included where
the trademarks are used: ``SSH is a registered trademark include fields `error
message' and Secure
Shell `language tag'.

10.2. Changes between versions 2 and 1

o The SSH_FXP_RENAME message was added.

10.3. Changes between versions 1 and 0

o Implementation changes, no actual protocol changes.

11. Trademark Issues

"ssh" is a registered trademark of SSH Communications Security Corp
(www.ssh.com)''. These trademarks may not be used as part of a product
name or in otherwise confusing manner without prior written permission
of SSH Communications Security Corp.

11.
the United States and/or other countries.

12. References

[RFC-2246] Dierks, T. and Allen, C.: "The TLS Protocol Version 1.0",
January 1999

[POSIX] ISO/IEC Std 9945-1, ANSI/IEEE Std 1003.1 Information technology
-- Portable Operating System Interface (POSIX)-Part 1: System
Application Program Interface (API) [C Language], July 1996.

[SSH-ARCH]

[SECSH-ARCH] Ylonen, T., et al: "SSH "Secure Shell Protocol Architecture", Internet-
Draft, draft-ietf-secsh-architecture-07.txt

[SSH-TRANSPORT]
Internet-Draft, draft-ietf-secsh-architecture-08.txt

[SECSH-TRANSPORT] Ylonen, T., et al: "SSH "Secure Shell Transport Protocol", Internet-
Draft, draft-ietf-secsh-transport-09.txt

[SSH-USERAUTH]
Internet-Draft, draft-ietf-secsh-transport-10.txt

[SECSH-USERAUTH] Ylonen, T., et al: "SSH "Secure Shell Authentication
Protocol", Internet-Draft, draft-ietf-secsh-userauth-09.txt

[SSH-CONNECT] draft-ietf-secsh-userauth-10.txt

[SECSH-CONNECT] Ylonen, T., et al: "SSH "Secure Shell Connection Protocol", Internet-
Draft, draft-ietf-secsh-connect-09.txt

12.
Internet-Draft, draft-ietf-secsh-connect-10.txt

13. Authors' Addresses

Tatu Ylonen
SSH Communications Security Corp
Fredrikinkatu 42
FIN-00100 HELSINKI
Finland
E-mail: ylo@ssh.com

Sami Lehtinen
SSH Communications Security Corp
Fredrikinkatu 42
FIN-00100 HELSINKI
Finland
E-mail: sjl@ssh.com