Annotation of src/usr.bin/ssh/RFC, Revision 1.1
1.1 ! deraadt 1:
! 2:
! 3:
! 4:
! 5:
! 6:
! 7: Network Working Group T. Ylonen
! 8: Internet-Draft Helsinki University of Technology
! 9: draft-ylonen-ssh-protocol-00.txt 15 November 1995
! 10: Expires: 15 May 1996
! 11:
! 12:
! 13: The SSH (Secure Shell) Remote Login Protocol
! 14:
! 15: Status of This Memo
! 16:
! 17: This document is an Internet-Draft. Internet-Drafts are working
! 18: documents of the Internet Engineering Task Force (IETF), its areas,
! 19: and its working groups. Note that other groups may also distribute
! 20: working documents as Internet-Drafts.
! 21:
! 22: Internet-Drafts are draft documents valid for a maximum of six
! 23: months and may be updated, replaced, or obsoleted by other docu-
! 24: ments at any time. It is inappropriate to use Internet-Drafts as
! 25: reference material or to cite them other than as ``work in pro-
! 26: gress.''
! 27:
! 28: To learn the current status of any Internet-Draft, please check the
! 29: ``1id-abstracts.txt'' listing contained in the Internet- Drafts
! 30: Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
! 31: munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
! 32: ftp.isi.edu (US West Coast).
! 33:
! 34: The distribution of this memo is unlimited.
! 35:
! 36: Introduction
! 37:
! 38: SSH (Secure Shell) is a program to log into another computer over a
! 39: network, to execute commands in a remote machine, and to move files
! 40: from one machine to another. It provides strong authentication and
! 41: secure communications over insecure networks. Its features include
! 42: the following:
! 43:
! 44: o Closes several security holes (e.g., IP, routing, and DNS spoof-
! 45: ing). New authentication methods: .rhosts together with RSA
! 46: [RSA] based host authentication, and pure RSA authentication.
! 47:
! 48: o All communications are automatically and transparently
! 49: encrypted. Encryption is also used to protect integrity.
! 50:
! 51: o X11 connection forwarding provides secure X11 sessions.
! 52:
! 53: o Arbitrary TCP/IP ports can be redirected over the encrypted
! 54: channel in both directions.
! 55:
! 56:
! 57:
! 58: Ylonen [Page 1]
! 59:
! 60: Internet-Draft SSH (Secure Shell) Remote Login Protocol 15 Nov 1995
! 61:
! 62:
! 63: o Client RSA-authenticates the server machine in the beginning of
! 64: every connection to prevent trojan horses (by routing or DNS
! 65: spoofing) and man-in-the-middle attacks, and the server RSA-
! 66: authenticates the client machine before accepting .rhosts or
! 67: /etc/hosts.equiv authentication (to prevent DNS, routing, or IP
! 68: spoofing).
! 69:
! 70: o An authentication agent, running in the user's local workstation
! 71: or laptop, can be used to hold the user's RSA authentication
! 72: keys.
! 73:
! 74: The goal has been to make the software as easy to use as possible for
! 75: ordinary users. The protocol has been designed to be as secure as
! 76: possible while making it possible to create implementations that are
! 77: easy to use and install. The sample implementation has a number of
! 78: convenient features that are not described in this document as they
! 79: are not relevant for the protocol.
! 80:
! 81:
! 82: Overview of the Protocol
! 83:
! 84: The software consists of a server program running on a server
! 85: machine, and a client program running on a client machine (plus a few
! 86: auxiliary programs). The machines are connected by an insecure IP
! 87: [RFC0791] network (that can be monitored, tampered with, and spoofed
! 88: by hostile parties).
! 89:
! 90: A connection is always initiated by the client side. The server
! 91: listens on a specific port waiting for connections. Many clients may
! 92: connect to the same server machine.
! 93:
! 94: The client and the server are connected via a TCP/IP [RFC0793] socket
! 95: that is used for bidirectional communication. Other types of tran-
! 96: sport can be used but are currently not defined.
! 97:
! 98: When the client connects the server, the server accepts the connec-
! 99: tion and responds by sending back its version identification string.
! 100: The client parses the server's identification, and sends its own
! 101: identification. The purpose of the identification strings is to
! 102: validate that the connection was to the correct port, declare the
! 103: protocol version number used, and to declare the software version
! 104: used on each side (for debugging purposes). The identification
! 105: strings are human-readable. If either side fails to understand or
! 106: support the other side's version, it closes the connection.
! 107:
! 108: After the protocol identification phase, both sides switch to a
! 109: packet based binary protocol. The server starts by sending its host
! 110: key (every host has an RSA key used to authenticate the host), server
! 111:
! 112:
! 113:
! 114: Ylonen [Page 2]
! 115:
! 116: Internet-Draft SSH (Secure Shell) Remote Login Protocol 15 Nov 1995
! 117:
! 118:
! 119: key (an RSA key regenerated every hour), and other information to the
! 120: client. The client then generates a 256 bit session key, encrypts it
! 121: using both RSA keys (see below for details), and sends the encrypted
! 122: session key and selected cipher type to the server. Both sides then
! 123: turn on encryption using the selected algorithm and key. The server
! 124: sends an encrypted confirmation message to the client.
! 125:
! 126: The client then authenticates itself using any of a number of authen-
! 127: tication methods. The currently supported authentication methods are
! 128: .rhosts or /etc/hosts.equiv authentication (disabled by default), the
! 129: same with RSA-based host authentication, RSA authentication, and
! 130: password authentication.
! 131:
! 132: After successful authentication, the client makes a number of
! 133: requests to prepare for the session. Typical requests include allo-
! 134: cating a pseudo tty, starting X11 [X11] or TCP/IP port forwarding,
! 135: starting authentication agent forwarding, and executing the shell or
! 136: a command.
! 137:
! 138: When a shell or command is executed, the connection enters interac-
! 139: tive session mode. In this mode, data is passed in both directions,
! 140: new forwarded connections may be opened, etc. The interactive ses-
! 141: sion normally terminates when the server sends the exit status of the
! 142: program to the client.
! 143:
! 144:
! 145: The protocol makes several reservations for future extensibility.
! 146: First of all, the initial protocol identification messages include
! 147: the protocol version number. Second, the first packet by both sides
! 148: includes a protocol flags field, which can be used to agree on exten-
! 149: sions in a compatible manner. Third, the authentication and session
! 150: preparation phases work so that the client sends requests to the
! 151: server, and the server responds with success or failure. If the
! 152: client sends a request that the server does not support, the server
! 153: simply returns failure for it. This permits compatible addition of
! 154: new authentication methods and preparation operations. The interac-
! 155: tive session phase, on the other hand, works asynchronously and does
! 156: not permit the use of any extensions (because there is no easy and
! 157: reliable way to signal rejection to the other side and problems would
! 158: be hard to debug). Any compatible extensions to this phase must be
! 159: agreed upon during any of the earlier phases.
! 160:
! 161: The Binary Packet Protocol
! 162:
! 163: After the protocol identification strings, both sides only send spe-
! 164: cially formatted packets. The packet layout is as follows:
! 165:
! 166: o Packet length: 32 bit unsigned integer, coded as four 8-bit
! 167:
! 168:
! 169:
! 170: Ylonen [Page 3]
! 171:
! 172: Internet-Draft SSH (Secure Shell) Remote Login Protocol 15 Nov 1995
! 173:
! 174:
! 175: bytes, msb first. Gives the length of the packet, not including
! 176: the length field and padding. The maximum length of a packet
! 177: (not including the length field and padding) is 262144 bytes.
! 178:
! 179: o Padding: 1-8 bytes of random data (or zeroes if not encrypting).
! 180: The amount of padding is (8 - (length % 8)) bytes (where %
! 181: stands for the modulo operator). The rationale for always hav-
! 182: ing some random padding at the beginning of each packet is to
! 183: make known plaintext attacks more difficult.
! 184:
! 185: o Packet type: 8-bit unsigned byte. The value 255 is reserved for
! 186: future extension.
! 187:
! 188: o Data: binary data bytes, depending on the packet type. The
! 189: number of data bytes is the "length" field minus 5.
! 190:
! 191: o Check bytes: 32-bit crc, four 8-bit bytes, msb first. The crc
! 192: is the Cyclic Redundancy Check, with the polynomial 0xedb88320,
! 193: of the Padding, Packet type, and Data fields. The crc is com-
! 194: puted before any encryption.
! 195:
! 196: The packet, except for the length field, may be encrypted using any
! 197: of a number of algorithms. The length of the encrypted part (Padding
! 198: + Type + Data + Check) is always a multiple of 8 bytes. Typically
! 199: the cipher is used in a chained mode, with all packets chained
! 200: together as if it was a single data stream (the length field is never
! 201: included in the encryption process). Details of encryption are
! 202: described below.
! 203:
! 204: When the session starts, encryption is turned off. Encryption is
! 205: enabled after the client has sent the session key. The encryption
! 206: algorithm to use is selected by the client.
! 207:
! 208:
! 209: Packet Compression
! 210:
! 211: If compression is supported (it is an optional feature, see
! 212: SSH_CMSG_REQUEST_COMPRESSION below), the packet type and data fields
! 213: of the packet are compressed using the gzip deflate algorithm [GZIP].
! 214: If compression is in effect, the packet length field indicates the
! 215: length of the compressed data, plus 4 for the crc. The amount of
! 216: padding is computed from the compressed data, so that the amount of
! 217: data to be encrypted becomes a multiple of 8 bytes.
! 218:
! 219: When compressing, the packets (type + data portions) in each direc-
! 220: tion are compressed as if they formed a continuous data stream, with
! 221: only the current compression block flushed between packets. This
! 222: corresponds to the GNU ZLIB library Z_PARTIAL_FLUSH option. The
! 223:
! 224:
! 225:
! 226: Ylonen [Page 4]
! 227:
! 228: Internet-Draft SSH (Secure Shell) Remote Login Protocol 15 Nov 1995
! 229:
! 230:
! 231: compression dictionary is not flushed between packets. The two
! 232: directions are compressed independently of each other.
! 233:
! 234:
! 235: Packet Encryption
! 236:
! 237: The protocol supports several encryption methods. During session
! 238: initialization, the server sends a bitmask of all encryption methods
! 239: that it supports, and the client selects one of these methods. The
! 240: client also generates a 256-bit random session key (32 8-bit bytes)
! 241: and sends it to the server.
! 242:
! 243: The encryption methods supported by the current implementation, and
! 244: their codes are:
! 245:
! 246: SSH_CIPHER_NONE 0 No encryption
! 247: SSH_CIPHER_IDEA 1 IDEA in CFB mode
! 248: SSH_CIPHER_DES 2 DES in CBC mode
! 249: SSH_CIPHER_3DES 3 Triple-DES in CBC mode
! 250: SSH_CIPHER_TSS 4 An experimental stream cipher
! 251: SSH_CIPHER_RC4 5 RC4
! 252:
! 253:
! 254: All implementations are required to support SSH_CIPHER_DES and
! 255: SSH_CIPHER_3DES. Supporting SSH_CIPHER_IDEA, SSH_CIPHER_RC4, and
! 256: SSH_CIPHER_NONE is recommended. Support for SSH_CIPHER_TSS is
! 257: optional (and it is not described in this document). Other ciphers
! 258: may be added at a later time; support for them is optional.
! 259:
! 260: For encryption, the encrypted portion of the packet is considered a
! 261: linear byte stream. The length of the stream is always a multiple of
! 262: 8. The encrypted portions of consecutive packets (in the same direc-
! 263: tion) are encrypted as if they were a continuous buffer (that is, any
! 264: initialization vectors are passed from the previous packet to the
! 265: next packet). Data in each direction is encrypted independently.
! 266:
! 267: SSH_CIPHER_DES
! 268: The key is taken from the first 8 bytes of the session key. The
! 269: least significant bit of each byte is ignored. This results in
! 270: 56 bits of key data. DES [DES] is used in CBC mode. The iv
! 271: (initialization vector) is initialized to all zeroes.
! 272:
! 273: SSH_CIPHER_3DES
! 274: The variant of triple-DES used here works as follows: there are
! 275: three independent DES-CBC ciphers, with independent initializa-
! 276: tion vectors. The data (the whole encrypted data stream) is
! 277: first encrypted with the first cipher, then decrypted with the
! 278: second cipher, and finally encrypted with the third cipher. All
! 279:
! 280:
! 281:
! 282: Ylonen [Page 5]
! 283:
! 284: Internet-Draft SSH (Secure Shell) Remote Login Protocol 15 Nov 1995
! 285:
! 286:
! 287: these operations are performed in CBC mode.
! 288:
! 289: The key for the first cipher is taken from the first 8 bytes of
! 290: the session key; the key for the next cipher from the next 8
! 291: bytes, and the key for the third cipher from the following 8
! 292: bytes. All three initialization vectors are initialized to
! 293: zero.
! 294:
! 295: (Note: the variant of 3DES used here differs from some other
! 296: descriptions.)
! 297:
! 298: SSH_CIPHER_IDEA
! 299: The key is taken from the first 16 bytes of the session key.
! 300: IDEA [IDEA] is used in CFB mode. The initialization vector is
! 301: initialized to all zeroes.
! 302:
! 303: SSH_CIPHER_TSS
! 304: All 32 bytes of the session key are used as the key.
! 305:
! 306: There is no reference available for the TSS algorithm; it is
! 307: currently only documented in the sample implementation source
! 308: code. The security of this cipher is unknown (but it is quite
! 309: fast). The cipher is basically a stream cipher that uses MD5 as
! 310: a random number generator and takes feedback from the data.
! 311:
! 312: SSH_CIPHER_RC4
! 313: The first 16 bytes of the session key are used as the key for
! 314: the server to client direction. The remaining 16 bytes are used
! 315: as the key for the client to server direction. This gives
! 316: independent 128-bit keys for each direction.
! 317:
! 318: This algorithm is the alleged RC4 cipher posted to the Usenet in
! 319: 1995. It is widely believed to be equivalent with the original
! 320: RSADSI RC4 cipher. This is a very fast algorithm.
! 321:
! 322:
! 323: Data Type Encodings
! 324:
! 325: The Data field of each packet contains data encoded as described in
! 326: this section. There may be several data items; each item is coded as
! 327: described here, and their representations are concatenated together
! 328: (without any alignment or padding).
! 329:
! 330: Each data type is stored as follows:
! 331:
! 332: 8-bit byte
! 333: The byte is stored directly as a single byte.
! 334:
! 335:
! 336:
! 337:
! 338: Ylonen [Page 6]
! 339:
! 340: Internet-Draft SSH (Secure Shell) Remote Login Protocol 15 Nov 1995
! 341:
! 342:
! 343: 32-bit unsigned integer
! 344: Stored in 4 bytes, msb first.
! 345:
! 346: Arbitrary length binary string
! 347: First 4 bytes are the length of the string, msb first (not
! 348: including the length itself). The following "length" bytes are
! 349: the string value. There are no terminating null characters.
! 350:
! 351: Multiple-precision integer
! 352: First 2 bytes are the number of bits in the integer, msb first
! 353: (for example, the value 0x00012345 would have 17 bits). The
! 354: value zero has zero bits. It is permissible that the number of
! 355: bits be larger than the real number of bits.
! 356:
! 357: The number of bits is followed by (bits + 7) / 8 bytes of binary
! 358: data, msb first, giving the value of the integer.
! 359:
! 360:
! 361: TCP/IP Port Number and Other Options
! 362:
! 363: The server listens for connections on TCP/IP port 22.
! 364:
! 365: The client may connect the server from any port. However, if the
! 366: client wishes to use any form of .rhosts or /etc/hosts.equiv authen-
! 367: tication, it must connect from a privileged port (less than 1024).
! 368:
! 369: For the IP Type of Service field [RFC0791], it is recommended that
! 370: interactive sessions (those having a user terminal or forwarding X11
! 371: connections) use the IPTOS_LOWDELAY, and non-interactive connections
! 372: use IPTOS_THROUGHPUT.
! 373:
! 374: It is recommended that keepalives are used, because otherwise pro-
! 375: grams on the server may never notice if the other end of the connec-
! 376: tion is rebooted.
! 377:
! 378:
! 379: Protocol Version Identification
! 380:
! 381: After the socket is opened, the server sends an identification
! 382: string, which is of the form "SSH-<protocolmajor>.<protocolminor>-
! 383: <version>\n", where <protocolmajor> and <protocolminor> are integers
! 384: and specify the protocol version number (not software distribution
! 385: version). <version> is server side software version string (max 40
! 386: characters); it is not interpreted by the remote side but may be use-
! 387: ful for debugging.
! 388:
! 389: The client parses the server's string, and sends a corresponding
! 390: string with its own information in response. If the server has lower
! 391:
! 392:
! 393:
! 394: Ylonen [Page 7]
! 395:
! 396: Internet-Draft SSH (Secure Shell) Remote Login Protocol 15 Nov 1995
! 397:
! 398:
! 399: version number, and the client contains special code to emulate it,
! 400: the client responds with the lower number; otherwise it responds with
! 401: its own number. The server then compares the version number the
! 402: client sent with its own, and determines whether they can work
! 403: together. The server either disconnects, or sends the first packet
! 404: using the binary packet protocol and both sides start working accord-
! 405: ing to the lower of the protocol versions.
! 406:
! 407: By convention, changes which keep the protocol compatible with previ-
! 408: ous versions keep the same major protocol version; changes that are
! 409: not compatible increment the major version (which will hopefully
! 410: never happen). The version described in this document is 1.3.
! 411:
! 412: The client will
! 413:
! 414: Key Exchange and Server Host Authentication
! 415:
! 416: The first message sent by the server using the packet protocol is
! 417: SSH_SMSG_PUBLIC_KEY. It declares the server's host key, server pub-
! 418: lic key, supported ciphers, supported authentication methods, and
! 419: flags for protocol extensions. It also contains a 64-bit random
! 420: number (cookie) that must be returned in the client's reply (to make
! 421: IP spoofing more difficult). No encryption is used for this message.
! 422:
! 423: Both sides compute a session id as follows. The modulus of the
! 424: server key is interpreted as a byte string (without explicit length
! 425: field, with minimum length able to hold the whole value), most signi-
! 426: ficant byte first. This string is concatenated with the server host
! 427: key interpreted the same way. Additionally, the cookie is con-
! 428: catenated with this. Both sides compute MD5 of the resulting string.
! 429: The resulting 16 bytes (128 bits) are stored by both parties and are
! 430: called the session id.
! 431:
! 432: The client responds with a SSH_CMSG_SESSION_KEY message, which con-
! 433: tains the selected cipher type, a copy of the 64-bit cookie sent by
! 434: the server, client's protocol flags, and a session key encrypted with
! 435: both the server's host key and server key. No encryption is used for
! 436: this message.
! 437:
! 438: The session key is 32 8-bit bytes (a total of 256 random bits gen-
! 439: erated by the client). The client first xors the 16 bytes of the
! 440: session id with the first 16 bytes of the session key. The resulting
! 441: string is then encrypted using the smaller key (one with smaller
! 442: modulus), and the result is then encrypted using the other key. The
! 443: number of bits in the public modulus of the two keys must differ by
! 444: at least 128 bits.
! 445:
! 446: At each encryption step, a multiple-precision integer is constructed
! 447:
! 448:
! 449:
! 450: Ylonen [Page 8]
! 451:
! 452: Internet-Draft SSH (Secure Shell) Remote Login Protocol 15 Nov 1995
! 453:
! 454:
! 455: from the data to be encrypted as follows (the integer is here inter-
! 456: preted as a sequence of bytes, msb first; the number of bytes is the
! 457: number of bytes needed to represent the modulus).
! 458:
! 459: The most significant byte (which is only partial as the value must be
! 460: less than the public modulus, which is never a power of two) is zero.
! 461:
! 462: The next byte contains the value 2 (which stands for public-key
! 463: encrypted data in the PKCS standard [PKCS#1]). Then, there are non-
! 464: zero random bytes to fill any unused space, a zero byte, and the data
! 465: to be encrypted in the least significant bytes, the last byte of the
! 466: data in the least significant byte.
! 467:
! 468: This algorithm is used twice. First, it is used to encrypt the 32
! 469: random bytes generated by the client to be used as the session key
! 470: (xored by the session id). This value is converted to an integer as
! 471: described above, and encrypted with RSA using the key with the
! 472: smaller modulus. The resulting integer is converted to a byte
! 473: stream, msb first. This byte stream is padded and encrypted identi-
! 474: cally using the key with the larger modulus.
! 475:
! 476: After the client has sent the session key, it starts to use the
! 477: selected algorithm and key for decrypting any received packets, and
! 478: for encrypting any sent packets. Separate ciphers are used for dif-
! 479: ferent directions (that is, both directions have separate initializa-
! 480: tion vectors or other state for the ciphers).
! 481:
! 482: When the server has received the session key message, and has turned
! 483: on encryption, it sends a SSH_SMSG_SUCCESS message to the client.
! 484:
! 485: The recommended size of the host key is 1024 bits, and 768 bits for
! 486: the server key. The minimum size is 512 bits for the smaller key.
! 487:
! 488:
! 489: Declaring the User Name
! 490:
! 491: The client then sends a SSH_CMSG_USER message to the server. This
! 492: message specifies the user name to log in as.
! 493:
! 494: The server validates that such a user exists, checks whether authen-
! 495: tication is needed, and responds with either SSH_SMSG_SUCCESS or
! 496: SSH_SMSG_FAILURE. SSH_SMSG_SUCCESS indicates that no authentication
! 497: is needed for this user (no password), and authentication phase has
! 498: now been completed. SSH_SMSG_FAILURE indicates that authentication
! 499: is needed (or the user does not exist).
! 500:
! 501: If the user does not exist, it is recommended that this returns
! 502: failure, but the server keeps reading messages from the client, and
! 503:
! 504:
! 505:
! 506: Ylonen [Page 9]
! 507:
! 508: Internet-Draft SSH (Secure Shell) Remote Login Protocol 15 Nov 1995
! 509:
! 510:
! 511: responds to any messages (except SSH_MSG_DISCONNECT, SSH_MSG_IGNORE,
! 512: and SSH_MSG_DEBUG) with SSH_SMSG_FAILURE. This way the client cannot
! 513: be certain whether the user exists.
! 514:
! 515:
! 516: Authentication Phase
! 517:
! 518: Provided the server didn't immediately accept the login, an authenti-
! 519: cation exchange begins. The client sends messages to the server
! 520: requesting different types of authentication in arbitrary order as
! 521: many times as desired (however, the server may close the connection
! 522: after a timeout). The server always responds with SSH_SMSG_SUCCESS
! 523: if it has accepted the authentication, and with SSH_SMSG_FAILURE if
! 524: it has denied authentication with the requested method or it does not
! 525: recognize the message. Some authentication methods cause an exchange
! 526: of further messages before the final result is sent. The authentica-
! 527: tion phase ends when the server responds with success.
! 528:
! 529: The recommended value for the authentication timeout (timeout before
! 530: disconnecting if no successful authentication has been made) is 5
! 531: minutes.
! 532:
! 533: The following authentication methods are currently supported:
! 534:
! 535: SSH_AUTH_RHOSTS 1 .rhosts or /etc/hosts.equiv
! 536: SSH_AUTH_RSA 2 pure RSA authentication
! 537: SSH_AUTH_PASSWORD 3 password authentication
! 538: SSH_AUTH_RHOSTS_RSA 4 .rhosts with RSA host authentication
! 539:
! 540:
! 541: SSH_AUTH_RHOSTS
! 542:
! 543: This is the authentication method used by rlogin and rsh
! 544: [RFC1282].
! 545:
! 546: The client sends SSH_CMSG_AUTH_RHOSTS with the client-side user
! 547: name as an argument.
! 548:
! 549: The server checks whether to permit authentication. On UNIX
! 550: systems, this is usually done by checking /etc/hosts.equiv, and
! 551: .rhosts in the user's home directory. The connection must come
! 552: from a privileged port.
! 553:
! 554: It is recommended that the server checks that there are no IP
! 555: options (such as source routing) specified for the socket before
! 556: accepting this type of authentication. The client host name
! 557: should be reverse-mapped and then forward mapped to ensure that
! 558: it has the proper IP-address.
! 559:
! 560:
! 561:
! 562: Ylonen [Page 10]
! 563:
! 564: Internet-Draft SSH (Secure Shell) Remote Login Protocol 15 Nov 1995
! 565:
! 566:
! 567: This authentication method trusts the remote host (root on the
! 568: remote host can pretend to be any other user on that host), the
! 569: name services, and partially the network: anyone who can see
! 570: packets coming out from the server machine can do IP-spoofing
! 571: and pretend to be any machine; however, the protocol prevents
! 572: blind IP-spoofing (which used to be possible with rlogin).
! 573:
! 574: Many sites probably want to disable this authentication method
! 575: because of the fundamental insecurity of conventional .rhosts or
! 576: /etc/hosts.equiv authentication when faced with spoofing. It is
! 577: recommended that this method not be supported by the server by
! 578: default.
! 579:
! 580: SSH_AUTH_RHOSTS_RSA
! 581:
! 582: In addition to conventional .rhosts and hosts.equiv authentica-
! 583: tion, this method additionally requires that the client host be
! 584: authenticated using RSA.
! 585:
! 586: The client sends SSH_CMSG_AUTH_RHOSTS_RSA specifying the
! 587: client-side user name, and the public host key of the client
! 588: host.
! 589:
! 590: The server first checks if normal .rhosts or /etc/hosts.equiv
! 591: authentication would be accepted, and if not, responds with
! 592: SSH_SMSG_FAILURE. Otherwise, it checks whether it knows the
! 593: host key for the client machine (using the same name for the
! 594: host that was used for checking the .rhosts and /etc/hosts.equiv
! 595: files). If it does not know the RSA key for the client, access
! 596: is denied and SSH_SMSG_FAILURE is sent.
! 597:
! 598: If the server knows the host key of the client machine, it veri-
! 599: fies that the given host key matches that known for the client.
! 600: If not, access is denied and SSH_SMSG_FAILURE is sent.
! 601:
! 602: The server then sends a SSH_SMSG_AUTH_RSA_CHALLENGE message con-
! 603: taining an encrypted challenge for the client. The challenge is
! 604: 32 8-bit random bytes (256 bits). When encrypted, the highest
! 605: (partial) byte is left as zero, the next byte contains the value
! 606: 2, the following are non-zero random bytes, followed by a zero
! 607: byte, and the challenge put in the remaining bytes. This is
! 608: then encrypted using RSA with the client host's public key.
! 609: (The padding and encryption algorithm is the same as that used
! 610: for the session key.)
! 611:
! 612: The client decrypts the challenge using its private host key,
! 613: concatenates this with the session id, and computes an MD5
! 614: checksum of the resulting 48 bytes. The MD5 output is returned
! 615:
! 616:
! 617:
! 618: Ylonen [Page 11]
! 619:
! 620: Internet-Draft SSH (Secure Shell) Remote Login Protocol 15 Nov 1995
! 621:
! 622:
! 623: as 16 bytes in a SSH_CMSG_AUTH_RSA_RESPONSE message. (MD5 is
! 624: used to deter chosen plaintext attacks against RSA; the session
! 625: id binds it to a specific session).
! 626:
! 627: The server verifies that the MD5 of the decrypted challenge
! 628: returned by the client matches that of the original value, and
! 629: sends SSH_SMSG_SUCCESS if so. Otherwise it sends
! 630: SSH_SMSG_FAILURE and refuses the authentication attempt.
! 631:
! 632: This authentication method trusts the client side machine in
! 633: that root on that machine can pretend to be any user on that
! 634: machine. Additionally, it trusts the client host key. The name
! 635: and/or IP address of the client host is only used to select the
! 636: public host key. The same host name is used when scanning
! 637: .rhosts or /etc/hosts.equiv and when selecting the host key. It
! 638: would in principle be possible to eliminate the host name
! 639: entirely and substitute it directly by the host key. IP and/or
! 640: DNS [RFC1034] spoofing can only be used to pretend to be a host
! 641: for which the attacker has the private host key.
! 642:
! 643: SSH_AUTH_RSA
! 644:
! 645: The idea behind RSA authentication is that the server recognizes
! 646: the public key offered by the client, generates a random chal-
! 647: lenge, and encrypts the challenge with the public key. The
! 648: client must then prove that it has the corresponding private key
! 649: by decrypting the challenge.
! 650:
! 651: The client sends SSH_CMSG_AUTH_RSA with public key modulus (n)
! 652: as an argument.
! 653:
! 654: The server may respond immediately with SSH_SMSG_FAILURE if it
! 655: does not permit authentication with this key. Otherwise it gen-
! 656: erates a challenge, encrypts it using the user's public key
! 657: (stored on the server and identified using the modulus), and
! 658: sends SSH_SMSG_AUTH_RSA_CHALLENGE with the challenge (mp-int) as
! 659: an argument.
! 660:
! 661: The challenge is 32 8-bit random bytes (256 bits). When
! 662: encrypted, the highest (partial) byte is left as zero, the next
! 663: byte contains the value 2, the following are non-zero random
! 664: bytes, followed by a zero byte, and the challenge put in the
! 665: remaining bytes. This is then encrypted with the public key.
! 666: (The padding and encryption algorithm is the same as that used
! 667: for the session key.)
! 668:
! 669: The client decrypts the challenge using its private key, con-
! 670: catenates it with the session id, and computes an MD5 checksum
! 671:
! 672:
! 673:
! 674: Ylonen [Page 12]
! 675:
! 676: Internet-Draft SSH (Secure Shell) Remote Login Protocol 15 Nov 1995
! 677:
! 678:
! 679: of the resulting 48 bytes. The MD5 output is returned as 16
! 680: bytes in a SSH_CMSG_AUTH_RSA_RESPONSE message. (Note that the
! 681: MD5 is necessary to avoid chosen plaintext attacks against RSA;
! 682: the session id binds it to a specific session.)
! 683:
! 684: The server verifies that the MD5 of the decrypted challenge
! 685: returned by the client matches that of the original value, and
! 686: sends SSH_SMSG_SUCCESS if so. Otherwise it sends
! 687: SSH_SMSG_FAILURE and refuses the authentication attempt.
! 688:
! 689: This authentication method does not trust the remote host, the
! 690: network, name services, or anything else. Authentication is
! 691: based solely on the possession of the private identification
! 692: keys. Anyone in possession of the private keys can log in, but
! 693: nobody else.
! 694:
! 695: The server may have additional requirements for a successful
! 696: authentiation. For example, to limit damage due to a comprom-
! 697: ised RSA key, a server might restrict access to a limited set of
! 698: hosts.
! 699:
! 700: SSH_AUTH_PASSWORD
! 701:
! 702: The client sends a SSH_CMSG_AUTH_PASSWORD message with the plain
! 703: text password. (Note that even though the password is plain
! 704: text inside the message, it is normally encrypted by the packet
! 705: mechanism.)
! 706:
! 707: The server verifies the password, and sends SSH_SMSG_SUCCESS if
! 708: authentication was accepted and SSH_SMSG_FAILURE otherwise.
! 709:
! 710: Note that the password is read from the user by the client; the
! 711: user never interacts with a login program.
! 712:
! 713: This authentication method does not trust the remote host, the
! 714: network, name services or anything else. Authentication is
! 715: based solely on the possession of the password. Anyone in pos-
! 716: session of the password can log in, but nobody else.
! 717:
! 718: Preparatory Operations
! 719:
! 720: After successful authentication, the server waits for a request from
! 721: the client, processes the request, and responds with SSH_SMSG_SUCCESS
! 722: whenever a request has been successfully processed. If it receives a
! 723: message that it does not recognize or it fails to honor a request, it
! 724: returns SSH_SMSG_FAILURE. It is expected that new message types
! 725: might be added to this phase in future.
! 726:
! 727:
! 728:
! 729:
! 730: Ylonen [Page 13]
! 731:
! 732: Internet-Draft SSH (Secure Shell) Remote Login Protocol 15 Nov 1995
! 733:
! 734:
! 735: The following messages are currently defined for this phase.
! 736:
! 737: SSH_CMSG_REQUEST_COMPRESSION
! 738: Requests that compression be enabled for this session. A gzip-
! 739: compatible compression level (1-9) is passed as an argument.
! 740:
! 741: SSH_CMSG_REQUEST_PTY
! 742: Requests that a pseudo terminal device be allocated for this
! 743: session. The user terminal type and terminal modes are supplied
! 744: as arguments.
! 745:
! 746: SSH_CMSG_X11_REQUEST_FORWARDING
! 747: Requests forwarding of X11 connections from the remote machine
! 748: to the local machine over the secure channel. Causes an
! 749: internet-domain socket to be allocated and the DISPLAY variable
! 750: to be set on the server. X11 authentication data is automati-
! 751: cally passed to the server, and the client may implement spoof-
! 752: ing of authentication data for added security. The authentica-
! 753: tion data is passed as arguments.
! 754:
! 755: SSH_CMSG_PORT_FORWARD_REQUEST
! 756: Requests forwarding of a TCP/IP port on the server host over the
! 757: secure channel. What happens is that whenever a connection is
! 758: made to the port on the server, a connection will be made from
! 759: the client end to the specified host/port. Any user can forward
! 760: unprivileged ports; only the root can forward privileged ports
! 761: (as determined by authentication done earlier).
! 762:
! 763: SSH_CMSG_AGENT_REQUEST_FORWARDING
! 764: Requests forwarding of the connection to the authentication
! 765: agent.
! 766:
! 767: SSH_CMSG_EXEC_SHELL
! 768: Starts a shell (command interpreter) for the user, and moves
! 769: into interactive session mode.
! 770:
! 771: SSH_CMSG_EXEC_CMD
! 772: Executes the given command (actually "<shell> -c <command>" or
! 773: equivalent) for the user, and moves into interactive session
! 774: mode.
! 775:
! 776:
! 777: Interactive Session and Exchange of Data
! 778:
! 779: During the interactive session, any data written by the shell or com-
! 780: mand running on the server machine is forwarded to stdin or stderr on
! 781: the client machine, and any input available from stdin on the client
! 782: machine is forwarded to the program on the server machine.
! 783:
! 784:
! 785:
! 786: Ylonen [Page 14]
! 787:
! 788: Internet-Draft SSH (Secure Shell) Remote Login Protocol 15 Nov 1995
! 789:
! 790:
! 791: All exchange is asynchronous; either side can send at any time, and
! 792: there are no acknowledgements (TCP/IP already provides reliable tran-
! 793: sport, and the packet protocol protects against tampering or IP
! 794: spoofing).
! 795:
! 796: When the client receives EOF from its standard input, it will send
! 797: SSH_CMSG_EOF; however, this in no way terminates the exchange. The
! 798: exchange terminates and interactive mode is left when the server
! 799: sends SSH_SMSG_EXITSTATUS to indicate that the client program has
! 800: terminated. Alternatively, either side may disconnect at any time by
! 801: sending SSH_MSG_DISCONNECT or closing the connection.
! 802:
! 803: The server may send any of the following messages:
! 804:
! 805: SSH_SMSG_STDOUT_DATA
! 806: Data written to stdout by the program running on the server.
! 807: The data is passed as a string argument. The client writes this
! 808: data to stdout.
! 809:
! 810: SSH_SMSG_STDERR_DATA
! 811: Data written to stderr by the program running on the server.
! 812: The data is passed as a string argument. The client writes this
! 813: data to stderr. (Note that if the program is running on a tty,
! 814: it is not possible to separate stdout and stderr data, and all
! 815: data will be sent as stdout data.)
! 816:
! 817: SSH_SMSG_EXITSTATUS
! 818: Indicates that the shell or command has exited. Exit status is
! 819: passed as an integer argument. This message causes termination
! 820: of the interactive session.
! 821:
! 822: SSH_SMSG_AGENT_OPEN
! 823: Indicates that someone on the server side is requesting a con-
! 824: nection to the authentication agent. The server-side channel
! 825: number is passed as an argument. The client must respond with
! 826: either SSH_CHANNEL_OPEN_CONFIRMATION or
! 827: SSH_CHANNEL_OPEN_FAILURE.
! 828:
! 829: SSH_SMSG_X11_OPEN
! 830: Indicates that a connection has been made to the X11 socket on
! 831: the server side and should be forwarded to the real X server.
! 832: An integer argument indicates the channel number allocated for
! 833: this connection on the server side. The client should send back
! 834: either SSH_MSG_CHANNEL_OPEN_CONFIRMATION or
! 835: SSH_MSG_CHANNEL_OPEN_FAILURE with the same server side channel
! 836: number.
! 837:
! 838: SSH_MSG_PORT_OPEN
! 839:
! 840:
! 841:
! 842: Ylonen [Page 15]
! 843:
! 844: Internet-Draft SSH (Secure Shell) Remote Login Protocol 15 Nov 1995
! 845:
! 846:
! 847: Indicates that a connection has been made to a port on the
! 848: server side for which forwarding has been requested. Arguments
! 849: are server side channel number, host name to connect to, and
! 850: port to connect to. The client should send back either
! 851: SSH_MSG_CHANNEL_OPEN_CONFIRMATION or
! 852: SSH_MSG_CHANNEL_OPEN_FAILURE with the same server side channel
! 853: number.
! 854:
! 855: SSH_MSG_CHANNEL_OPEN_CONFIRMATION
! 856: This is sent by the server to indicate that it has opened a con-
! 857: nection as requested in a previous message. The first argument
! 858: indicates the client side channel number, and the second argu-
! 859: ment is the channel number that the server has allocated for
! 860: this connection.
! 861:
! 862: SSH_MSG_CHANNEL_OPEN_FAILURE
! 863: This is sent by the server to indicate that it failed to open a
! 864: connection as requested in a previous message. The client-side
! 865: channel number is passed as an argument. The client will close
! 866: the descriptor associated with the channel and free the channel.
! 867:
! 868: SSH_MSG_CHANNEL_DATA
! 869: This packet contains data for a channel from the server. The
! 870: first argument is the client-side channel number, and the second
! 871: argument (a string) is the data.
! 872:
! 873: SSH_MSG_CHANNEL_CLOSE
! 874: This is sent by the server to indicate that whoever was in the
! 875: other end of the channel has closed it. The argument is the
! 876: client side channel number. The client will let all buffered
! 877: data in the channel to drain, and when ready, will close the
! 878: socket, free the channel, and send the server a
! 879: SSH_MSG_CHANNEL_CLOSE_CONFIRMATION message for the channel.
! 880:
! 881: SSH_MSG_CHANNEL_CLOSE_CONFIRMATION
! 882: This is send by the server to indicate that a channel previously
! 883: closed by the client has now been closed on the server side as
! 884: well. The argument indicates the client channel number. The
! 885: client frees the channel.
! 886:
! 887: The client may send any of the following messages:
! 888:
! 889: SSH_CMSG_STDIN_DATA
! 890: This is data to be sent as input to the program running on the
! 891: server. The data is passed as a string.
! 892:
! 893: SSH_CMSG_EOF
! 894: Indicates that the client has encountered EOF while reading
! 895:
! 896:
! 897:
! 898: Ylonen [Page 16]
! 899:
! 900: Internet-Draft SSH (Secure Shell) Remote Login Protocol 15 Nov 1995
! 901:
! 902:
! 903: standard input. The server will allow any buffered input data
! 904: to drain, and will then close the input to the program.
! 905:
! 906: SSH_CMSG_WINDOW_SIZE
! 907: Indicates that window size on the client has been changed. The
! 908: server updates the window size of the tty and causes SIGWINCH to
! 909: be sent to the program. The new window size is passed as four
! 910: integer arguments: row, col, xpixel, ypixel.
! 911:
! 912: SSH_MSG_PORT_OPEN
! 913: Indicates that a connection has been made to a port on the
! 914: client side for which forwarding has been requested. Arguments
! 915: are client side channel number, host name to connect to, and
! 916: port to connect to. The server should send back either
! 917: SSH_MSG_CHANNEL_OPEN_CONFIRMATION or
! 918: SSH_MSG_CHANNEL_OPEN_FAILURE with the same client side channel
! 919: number.
! 920:
! 921: SSH_MSG_CHANNEL_OPEN_CONFIRMATION
! 922: This is sent by the client to indicate that it has opened a con-
! 923: nection as requested in a previous message. The first argument
! 924: indicates the server side channel number, and the second argu-
! 925: ment is the channel number that the client has allocated for
! 926: this connection.
! 927:
! 928: SSH_MSG_CHANNEL_OPEN_FAILURE
! 929: This is sent by the client to indicate that it failed to open a
! 930: connection as requested in a previous message. The server side
! 931: channel number is passed as an argument. The server will close
! 932: the descriptor associated with the channel and free the channel.
! 933:
! 934: SSH_MSG_CHANNEL_DATA
! 935: This packet contains data for a channel from the client. The
! 936: first argument is the server side channel number, and the second
! 937: argument (a string) is the data.
! 938:
! 939: SSH_MSG_CHANNEL_CLOSE
! 940: This is sent by the client to indicate that whoever was in the
! 941: other end of the channel has closed it. The argument is the
! 942: server channel number. The server will allow buffered data to
! 943: drain, and when ready, will close the socket, free the channel,
! 944: and send the client a SSH_MSG_CHANNEL_CLOSE_CONFIRMATION message
! 945: for the channel.
! 946:
! 947: SSH_MSG_CHANNEL_CLOSE_CONFIRMATION
! 948: This is send by the client to indicate that a channel previously
! 949: closed by the server has now been closed on the client side as
! 950: well. The argument indicates the server channel number. The
! 951:
! 952:
! 953:
! 954: Ylonen [Page 17]
! 955:
! 956: Internet-Draft SSH (Secure Shell) Remote Login Protocol 15 Nov 1995
! 957:
! 958:
! 959: server frees the channel.
! 960:
! 961: Any unsupported messages during interactive mode cause the connection
! 962: to be terminated with SSH_MSG_DISCONNECT and an error message. Com-
! 963: patible protocol upgrades should agree about any extensions during
! 964: the preparation phase or earlier.
! 965:
! 966:
! 967: Termination of the Connection
! 968:
! 969: Normal termination of the connection is always initiated by the
! 970: server by sending SSH_SMSG_EXITSTATUS after the program has exited.
! 971: The client responds to this message by sending
! 972: SSH_CMSG_EXIT_CONFIRMATION and closes the socket; the server then
! 973: closes the socket. There are two purposes for the confirmation: some
! 974: systems may lose previously sent data when the socket is closed, and
! 975: closing the client side first causes any TCP/IP TIME_WAIT [RFC0793]
! 976: waits to occur on the client side, not consuming server resources.
! 977:
! 978: If the program terminates due to a signal, the server will send
! 979: SSH_MSG_DISCONNECT with an appropriate message. If the connection is
! 980: closed, all file descriptors to the program will be closed and the
! 981: server will exit. If the program runs on a tty, the kernel sends it
! 982: the SIGHUP signal when the pty master side is closed.
! 983:
! 984: Protocol Flags
! 985:
! 986: Both the server and the client pass 32 bits of protocol flags to the
! 987: other side. The flags are intended for compatible protocol exten-
! 988: sion; the server first announces which added capabilities it sup-
! 989: ports, and the client then sends the capabilities that it supports.
! 990:
! 991: The following flags are currently defined (the values are bit masks):
! 992:
! 993: 1 SSH_PROTOFLAG_SCREEN_NUMBER
! 994: This flag can only be sent by the client. It indicates that the
! 995: X11 forwarding requests it sends will include the screen number.
! 996:
! 997: 2 SSH_PROTOFLAG_HOST_IN_FWD_OPEN
! 998: If both sides specify this flag, SSH_SMSG_X11_OPEN and
! 999: SSH_MSG_PORT_OPEN messages will contain an additional field con-
! 1000: taining a description of the host at the other end of the con-
! 1001: nection.
! 1002:
! 1003: Detailed Description of Packet Types and Formats
! 1004:
! 1005: The supported packet types and the corresponding message numbers are
! 1006: given in the following table. Messages with _MSG_ in their name may
! 1007:
! 1008:
! 1009:
! 1010: Ylonen [Page 18]
! 1011:
! 1012: Internet-Draft SSH (Secure Shell) Remote Login Protocol 15 Nov 1995
! 1013:
! 1014:
! 1015: be sent by either side. Messages with _CMSG_ are only sent by the
! 1016: client, and messages with _SMSG_ only by the server.
! 1017:
! 1018: A packet may contain additional data after the arguments specified
! 1019: below. Any such data should be ignored by the receiver. However, it
! 1020: is recommended that no such data be stored without good reason.
! 1021: (This helps build compatible extensions.)
! 1022:
! 1023: 0 SSH_MSG_NONE
! 1024: This code is reserved. This message type is never sent.
! 1025:
! 1026: 1 SSH_MSG_DISCONNECT
! 1027:
! 1028: string Cause of disconnection
! 1029:
! 1030: This message may be sent by either party at any time. It causes
! 1031: the immediate disconnection of the connection. The message is
! 1032: intended to be displayed to a human, and describes the reason
! 1033: for disconnection.
! 1034:
! 1035: 2 SSH_SMSG_PUBLIC_KEY
! 1036:
! 1037: 8 bytes anti_spoofing_cookie
! 1038: 32-bit int server_key_bits
! 1039: mp-int server_key_public_exponent
! 1040: mp-int server_key_public_modulus
! 1041: 32-bit int host_key_bits
! 1042: mp-int host_key_public_exponent
! 1043: mp-int host_key_public_modulus
! 1044: 32-bit int protocol_flags
! 1045: 32-bit int supported_ciphers_mask
! 1046: 32-bit int supported_authentications_mask
! 1047:
! 1048: Sent as the first message by the server. This message gives the
! 1049: server's host key, server key, protocol flags (intended for com-
! 1050: patible protocol extension), supported_ciphers_mask (which is
! 1051: the bitwise or of (1 << cipher_number), where << is the left
! 1052: shift operator, for all supported ciphers), and
! 1053: supported_authentications_mask (which is the bitwise or of (1 <<
! 1054: authentication_type) for all supported authentication types).
! 1055: The anti_spoofing_cookie is 64 random bytes, and must be sent
! 1056: back verbatim by the client in its reply. It is used to make
! 1057: IP-spoofing more difficult (encryption and host keys are the
! 1058: real defense against spoofing).
! 1059:
! 1060: 3 SSH_CMSG_SESSION_KEY
! 1061:
! 1062: 1 byte cipher_type (must be one of the supported values)
! 1063:
! 1064:
! 1065:
! 1066: Ylonen [Page 19]
! 1067:
! 1068: Internet-Draft SSH (Secure Shell) Remote Login Protocol 15 Nov 1995
! 1069:
! 1070:
! 1071: 8 bytes anti_spoofing_cookie (must match data sent by the server)
! 1072: mp-int double-encrypted session key
! 1073: 32-bit int protocol_flags
! 1074:
! 1075: Sent by the client as the first message in the session. Selects
! 1076: the cipher to use, and sends the encrypted session key to the
! 1077: server. The anti_spoofing_cookie must be the same bytes that
! 1078: were sent by the server. Protocol_flags is intended for nego-
! 1079: tiating compatible protocol extensions.
! 1080:
! 1081: 4 SSH_CMSG_USER
! 1082:
! 1083: string user login name on server
! 1084:
! 1085: Sent by the client to begin authentication. Specifies the user
! 1086: name on the server to log in as. The server responds with
! 1087: SSH_SMSG_SUCCESS if no authentication is needed for this user,
! 1088: or SSH_SMSG_FAILURE if authentication is needed (or the user
! 1089: does not exist). [Note to the implementator: the user name is
! 1090: of arbitrary size. The implementation must be careful not to
! 1091: overflow internal buffers.]
! 1092:
! 1093: 5 SSH_CMSG_AUTH_RHOSTS
! 1094:
! 1095: string client-side user name
! 1096:
! 1097: Requests authentication using /etc/hosts.equiv and .rhosts (or
! 1098: equivalent mechanisms). This authentication method is normally
! 1099: disabled in the server because it is not secure (but this is the
! 1100: method used by rsh and rlogin). The server responds with
! 1101: SSH_SMSG_SUCCESS if authentication was successful, and
! 1102: SSH_SMSG_FAILURE if access was not granted. The server should
! 1103: check that the client side port number is less than 1024 (a
! 1104: privileged port), and immediately reject authentication if it is
! 1105: not. Supporting this authentication method is optional. This
! 1106: method should normally not be enabled in the server because it
! 1107: is not safe. (However, not enabling this only helps if rlogind
! 1108: and rshd are disabled.)
! 1109:
! 1110: 6 SSH_CMSG_AUTH_RSA
! 1111:
! 1112: mp-int identity_public_modulus
! 1113:
! 1114: Requests authentication using pure RSA authentication. The
! 1115: server checks if the given key is permitted to log in, and if
! 1116: so, responds with SSH_SMSG_AUTH_RSA_CHALLENGE. Otherwise, it
! 1117: responds with SSH_SMSG_FAILURE. The client often tries several
! 1118: different keys in sequence until one supported by the server is
! 1119:
! 1120:
! 1121:
! 1122: Ylonen [Page 20]
! 1123:
! 1124: Internet-Draft SSH (Secure Shell) Remote Login Protocol 15 Nov 1995
! 1125:
! 1126:
! 1127: found. Authentication is accepted if the client gives the
! 1128: correct response to the challenge. The server is free to add
! 1129: other criteria for authentication, such as a requirement that
! 1130: the connection must come from a certain host. Such additions
! 1131: are not visible at the protocol level. Supporting this authen-
! 1132: tication method is optional but recommended.
! 1133:
! 1134: 7 SSH_SMSG_AUTH_RSA_CHALLENGE
! 1135:
! 1136: mp-int encrypted challenge
! 1137:
! 1138: Presents an RSA authentication challenge to the client. The
! 1139: challenge is a 256-bit random value encrypted as described else-
! 1140: where in this document. The client must decrypt the challenge
! 1141: using the RSA private key, compute MD5 of the challenge plus
! 1142: session id, and send back the resulting 16 bytes using
! 1143: SSH_CMSG_AUTH_RSA_RESPONSE.
! 1144:
! 1145: 8 SSH_CMSG_AUTH_RSA_RESPONSE
! 1146:
! 1147: 16 bytes MD5 of decrypted challenge
! 1148:
! 1149: This message is sent by the client in response to an RSA chal-
! 1150: lenge. The MD5 checksum is returned instead of the decrypted
! 1151: challenge to deter known-plaintext attacks against the RSA key.
! 1152: The server responds to this message with either SSH_SMSG_SUCCESS
! 1153: or SSH_SMSG_FAILURE.
! 1154:
! 1155: 9 SSH_CMSG_AUTH_PASSWORD
! 1156:
! 1157: string plain text password
! 1158:
! 1159: Requests password authentication using the given password. Note
! 1160: that even though the password is plain text inside the packet,
! 1161: the whole packet is normally encrypted by the packet layer. It
! 1162: would not be possible for the client to perform password
! 1163: encryption/hashing, because it cannot know which kind of
! 1164: encryption/hashing, if any, the server uses. The server
! 1165: responds to this message with SSH_SMSG_SUCCESS or
! 1166: SSH_SMSG_FAILURE.
! 1167:
! 1168: 10 SSH_CMSG_REQUEST_PTY
! 1169:
! 1170: string TERM environment variable value (e.g. vt100)
! 1171: 32-bit int terminal height, rows (e.g., 24)
! 1172: 32-bit int terminal width, columns (e.g., 80)
! 1173: 32-bit int terminal width, pixels (0 if no graphics) (e.g., 480)
! 1174: 32-bit int terminal height, pixels (0 if no graphics) (e.g., 640)
! 1175:
! 1176:
! 1177:
! 1178: Ylonen [Page 21]
! 1179:
! 1180: Internet-Draft SSH (Secure Shell) Remote Login Protocol 15 Nov 1995
! 1181:
! 1182:
! 1183: n bytes tty modes encoded in binary
! 1184:
! 1185: Requests a pseudo-terminal to be allocated for this command.
! 1186: This message can be used regardless of whether the session will
! 1187: later execute the shell or a command. If a pty has been
! 1188: requested with this message, the shell or command will run on a
! 1189: pty. Otherwise it will communicate with the server using pipes,
! 1190: sockets or some other similar mechanism.
! 1191:
! 1192: The terminal type gives the type of the user's terminal. In the
! 1193: UNIX environment it is passed to the shell or command in the
! 1194: TERM environment variable.
! 1195:
! 1196: The width and height values give the initial size of the user's
! 1197: terminal or window. All values can be zero if not supported by
! 1198: the operating system. The server will pass these values to the
! 1199: kernel if supported.
! 1200:
! 1201: Terminal modes are encoded into a byte stream in a portable for-
! 1202: mat. The exact format is described later in this document.
! 1203:
! 1204: The server responds to the request with either SSH_SMSG_SUCCESS
! 1205: or SSH_SMSG_FAILURE. If the server does not have the concept of
! 1206: pseudo terminals, it should return success if it is possible to
! 1207: execute a shell or a command so that it looks to the client as
! 1208: if it was running on a pseudo terminal.
! 1209:
! 1210: 11 SSH_CMSG_WINDOW_SIZE
! 1211:
! 1212: 32-bit int terminal height, rows
! 1213: 32-bit int terminal width, columns
! 1214: 32-bit int terminal width, pixels
! 1215: 32-bit int terminal height, pixels
! 1216:
! 1217: This message can only be sent by the client during the interac-
! 1218: tive session. This indicates that the size of the user's window
! 1219: has changed, and provides the new size. The server will update
! 1220: the kernel's notion of the window size, and a SIGWINCH signal or
! 1221: equivalent will be sent to the shell or command (if supported by
! 1222: the operating system).
! 1223:
! 1224: 12 SSH_CMSG_EXEC_SHELL
! 1225:
! 1226: (no arguments)
! 1227:
! 1228: Starts a shell (command interpreter), and enters interactive
! 1229: session mode.
! 1230:
! 1231:
! 1232:
! 1233:
! 1234: Ylonen [Page 22]
! 1235:
! 1236: Internet-Draft SSH (Secure Shell) Remote Login Protocol 15 Nov 1995
! 1237:
! 1238:
! 1239: 13 SSH_CMSG_EXEC_CMD
! 1240:
! 1241: string command to execute
! 1242:
! 1243: Starts executing the given command, and enters interactive ses-
! 1244: sion mode. On UNIX, the command is run as "<shell> -c <com-
! 1245: mand>", where <shell> is the user's login shell.
! 1246:
! 1247: 14 SSH_SMSG_SUCCESS
! 1248:
! 1249: (no arguments)
! 1250:
! 1251: This message is sent by the server in response to the session
! 1252: key, a successful authentication request, and a successfully
! 1253: completed preparatory operation.
! 1254:
! 1255: 15 SSH_SMSG_FAILURE
! 1256:
! 1257: (no arguments)
! 1258:
! 1259: This message is sent by the server in response to a failed
! 1260: authentication operation to indicate that the user has not yet
! 1261: been successfully authenticated, and in response to a failed
! 1262: preparatory operation. This is also sent in response to an
! 1263: authentication or preparatory operation request that is not
! 1264: recognized or supported.
! 1265:
! 1266: 16 SSH_CMSG_STDIN_DATA
! 1267:
! 1268: string data
! 1269:
! 1270: Delivers data from the client to be supplied as input to the
! 1271: shell or program running on the server side. This message can
! 1272: only be used in the interactive session mode. No acknowledge-
! 1273: ment is sent for this message.
! 1274:
! 1275: 17 SSH_SMSG_STDOUT_DATA
! 1276:
! 1277: string data
! 1278:
! 1279: Delivers data from the server that was read from the standard
! 1280: output of the shell or program running on the server side. This
! 1281: message can only be used in the interactive session mode. No
! 1282: acknowledgement is sent for this message.
! 1283:
! 1284: 18 SSH_SMSG_STDERR_DATA
! 1285:
! 1286: string data
! 1287:
! 1288:
! 1289:
! 1290: Ylonen [Page 23]
! 1291:
! 1292: Internet-Draft SSH (Secure Shell) Remote Login Protocol 15 Nov 1995
! 1293:
! 1294:
! 1295: Delivers data from the server that was read from the standard
! 1296: error of the shell or program running on the server side. This
! 1297: message can only be used in the interactive session mode. No
! 1298: acknowledgement is sent for this message.
! 1299:
! 1300: 19 SSH_CMSG_EOF
! 1301:
! 1302: (no arguments)
! 1303:
! 1304: This message is sent by the client to indicate that EOF has been
! 1305: reached on the input. Upon receiving this message, and after
! 1306: all buffered input data has been sent to the shell or program,
! 1307: the server will close the input file descriptor to the program.
! 1308: This message can only be used in the interactive session mode.
! 1309: No acknowledgement is sent for this message.
! 1310:
! 1311: 20 SSH_SMSG_EXITSTATUS
! 1312:
! 1313: 32-bit int exit status of the command
! 1314:
! 1315: Returns the exit status of the shell or program after it has
! 1316: exited. The client should respond with
! 1317: SSH_CMSG_EXIT_CONFIRMATION when it has received this message.
! 1318: This will be the last message sent by the server. If the pro-
! 1319: gram being executed dies with a signal instead of exiting nor-
! 1320: mally, the server should terminate the session with
! 1321: SSH_MSG_DISCONNECT (which can be used to pass a human-readable
! 1322: string indicating that the program died due to a signal) instead
! 1323: of using this message.
! 1324:
! 1325: 21 SSH_MSG_CHANNEL_OPEN_CONFIRMATION
! 1326:
! 1327: 32-bit int remote_channel
! 1328: 32-bit int local_channel
! 1329:
! 1330: This is sent in response to any channel open request if the
! 1331: channel has been successfully opened. Remote_channel is the
! 1332: channel number received in the initial open request;
! 1333: local_channel is the channel number the side sending this mes-
! 1334: sage has allocated for the channel. Data can be transmitted on
! 1335: the channel after this message.
! 1336:
! 1337: 22 SSH_MSG_CHANNEL_OPEN_FAILURE
! 1338:
! 1339: 32-bit int remote_channel
! 1340:
! 1341: This message indicates that an earlier channel open request by
! 1342: the other side has failed or has been denied. Remote_channel is
! 1343:
! 1344:
! 1345:
! 1346: Ylonen [Page 24]
! 1347:
! 1348: Internet-Draft SSH (Secure Shell) Remote Login Protocol 15 Nov 1995
! 1349:
! 1350:
! 1351: the channel number given in the original request.
! 1352:
! 1353: 23 SSH_MSG_CHANNEL_DATA
! 1354:
! 1355: 32-bit int remote_channel
! 1356: string data
! 1357:
! 1358: Data is transmitted in a channel in these messages. A channel
! 1359: is bidirectional, and both sides can send these messages. There
! 1360: is no acknowledgement for these messages. It is possible that
! 1361: either side receives these messages after it has sent
! 1362: SSH_MSG_CHANNEL_CLOSE for the channel. These messages cannot be
! 1363: received after the party has sent or received
! 1364: SSH_MSG_CHANNEL_CLOSE_CONFIRMATION.
! 1365:
! 1366: 24 SSH_MSG_CHANNEL_CLOSE
! 1367:
! 1368: 32-bit int remote_channel
! 1369:
! 1370: When a channel is closed at one end of the connection, that side
! 1371: sends this message. Upon receiving this message, the channel
! 1372: should be closed. When this message is received, if the channel
! 1373: is already closed (the receiving side has sent this message for
! 1374: the same channel earlier), the channel is freed and no further
! 1375: action is taken; otherwise the channel is freed and
! 1376: SSH_MSG_CHANNEL_CLOSE_CONFIRMATION is sent in response. (It is
! 1377: possible that the channel is closed simultaneously at both
! 1378: ends.)
! 1379:
! 1380: 25 SSH_MSG_CHANNEL_CLOSE_CONFIRMATION
! 1381:
! 1382: 32-bit int remote_channel
! 1383:
! 1384: This message is sent in response to SSH_MSG_CHANNEL_CLOSE unless
! 1385: the channel was already closed. When this message is sent or
! 1386: received, the channel is freed.
! 1387:
! 1388: 26 (OBSOLETED; was unix-domain X11 forwarding)
! 1389:
! 1390: 27 SSH_SMSG_X11_OPEN
! 1391:
! 1392: 32-bit int local_channel
! 1393: string originator_string (see below)
! 1394:
! 1395: This message can be sent by the server during the interactive
! 1396: session mode to indicate that a client has connected the fake X
! 1397: server. Local_channel is the channel number that the server has
! 1398: allocated for the connection. The client should try to open a
! 1399:
! 1400:
! 1401:
! 1402: Ylonen [Page 25]
! 1403:
! 1404: Internet-Draft SSH (Secure Shell) Remote Login Protocol 15 Nov 1995
! 1405:
! 1406:
! 1407: connection to the real X server, and respond with
! 1408: SSH_MSG_CHANNEL_OPEN_CONFIRMATION or
! 1409: SSH_MSG_CHANNEL_OPEN_FAILURE.
! 1410:
! 1411: The field originator_string is present if both sides specified
! 1412: SSH_PROTOFLAG_HOST_IN_FWD_OPEN in the protocol flags. It con-
! 1413: tains a description of the host originating the connection.
! 1414:
! 1415: 28 SSH_CMSG_PORT_FORWARD_REQUEST
! 1416:
! 1417: 32-bit int server_port
! 1418: string host_to_connect
! 1419: 32-bit int port_to_connect
! 1420:
! 1421: Sent by the client in the preparatory phase, this message
! 1422: requests that server_port on the server machine be forwarded
! 1423: over the secure channel to the client machine, and from there to
! 1424: the specified host and port. The server should start listening
! 1425: on the port, and send SSH_MSG_PORT_OPEN whenever a connection is
! 1426: made to it. Supporting this message is optional, and the server
! 1427: is free to reject any forward request. For example, it is
! 1428: highly recommended that unless the user has been authenticated
! 1429: as root, forwarding any privileged port numbers (below 1024) is
! 1430: denied.
! 1431:
! 1432: 29 SSH_MSG_PORT_OPEN
! 1433:
! 1434: 32-bit int local_channel
! 1435: string host_name
! 1436: 32-bit int port
! 1437: string originator_string (see below)
! 1438:
! 1439: Sent by either party in interactive session mode, this message
! 1440: indicates that a connection has been opened to a forwarded
! 1441: TCP/IP port. Local_channel is the channel number that the send-
! 1442: ing party has allocated for the connection. Host_name is the
! 1443: host the connection should be be forwarded to, and the port is
! 1444: the port on that host to connect. The receiving party should
! 1445: open the connection, and respond with
! 1446: SSH_MSG_CHANNEL_OPEN_CONFIRMATION or
! 1447: SSH_MSG_CHANNEL_OPEN_FAILURE. It is recommended that the
! 1448: receiving side check the host_name and port for validity to
! 1449: avoid compromising local security by compromised remote side
! 1450: software. Particularly, it is recommended that the client per-
! 1451: mit connections only to those ports for which it has requested
! 1452: forwarding with SSH_CMSG_PORT_FORWARD_REQUEST.
! 1453:
! 1454: The field originator_string is present if both sides specified
! 1455:
! 1456:
! 1457:
! 1458: Ylonen [Page 26]
! 1459:
! 1460: Internet-Draft SSH (Secure Shell) Remote Login Protocol 15 Nov 1995
! 1461:
! 1462:
! 1463: SSH_PROTOFLAG_HOST_IN_FWD_OPEN in the protocol flags. It con-
! 1464: tains a description of the host originating the connection.
! 1465:
! 1466: 30 SSH_CMSG_AGENT_REQUEST_FORWARDING
! 1467:
! 1468: (no arguments)
! 1469:
! 1470: Requests that the connection to the authentication agent be for-
! 1471: warded over the secure channel. The method used by clients to
! 1472: contact the authentication agent within each machine is imple-
! 1473: mentation and machine dependent. If the server accepts this
! 1474: request, it should arrange that any clients run from this ses-
! 1475: sion will actually contact the server program when they try to
! 1476: contact the authentication agent. The server should then send a
! 1477: SSH_SMSG_AGENT_OPEN to open a channel to the agent, and the
! 1478: client should forward the connection to the real authentication
! 1479: agent. Supporting this message is optional.
! 1480:
! 1481: 31 SSH_SMSG_AGENT_OPEN
! 1482:
! 1483: 32-bit int local_channel
! 1484:
! 1485: Sent by the server in interactive session mode, this message
! 1486: requests opening a channel to the authentication agent. The
! 1487: client should open a channel, and respond with either
! 1488: SSH_MSG_CHANNEL_OPEN_CONFIRMATION or
! 1489: SSH_MSG_CHANNEL_OPEN_FAILURE.
! 1490:
! 1491: 32 SSH_MSG_IGNORE
! 1492:
! 1493: string data
! 1494:
! 1495: Either party may send this message at any time. This message,
! 1496: and the argument string, is silently ignored. This message
! 1497: might be used in some implementations to make traffic analysis
! 1498: more difficult. This message is not currently sent by the
! 1499: implementation, but all implementations are required to recog-
! 1500: nize and ignore it.
! 1501:
! 1502: 33 SSH_CMSG_EXIT_CONFIRMATION
! 1503:
! 1504: (no arguments)
! 1505:
! 1506: Sent by the client in response to SSH_SMSG_EXITSTATUS. This is
! 1507: the last message sent by the client.
! 1508:
! 1509: 34 SSH_CMSG_X11_REQUEST_FORWARDING
! 1510:
! 1511:
! 1512:
! 1513:
! 1514: Ylonen [Page 27]
! 1515:
! 1516: Internet-Draft SSH (Secure Shell) Remote Login Protocol 15 Nov 1995
! 1517:
! 1518:
! 1519: string x11_authentication_protocol
! 1520: string x11_authentication_data
! 1521: 32-bit int screen number (if SSH_PROTOFLAG_SCREEN_NUMBER)
! 1522:
! 1523: Sent by the client during the preparatory phase, this message
! 1524: requests that the server create a fake X11 display and set the
! 1525: DISPLAY environment variable accordingly. An internet-domain
! 1526: display is preferable. The given authentication protocol and
! 1527: the associated data should be recorded by the server so that it
! 1528: is used as authentication on connections (e.g., in .Xauthority).
! 1529: The authentication protocol must be one of the supported X11
! 1530: authentication protocols, e.g., "MIT-MAGIC-COOKIE-1". Authenti-
! 1531: cation data must be a lowercase hex string of even length. Its
! 1532: interpretation is protocol dependent. The data is in a format
! 1533: that can be used with e.g. the xauth program. Supporting this
! 1534: message is optional.
! 1535:
! 1536: The client is permitted (and recommended) to generate fake
! 1537: authentication information and send fake information to the
! 1538: server. This way, a corrupt server will not have access to the
! 1539: user's terminal after the connection has terminated. The
! 1540: correct authorization codes will also not be left hanging around
! 1541: in files on the server (many users keep the same X session for
! 1542: months, thus protecting the authorization data becomes impor-
! 1543: tant).
! 1544:
! 1545: X11 authentication spoofing works by initially sending fake
! 1546: (random) authentication data to the server, and interpreting the
! 1547: first packet sent by the X11 client after the connection has
! 1548: been opened. The first packet contains the client's authentica-
! 1549: tion. If the packet contains the correct fake data, it is
! 1550: replaced by the client by the correct authentication data, and
! 1551: then sent to the X server.
! 1552:
! 1553: 35 SSH_CMSG_AUTH_RHOSTS_RSA
! 1554:
! 1555: string clint-side user name
! 1556: 32-bit int client_host_key_bits
! 1557: mp-int client_host_key_public_exponent
! 1558: mp-int client_host_key_public_modulus
! 1559:
! 1560: Requests authentication using /etc/hosts.equiv and .rhosts (or
! 1561: equivalent) together with RSA host authentication. The server
! 1562: should check that the client side port number is less than 1024
! 1563: (a privileged port), and immediately reject authentication if it
! 1564: is not. The server responds with SSH_SMSG_FAILURE or
! 1565: SSH_SMSG_AUTH_RSA_CHALLENGE. The client must respond to the
! 1566: challenge with the proper SSH_CMSG_AUTH_RSA_RESPONSE. The
! 1567:
! 1568:
! 1569:
! 1570: Ylonen [Page 28]
! 1571:
! 1572: Internet-Draft SSH (Secure Shell) Remote Login Protocol 15 Nov 1995
! 1573:
! 1574:
! 1575: server then responds with success if access was granted, or
! 1576: failure if the client gave a wrong response. Supporting this
! 1577: authentication method is optional but recommended in most
! 1578: environments.
! 1579:
! 1580: 36 SSH_MSG_DEBUG
! 1581:
! 1582: string debugging message sent to the other side
! 1583:
! 1584: This message may be sent by either party at any time. It is
! 1585: used to send debugging messages that may be informative to the
! 1586: user in solving various problems. For example, if authentica-
! 1587: tion fails because of some configuration error (e.g., incorrect
! 1588: permissions for some file), it can be very helpful for the user
! 1589: to make the cause of failure available. On the other hand, one
! 1590: should not make too much information available for security rea-
! 1591: sons. It is recommended that the client provides an option to
! 1592: display the debugging information sent by the sender (the user
! 1593: probably does not want to see it by default). The server can
! 1594: log debugging data sent by the client (if any). Either party is
! 1595: free to ignore any received debugging data. Every implementa-
! 1596: tion must be able to receive this message, but no implementation
! 1597: is required to send these.
! 1598:
! 1599: 37 SSH_CMSG_REQUEST_COMPRESSION
! 1600:
! 1601: 32-bit int gzip compression level (1-9)
! 1602:
! 1603: This message can be sent by the client in the preparatory opera-
! 1604: tions phase. The server responds with SSH_SMSG_FAILURE if it
! 1605: does not support compression or does not want to compress; it
! 1606: responds with SSH_SMSG_SUCCESS if it accepted the compression
! 1607: request. In the latter case the response to this packet will
! 1608: still be uncompressed, but all further packets in either direc-
! 1609: tion will be compressed by gzip.
! 1610:
! 1611:
! 1612: Encoding of Terminal Modes
! 1613:
! 1614: Terminal modes (as passed in SSH_CMSG_REQUEST_PTY) are encoded into a
! 1615: byte stream. It is intended that the coding be portable across dif-
! 1616: ferent environments.
! 1617:
! 1618: The tty mode description is a stream of bytes. The stream consists
! 1619: of opcode-argument pairs. It is terminated by opcode TTY_OP_END (0).
! 1620: Opcodes 1-127 have one-byte arguments. Opcodes 128-159 have 32-bit
! 1621: integer arguments (stored msb first). Opcodes 160-255 are not yet
! 1622: defined, and cause parsing to stop (they should only be used after
! 1623:
! 1624:
! 1625:
! 1626: Ylonen [Page 29]
! 1627:
! 1628: Internet-Draft SSH (Secure Shell) Remote Login Protocol 15 Nov 1995
! 1629:
! 1630:
! 1631: any other data).
! 1632:
! 1633: The client puts in the stream any modes it knows about, and the
! 1634: server ignores any modes it does not know about. This allows some
! 1635: degree of machine-independence, at least between systems that use a
! 1636: POSIX-like [POSIX] tty interface. The protocol can support other
! 1637: systems as well, but the client may need to fill reasonable values
! 1638: for a number of parameters so the server pty gets set to a reasonable
! 1639: mode (the server leaves all unspecified mode bits in their default
! 1640: values, and only some combinations make sense).
! 1641:
! 1642: The following opcodes have been defined. The naming of opcodes
! 1643: mostly follows the POSIX terminal mode flags.
! 1644:
! 1645: 0 TTY_OP_END
! 1646: Indicates end of options.
! 1647:
! 1648: 1 VINTR
! 1649: Interrupt character; 255 if none. Similarly for the other char-
! 1650: acters. Not all of these characters are supported on all sys-
! 1651: tems.
! 1652:
! 1653: 2 VQUIT
! 1654: The quit character (sends SIGQUIT signal on UNIX systems).
! 1655:
! 1656: 3 VERASE
! 1657: Erase the character to left of the cursor.
! 1658:
! 1659: 4 VKILL
! 1660: Kill the current input line.
! 1661:
! 1662: 5 VEOF
! 1663: End-of-file character (sends EOF from the terminal).
! 1664:
! 1665: 6 VEOL
! 1666: End-of-line character in addition to carriage return and/or
! 1667: linefeed.
! 1668:
! 1669: 7 VEOL2
! 1670: Additional end-of-line character.
! 1671:
! 1672: 8 VSTART
! 1673: Continues paused output (normally ^Q).
! 1674:
! 1675: 9 VSTOP
! 1676: Pauses output (^S).
! 1677:
! 1678: 10 VSUSP
! 1679:
! 1680:
! 1681:
! 1682: Ylonen [Page 30]
! 1683:
! 1684: Internet-Draft SSH (Secure Shell) Remote Login Protocol 15 Nov 1995
! 1685:
! 1686:
! 1687: Suspends the current program.
! 1688:
! 1689: 11 VDSUSP
! 1690: Another suspend character.
! 1691:
! 1692: 12 VREPRINT
! 1693: Reprints the current input line.
! 1694:
! 1695: 13 VWERASE
! 1696: Erases a word left of cursor.
! 1697:
! 1698: 14 VLNEXT
! 1699: More special input characters; these are probably not supported
! 1700: on most systems.
! 1701:
! 1702: 15 VFLUSH
! 1703:
! 1704: 16 VSWTCH
! 1705:
! 1706: 17 VSTATUS
! 1707:
! 1708: 18 VDISCARD
! 1709:
! 1710:
! 1711: 30 IGNPAR
! 1712: The ignore parity flag. The next byte should be 0 if this flag
! 1713: is not set, and 1 if it is set.
! 1714:
! 1715: 31 PARMRK
! 1716: More flags. The exact definitions can be found in the POSIX
! 1717: standard.
! 1718:
! 1719: 32 INPCK
! 1720:
! 1721: 33 ISTRIP
! 1722:
! 1723: 34 INLCR
! 1724:
! 1725: 35 IGNCR
! 1726:
! 1727: 36 ICRNL
! 1728:
! 1729: 37 IUCLC
! 1730:
! 1731: 38 IXON
! 1732:
! 1733: 39 IXANY
! 1734:
! 1735:
! 1736:
! 1737:
! 1738: Ylonen [Page 31]
! 1739:
! 1740: Internet-Draft SSH (Secure Shell) Remote Login Protocol 15 Nov 1995
! 1741:
! 1742:
! 1743: 40 IXOFF
! 1744:
! 1745: 41 IMAXBEL
! 1746:
! 1747:
! 1748: 50 ISIG
! 1749:
! 1750: 51 ICANON
! 1751:
! 1752: 52 XCASE
! 1753:
! 1754: 53 ECHO
! 1755:
! 1756: 54 ECHOE
! 1757:
! 1758: 55 ECHOK
! 1759:
! 1760: 56 ECHONL
! 1761:
! 1762: 57 NOFLSH
! 1763:
! 1764: 58 TOSTOP
! 1765:
! 1766: 59 IEXTEN
! 1767:
! 1768: 60 ECHOCTL
! 1769:
! 1770: 61 ECHOKE
! 1771:
! 1772: 62 PENDIN
! 1773:
! 1774:
! 1775: 70 OPOST
! 1776:
! 1777: 71 OLCUC
! 1778:
! 1779: 72 ONLCR
! 1780:
! 1781: 73 OCRNL
! 1782:
! 1783: 74 ONOCR
! 1784:
! 1785: 75 ONLRET
! 1786:
! 1787:
! 1788: 90 CS7
! 1789:
! 1790: 91 CS8
! 1791:
! 1792:
! 1793:
! 1794: Ylonen [Page 32]
! 1795:
! 1796: Internet-Draft SSH (Secure Shell) Remote Login Protocol 15 Nov 1995
! 1797:
! 1798:
! 1799: 92 PARENB
! 1800:
! 1801: 93 PARODD
! 1802:
! 1803:
! 1804: 192 TTY_OP_ISPEED
! 1805: Specifies the input baud rate in bits per second.
! 1806:
! 1807: 193 TTY_OP_OSPEED
! 1808: Specifies the output baud rate in bits per second.
! 1809:
! 1810:
! 1811: The Authentication Agent Protocol
! 1812:
! 1813: The authentication agent is a program that can be used to hold RSA
! 1814: authentication keys for the user (in future, it might hold data for
! 1815: other authentication types as well). An authorized program can send
! 1816: requests to the agent to generate a proper response to an RSA chal-
! 1817: lenge. How the connection is made to the agent (or its representa-
! 1818: tive) inside a host and how access control is done inside a host is
! 1819: implementation-dependent; however, how it is forwarded and how one
! 1820: interacts with it is specified in this protocol. The connection to
! 1821: the agent is normally automatically forwarded over the secure chan-
! 1822: nel.
! 1823:
! 1824: A program that wishes to use the agent first opens a connection to
! 1825: its local representative (typically, the agent itself or an SSH
! 1826: server). It then writes a request to the connection, and waits for
! 1827: response. It is recommended that at least five minutes of timeout
! 1828: are provided waiting for the agent to respond to an authentication
! 1829: challenge (this gives sufficient time for the user to cut-and-paste
! 1830: the challenge to a separate machine, perform the computation there,
! 1831: and cut-and-paste the result back if so desired).
! 1832:
! 1833: Messages sent to and by the agent are in the following format:
! 1834:
! 1835: 4 bytes Length, msb first. Does not include length itself.
! 1836: 1 byte Packet type. The value 255 is reserved for future extensions.
! 1837: data Any data, depending on packet type. Encoding as in the ssh packet
! 1838: protocol.
! 1839:
! 1840:
! 1841: The following message types are currently defined:
! 1842:
! 1843: 1 SSH_AGENTC_REQUEST_RSA_IDENTITIES
! 1844:
! 1845: (no arguments)
! 1846:
! 1847:
! 1848:
! 1849:
! 1850: Ylonen [Page 33]
! 1851:
! 1852: Internet-Draft SSH (Secure Shell) Remote Login Protocol 15 Nov 1995
! 1853:
! 1854:
! 1855: Requests the agent to send a list of all RSA keys for which it
! 1856: can answer a challenge.
! 1857:
! 1858: 2 SSH_AGENT_RSA_IDENTITIES_ANSWER
! 1859:
! 1860: 32-bit int howmany
! 1861: howmany times:
! 1862: 32-bit int bits
! 1863: mp-int public exponent
! 1864: mp-int public modulus
! 1865: string comment
! 1866:
! 1867: The agent sends this message in response to the to
! 1868: SSH_AGENTC_REQUEST_RSA_IDENTITIES. The answer lists all RSA
! 1869: keys for which the agent can answer a challenge. The comment
! 1870: field is intended to help identify each key; it may be printed
! 1871: by an application to indicate which key is being used. If the
! 1872: agent is not holding any keys, howmany will be zero.
! 1873:
! 1874: 3 SSH_AGENTC_RSA_CHALLENGE
! 1875:
! 1876: 32-bit int bits
! 1877: mp-int public exponent
! 1878: mp-int public modulus
! 1879: mp-int challenge
! 1880: 16 bytes session_id
! 1881: 32-bit int response_type
! 1882:
! 1883: Requests RSA decryption of random challenge to authenticate the
! 1884: other side. The challenge will be decrypted with the RSA
! 1885: private key corresponding to the given public key.
! 1886:
! 1887: The decrypted challenge must contain a zero in the highest (par-
! 1888: tial) byte, 2 in the next byte, followed by non-zero random
! 1889: bytes, a zero byte, and then the real challenge value in the
! 1890: lowermost bytes. The real challenge must be 32 8-bit bytes (256
! 1891: bits).
! 1892:
! 1893: Response_type indicates the format of the response to be
! 1894: returned. Currently the only supported value is 1, which means
! 1895: to compute MD5 of the real challenge plus session id, and return
! 1896: the resulting 16 bytes in a SSH_AGENT_RSA_RESPONSE message.
! 1897:
! 1898: 4 SSH_AGENT_RSA_RESPONSE
! 1899:
! 1900: 16 bytes MD5 of decrypted challenge
! 1901:
! 1902: Answers an RSA authentication challenge. The response is 16
! 1903:
! 1904:
! 1905:
! 1906: Ylonen [Page 34]
! 1907:
! 1908: Internet-Draft SSH (Secure Shell) Remote Login Protocol 15 Nov 1995
! 1909:
! 1910:
! 1911: bytes: the MD5 checksum of the 32-byte challenge.
! 1912:
! 1913: 5 SSH_AGENT_FAILURE
! 1914:
! 1915: (no arguments)
! 1916:
! 1917: This message is sent whenever the agent fails to answer a
! 1918: request properly. For example, if the agent cannot answer a
! 1919: challenge (e.g., no longer has the proper key), it can respond
! 1920: with this. The agent also responds with this message if it
! 1921: receives a message it does not recognize.
! 1922:
! 1923: 6 SSH_AGENT_SUCCESS
! 1924:
! 1925: (no arguments)
! 1926:
! 1927: This message is sent by the agent as a response to certain
! 1928: requests that do not otherwise cause a message be sent.
! 1929: Currently, this is only sent in response to
! 1930: SSH_AGENTC_ADD_RSA_IDENTITY and SSH_AGENTC_REMOVE_RSA_IDENTITY.
! 1931:
! 1932: 7 SSH_AGENTC_ADD_RSA_IDENTITY
! 1933:
! 1934: 32-bit int bits
! 1935: mp-int public modulus
! 1936: mp-int public exponent
! 1937: mp-int private exponent
! 1938: mp-int multiplicative inverse of p mod q
! 1939: mp-int p
! 1940: mp-int q
! 1941: string comment
! 1942:
! 1943: Registers an RSA key with the agent. After this request, the
! 1944: agent can use this RSA key to answer requests. The agent
! 1945: responds with SSH_AGENT_SUCCESS or SSH_AGENT_FAILURE.
! 1946:
! 1947: 8 SSH_AGENT_REMOVE_RSA_IDENTITY
! 1948:
! 1949: 32-bit int bits
! 1950: mp-int public exponent
! 1951: mp-int public modulus
! 1952:
! 1953: Removes an RSA key from the agent. The agent will no longer
! 1954: accept challenges for this key and will not list it as a sup-
! 1955: ported identity. The agent responds with SSH_AGENT_SUCCESS or
! 1956: SSH_AGENT_FAILURE.
! 1957:
! 1958: If the agent receives a message that it does not understand, it
! 1959:
! 1960:
! 1961:
! 1962: Ylonen [Page 35]
! 1963:
! 1964: Internet-Draft SSH (Secure Shell) Remote Login Protocol 15 Nov 1995
! 1965:
! 1966:
! 1967: responds with SSH_AGENT_FAILURE. This permits compatible future
! 1968: extensions.
! 1969:
! 1970: It is possible that several clients have a connection open to the
! 1971: authentication agent simultaneously. Each client will use a separate
! 1972: connection (thus, any SSH connection can have multiple agent connec-
! 1973: tions active simultaneously).
! 1974:
! 1975:
! 1976: References
! 1977:
! 1978:
! 1979: [DES] FIPS PUB 46-1: Data Encryption Standard. National Bureau of
! 1980: Standards, January 1988. FIPS PUB 81: DES Modes of Operation.
! 1981: National Bureau of Standards, December 1980. Bruce Schneier:
! 1982: Applied Cryptography. John Wiley & Sons, 1994. J. Seberry and
! 1983: J. Pieprzyk: Cryptography: An Introduction to Computer Secu-
! 1984: rity. Prentice-Hall, 1989.
! 1985:
! 1986: [GZIP]
! 1987: The GNU GZIP program; available for anonymous ftp at
! 1988: prep.ai.mit.edu. Please let me know if you know a paper
! 1989: describing the algorithm.
! 1990:
! 1991: [IDEA]
! 1992: Xuejia Lai: On the Design and Security of Block Ciphers, ETH
! 1993: Series in Information Processing, vol. 1, Hartung-Gorre Verlag,
! 1994: Konstanz, Switzerland, 1992. Bruce Schneier: Applied Cryptogra-
! 1995: phy, John Wiley & Sons, 1994. See also the following patents:
! 1996: PCT/CH91/00117, EP 0 482 154 B1, US Pat. 5,214,703.
! 1997:
! 1998: [PKCS#1]
! 1999: PKCS #1: RSA Encryption Standard. Version 1.5, RSA Labora-
! 2000: tories, November 1993. Available for anonymous ftp at
! 2001: ftp.rsa.com.
! 2002:
! 2003: [POSIX]
! 2004: Portable Operating System Interface (POSIX) - Part 1: Applica-
! 2005: tion Program Interface (API) [C language], ISO/IEC 9945-1, IEEE
! 2006: Std 1003.1, 1990.
! 2007:
! 2008: [RFC0791]
! 2009: J. Postel: Internet Protocol, RFC 791, USC/ISI, September 1981.
! 2010:
! 2011: [RFC0793]
! 2012: J. Postel: Transmission Control Protocol, RFC 793, USC/ISI, Sep-
! 2013: tember 1981.
! 2014:
! 2015:
! 2016:
! 2017:
! 2018: Ylonen [Page 36]
! 2019:
! 2020: Internet-Draft SSH (Secure Shell) Remote Login Protocol 15 Nov 1995
! 2021:
! 2022:
! 2023: [RFC1034]
! 2024: P. Mockapetris: Domain Names - Concepts and Facilities, RFC
! 2025: 1034, USC/ISI, November 1987.
! 2026:
! 2027: [RFC1282]
! 2028: B. Kantor: BSD Rlogin, RFC 1258, UCSD, December 1991.
! 2029:
! 2030: [RSA] Bruce Schneier: Applied Cryptography. John Wiley & Sons, 1994.
! 2031: See also R. Rivest, A. Shamir, and L. M. Adleman: Cryptographic
! 2032: Communications System and Method. US Patent 4,405,829, 1983.
! 2033:
! 2034: [X11] R. Scheifler: X Window System Protocol, X Consortium Standard,
! 2035: Version 11, Release 6. Massachusetts Institute of Technology,
! 2036: Laboratory of Computer Science, 1994.
! 2037:
! 2038:
! 2039: Security Considerations
! 2040:
! 2041: This protocol deals with the very issue of user authentication and
! 2042: security.
! 2043:
! 2044: First of all, as an implementation issue, the server program will
! 2045: have to run as root (or equivalent) on the server machine. This is
! 2046: because the server program will need be able to change to an arbi-
! 2047: trary user id. The server must also be able to create a privileged
! 2048: TCP/IP port.
! 2049:
! 2050: The client program will need to run as root if any variant of .rhosts
! 2051: authentication is to be used. This is because the client program
! 2052: will need to create a privileged port. The client host key is also
! 2053: usually stored in a file which is readable by root only. The client
! 2054: needs the host key in .rhosts authentication only. Root privileges
! 2055: can be dropped as soon as the privileged port has been created and
! 2056: the host key has been read.
! 2057:
! 2058: The SSH protocol offers major security advantages over existing tel-
! 2059: net and rlogin protocols.
! 2060:
! 2061: o IP spoofing is restricted to closing a connection (by encryp-
! 2062: tion, host keys, and the special random cookie). If encryption
! 2063: is not used, IP spoofing is possible for those who can hear
! 2064: packets going out from the server.
! 2065:
! 2066: o DNS spoofing is made ineffective (by host keys).
! 2067:
! 2068: o Routing spoofing is made ineffective (by host keys).
! 2069:
! 2070: o All data is encrypted with strong algorithms to make
! 2071:
! 2072:
! 2073:
! 2074: Ylonen [Page 37]
! 2075:
! 2076: Internet-Draft SSH (Secure Shell) Remote Login Protocol 15 Nov 1995
! 2077:
! 2078:
! 2079: eavesdropping as difficult as possible. This includes encrypt-
! 2080: ing any authentication information such as passwords. The
! 2081: information for decrypting session keys is destroyed every hour.
! 2082:
! 2083: o Strong authentication methods: .rhosts combined with RSA host
! 2084: authentication, and pure RSA authentication.
! 2085:
! 2086: o X11 connections and arbitrary TCP/IP ports can be forwarded
! 2087: securely.
! 2088:
! 2089: o Man-in-the-middle attacks are deterred by using the server host
! 2090: key to encrypt the session key.
! 2091:
! 2092: o Trojan horses to catch a password by routing manipulation are
! 2093: deterred by checking that the host key of the server machine
! 2094: matches that stored on the client host.
! 2095:
! 2096: The security of SSH against man-in-the-middle attacks and the secu-
! 2097: rity of the new form of .rhosts authentication, as well as server
! 2098: host validation, depends on the integrity of the host key and the
! 2099: files containing known host keys.
! 2100:
! 2101: The host key is normally stored in a root-readable file. If the host
! 2102: key is compromised, it permits attackers to use IP, DNS and routing
! 2103: spoofing as with current rlogin and rsh. It should never be any
! 2104: worse than the current situation.
! 2105:
! 2106: The files containing known host keys are not sensitive. However, if
! 2107: an attacker gets to modify the known host key files, it has the same
! 2108: consequences as a compromised host key, because the attacker can then
! 2109: change the recorded host key.
! 2110:
! 2111: The security improvements obtained by this protocol for X11 are of
! 2112: particular significance. Previously, there has been no way to pro-
! 2113: tect data communicated between an X server and a client running on a
! 2114: remote machine. By creating a fake display on the server, and for-
! 2115: warding all X11 requests over the secure channel, SSH can be used to
! 2116: run any X11 applications securely without any cooperation with the
! 2117: vendors of the X server or the application.
! 2118:
! 2119: Finally, the security of this program relies on the strength of the
! 2120: underlying cryptographic algorithms. The RSA algorithm is used for
! 2121: authentication key exchange. It is widely believed to be secure. Of
! 2122: the algorithms used to encrypt the session, DES has a rather small
! 2123: key these days, probably permitting governments and organized crimi-
! 2124: nals to break it in very short time with specialized hardware. 3DES
! 2125: is probably safe (but slower). IDEA is widely believed to be secure.
! 2126: People have varying degrees of confidence in the other algorithms.
! 2127:
! 2128:
! 2129:
! 2130: Ylonen [Page 38]
! 2131:
! 2132: Internet-Draft SSH (Secure Shell) Remote Login Protocol 15 Nov 1995
! 2133:
! 2134:
! 2135: This program is not secure if used with no encryption at all.
! 2136:
! 2137:
! 2138: Additional Information
! 2139:
! 2140: Additional information (especially on the implementation and mailing
! 2141: lists) is available via WWW at http://www.cs.hut.fi/ssh.
! 2142:
! 2143: Comments should be sent to Tatu Ylonen <ylo@cs.hut.fi> or the SSH
! 2144: Mailing List <ssh@clinet.fi>.
! 2145:
! 2146: Author's Address
! 2147:
! 2148:
! 2149: Tatu Ylonen
! 2150: Helsinki University of Technology
! 2151: Otakaari 1
! 2152: FIN-02150 Espoo, Finland
! 2153:
! 2154: Phone: +358-0-451-3374
! 2155: Fax: +358-0-451-3293
! 2156: EMail: ylo@cs.hut.fi
! 2157:
! 2158:
! 2159:
! 2160:
! 2161:
! 2162:
! 2163:
! 2164:
! 2165:
! 2166:
! 2167:
! 2168:
! 2169:
! 2170:
! 2171:
! 2172:
! 2173:
! 2174:
! 2175:
! 2176:
! 2177:
! 2178:
! 2179:
! 2180:
! 2181:
! 2182:
! 2183:
! 2184:
! 2185:
! 2186: Ylonen [Page 39]
! 2187:
![[BACK]](/icons/back.gif){kind=icon}
Return to RFC CVS log ![[TXT]](/icons/text.gif){kind=icon}
![[DIR]](/icons/dir.gif){kind=icon}
Up to [local] / src / usr.bin / ssh