idnits 2.17.1 draft-ietf-secsh-connect-17.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Introduction' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 8. Security Considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 7 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 196: '...URE. The client MAY show the addition...' RFC 2119 keyword, line 217: '...sage, the recipient MAY send the given...' RFC 2119 keyword, line 229: '... parties MAY ignore all extra dat...' RFC 2119 keyword, line 253: '...send more data to a channel, it SHOULD...' RFC 2119 keyword, line 267: '...n receiving this message, a party MUST...' (28 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 112 has weird spacing: '... string req...' == Line 113 has weird spacing: '...boolean want...' == Line 157 has weird spacing: '... string cha...' == Line 191 has weird spacing: '... string add...' == Line 192 has weird spacing: '... string lan...' == (33 more instances...) == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: The server SHOULD not halt the execution of the protocol stack when starting a shell or a program. All input and output from these SHOULD be redirected to the channel or to the encrypted tunnel. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 14, 2003) is 7592 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'SSH-ARCH' on line 891 looks like a reference -- Missing reference section? 'RFC2279' on line 878 looks like a reference -- Missing reference section? 'RFC1766' on line 872 looks like a reference -- Missing reference section? 'SCHEIFLER' on line 881 looks like a reference -- Missing reference section? 'POSIX' on line 886 looks like a reference -- Missing reference section? 'RFC1884' on line 875 looks like a reference -- Missing reference section? 'SSH-TRANS' on line 894 looks like a reference -- Missing reference section? 'SSH-USERAUTH' on line 897 looks like a reference -- Missing reference section? 'SSH-CONNECT' on line 900 looks like a reference -- Missing reference section? 'SSH-NUMBERS' on line 903 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 9 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Ylonen 3 Internet-Draft T. Kivinen 4 Expires: January 12, 2004 SSH Communications Security Corp 5 M. Saarinen 6 University of Jyvaskyla 7 T. Rinne 8 S. Lehtinen 9 SSH Communications Security Corp 10 July 14, 2003 12 SSH Connection Protocol 13 draft-ietf-secsh-connect-17.txt 15 Status of this Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or obsoleted by other 27 documents at any time. It is inappropriate to use Internet-Drafts 28 as reference material or to cite them other than as "work in 29 progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on January 12, 2004. 39 Copyright Notice 41 Copyright (C) The Internet Society (2003). All Rights Reserved. 43 Abstract 45 SSH is a protocol for secure remote login and other secure network 46 services over an insecure network. 48 This document describes the SSH Connection Protocol. It provides 49 interactive login sessions, remote execution of commands, 50 forwarded TCP/IP connections, and forwarded X11 connections. All 51 of these channels are multiplexed into a single encrypted tunnel. 53 The SSH Connection Protocol has been designed to run on top of the 54 SSH transport layer and user authentication protocols. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Global Requests . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Channel Mechanism . . . . . . . . . . . . . . . . . . . . . 3 61 3.1 Opening a Channel . . . . . . . . . . . . . . . . . . . . . 4 62 3.2 Data Transfer . . . . . . . . . . . . . . . . . . . . . . . 5 63 3.3 Closing a Channel . . . . . . . . . . . . . . . . . . . . . 6 64 3.4 Channel-Specific Requests . . . . . . . . . . . . . . . . . 7 65 4. Interactive Sessions . . . . . . . . . . . . . . . . . . . . 8 66 4.1 Opening a Session . . . . . . . . . . . . . . . . . . . . . 8 67 4.2 Requesting a Pseudo-Terminal . . . . . . . . . . . . . . . . 8 68 4.3 X11 Forwarding . . . . . . . . . . . . . . . . . . . . . . . 9 69 4.3.1 Requesting X11 Forwarding . . . . . . . . . . . . . . . . . 9 70 4.3.2 X11 Channels . . . . . . . . . . . . . . . . . . . . . . . . 9 71 4.4 Environment Variable Passing . . . . . . . . . . . . . . . . 10 72 4.5 Starting a Shell or a Command . . . . . . . . . . . . . . . 10 73 4.6 Session Data Transfer . . . . . . . . . . . . . . . . . . . 11 74 4.7 Window Dimension Change Message . . . . . . . . . . . . . . 11 75 4.8 Local Flow Control . . . . . . . . . . . . . . . . . . . . . 12 76 4.9 Signals . . . . . . . . . . . . . . . . . . . . . . . . . . 12 77 4.10 Returning Exit Status . . . . . . . . . . . . . . . . . . . 12 78 5. TCP/IP Port Forwarding . . . . . . . . . . . . . . . . . . . 14 79 5.1 Requesting Port Forwarding . . . . . . . . . . . . . . . . . 14 80 5.2 TCP/IP Forwarding Channels . . . . . . . . . . . . . . . . . 15 81 6. Encoding of Terminal Modes . . . . . . . . . . . . . . . . . 16 82 7. Summary of Message Numbers . . . . . . . . . . . . . . . . . 18 83 8. Security Considerations . . . . . . . . . . . . . . . . . . 18 84 9. Intellectual Property . . . . . . . . . . . . . . . . . . . 18 85 10. Additional Information . . . . . . . . . . . . . . . . . . . 19 86 References . . . . . . . . . . . . . . . . . . . . . . . . . 19 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 20 88 Full Copyright Statement . . . . . . . . . . . . . . . . . . 22 90 1. Introduction 92 The SSH Connection Protocol has been designed to run on top of the 93 SSH transport layer and user authentication protocols. It 94 provides interactive login sessions, remote execution of commands, 95 forwarded TCP/IP connections, and forwarded X11 connections. The 96 service name for this protocol (after user authentication) is 97 "ssh-connection". 99 This document should be read only after reading the SSH 100 architecture document [SSH-ARCH]. This document freely uses 101 terminology and notation from the architecture document without 102 reference or further explanation. 104 2. Global Requests 106 There are several kinds of requests that affect the state of the 107 remote end "globally", independent of any channels. An example is 108 a request to start TCP/IP forwarding for a specific port. All 109 such requests use the following format. 111 byte SSH_MSG_GLOBAL_REQUEST 112 string request name (restricted to US-ASCII) 113 boolean want reply 114 ... request-specific data follows 116 Request names follow the DNS extensibility naming convention 117 outlined in [SSH-ARCH]. 119 The recipient will respond to this message with 120 SSH_MSG_REQUEST_SUCCESS or SSH_MSG_REQUEST_FAILURE if `want reply' 121 is TRUE. 123 byte SSH_MSG_REQUEST_SUCCESS 124 ..... response specific data 126 Usually the response specific data is non-existent. 128 If the recipient does not recognize or support the request, it 129 simply responds with SSH_MSG_REQUEST_FAILURE. 131 byte SSH_MSG_REQUEST_FAILURE 133 3. Channel Mechanism 135 All terminal sessions, forwarded connections, etc. are channels. 136 Either side may open a channel. Multiple channels are multiplexed 137 into a single connection. 139 Channels are identified by numbers at each end. The number 140 referring to a channel may be different on each side. Requests to 141 open a channel contain the sender's channel number. Any other 142 channel-related messages contain the recipient's channel number 143 for the channel. 145 Channels are flow-controlled. No data may be sent to a channel 146 until a message is received to indicate that window space is 147 available. 149 3.1 Opening a Channel 151 When either side wishes to open a new channel, it allocates a 152 local number for the channel. It then sends the following message 153 to the other side, and includes the local channel number and 154 initial window size in the message. 156 byte SSH_MSG_CHANNEL_OPEN 157 string channel type (restricted to US-ASCII) 158 uint32 sender channel 159 uint32 initial window size 160 uint32 maximum packet size 161 ... channel type specific data follows 163 The channel type is a name as described in the SSH architecture 164 document, with similar extension mechanisms. `sender channel' is 165 a local identifier for the channel used by the sender of this 166 message. `initial window size' specifies how many bytes of 167 channel data can be sent to the sender of this message without 168 adjusting the window. `Maximum packet size' specifies the maximum 169 size of an individual data packet that can be sent to the sender 170 (for example, one might want to use smaller packets for 171 interactive connections to get better interactive response on slow 172 links). 174 The remote side then decides whether it can open the channel, and 175 responds with either 177 byte SSH_MSG_CHANNEL_OPEN_CONFIRMATION 178 uint32 recipient channel 179 uint32 sender channel 180 uint32 initial window size 181 uint32 maximum packet size 182 ... channel type specific data follows 184 where `recipient channel' is the channel number given in the 185 original open request, and `sender channel' is the channel number 186 allocated by the other side, or 188 byte SSH_MSG_CHANNEL_OPEN_FAILURE 189 uint32 recipient channel 190 uint32 reason code 191 string additional textual information (ISO-10646 UTF-8 [RFC2279]) 192 string language tag (as defined in [RFC1766]) 194 If the recipient of the SSH_MSG_CHANNEL_OPEN message does not 195 support the specified channel type, it simply responds with 196 SSH_MSG_CHANNEL_OPEN_FAILURE. The client MAY show the additional 197 information to the user. If this is done, the client software 198 should take the precautions discussed in [SSH-ARCH]. 200 The following reason codes are defined: 202 #define SSH_OPEN_ADMINISTRATIVELY_PROHIBITED 1 203 #define SSH_OPEN_CONNECT_FAILED 2 204 #define SSH_OPEN_UNKNOWN_CHANNEL_TYPE 3 205 #define SSH_OPEN_RESOURCE_SHORTAGE 4 207 3.2 Data Transfer 209 The window size specifies how many bytes the other party can send 210 before it must wait for the window to be adjusted. Both parties 211 use the following message to adjust the window. 213 byte SSH_MSG_CHANNEL_WINDOW_ADJUST 214 uint32 recipient channel 215 uint32 bytes to add 217 After receiving this message, the recipient MAY send the given 218 number of bytes more than it was previously allowed to send; the 219 window size is incremented. 221 Data transfer is done with messages of the following type. 223 byte SSH_MSG_CHANNEL_DATA 224 uint32 recipient channel 225 string data 227 The maximum amount of data allowed is the current window size. 228 The window size is decremented by the amount of data sent. Both 229 parties MAY ignore all extra data sent after the allowed window is 230 empty. 232 Additionally, some channels can transfer several types of data. 233 An example of this is stderr data from interactive sessions. Such 234 data can be passed with SSH_MSG_CHANNEL_EXTENDED_DATA messages, 235 where a separate integer specifies the type of the data. The 236 available types and their interpretation depend on the type of the 237 channel. 239 byte SSH_MSG_CHANNEL_EXTENDED_DATA 240 uint32 recipient_channel 241 uint32 data_type_code 242 string data 244 Data sent with these messages consumes the same window as ordinary 245 data. 247 Currently, only the following type is defined. 249 #define SSH_EXTENDED_DATA_STDERR 1 251 3.3 Closing a Channel 253 When a party will no longer send more data to a channel, it SHOULD 254 send SSH_MSG_CHANNEL_EOF. 256 byte SSH_MSG_CHANNEL_EOF 257 uint32 recipient_channel 259 No explicit response is sent to this message; however, the 260 application may send EOF to whatever is at the other end of the 261 channel. Note that the channel remains open after this message, 262 and more data may still be sent in the other direction. This 263 message does not consume window space and can be sent even if no 264 window space is available. 266 When either party wishes to terminate the channel, it sends 267 SSH_MSG_CHANNEL_CLOSE. Upon receiving this message, a party MUST 268 send back a SSH_MSG_CHANNEL_CLOSE unless it has already sent this 269 message for the channel. The channel is considered closed for a 270 party when it has both sent and received SSH_MSG_CHANNEL_CLOSE, 271 and the party may then reuse the channel number. A party MAY send 272 SSH_MSG_CHANNEL_CLOSE without having sent or received 273 SSH_MSG_CHANNEL_EOF. 275 byte SSH_MSG_CHANNEL_CLOSE 276 uint32 recipient_channel 278 This message does not consume window space and can be sent even if 279 no window space is available. 281 It is recommended that any data sent before this message is 282 delivered to the actual destination, if possible. 284 3.4 Channel-Specific Requests 286 Many channel types have extensions that are specific to that 287 particular channel type. An example is requesting a pty (pseudo 288 terminal) for an interactive session. 290 All channel-specific requests use the following format. 292 byte SSH_MSG_CHANNEL_REQUEST 293 uint32 recipient channel 294 string request type (restricted to US-ASCII) 295 boolean want reply 296 ... type-specific data 298 If want reply is FALSE, no response will be sent to the request. 299 Otherwise, the recipient responds with either 300 SSH_MSG_CHANNEL_SUCCESS or SSH_MSG_CHANNEL_FAILURE, or request- 301 specific continuation messages. If the request is not recognized 302 or is not supported for the channel, SSH_MSG_CHANNEL_FAILURE is 303 returned. 305 This message does not consume window space and can be sent even if 306 no window space is available. Request types are local to each 307 channel type. 309 The client is allowed to send further messages without waiting for 310 the response to the request. 312 request type names follow the DNS extensibility naming convention 313 outlined in [SSH-ARCH] 315 byte SSH_MSG_CHANNEL_SUCCESS 316 uint32 recipient_channel 318 byte SSH_MSG_CHANNEL_FAILURE 319 uint32 recipient_channel 321 These messages do not consume window space and can be sent even if 322 no window space is available. 324 4. Interactive Sessions 326 A session is a remote execution of a program. The program may be 327 a shell, an application, a system command, or some built-in 328 subsystem. It may or may not have a tty, and may or may not 329 involve X11 forwarding. Multiple sessions can be active 330 simultaneously. 332 4.1 Opening a Session 334 A session is started by sending the following message. 336 byte SSH_MSG_CHANNEL_OPEN 337 string "session" 338 uint32 sender channel 339 uint32 initial window size 340 uint32 maximum packet size 342 Client implementations SHOULD reject any session channel open 343 requests to make it more difficult for a corrupt server to attack 344 the client. 346 4.2 Requesting a Pseudo-Terminal 348 A pseudo-terminal can be allocated for the session by sending the 349 following message. 351 byte SSH_MSG_CHANNEL_REQUEST 352 uint32 recipient_channel 353 string "pty-req" 354 boolean want_reply 355 string TERM environment variable value (e.g., vt100) 356 uint32 terminal width, characters (e.g., 80) 357 uint32 terminal height, rows (e.g., 24) 358 uint32 terminal width, pixels (e.g., 640) 359 uint32 terminal height, pixels (e.g., 480) 360 string encoded terminal modes 362 The encoding of terminal modes is described in Section Encoding of 363 Terminal Modes (Section 6). Zero dimension parameters MUST be 364 ignored. The character/row dimensions override the pixel 365 dimensions (when nonzero). Pixel dimensions refer to the drawable 366 area of the window. 368 The dimension parameters are only informational. 370 The client SHOULD ignore pty requests. 372 4.3 X11 Forwarding 374 4.3.1 Requesting X11 Forwarding 376 X11 forwarding may be requested for a session by sending 378 byte SSH_MSG_CHANNEL_REQUEST 379 uint32 recipient channel 380 string "x11-req" 381 boolean want reply 382 boolean single connection 383 string x11 authentication protocol 384 string x11 authentication cookie 385 uint32 x11 screen number 387 It is recommended that the authentication cookie that is sent be a 388 fake, random cookie, and that the cookie is checked and replaced 389 by the real cookie when a connection request is received. 391 X11 connection forwarding should stop when the session channel is 392 closed; however, already opened forwardings should not be 393 automatically closed when the session channel is closed. 395 If `single connection' is TRUE, only a single connection should be 396 forwarded. No more connections will be forwarded after the first, 397 or after the session channel has been closed. 399 The `x11 authentication protocol' is the name of the X11 400 authentication method used, e.g. "MIT-MAGIC-COOKIE-1". 402 The x11 authentication cookie MUST be hexadecimal encoded. 404 X Protocol is documented in [SCHEIFLER]. 406 4.3.2 X11 Channels 408 X11 channels are opened with a channel open request. The 409 resulting channels are independent of the session, and closing the 410 session channel does not close the forwarded X11 channels. 412 byte SSH_MSG_CHANNEL_OPEN 413 string "x11" 414 uint32 sender channel 415 uint32 initial window size 416 uint32 maximum packet size 417 string originator address (e.g. "192.168.7.38") 418 uint32 originator port 419 The recipient should respond with 420 SSH_MSG_CHANNEL_OPEN_CONFIRMATION or SSH_MSG_CHANNEL_OPEN_FAILURE. 422 Implementations MUST reject any X11 channel open requests if they 423 have not requested X11 forwarding. 425 4.4 Environment Variable Passing 427 Environment variables may be passed to the shell/command to be 428 started later. Uncontrolled setting of environment variables in a 429 privileged process can be a security hazard. It is recommended 430 that implementations either maintain a list of allowable variable 431 names or only set environment variables after the server process 432 has dropped sufficient privileges. 434 byte SSH_MSG_CHANNEL_REQUEST 435 uint32 recipient channel 436 string "env" 437 boolean want reply 438 string variable name 439 string variable value 441 4.5 Starting a Shell or a Command 443 Once the session has been set up, a program is started at the 444 remote end. The program can be a shell, an application program or 445 a subsystem with a host-independent name. Only one of these 446 requests can succeed per channel. 448 byte SSH_MSG_CHANNEL_REQUEST 449 uint32 recipient channel 450 string "shell" 451 boolean want reply 453 This message will request the user's default shell (typically 454 defined in /etc/passwd in UNIX systems) to be started at the other 455 end. 457 byte SSH_MSG_CHANNEL_REQUEST 458 uint32 recipient channel 459 string "exec" 460 boolean want reply 461 string command 463 This message will request the server to start the execution of the 464 given command. The command string may contain a path. Normal 465 precautions MUST be taken to prevent the execution of unauthorized 466 commands. 468 byte SSH_MSG_CHANNEL_REQUEST 469 uint32 recipient channel 470 string "subsystem" 471 boolean want reply 472 string subsystem name 474 This last form executes a predefined subsystem. It is expected 475 that these will include a general file transfer mechanism, and 476 possibly other features. Implementations may also allow 477 configuring more such mechanisms. As the user's shell is usually 478 used to execute the subsystem, it is advisable for the subsystem 479 protocol to have a "magic cookie" at the beginning of the protocol 480 transaction to distinguish it from arbitrary output generated by 481 shell initialization scripts etc. This spurious output from the 482 shell may be filtered out either at the server or at the client. 484 The server SHOULD not halt the execution of the protocol stack 485 when starting a shell or a program. All input and output from 486 these SHOULD be redirected to the channel or to the encrypted 487 tunnel. 489 It is RECOMMENDED to request and check the reply for these 490 messages. The client SHOULD ignore these messages. 492 Subsystem names follow the DNS extensibility naming convention 493 outlined in [SSH-ARCH]. 495 4.6 Session Data Transfer 497 Data transfer for a session is done using SSH_MSG_CHANNEL_DATA and 498 SSH_MSG_CHANNEL_EXTENDED_DATA packets and the window mechanism. 499 The extended data type SSH_EXTENDED_DATA_STDERR has been defined 500 for stderr data. 502 4.7 Window Dimension Change Message 504 When the window (terminal) size changes on the client side, it MAY 505 send a message to the other side to inform it of the new 506 dimensions. 508 byte SSH_MSG_CHANNEL_REQUEST 509 uint32 recipient_channel 510 string "window-change" 511 boolean FALSE 512 uint32 terminal width, columns 513 uint32 terminal height, rows 514 uint32 terminal width, pixels 515 uint32 terminal height, pixels 517 No response SHOULD be sent to this message. 519 4.8 Local Flow Control 521 On many systems, it is possible to determine if a pseudo-terminal 522 is using control-S/control-Q flow control. When flow control is 523 allowed, it is often desirable to do the flow control at the 524 client end to speed up responses to user requests. This is 525 facilitated by the following notification. Initially, the server 526 is responsible for flow control. (Here, again, client means the 527 side originating the session, and server means the other side.) 529 The message below is used by the server to inform the client when 530 it can or cannot perform flow control (control-S/control-Q 531 processing). If `client can do' is TRUE, the client is allowed to 532 do flow control using control-S and control-Q. The client MAY 533 ignore this message. 535 byte SSH_MSG_CHANNEL_REQUEST 536 uint32 recipient channel 537 string "xon-xoff" 538 boolean FALSE 539 boolean client can do 541 No response is sent to this message. 543 4.9 Signals 545 A signal can be delivered to the remote process/service using the 546 following message. Some systems may not implement signals, in 547 which case they SHOULD ignore this message. 549 byte SSH_MSG_CHANNEL_REQUEST 550 uint32 recipient channel 551 string "signal" 552 boolean FALSE 553 string signal name without the "SIG" prefix. 555 Signal names will be encoded as discussed in the "exit-signal" 556 SSH_MSG_CHANNEL_REQUEST. 558 4.10 Returning Exit Status 560 When the command running at the other end terminates, the 561 following message can be sent to return the exit status of the 562 command. Returning the status is RECOMMENDED. No acknowledgment 563 is sent for this message. The channel needs to be closed with 564 SSH_MSG_CHANNEL_CLOSE after this message. 566 The client MAY ignore these messages. 568 byte SSH_MSG_CHANNEL_REQUEST 569 uint32 recipient_channel 570 string "exit-status" 571 boolean FALSE 572 uint32 exit_status 574 The remote command may also terminate violently due to a signal. 575 Such a condition can be indicated by the following message. A 576 zero exit_status usually means that the command terminated 577 successfully. 579 byte SSH_MSG_CHANNEL_REQUEST 580 uint32 recipient channel 581 string "exit-signal" 582 boolean FALSE 583 string signal name without the "SIG" prefix. 584 boolean core dumped 585 string error message (ISO-10646 UTF-8) 586 string language tag (as defined in [RFC1766]) 588 The signal name is one of the following (these are from [POSIX]) 590 ABRT 591 ALRM 592 FPE 593 HUP 594 ILL 595 INT 596 KILL 597 PIPE 598 QUIT 599 SEGV 600 TERM 601 USR1 602 USR2 604 Additional signal names MAY be sent in the format "sig-name@xyz", 605 where `sig-name' and `xyz' may be anything a particular 606 implementor wants (except the `@' sign). However, it is suggested 607 that if a `configure' script is used, the non-standard signal 608 names it finds be encoded as "SIG@xyz.config.guess", where `SIG' 609 is the signal name without the "SIG" prefix, and `xyz' be the host 610 type, as determined by `config.guess'. 612 The `error message' contains an additional explanation of the 613 error message. The message may consist of multiple lines. The 614 client software MAY display this message to the user. If this is 615 done, the client software should take the precautions discussed in 616 [SSH-ARCH]. 618 5. TCP/IP Port Forwarding 620 5.1 Requesting Port Forwarding 622 A party need not explicitly request forwardings from its own end 623 to the other direction. However, if it wishes that connections to 624 a port on the other side be forwarded to the local side, it must 625 explicitly request this. 627 byte SSH_MSG_GLOBAL_REQUEST 628 string "tcpip-forward" 629 boolean want reply 630 string address to bind (e.g. "0.0.0.0") 631 uint32 port number to bind 633 `Address to bind' and `port number to bind' specify the IP address 634 and port to which the socket to be listened is bound. The address 635 should be "0.0.0.0" if connections are allowed from anywhere. 636 (Note that the client can still filter connections based on 637 information passed in the open request.) 639 Implementations should only allow forwarding privileged ports if 640 the user has been authenticated as a privileged user. 642 Client implementations SHOULD reject these messages; they are 643 normally only sent by the client. 645 If a client passes 0 as port number to bind and has want reply 646 TRUE then the server allocates the next available unprivileged 647 port number and replies with the following message, otherwise 648 there is no response specific data. 650 byte SSH_MSG_GLOBAL_REQUEST_SUCCESS 651 uint32 port that was bound on the server 653 A port forwarding can be cancelled with the following message. 654 Note that channel open requests may be received until a reply to 655 this message is received. 657 byte SSH_MSG_GLOBAL_REQUEST 658 string "cancel-tcpip-forward" 659 boolean want reply 660 string address_to_bind (e.g. "127.0.0.1") 661 uint32 port number to bind 663 Client implementations SHOULD reject these messages; they are 664 normally only sent by the client. 666 5.2 TCP/IP Forwarding Channels 668 When a connection comes to a port for which remote forwarding has 669 been requested, a channel is opened to forward the port to the 670 other side. 672 byte SSH_MSG_CHANNEL_OPEN 673 string "forwarded-tcpip" 674 uint32 sender channel 675 uint32 initial window size 676 uint32 maximum packet size 677 string address that was connected 678 uint32 port that was connected 679 string originator IP address 680 uint32 originator port 682 Implementations MUST reject these messages unless they have 683 previously requested a remote TCP/IP port forwarding with the 684 given port number. 686 When a connection comes to a locally forwarded TCP/IP port, the 687 following packet is sent to the other side. Note that these 688 messages MAY be sent also for ports for which no forwarding has 689 been explicitly requested. The receiving side must decide whether 690 to allow the forwarding. 692 byte SSH_MSG_CHANNEL_OPEN 693 string "direct-tcpip" 694 uint32 sender channel 695 uint32 initial window size 696 uint32 maximum packet size 697 string host to connect 698 uint32 port to connect 699 string originator IP address 700 uint32 originator port 702 `Host to connect' and `port to connect' specify the TCP/IP host 703 and port where the recipient should connect the channel. `Host to 704 connect' may be either a domain name or a numeric IP address. 706 `Originator IP address' is the numeric IP address of the machine 707 where the connection request comes from, and `originator port' is 708 the port on the originator host from where the connection came 709 from. 711 Forwarded TCP/IP channels are independent of any sessions, and 712 closing a session channel does not in any way imply that forwarded 713 connections should be closed. 715 Client implementations SHOULD reject direct TCP/IP open requests 716 for security reasons. 718 6. Encoding of Terminal Modes 720 Terminal modes (as passed in a pty request) are encoded into a 721 byte stream. It is intended that the coding be portable across 722 different environments. 724 The tty mode description is a stream of bytes. The stream 725 consists of opcode-argument pairs. It is terminated by opcode 726 TTY_OP_END (0). Opcodes 1 to 159 have a single uint32 argument. 727 Opcodes 160 to 255 are not yet defined, and cause parsing to stop 728 (they should only be used after any other data). 730 The client SHOULD put in the stream any modes it knows about, and 731 the server MAY ignore any modes it does not know about. This 732 allows some degree of machine-independence, at least between 733 systems that use a POSIX-like tty interface. The protocol can 734 support other systems as well, but the client may need to fill 735 reasonable values for a number of parameters so the server pty 736 gets set to a reasonable mode (the server leaves all unspecified 737 mode bits in their default values, and only some combinations make 738 sense). 740 The following opcodes have been defined. The naming of opcodes 741 mostly follows the POSIX terminal mode flags. 743 0 TTY_OP_END Indicates end of options. 744 1 VINTR Interrupt character; 255 if none. Similarly for the 745 other characters. Not all of these characters are 746 supported on all systems. 747 2 VQUIT The quit character (sends SIGQUIT signal on POSIX 748 systems). 749 3 VERASE Erase the character to left of the cursor. 750 4 VKILL Kill the current input line. 752 5 VEOF End-of-file character (sends EOF from the terminal). 753 6 VEOL End-of-line character in addition to carriage return 754 and/or linefeed. 755 7 VEOL2 Additional end-of-line character. 756 8 VSTART Continues paused output (normally control-Q). 757 9 VSTOP Pauses output (normally control-S). 758 10 VSUSP Suspends the current program. 759 11 VDSUSP Another suspend character. 760 12 VREPRINT Reprints the current input line. 761 13 VWERASE Erases a word left of cursor. 762 14 VLNEXT Enter the next character typed literally, even if it 763 is a special character 764 15 VFLUSH Character to flush output. 765 16 VSWTCH Switch to a different shell layer. 766 17 VSTATUS Prints system status line (load, command, pid etc). 767 18 VDISCARD Toggles the flushing of terminal output. 768 30 IGNPAR The ignore parity flag. The parameter SHOULD be 0 if 769 this flag is FALSE set, and 1 if it is TRUE. 770 31 PARMRK Mark parity and framing errors. 771 32 INPCK Enable checking of parity errors. 772 33 ISTRIP Strip 8th bit off characters. 773 34 INLCR Map NL into CR on input. 774 35 IGNCR Ignore CR on input. 775 36 ICRNL Map CR to NL on input. 776 37 IUCLC Translate uppercase characters to lowercase. 777 38 IXON Enable output flow control. 778 39 IXANY Any char will restart after stop. 779 40 IXOFF Enable input flow control. 780 41 IMAXBEL Ring bell on input queue full. 781 50 ISIG Enable signals INTR, QUIT, [D]SUSP. 782 51 ICANON Canonicalize input lines. 783 52 XCASE Enable input and output of uppercase characters by 784 preceding their lowercase equivalents with `\'. 785 53 ECHO Enable echoing. 786 54 ECHOE Visually erase chars. 787 55 ECHOK Kill character discards current line. 788 56 ECHONL Echo NL even if ECHO is off. 789 57 NOFLSH Don't flush after interrupt. 790 58 TOSTOP Stop background jobs from output. 791 59 IEXTEN Enable extensions. 792 60 ECHOCTL Echo control characters as ^(Char). 793 61 ECHOKE Visual erase for line kill. 794 62 PENDIN Retype pending input. 795 70 OPOST Enable output processing. 796 71 OLCUC Convert lowercase to uppercase. 797 72 ONLCR Map NL to CR-NL. 798 73 OCRNL Translate carriage return to newline (output). 799 74 ONOCR Translate newline to carriage return-newline 800 (output). 801 75 ONLRET Newline performs a carriage return (output). 802 90 CS7 7 bit mode. 803 91 CS8 8 bit mode. 804 92 PARENB Parity enable. 805 93 PARODD Odd parity, else even. 807 128 TTY_OP_ISPEED Specifies the input baud rate in bits per second. 808 129 TTY_OP_OSPEED Specifies the output baud rate in bits per second. 810 7. Summary of Message Numbers 812 #define SSH_MSG_GLOBAL_REQUEST 80 813 #define SSH_MSG_REQUEST_SUCCESS 81 814 #define SSH_MSG_REQUEST_FAILURE 82 815 #define SSH_MSG_CHANNEL_OPEN 90 816 #define SSH_MSG_CHANNEL_OPEN_CONFIRMATION 91 817 #define SSH_MSG_CHANNEL_OPEN_FAILURE 92 818 #define SSH_MSG_CHANNEL_WINDOW_ADJUST 93 819 #define SSH_MSG_CHANNEL_DATA 94 820 #define SSH_MSG_CHANNEL_EXTENDED_DATA 95 821 #define SSH_MSG_CHANNEL_EOF 96 822 #define SSH_MSG_CHANNEL_CLOSE 97 823 #define SSH_MSG_CHANNEL_REQUEST 98 824 #define SSH_MSG_CHANNEL_SUCCESS 99 825 #define SSH_MSG_CHANNEL_FAILURE 100 827 8. Security Considerations 829 This protocol is assumed to run on top of a secure, authenticated 830 transport. User authentication and protection against network- 831 level attacks are assumed to be provided by the underlying 832 protocols. 834 It is RECOMMENDED that implementations disable all the potentially 835 dangerous features (e.g. agent forwarding, X11 forwarding, and 836 TCP/IP forwarding) if the host key has changed. 838 Full security considerations for this protocol are provided in 839 Section 8 of [SSH-ARCH] 841 9. Intellectual Property 843 The IETF takes no position regarding the validity or scope of any 844 intellectual property or other rights that might be claimed to 845 pertain to the implementation or use of the technology described 846 in this document or the extent to which any license under such 847 rights might or might not be available; neither does it represent 848 that it has made any effort to identify any such rights. 849 Information on the IETF's procedures with respect to rights in 850 standards-track and standards-related documentation can be found 851 in BCP-11. Copies of claims of rights made available for 852 publication and any assurances of licenses to be made available, 853 or the result of an attempt made to obtain a general license or 854 permission for the use of such proprietary rights by implementers 855 or users of this specification can be obtained from the IETF 856 Secretariat. 858 The IETF has been notified of intellectual property rights claimed 859 in regard to some or all of the specification contained in this 860 document. For more information consult the online list of claimed 861 rights. 863 10. Additional Information 865 The current document editor is: Darren.Moffat@Sun.COM. Comments 866 on this internet draft should be sent to the IETF SECSH working 867 group, details at: http://ietf.org/html.charters/secsh- 868 charter.html 870 References 872 [RFC1766] Alvestrand, H., "Tags for the Identification of 873 Languages", RFC 1766, March 1995. 875 [RFC1884] Hinden, R., Deering, S. and Editors, "IP Version 6 876 Addressing Architecture", RFC 1884, December 1995. 878 [RFC2279] Yergeau, F., "UTF-8, a transformation format of 879 ISO 10646", RFC 2279, January 1998. 881 [SCHEIFLER] Scheifler, R., "X Window System : The Complete 882 Reference to Xlib, X Protocol, Icccm, Xlfd, 3rd 883 edition.", Digital Press ISBN 1555580882, Feburary 884 1992. 886 [POSIX] ISO/IEC, 9945-1., "Information technology -- 887 Portable Operating System Interface (POSIX)-Part 888 1: System Application Program Interface (API) C 889 Language", ANSI/IEE Std 1003.1, July 1996. 891 [SSH-ARCH] Ylonen, T., "SSH Protocol Architecture", I-D 892 draft-ietf-architecture-14.txt, July 2003. 894 [SSH-TRANS] Ylonen, T., "SSH Transport Layer Protocol", I-D 895 draft-ietf-transport-16.txt, July 2003. 897 [SSH-USERAUTH] Ylonen, T., "SSH Authentication Protocol", I-D 898 draft-ietf-userauth-17.txt, July 2003. 900 [SSH-CONNECT] Ylonen, T., "SSH Connection Protocol", I-D draft- 901 ietf-connect-17.txt, July 2003. 903 [SSH-NUMBERS] Lehtinen, S. and D. Moffat, "SSH Protocol Assigned 904 Numbers", I-D draft-ietf-secsh-assignednumbers- 905 03.txt, July 2003. 907 Authors' Addresses 909 Tatu Ylonen 910 SSH Communications Security Corp 911 Fredrikinkatu 42 912 HELSINKI FIN-00100 913 Finland 915 EMail: ylo@ssh.com 917 Tero Kivinen 918 SSH Communications Security Corp 919 Fredrikinkatu 42 920 HELSINKI FIN-00100 921 Finland 923 EMail: kivinen@ssh.com 925 Markku-Juhani O. Saarinen 926 University of Jyvaskyla 928 Timo J. Rinne 929 SSH Communications Security Corp 930 Fredrikinkatu 42 931 HELSINKI FIN-00100 932 Finland 934 EMail: tri@ssh.com 935 Sami Lehtinen 936 SSH Communications Security Corp 937 Fredrikinkatu 42 938 HELSINKI FIN-00100 939 Finland 941 EMail: sjl@ssh.com 943 Full Copyright Statement 945 Copyright (C) The Internet Society (2003). All Rights Reserved. 947 This document and translations of it may be copied and furnished 948 to others, and derivative works that comment on or otherwise 949 explain it or assist in its implementation may be prepared, 950 copied, published and distributed, in whole or in part, without 951 restriction of any kind, provided that the above copyright notice 952 and this paragraph are included on all such copies and derivative 953 works. However, this document itself may not be modified in any 954 way, such as by removing the copyright notice or references to the 955 Internet Society or other Internet organizations, except as needed 956 for the purpose of developing Internet standards in which case the 957 procedures for copyrights defined in the Internet Standards 958 process must be followed, or as required to translate it into 959 languages other than English. 961 The limited permissions granted above are perpetual and will not 962 be revoked by the Internet Society or its successors or assigns. 964 This document and the information contained herein is provided on 965 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 966 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 967 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 968 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 969 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 971 Acknowledgement 973 Funding for the RFC Editor function is currently provided by the 974 Internet Society.