HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 07:40:53 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Thu, 31 Jul 1997 16:41:00 GMT ETag: "3050be-81a6-33e0c01c" Accept-Ranges: bytes Content-Length: 33190 Connection: close Content-Type: text/plain Network Working Group Tatu Ylonen INTERNET-DRAFT SSH Communications Security draft-ietf-secsh-connect-01.txt July 30, 1997 Expires in six months SSH Connection Protocol 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 documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' 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). Abstract This document describes the SSH connection protocol. It multiplexes a single encrypted tunnel into a number of channels (interactive sessions, forwarded TCP/IP ports, X11 connections, etc). It is intended to run above the SSH user authentication layer. Tatu Ylonen [page 1] INTERNET-DRAFT July 30, 1997 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Global Requests . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Channel Mechanism . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Opening a Channel . . . . . . . . . . . . . . . . . . . . . 3 3.2. Data Transfer . . . . . . . . . . . . . . . . . . . . . . . 4 3.3. Closing a Channel . . . . . . . . . . . . . . . . . . . . . 5 3.4. Channel-Specific Requests . . . . . . . . . . . . . . . . . 5 4. Interactive Sessions . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Opening a Session . . . . . . . . . . . . . . . . . . . . . 6 4.2. Requesting a Pseudo-Terminal . . . . . . . . . . . . . . . . 6 4.3. X11 Forwarding . . . . . . . . . . . . . . . . . . . . . . . 7 4.3.1. Requesting X11 Forwarding . . . . . . . . . . . . . . . 7 4.3.2. X11 Channels . . . . . . . . . . . . . . . . . . . . . . 7 4.4. Authentication Agent Forwarding . . . . . . . . . . . . . . 8 4.4.1. Requesting Athentication Agent Forwarding . . . . . . . 8 4.4.2. Authentication Agent Channels . . . . . . . . . . . . . 8 4.5. Environment Variable Passing . . . . . . . . . . . . . . . . 8 4.6. Starting Shell or Command . . . . . . . . . . . . . . . . . 9 4.7. Session Data Transfer . . . . . . . . . . . . . . . . . . . 9 4.8. Window Change Message . . . . . . . . . . . . . . . . . . . 9 4.9. Local Flow Control . . . . . . . . . . . . . . . . . . . . . 10 4.10. Signals . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.11. Returning Exit Status . . . . . . . . . . . . . . . . . . . 10 5. TCP/IP Port Forwarding . . . . . . . . . . . . . . . . . . . . . 11 5.1. Requesting Port Forwarding . . . . . . . . . . . . . . . . . 11 5.2. TCP/IP Forwarding Channels . . . . . . . . . . . . . . . . . 11 6. FTP Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . 12 7. Encoding of Terminal Modes . . . . . . . . . . . . . . . . . . . 12 8. Summary of Message Numbers . . . . . . . . . . . . . . . . . . . 16 9. Security Considerations . . . . . . . . . . . . . . . . . . . . 16 10. Address of Author . . . . . . . . . . . . . . . . . . . . . . . 17 1. Introduction This protocol has been designed to run over the SSH transport layer and user authentication protocols. The service name for this protocol (after user authentication) is "ssh-connection". It provides interactive login sessions, remote execution of commands, forwarded TCP/IP connections, and forwarded X11 connections. 2. Global Requests There are several kinds of requests that affect the state of the remote end "globally", independent of any channels. An example is a request to start TCP/IP forwarding for a specific port. All such requests use the following format. byte SSH_MSG_GLOBAL_REQUEST string request name Tatu Ylonen [page 2] INTERNET-DRAFT July 30, 1997 boolean want_reply ... request-specific data follows The recipient will respond to this message with SSH_MSG_REQUEST_SUCCESS, SSH_MSG_REQUEST_FAILURE, or some request-specific continuation messages. If the recipient does not recognize or support the request, it simply responds with SSH_MSG_REQUEST_FAILURE. byte SSH_MSG_REQUEST_SUCCESS byte SSH_MSG_REQUEST_FAILURE 3. Channel Mechanism All terminal sessions, forwarded connections, etc. are channels. Either side may open a channel. Multiple channels are multiplexed on the single connection. Channels are identified by numbers at each end. The number referring to a channel may be different on each side. Requests to open a channel contain the sender's channel number. Any other channel-related messages contain the recipient's channel number for the channel. Channels are flow-controlled. No data may be sent to a channel until a message is received to indicate that window space is available. 3.1. Opening a Channel When either side wishes to open a new channel, it allocates a local number for the channel. It then sends the following message to the other side, and includes the local channel number and initial window size in the message. byte SSH_MSG_CHANNEL_OPEN string channel type uint32 sender_channel uint32 initial_window_size uint32 max_packet_size ... channel type specific data follows The channel type is a name as described in the transport layer protocol, with similar extension mechanisms (the domain name suffic convention). Sender_channel is a local identifier for the channel used by the sender of this message. Initial_window_size specifies how many bytes of channel data can be sent to the sender of this message without adjusting the window. Max_packet_size specifies the maximum size of an individual data packet that can be sent to the sender (for example, one might want to use smaller packets for interactive connections to get better interactive response on slow links). The remote side then decides whether it can open the channel, and responds with either Tatu Ylonen [page 3] INTERNET-DRAFT July 30, 1997 byte SSH_MSG_CHANNEL_OPEN_CONFIRMATION uint32 recipient_channel uint32 sender_channel uint32 initial_window_size uint32 max_packet_size ... channel type specific data follows where recipient_channel is the channel number given in the original open request, and sender_channel is the channel number allocated by the other side, or byte SSH_MSG_CHANNEL_OPEN_FAILURE uint32 recipient_channel uint32 reason_code If the recipient of the SSH_MSG_CHANNEL_OPEN message does not support the specified channel type, it simply responds with SSH_MSG_CHANNEL_OPEN_FAILURE. The following reason codes are defined: #define SSH_OPEN_ADMINISTRATIVELY_PROHIBITED 1 #define SSH_OPEN_CONNECT_FAILED 2 #define SSH_OPEN_UNKNOWN_CHANNEL_TYPE 3 #define SSH_OPEN_RESOURCE_SHORTAGE 4 3.2. Data Transfer The window size specifies how many characters the other party can send before it must wait for the window to be adjusted. Both parties use the following message to adjust the window. byte SSH_MSG_CHANNEL_WINDOW_ADJUST uint32 recipient_channel uint32 bytes_to_add Upon receiving this message, the recipient increases the number of bytes it is allowed to send by the given amount. Data transfer is done with messages of the following type. byte SSH_MSG_CHANNEL_DATA uint32 recipient_channel string data The maximum amount of data allowed is the current window size. The window size is decremented by the amount of data sent. Additionally, some channels can transfer several types of data. An example of this is stderr data from interactive sessions. Such data can be passed with SSH_MSG_CHANNEL_EXTENDED_DATA messages, where a separate integer specifies the type of the data. The available types and their interpretation depend on the type of the channel. Tatu Ylonen [page 4] INTERNET-DRAFT July 30, 1997 byte SSH_MSG_CHANNEL_EXTENDED_DATA uint32 recipient_channel uint32 data_type_code string data Data sent with these messages consumes the same window as ordinary data. Currently, only the following type is defined. #define SSH_EXTENDED_DATA_STDERR 1 3.3. Closing a Channel When a party will no longer send more data to a channel, it should send SSH_MSG_CHANNEL_EOF. byte SSH_MSG_CHANNEL_EOF uint32 recipient_channel No explicit response is sent to this message; however, the application may send EOF to whatever is at the other end of the channel. Note that the channel remains open after this message, and more data may still be sent in the other direction. This message does not consume window space and can be sent even if no window space is available. When either party wishes to terminate the channel, it sends SSH_MSG_CHANNEL_CLOSE. Upon receiving this message, a party must send back an SSH_MSG_CHANNEL_CLOSE unless it has already sent this message for the channel. The channel is considered closed for a party when it has both sent and received SSH_MSG_CHANNEL_CLOSE, and the party may then reuse the channel number. It is legal to send SSH_MSG_CHANNEL_CLOSE without having sent or received SSH_MSG_EOF. byte SSH_MSG_CHANNEL_CLOSE uint32 recipient_channel This message does not consume window space and can be sent even if no window space is available. It is recommended that any data sent before this message be delivered to the actual destination, if possible. This message should not normally flush buffers. 3.4. Channel-Specific Requests Many channel types have extensions that are specific to that particular channel type. An example is requesting a pty for an interactive session. All channel-specific requests use the following format. byte SSH_MSG_CHANNEL_REQUEST uint32 recipient_channel Tatu Ylonen [page 5] INTERNET-DRAFT July 30, 1997 string request type boolean want_reply ... type-specific data If want_reply is FALSE, no response will be sent to the request. Otherwise, the recipient responds with either SSH_MSG_CHANNEL_SUCCESS or SSH_MSG_CHANNEL_FAILURE, or request-specific continuation messages. If the request is not recognized or is not supported for the channel, SSH_MSG_CHANNEL_FAILURE is returned. This message does not consume window space and can be sent even if no window space is available. Request names are local to each channel type (it is recommended that names with the same extension rules again be used). The client is allowed to send further messages without waiting for the response to the request. byte SSH_MSG_CHANNEL_SUCCESS uint32 recipient_channel byte SSH_MSG_CHANNEL_FAILURE uint32 recipient_channel These messages do not consume window space and can be sent even if no window space is available. 4. Interactive Sessions A session is a remote execution of a command. The command may be a shell, a program, or some built-in subsystem. It may or may not have a tty, and may or may not involve X11 forwarding. Multiple sessions can be active simultaneously. 4.1. Opening a Session A session is started by sending the following message. While this message can be sent by either side, it is normally recommended for clients not to permit opening new sessions to avoid a corrupt server from attacking clients. byte SSH_MSG_CHANNEL_OPEN string "session" uint32 sender_channel uint32 initial_window_size uint32 max_packet_size 4.2. Requesting a Pseudo-Terminal A pseudo-terminal can be allocated for the session by sending the following message. Tatu Ylonen [page 6] INTERNET-DRAFT July 30, 1997 byte SSH_MSG_CHANNEL_REQUEST uint32 recipient_channel string "pty-req" boolean want_reply string TERM environment variable value (e.g., vt100) uint32 terminal width, characters (e.g., 80) uint32 terminal height, rows (e.g., 24) uint32 terminal width, pixels (e.g., 480) uint32 terminal height, pixels (e.g., 640) string encoded terminal modes The encoding of terminal modes is described in Section ``Encoding of Terminal Modes''. 4.3. X11 Forwarding 4.3.1. Requesting X11 Forwarding X11 forwarding may be requested for a session by sending byte SSH_MSG_CHANNEL_REQUEST uint32 recipient_channel string "x11-req" boolean want_reply boolean single_connection string x11_authentication_protocol string x11_authentication_cookie uint32 x11_screen_number It is recommended that the authentication cookie that is sent be a fake, random cookie, and that the cookie is checked and replaced by the real cookie when a connection request is received. X11 connection forwarding should stop when the session channel is closed; however, already opened forwardings should not be automatically closed when the session channel is closed. If single_connection is true, only a single connection should be forwarded. No more connections will be forwarded after the first, or after the session channel has been closed. 4.3.2. X11 Channels Forwarded X11 connections are normal channels, independent of the session that originated them. X11 channels are opened with a normal channel open request. The resulting channels are independent of the session, and closing the session channel does not imply closing forwarded X11 channels. byte SSH_MSG_CHANNEL_OPEN string "x11" uint32 sender_channel uint32 initial_window_size uint32 max_packet_size Tatu Ylonen [page 7] INTERNET-DRAFT July 30, 1997 string originator_string The recipient should respond with open confirmation or open failure. Originator_string is a free-form implementation-dependent description of the X11 client that made the connection. It should typically contain the IP address and port of the client, and may also contain user name or other information if available. It should be in a format that is understandable by a user. 4.4. Authentication Agent Forwarding 4.4.1. Requesting Athentication Agent Forwarding Authentication agent forwarding may be requested for a session by sending byte SSH_MSG_CHANNEL_REQUEST uint32 recipient_channel string "auth-agent-req" boolean want_reply The server responds with either SSH_MSG_CHANNEL_SUCCESS or SSH_MSG_CHANNEL_FAILURE (if want_reply is TRUE). The client is allowed to send futher messages without waiting for the reponse to this message. 4.4.2. Authentication Agent Channels When an application requests a connection to the authentication agent, the following message is sent to the originator of the session. byte SSH_MSG_CHANNEL_OPEN string "auth-agent" uint32 sender_channel uint32 initial_window_size uint32 max_packet_size The recipient should respond with open confirmation or open failure. 4.5. Environment Variable Passing Environment variables may be passed to the shell/command to be started later. Typically, each machine will have a preconfigured set of variables that it will allow. Since uncontrolled setting of environment variables can be very dangerous, it is recommended that implementations allow setting only variables whose names have been explicitly configured to be allowed. byte SSH_MSG_CHANNEL_REQUEST uint32 recipient_channel string "env" boolean want_reply string variable_name string variable_value Tatu Ylonen [page 8] INTERNET-DRAFT July 30, 1997 4.6. Starting Shell or Command Once the session has been set up, a shell or command is started at the remote end. This can happen in any of a number of ways. Only one of these requests can succeed per channel. byte SSH_MSG_CHANNEL_REQUEST uint32 recipient_channel string "shell" boolean want_reply byte SSH_MSG_CHANNEL_REQUEST uint32 recipient_channel string "exec" boolean want_reply string command byte SSH_MSG_CHANNEL_REQUEST uint32 recipient_channel string "subsystem" boolean want_reply string subsystem_name This last form executes a predefined subsystem. It expected that these will include a general file transfer mechanism, and possibly other features. Implementations may also allow configuring more such mechanisms. Having a special message for them avoids the need to have their paths and command names be supplied by the other side. This also makes it easier to implement them in the same executable as the rest of the protocol on platforms where that is desirable. It is strongly recommended to request and check the reply for these messages. 4.7. Session Data Transfer Data transfer for a session is done using SSH_MSG_CHANNEL_DATA and SSH_MSG_CHANNEL_EXTENDED_DATA packets and the window mechanism. The extended data type SSH_EXTENDED_DATA_STDERR has been defined for stderr data. 4.8. Window Change Message When the window (terminal) size changes on the client side (client here means the party who sent the create message for the session), it may send a message to the other side to inform it of the new size. byte SSH_MSG_CHANNEL_REQUEST uint32 recipient_channel string "window-change" boolean FALSE uint32 terminal width, columns uint32 terminal height, rows Tatu Ylonen [page 9] INTERNET-DRAFT July 30, 1997 uint32 terminal width, pixels uint32 terminal height, pixels No response is sent to this message. 4.9. Local Flow Control On many systems it is possible to determine if a pseudo-terminal is using control-S control-Q flow control. When this is the case, it is often desirable to do the flow control at the client end to speed up responses to user requests. This is facilitated by the following two notifications. Initially, the server is responsible for flow control. (Here, again, client means the side originating the session, and server the other side.) The message below is used by the server to inform the client when it can or cannot perform flow control (control-S/control-Q processing). If client_can_do is true, the client is allowed to do flow control using control-S and control-Q. The client is allowed to ignore this message. byte SSH_MSG_CHANNEL_REQUEST uint32 recipient_channel string "xon-xoff" boolean FALSE boolean client_can_do If client_can_do is true, the client (originator) can do control-S control-Q flow control locally. No response is sent to this message. 4.10. Signals A signal can be delivered to the remote process/service using the following message. Some systems may not implement signals, in which case they will ignore this message. byte SSH_MSG_CHANNEL_REQUEST uint32 recipient_channel string "signal" boolean FALSE uint32 signal_number 4.11. Returning Exit Status When the command running at the other end terminates, The following message may be sent to return the exit status of the command. Returning the status is optional, but recommended. No acknowledgement is sent for this message. The channel needs to be closed with SSH_MSG_CHANNEL_CLOSE after this message. byte SSH_MSG_CHANNEL_REQUEST uint32 recipient_channel Tatu Ylonen [page 10] INTERNET-DRAFT July 30, 1997 string "exit-status" string FALSE uint32 exit_status The remote command may also terminate violently due to a signal. Such a condition can be indicated by the following message. byte SSH_MSG_CHANNEL_REQUEST uint32 recipient_channel string "exit-signal" string FALSE uint32 signal number boolean core dumped 5. TCP/IP Port Forwarding 5.1. Requesting Port Forwarding A party need not explicitly request forwardings from its own end to the other direction. However, it if wishes to have connections to a port on the other side be forwarded to the local side, it must explicitly request this. byte SSH_MSG_GLOBAL_REQUEST string "tcpip-forward" boolean want_reply string address_to_bind uint32 port_number_to_bind Address_to_bind and port_number_to_bind specify the IP address and port to which the socket to be listened is bound. The address should be "0.0.0.0" if connections are allowed from anywhere. (Note that the client can still filter connections based on information passed in the open request.) Implementations should only allow forwarding privileged ports if the user has been authenticated as a privileged user. A port forwarding can be cancelled with the following message. Note that channel open requests may be received until a reply to this message is received. byte SSH_MSG_GLOBAL_REQUEST string "cancel-tcpip-forward" boolean want_reply string address_to_bind uint32 port_number_to_bind 5.2. TCP/IP Forwarding Channels When a connection comes to a port for which remote forwarding has been requested, a channel is opened to forward the port to the other side. Tatu Ylonen [page 11] INTERNET-DRAFT July 30, 1997 byte SSH_MSG_CHANNEL_OPEN string "forwarded-tcpip" uint32 sender_channel uint32 initial_window_size uint32 max_packet_size string address_that_was_connected uint32 port_that_was_connected string originator_ip_address uint32 originator_port string originator_string When a connection comes to a locally forwarded TCP/IP port, the following packet is sent to the other side. Note that these messages may be sent also for ports for which no forwarding has been explicitly requested. The receiving side must decide whether to allow the forwarding. byte SSH_MSG_CHANNEL_OPEN string "direct-tcpip" uint32 sender_channel uint32 initial_window_size uint32 max_packet_size string host_to_connect uint32 port_to_connect string originator_ip_address uint32 originator_port string originator_string Host_to_connect and port_to_connect specify the TCP/IP host and port where the recipient should connect the channel. Host_to_connect may be either a domain name or a numeric IP address. Originator_ip_address is the numeric IP address of the machine where the connection request comes from, and originator_port is the port on the originator host from where the connection came from. Originator_string is a free-form description of where the connection came in a form that can be displayed to the user. Forwarded TCP/IP channels are independent of any sessions, and closing a session channel does not in any way imply that forwarded connections should be closed. 6. FTP Forwarding XXX 7. Encoding of Terminal Modes Terminal modes (as passed in a pty request) 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 Tatu Ylonen [page 12] INTERNET-DRAFT July 30, 1997 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 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. 0 TTY_OP_END Indicates end of options. 1 VINTR Interrupt character; 255 if none. Similarly for the other characters. Not all of these characters are supported on all systems. 2 VQUIT The quit character (sends SIGQUIT signal on UNIX systems). 3 VERASE Erase the character to left of the cursor. 4 VKILL Kill the current input line. 5 VEOF End-of-file character (sends EOF from the terminal). 6 VEOL End-of-line character in addition to carriage return and/or linefeed. 7 VEOL2 Additional end-of-line character. 8 VSTART Continues paused output (normally control-Q). 9 VSTOP Pauses output (normally control-S). 10 VSUSP Suspends the current program. Tatu Ylonen [page 13] INTERNET-DRAFT July 30, 1997 11 VDSUSP Another suspend character. 12 VREPRINT Reprints the current input line. 13 VWERASE Erases a word left of cursor. 14 VLNEXT More special input characters; these are probably not supported on most systems. 15 VFLUSH Character to flush output. 16 VSWTCH ??? 17 VSTATUS ??? 18 VDISCARD ??? 30 IGNPAR The ignore parity flag. The next byte should be 0 if this flag is not set, and 1 if it is set. 31 PARMRK Mark parity and framing errors. 32 INPCK Enable checking of parity errors. 33 ISTRIP Strip 8th bit off chars. 34 INLCR Map NL into CR on input. 35 IGNCR Ignore CR on input. 36 ICRNL Map CR to NL on input. 37 IUCLC ??? 38 IXON Enable output flow control. Tatu Ylonen [page 14] INTERNET-DRAFT July 30, 1997 39 IXANY Any char will restart after stop. 40 IXOFF Enable input flow control. 41 IMAXBEL Ring bell on input queue full. 50 ISIG Enable signals INTR, QUIT, DSUSP. 51 ICANON Canonicalize input lines. 52 XCASE ??? 53 ECHO Enable echoing. 54 ECHOE Visually erase chars. 55 ECHOK Kill character discards current line. 56 ECHONL Echo NL even if ECHO is off. 57 NOFLSH Don't flush after interrupt. 58 TOSTOP Stop background jobs from output. 59 IEXTEN Enable extensions. 60 ECHOCTL Echo control characters as ^(Char). 61 ECHOKE Visual erase for line kill. 62 PENDIN Retype pending input. 70 OPOST Enable output processing. 71 OLCUC Convert lowercase to uppercase. Tatu Ylonen [page 15] INTERNET-DRAFT July 30, 1997 72 ONLCR Map NL to CR-NL. 73 OCRNL ??? 74 ONOCR ??? 75 ONLRET ??? 90 CS7 7 bits. 91 CS8 8 bits. 92 PARENB Parity enable. 93 PARODD Odd parity, else even. 128 TTY_OP_ISPEED Specifies the input baud rate in bits per second (as a 32-bit int, msb first). 129 TTY_OP_OSPEED Specifies the output baud rate in bits per second (as a 32-bt int, msb first). 8. Summary of Message Numbers #define SSH_MSG_GLOBAL_REQUEST 30 #define SSH_MSG_REQUEST_SUCCESS 31 #define SSH_MSG_REQUEST_FAILURE 32 #define SSH_MSG_CHANNEL_OPEN 33 #define SSH_MSG_CHANNEL_OPEN_CONFIRMATION 34 #define SSH_MSG_CHANNEL_OPEN_FAILURE 35 #define SSH_MSG_CHANNEL_WINDOW_ADJUST 36 #define SSH_MSG_CHANNEL_DATA 37 #define SSH_MSG_CHANNEL_EXTENDED_DATA 38 #define SSH_MSG_CHANNEL_EOF 39 #define SSH_MSG_CHANNEL_CLOSE 40 #define SSH_MSG_CHANNEL_REQUEST 41 #define SSH_MSG_CHANNEL_SUCCESS 42 #define SSH_MSG_CHANNEL_FAILURE 43 9. Security Considerations This protocol is assumed to run on top of a secure, authenticated protocol. User authentication and protection against network-level Tatu Ylonen [page 16] INTERNET-DRAFT July 30, 1997 attacks are assumed to be provided by the underlying protocol. This protocol can, however, be used to execute commands on remote machines. The protocol also permits the server to run commands on the client. Implementations may wish to disallow this to prevent an attacker from coming from the server machine to the client machine. X11 forwarding provides major security improvements over normal cookie- based X11 forwarding. The cookie never needs to be transmitted in the clear, and traffic is encrypted and integrity-protected. No useful authentication data will remain on the server machine after the connection has been closed. On the other hand, in some situations a forwarded X11 connection might be used to get access to the local X server across security perimeters. Port forwardings can potentially allow an intruder to cross security perimeters such as firewalls. They do not offer anything fundamentally new that a user couldn't do otherwise; however, they make opening tunnels very easy. Implementations should allow policy control over what can be forwarded. Administrators should be able to deny forwardings where appropriate. Since this protocol normally runs inside an encrypted tunnel, firewalls will not be able to examine the traffic. 10. Address of Author Tatu Ylonen SSH Communications Security Ltd. Tekniikantie 12 FIN-02150 ESPOO Finland E-mail: ylo@ssh.fi Tatu Ylonen [page 17]