idnits 2.17.1 draft-ietf-secsh-connect-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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 a Security Considerations section. ** 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.) ** The document seems to lack an Authors' Addresses Section. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 126 has weird spacing: '... string dat...' == Line 140 has weird spacing: '... string dat...' == Line 209 has weird spacing: '... string enc...' == Line 235 has weird spacing: '... string var...' == Line 236 has weird spacing: '... string var...' == (14 more instances...) -- 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 (March 22, 1997) is 9897 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) No issues found here. Summary: 9 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Tatu Ylonen 2 INTERNET-DRAFT SSH Communications Security 3 draft-ietf-secsh-connect-00.txt March 22, 1997 4 Expires: September 1, 1997 6 Status of This memo 8 This document is an Internet-Draft. Internet-Drafts are working 9 documents of the Internet Engineering Task Force (IETF), its areas, 10 and its working groups. Note that other groups may also distribute 11 working documents as Internet-Drafts. 13 Internet-Drafts are draft documents valid for a maximum of six 14 months and may be updated, replaced, or obsoleted by other documents 15 at any time. It is inappropriate to use Internet-Drafts as reference 16 material or to cite them other than as ``work in progress.'' 18 To learn the current status of any Internet-Draft, please check 19 the ``1id-abstracts.txt'' listing contained in the Internet-Drafts 20 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 21 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), 22 or ftp.isi.edu (US West Coast). 24 Abstract 26 This document describes the SSH connection protocol. It runs over the 27 SSH user authentication layer, and performs management of forwarded con- 28 nections and the terminal session(s). 30 Table of Contents 32 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2 33 2. Channel Mechanism . . . . . . . . . . . . . . . . . . . . . . . 2 34 2.1. Opening a Channel . . . . . . . . . . . . . . . . . . . . . 3 35 2.2. Data Transfer . . . . . . . . . . . . . . . . . . . . . . . 3 36 2.3. Closing a Channel . . . . . . . . . . . . . . . . . . . . . 4 37 3. Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 38 3.1. Opening a Session . . . . . . . . . . . . . . . . . . . . . 4 39 3.2. Requesting a Pseudo-Terminal . . . . . . . . . . . . . . . . 5 40 3.3. Environment Variable Passing . . . . . . . . . . . . . . . . 5 41 3.4. Requesting X11 Forwarding . . . . . . . . . . . . . . . . . 6 42 3.5. Requesting Athentication Agent Forwarding . . . . . . . . . 6 43 3.6. Starting Shell or Command . . . . . . . . . . . . . . . . . 6 44 3.7. Session Data Transfer . . . . . . . . . . . . . . . . . . . 7 45 3.8. Additional Control Messages . . . . . . . . . . . . . . . . 7 46 3.8.1. Window Change Message . . . . . . . . . . . . . . . . . 7 47 3.8.2. Local Flow Control . . . . . . . . . . . . . . . . . . . 7 48 3.9. Terminating a Session . . . . . . . . . . . . . . . . . . . 8 49 4. X11 Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . 8 50 5. Authentication Agent Forwarding . . . . . . . . . . . . . . . . 8 51 6. TCP/IP Port Forwarding . . . . . . . . . . . . . . . . . . . . . 9 52 6.1. Requesting Port Forwarding . . . . . . . . . . . . . . . . . 9 53 6.2. Opening a Forwarded Connection . . . . . . . . . . . . . . . 9 54 7. FTP Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . 10 55 8. Encoding of Terminal Modes . . . . . . . . . . . . . . . . . . . 10 56 9. Summary of Message Numbers . . . . . . . . . . . . . . . . . . . 14 57 10. Address of Author . . . . . . . . . . . . . . . . . . . . . . . 15 59 1. Introduction 61 This protocol has been designed to run over the SSH transport layer and 62 user authentication protocols. The service name for this protocol 63 (after user authentication) is "ssh-connection". It provides 64 interactive login sessions, remote execution of commands, forwarded 65 TCP/IP connections, and forwarded X11 connections. 67 2. Channel Mechanism 69 All terminal sessions, forwarded connections, etc. are channels. Either 70 side may open a channel. Multiple channels are multiplexed on the 71 single connection. 73 There are several ways to open a channel; typically the method used 74 depends on the intended use of the channel. After opening, however, 75 different channels use the same mechanisms for communication. 77 Channels are identified by numbers at each end. The number referring to 78 a channel may be different on each side. Requests to open a channel 79 contain the sender's channel number. Any other channel-related messages 80 contain the recipient's channel number for the channel. 82 All channel-related messages contain the number of the channel they 83 refer to. 85 Channels are flow-controlled. No data may be sent to a channel until a 86 message is received to indicate that window space is available. 88 2.1. Opening a Channel 90 Regardless of the method used to open a channel, when a side wishes to 91 open a channel, it allocates a local number for the channel. It then 92 sends a method-specific message to the other side, and includes the 93 local channel number and initial window size in the message. The remote 94 side then decides whether it can open the channel, and responds with 95 either 97 vlint32 SSH_MSG_CHANNEL_OPEN_CONFIRMATION 98 vlint32 recipient_channel 99 vlint32 sender_channel 100 vlint32 initial_window_size 102 where recipient_channel is the channel number given in the original open 103 request, and sender_channel is the channel number allocated by the other 104 side, or 106 vlint32 SSH_MSG_CHANNEL_OPEN_FAILURE 107 vlint32 recipient_channel 109 The window size specifies how many characters the other party can send 110 before it must wait for the window to be adjusted. Both parties use the 111 following message to adjust the window. 113 vlint32 SSH_MSG_CHANNEL_WINDOW_ADJUST 114 vlint32 recipient_channel 115 vlint32 bytes_to_add 117 Upon receiving this message, the recipient increases the number of bytes 118 it is allowed to send by the given amount. 120 2.2. Data Transfer 122 Data transfer is done with messages of the following type. 124 vlint32 SSH_MSG_CHANNEL_DATA 125 vlint32 recipient_channel 126 string data 128 The maximum amount of data allowed is the current window size. The 129 window size is decremented by the amount of data sent. 131 Additionally, some channels can transfer several types of data. An 132 example of this is stderr data from interactive sessions. Such data can 133 be passed with SSH_MSG_CHANNEL_EXTENDED_DATA messages, where a separate 134 integer specifies the type of the data. The available types and their 135 interpretation depend on the type of the channel. 137 vlint32 SSH_MSG_CHANNEL_EXTENDED_DATA 138 vlint32 recipient_channel 139 vlint32 data_type_code 140 string data 142 Data sent with these messages consumes the same window as ordinary data. 144 Currently, only the following type is defined. 146 #define SSH_EXTENDED_DATA_STDERR 1 148 2.3. Closing a Channel 150 When a party will no longer send more data to a channel, it should send 151 SSH_MSG_CHANNEL_EOF. 153 vlint32 SSH_MSG_CHANNEL_EOF 154 vlint32 recipient_channel 156 No explicit response is sent to this message; however, the application 157 may send EOF to whatever is at the other end of the channel. Note that 158 the channel remains open after this message, and more data may still be 159 sent in the other direction. 161 When either party wishes to terminate the channel, it sends 162 SSH_MSG_CHANNEL_CLOSE. Upon receiving this message, a party must send 163 back an SSH_MSG_CHANNEL_CLOSE unless it has already sent this message 164 for the channel. The channel is considered closed for a party when it 165 has both sent and received SSH_MSG_CHANNEL_CLOSE, and the party may then 166 reuse the channel number. It is legal to send SSH_MSG_CHANNEL_CLOSE 167 without having sent or received SSH_MSG_EOF. 169 vlint32 SSH_MSG_CHANNEL_CLOSE 170 vlint32 recipient_channel 172 3. Sessions 174 A session is a remote execution of a command. The command may be an 175 shell, a program, or some built-in subsystem. It may or may not have a 176 tty, and may or may not involve X11 forwarding. Multiple sessions can 177 be active simultaneously. 179 A session is created by SSH_MSG_CHANNEL_CREATE_SESSION. Then, the 180 client may send preparatory requests for the session, such as starting 181 X11 forwarding or allocating a pseudo-terminal. Finally, the client 182 requests to execute a command or to start an interactive shell. 184 3.1. Opening a Session 186 A session is started by sending the following message. While this 187 message can be sent by either side, it is normally recommended for 188 clients not to permit opening new sessions to avoid a corrupt server 189 from attacking clients. 191 vlint32 SSH_MSG_CHANNEL_CREATE_SESSION 192 vlint32 sender_channel 194 The server allocates a channel number and responds with open 195 confirmation or open failure. 197 3.2. Requesting a Pseudo-Terminal 199 A pseudo-terminal can be allocated for the session by sending the 200 following message. 202 vlint32 SSH_MSG_SESSION_REQUEST_PTY 203 vlint32 recipient_channel (session) 204 string TERM environment variable value (e.g., vt100) 205 vlint32 terminal width, characters (e.g., 80) 206 vlint32 terminal height, rows (e.g., 24) 207 vlint32 terminal width, pixels (e.g., 480) 208 vlint32 terminal height, pixels (e.g., 640) 209 string encoded terminal modes 211 The encoding of terminal modes is described in Section ``Encoding of 212 Terminal Modes''. 214 The server responds with either SSH_MSG_CHANNEL_SUCCESS or 215 SSH_MSG_CHANNEL_FAILURE. The client is allowed to send further messages 216 without waiting for the response to this message. 218 vlint32 SSH_MSG_CHANNEL_SUCCESS 219 vlint32 recipient_channel 221 vlint32 SSH_MSG_CHANNEL_FAILURE 222 vlint32 recipient_channel 224 3.3. Environment Variable Passing 226 Environment variables may be passed to the shell/command to be started 227 later. Typically, each machine will have a preconfigured set of 228 variables that it will allow. Since uncontrolled setting of environment 229 variables can be very dangerous, it is recommended that implementations 230 allow setting only variables whose names have been explicitly configured 231 to be allowed. 233 vlint32 SSH_MSG_SESSION_ENVIRONMENT_VARIABLE 234 vlint32 recipient_channel 235 string variable_name 236 string variable_value 238 The server responds with either SSH_MSG_CHANNEL_SUCCESS or 239 SSH_MSG_CHANNEL_FAILURE. The client is allowed to send further messages 240 without waiting for the response to this message. 242 3.4. Requesting X11 Forwarding 244 X11 forwarding may be requested for a session by sending 246 vlint32 SSH_MSG_SESSION_REQUEST_X11_FORWARDING 247 vlint32 recipient_channel (session) 248 string x11_authentication_protocol 249 string x11_authentication_cookie 250 vlint32 x11_screen_number 252 It is recommended that the authentication cookie that is sent be a fake, 253 random cookie, and that the cookie is checked and replaced by the real 254 cookie when a connection request is received. 256 The server responds with either SSH_MSG_CHANNEL_SUCCESS or 257 SSH_MSG_CHANNEL_FAILURE. The client is allowed to send futher messages 258 without waiting for the reponse to this message. 260 3.5. Requesting Athentication Agent Forwarding 262 Authentication agent forwarding may be requested for a session by 263 sending 265 vlint32 SSH_MSG_SESSION_REQUEST_AGENT_FORWARDING 266 vlint32 recipient_channel (session) 268 The server responds with either SSH_MSG_CHANNEL_SUCCESS or 269 SSH_MSG_CHANNEL_FAILURE. The client is allowed to send futher messages 270 without waiting for the reponse to this message. 272 3.6. Starting Shell or Command 274 Once the session has been set up, a shell or command is started at the 275 remote end. This can happen in any of a number of ways. 277 vlint32 SSH_MSG_SESSION_EXEC_SHELL 278 vlint32 recipient_channel 280 vlint32 SSH_MSG_SESSION_EXEC_COMMAND 281 vlint32 recipient_channel 282 string command 284 vlint32 SSH_MSG_SESSION_EXEC_PREDEFINED 285 vlint32 recipient_channel 286 vlint32 subsystem_name 288 This last form executes a predefined subsystem. It expected that these 289 will include a general file transfer mechanism, and possibly other 290 features. Implementations may also allow configuring more such 291 mechanisms. Having a special message for them avoids the need to have 292 their paths and command names be supplied by the other side. This also 293 makes it easier to implement them in the same executable as the rest of 294 the protocol on platforms where that is desirable. 296 3.7. Session Data Transfer 298 Data transfer for a session is done using SSH_MSG_CHANNEL_DATA and 299 SSH_MSG_CHANNEL_EXTENDED_DATA packets and the window mechanism. The 300 extended data type SSH_EXTENDED_DATA_STDERR has been defined for stderr 301 data. 303 3.8. Additional Control Messages 305 Smooth operation sometimes requires extra messages to be passed to 306 notify the other side of some event or change. 308 A single message type, SSH_MSG_SESSION_NOTIFICATION has been defined for 309 all of these notifications. Implementations should ignore all 310 notifications that they cannot interpret, and are free to ignore any 311 notifications. 313 vlint32 SSH_MSG_SESSION_NOTIFICATION 314 vlint32 recipient_channel 315 string notification_type 316 ... 318 Currently, the following notification types have been defined: 320 window_change Window size changed 321 xon_xoff_flow_control Local flow control 323 3.8.1. Window Change Message 325 When the window (terminal) size changes on the client side (client here 326 means the party who sent the create message for the session), it may 327 send a message to the other side to inform it of the new size. 329 vlint32 SSH_MSG_SESSION_NOTIFICATION 330 vlint32 recipient_channel 331 string "window_change" 332 vlint32 terminal width, columns 333 vlint32 terminal height, rows 334 vlint32 terminal width, pixels 335 vlint32 terminal height, pixels 337 3.8.2. Local Flow Control 339 On many systems it is possible to determine if a pseudo-terminal is 340 using control-S control-Q flow control. When this is the case, it is 341 often desirable to do the flow control at the client end to speed up 342 responses to user requests. This is facilitated by the following two 343 notifications. Initially, the server is responsible for flow control. 344 (Here, again, client means the side originating the session, and server 345 the other side.) 347 vlint32 SSH_MSG_SESSION_NOTIFICATION 348 vlint32 recipient_channel 349 string "xon_xoff_flow_control" 350 boolean client_can_do 352 If client_can_do is true, the client (originator) can do control-S 353 control-Q flow control locally. 355 3.9. Terminating a Session 357 When the command running at the other end terminates, 358 SSH_MSG_SESSION_EXIT_STATUS may be sent to return the exit status of the 359 command. Returning the status is optional, but recommended. No 360 acknowledgement is sent for this message. The channel needs to be 361 closed with SSH_MSG_CHANNEL_CLOSE after this message. 363 vlint32 SSH_MSG_SESSION_EXIT_STATUS 364 vlint32 recipient_channel 365 vlint32 exit_status 367 4. X11 Forwarding 369 X11 forwarding is requested with respect to a session. However, 370 forwarded connections are independent of the session. 372 The request to forward X11 connections opens a fake X11 display on the 373 server. No connections are opened at this time. 375 When an X11 client connects the fake X11 server, a request is sent to 376 the originator of the session. 378 vlint32 SSH_MSG_X11_OPEN 379 vlint32 sender_channel 380 vlint32 initial_window_size 381 string originator_string 383 The recipient should respond with open confirmation or open failure. 384 Originator_string is a free-form implementation-dependent description of 385 the X11 client that made the connection. It should typically contain 386 the IP address and port of the client, and may also contain user name or 387 other information if available. It should be in a format that is 388 understandable by a user. 390 5. Authentication Agent Forwarding 392 Authentication agent forwarding is requested with respect to a session. 393 However, forwarded connections are independent of the session. 395 When an application requests a connection to the authentication agent, 396 the following message is sent to the originator of the session. 398 vlint32 SSH_MSG_AGENT_OPEN 399 vlint32 sender_channel 400 vlint32 initial_window_size 401 string originator_string 402 string host_chain 404 The recipient should respond with open confirmation or open failure. 405 Originator_string is a free-form implementation-dependent description of 406 the application that made the connection, or empty if no description is 407 available. host_chain is a comma-separated list of hosts this request 408 has passed through. (Receiver of the message appends the sender's name, 409 if the message will be passed on (i.e. receiver is not the actual 410 agent).) 412 Because only one application can use a forwarded agent channel at a 413 time, multiple channels cannot be multiplexed in a ssh daemon. Instead, 414 ssh daemon must pass the request, and forward the reply all the way from 415 the agent to the requesting application. This results in creation of a 416 private channel for application using the agent. Agent stores the host 417 chain for every channel and uses it to determine which operations are 418 permitted. 420 6. TCP/IP Port Forwarding 422 6.1. Requesting Port Forwarding 424 A party need not explicitly request forwardings from its own end to the 425 other direction. However, it if wishes to have connections to a port on 426 the other side be forwarded to the local side, it must explicitly 427 request this. 429 vlint32 SSH_MSG_REQUEST_TCPIP_PORT_FORWARDING 430 string address_to_bind 431 vlint32 port_number_to_bind 433 Address_to_bind and port_number_to_bind specify the IP address and port 434 to which the socket to be listened is bound. The address should be 435 "0.0.0.0" if connections are allowed from anywhere. (Note that the 436 client can still filter connections based on information passed in the 437 open request.) 439 Implementations should only allow forwarding privileged ports if the 440 user has been authenticated as a privileged user. 442 The recipient will respond to this message with either 443 SSH_MSG_REQUEST_SUCCESS or SSH_MSG_REQUEST_FAILURE. 445 vlint32 SSH_MSG_REQUEST_SUCCESS 447 vlint32 SSH_MSG_REQUEST_FAILURE 449 6.2. Opening a Forwarded Connection 451 When a connection comes to a port for which forwarding was requested 452 with SSH_MSG_REQUEST_TCPIP_PORT_FORWARDING, the following message is 453 sent to the other side. 455 vlint32 SSH_MSG_TCPIP_REMOTE_PORT_OPEN 456 vlint32 sender_channel 457 vlint32 initial_window_size 458 vlint32 port_that_was_connected 459 string originator_ip_address 460 vlint32 originator_port 461 string originator_string 463 When a connection comes to a locally forwarded TCP/IP port, the 464 following packet is sent to the other side. Note that these messages 465 may be sent also for ports for which no forwarding has been explicitly 466 requested. The receiving side must decide whether to allow the 467 forwarding. 469 vlint32 SSH_MSG_TCPIP_PORT_OPEN 470 vlint32 sender_channel 471 vlint32 initial_window_size 472 string host_to_connect 473 vlint32 port_to_connect 474 string originator_ip_address 475 vlint32 originator_port 476 string originator_string 478 Host_to_connect and port_to_connect specify the TCP/IP host and port 479 where the recipient should connect the channel. Host_to_connect may be 480 either a domain name or a numeric IP address. 482 Originator_ip_address is the numeric IP address of the machine where the 483 connection request comes from, and originator_port is the port on the 484 originator host from where the connection came from. Originator_string 485 is a free-form description of where the connection came in a form that 486 can be displayed to the user. 488 7. FTP Forwarding 490 XXX 492 8. Encoding of Terminal Modes 494 Terminal modes (as passed in SSH_MSG_SESSION_REQUEST_PTY) are encoded 495 into a byte stream. It is intended that the coding be portable across 496 different environments. 498 The tty mode description is a stream of bytes. The stream consists of 499 opcode-argument pairs. It is terminated by opcode TTY_OP_END (0). 500 Opcodes 1-127 have one-byte arguments. Opcodes 128-159 have 32-bit 501 integer arguments (stored msb first). Opcodes 160-255 are not yet 502 defined, and cause parsing to stop (they should only be used after any 503 other data). 505 The client puts in the stream any modes it knows about, and the server 506 ignores any modes it does not know about. This allows some degree of 507 machine-independence, at least between systems that use a POSIX-like tty 508 interface. The protocol can support other systems as well, but the 509 client may need to fill reasonable values for a number of parameters so 510 the server pty gets set to a reasonable mode (the server leaves all 511 unspecified mode bits in their default values, and only some 512 combinations make sense). 514 The following opcodes have been defined. The naming of opcodes mostly 515 follows the POSIX terminal mode flags. 517 0 TTY_OP_END 518 Indicates end of options. 520 1 VINTR 521 Interrupt character; 255 if none. Similarly for the other 522 characters. Not all of these characters are supported on all 523 systems. 525 2 VQUIT 526 The quit character (sends SIGQUIT signal on UNIX systems). 528 3 VERASE 529 Erase the character to left of the cursor. 531 4 VKILL 532 Kill the current input line. 534 5 VEOF 535 End-of-file character (sends EOF from the terminal). 537 6 VEOL 538 End-of-line character in addition to carriage return and/or 539 linefeed. 541 7 VEOL2 542 Additional end-of-line character. 544 8 VSTART 545 Continues paused output (normally control-Q). 547 9 VSTOP 548 Pauses output (normally control-S). 550 10 VSUSP 551 Suspends the current program. 553 11 VDSUSP 554 Another suspend character. 556 12 VREPRINT 557 Reprints the current input line. 559 13 VWERASE 560 Erases a word left of cursor. 562 14 VLNEXT 563 More special input characters; these are probably not supported on 564 most systems. 565 15 VFLUSH 566 Character to flush output. 568 16 VSWTCH 569 ??? 571 17 VSTATUS 572 ??? 574 18 VDISCARD 575 ??? 577 30 IGNPAR 578 The ignore parity flag. The next byte should be 0 if this flag is 579 not set, and 1 if it is set. 581 31 PARMRK 582 Mark parity and framing errors. 584 32 INPCK 585 Enable checking of parity errors. 587 33 ISTRIP 588 Strip 8th bit off chars. 590 34 INLCR 591 Map NL into CR on input. 593 35 IGNCR 594 Ignore CR on input. 596 36 ICRNL 597 Map CR to NL on input. 599 37 IUCLC 600 ??? 602 38 IXON 603 Enable output flow control. 605 39 IXANY 606 Any char will restart after stop. 608 40 IXOFF 609 Enable input flow control. 611 41 IMAXBEL 612 Ring bell on input queue full. 614 50 ISIG 615 Enable signals INTR, QUIT, DSUSP. 617 51 ICANON 618 Canonicalize input lines. 620 52 XCASE 621 ??? 622 53 ECHO 623 Enable echoing. 625 54 ECHOE 626 Visually erase chars. 628 55 ECHOK 629 Kill character discards current line. 631 56 ECHONL 632 Echo NL even if ECHO is off. 634 57 NOFLSH 635 Don't flush after interrupt. 637 58 TOSTOP 638 Stop background jobs from output. 640 59 IEXTEN 641 Enable extensions. 643 60 ECHOCTL 644 Echo control characters as ^(Char). 646 61 ECHOKE 647 Visual erase for line kill. 649 62 PENDIN 650 Retype pending input. 652 70 OPOST 653 Enable output processing. 655 71 OLCUC 656 Convert lowercase to uppercase. 658 72 ONLCR 659 Map NL to CR-NL. 661 73 OCRNL 662 ??? 664 74 ONOCR 665 ??? 667 75 ONLRET 668 ??? 670 90 CS7 671 7 bits. 673 91 CS8 674 8 bits. 676 92 PARENB 677 Parity enable. 679 93 PARODD 680 Odd parity, else even. 682 192 TTY_OP_ISPEED 683 Specifies the input baud rate in bits per second (as a 32-bit int, 684 msb first). 686 193 TTY_OP_OSPEED 687 Specifies the output baud rate in bits per second (as a 32-bt int, 688 msb first). 690 9. Summary of Message Numbers 692 The following message numbers are used by this protocol. If an 693 unrecognized message is received, SSH_MSG_REQUEST_FAILURE should be sent 694 in response. 696 #define SSH_MSG_CHANNEL_OPEN_CONFIRMATION 40 697 #define SSH_MSG_CHANNEL_OPEN_FAILURE 41 698 #define SSH_MSG_CHANNEL_WINDOW_ADJUST 42 699 #define SSH_MSG_CHANNEL_DATA 43 700 #define SSH_MSG_CHANNEL_EOF 44 701 #define SSH_MSG_CHANNEL_CLOSE 45 702 #define SSH_MSG_CHANNEL_CREATE_SESSION 46 703 #define SSH_MSG_SESSION_REQUEST_PTY 47 704 #define SSH_MSG_CHANNEL_SUCCESS 48 705 #define SSH_MSG_CHANNEL_FAILURE 49 706 #define SSH_MSG_SESSION_ENVIRONMENT_VARIABLE 50 707 #define SSH_MSG_SESSION_REQUEST_X11_FORWARDING 51 708 #define SSH_MSG_SESSION_REQUEST_AGENT_FORWARDING 52 709 #define SSH_MSG_SESSION_EXEC_SHELL 53 710 #define SSH_MSG_SESSION_EXEC_COMMAND 54 711 #define SSH_MSG_SESSION_EXEC_PREDEFINED 55 712 #define SSH_MSG_SESSION_NOTIFICATION 56 713 #define SSH_MSG_SESSION_EXIT_STATUS 57 714 #define SSH_MSG_X11_OPEN 58 715 #define SSH_MSG_AGENT_OPEN 59 716 #define SSH_MSG_REQUEST_TCPIP_PORT_FORWARDING 60 717 #define SSH_MSG_REQUEST_SUCCESS 61 718 #define SSH_MSG_REQUEST_FAILURE 62 719 #define SSH_MSG_TCPIP_REMOTE_PORT_OPEN 63 720 #define SSH_MSG_TCPIP_PORT_OPEN 64 722 10. Address of Author 724 Tatu Ylonen 725 SSH Communications Security Ltd. 726 Tekniikantie 12 727 FIN-02150 ESPOO 728 Finland 730 E-mail: ylo@ssh.fi