diff options
Diffstat (limited to 'lib/ssh/doc/standard')
| -rw-r--r-- | lib/ssh/doc/standard/draft-ietf-secsh-architecture-15.2.ps | 3315 | ||||
| -rw-r--r-- | lib/ssh/doc/standard/draft-ietf-secsh-architecture-15.txt | 1624 | ||||
| -rw-r--r-- | lib/ssh/doc/standard/draft-ietf-secsh-connect-18.2.ps | 2557 | ||||
| -rw-r--r-- | lib/ssh/doc/standard/draft-ietf-secsh-connect-18.txt | 1232 | ||||
| -rw-r--r-- | lib/ssh/doc/standard/draft-ietf-secsh-filexfer-02.2.ps | 2853 | ||||
| -rw-r--r-- | lib/ssh/doc/standard/draft-ietf-secsh-filexfer-02.txt | 1627 | ||||
| -rw-r--r-- | lib/ssh/doc/standard/draft-ietf-secsh-filexfer-03.2.ps | 3511 | ||||
| -rw-r--r-- | lib/ssh/doc/standard/draft-ietf-secsh-filexfer-03.txt | 1962 | ||||
| -rw-r--r-- | lib/ssh/doc/standard/draft-ietf-secsh-filexfer-04.txt | 2130 | ||||
| -rw-r--r-- | lib/ssh/doc/standard/draft-ietf-secsh-transport-17.2.ps | 3205 | ||||
| -rw-r--r-- | lib/ssh/doc/standard/draft-ietf-secsh-transport-17.txt | 1624 | ||||
| -rw-r--r-- | lib/ssh/doc/standard/draft-ietf-secsh-userauth-18.2.ps | 1881 | ||||
| -rw-r--r-- | lib/ssh/doc/standard/draft-ietf-secsh-userauth-18.txt | 896 |
13 files changed, 28417 insertions, 0 deletions
diff --git a/lib/ssh/doc/standard/draft-ietf-secsh-architecture-15.2.ps b/lib/ssh/doc/standard/draft-ietf-secsh-architecture-15.2.ps new file mode 100644 index 0000000000..d766a933b4 --- /dev/null +++ b/lib/ssh/doc/standard/draft-ietf-secsh-architecture-15.2.ps @@ -0,0 +1,3315 @@ +%!PS-Adobe-3.0 +%%BoundingBox: 75 0 595 747 +%%Title: Enscript Output +%%For: Magnus Thoang +%%Creator: GNU enscript 1.6.1 +%%CreationDate: Fri Oct 31 13:31:26 2003 +%%Orientation: Portrait +%%Pages: 15 0 +%%DocumentMedia: A4 595 842 0 () () +%%DocumentNeededResources: (atend) +%%EndComments +%%BeginProlog +%%BeginProcSet: PStoPS 1 15 +userdict begin +[/showpage/erasepage/copypage]{dup where{pop dup load + type/operatortype eq{1 array cvx dup 0 3 index cvx put + bind def}{pop}ifelse}{pop}ifelse}forall +[/letter/legal/executivepage/a4/a4small/b5/com10envelope + /monarchenvelope/c5envelope/dlenvelope/lettersmall/note + /folio/quarto/a5]{dup where{dup wcheck{exch{}put} + {pop{}def}ifelse}{pop}ifelse}forall +/setpagedevice {pop}bind 1 index where{dup wcheck{3 1 roll put} + {pop def}ifelse}{def}ifelse +/PStoPSmatrix matrix currentmatrix def +/PStoPSxform matrix def/PStoPSclip{clippath}def +/defaultmatrix{PStoPSmatrix exch PStoPSxform exch concatmatrix}bind def +/initmatrix{matrix defaultmatrix setmatrix}bind def +/initclip[{matrix currentmatrix PStoPSmatrix setmatrix + [{currentpoint}stopped{$error/newerror false put{newpath}} + {/newpath cvx 3 1 roll/moveto cvx 4 array astore cvx}ifelse] + {[/newpath cvx{/moveto cvx}{/lineto cvx} + {/curveto cvx}{/closepath cvx}pathforall]cvx exch pop} + stopped{$error/errorname get/invalidaccess eq{cleartomark + $error/newerror false put cvx exec}{stop}ifelse}if}bind aload pop + /initclip dup load dup type dup/operatortype eq{pop exch pop} + {dup/arraytype eq exch/packedarraytype eq or + {dup xcheck{exch pop aload pop}{pop cvx}ifelse} + {pop cvx}ifelse}ifelse + {newpath PStoPSclip clip newpath exec setmatrix} bind aload pop]cvx def +/initgraphics{initmatrix newpath initclip 1 setlinewidth + 0 setlinecap 0 setlinejoin []0 setdash 0 setgray + 10 setmiterlimit}bind def +end +%%EndProcSet +%%BeginResource: procset Enscript-Prolog 1.6 1 +% +% Procedures. +% + +/_S { % save current state + /_s save def +} def +/_R { % restore from saved state + _s restore +} def + +/S { % showpage protecting gstate + gsave + showpage + grestore +} bind def + +/MF { % fontname newfontname -> - make a new encoded font + /newfontname exch def + /fontname exch def + + /fontdict fontname findfont def + /newfont fontdict maxlength dict def + + fontdict { + exch + dup /FID eq { + % skip FID pair + pop pop + } { + % copy to the new font dictionary + exch newfont 3 1 roll put + } ifelse + } forall + + newfont /FontName newfontname put + + % insert only valid encoding vectors + encoding_vector length 256 eq { + newfont /Encoding encoding_vector put + } if + + newfontname newfont definefont pop +} def + +/SF { % fontname width height -> - set a new font + /height exch def + /width exch def + + findfont + [width 0 0 height 0 0] makefont setfont +} def + +/SUF { % fontname width height -> - set a new user font + /height exch def + /width exch def + + /F-gs-user-font MF + /F-gs-user-font width height SF +} def + +/M {moveto} bind def +/s {show} bind def + +/Box { % x y w h -> - define box path + /d_h exch def /d_w exch def /d_y exch def /d_x exch def + d_x d_y moveto + d_w 0 rlineto + 0 d_h rlineto + d_w neg 0 rlineto + closepath +} def + +/bgs { % x y height blskip gray str -> - show string with bg color + /str exch def + /gray exch def + /blskip exch def + /height exch def + /y exch def + /x exch def + + gsave + x y blskip sub str stringwidth pop height Box + gray setgray + fill + grestore + x y M str s +} def + +% Highlight bars. +/highlight_bars { % nlines lineheight output_y_margin gray -> - + gsave + setgray + /ymarg exch def + /lineheight exch def + /nlines exch def + + % This 2 is just a magic number to sync highlight lines to text. + 0 d_header_y ymarg sub 2 sub translate + + /cw d_output_w cols div def + /nrows d_output_h ymarg 2 mul sub lineheight div cvi def + + % for each column + 0 1 cols 1 sub { + cw mul /xp exch def + + % for each rows + 0 1 nrows 1 sub { + /rn exch def + rn lineheight mul neg /yp exch def + rn nlines idiv 2 mod 0 eq { + % Draw highlight bar. 4 is just a magic indentation. + xp 4 add yp cw 8 sub lineheight neg Box fill + } if + } for + } for + + grestore +} def + +% Line highlight bar. +/line_highlight { % x y width height gray -> - + gsave + /gray exch def + Box gray setgray fill + grestore +} def + +% Column separator lines. +/column_lines { + gsave + .1 setlinewidth + 0 d_footer_h translate + /cw d_output_w cols div def + 1 1 cols 1 sub { + cw mul 0 moveto + 0 d_output_h rlineto stroke + } for + grestore +} def + +% Column borders. +/column_borders { + gsave + .1 setlinewidth + 0 d_footer_h moveto + 0 d_output_h rlineto + d_output_w 0 rlineto + 0 d_output_h neg rlineto + closepath stroke + grestore +} def + +% Do the actual underlay drawing +/draw_underlay { + ul_style 0 eq { + ul_str true charpath stroke + } { + ul_str show + } ifelse +} def + +% Underlay +/underlay { % - -> - + gsave + 0 d_page_h translate + d_page_h neg d_page_w atan rotate + + ul_gray setgray + ul_font setfont + /dw d_page_h dup mul d_page_w dup mul add sqrt def + ul_str stringwidth pop dw exch sub 2 div ul_h_ptsize -2 div moveto + draw_underlay + grestore +} def + +/user_underlay { % - -> - + gsave + ul_x ul_y translate + ul_angle rotate + ul_gray setgray + ul_font setfont + 0 0 ul_h_ptsize 2 div sub moveto + draw_underlay + grestore +} def + +% Page prefeed +/page_prefeed { % bool -> - + statusdict /prefeed known { + statusdict exch /prefeed exch put + } { + pop + } ifelse +} def + +% Wrapped line markers +/wrapped_line_mark { % x y charwith charheight type -> - + /type exch def + /h exch def + /w exch def + /y exch def + /x exch def + + type 2 eq { + % Black boxes (like TeX does) + gsave + 0 setlinewidth + x w 4 div add y M + 0 h rlineto w 2 div 0 rlineto 0 h neg rlineto + closepath fill + grestore + } { + type 3 eq { + % Small arrows + gsave + .2 setlinewidth + x w 2 div add y h 2 div add M + w 4 div 0 rlineto + x w 4 div add y lineto stroke + + x w 4 div add w 8 div add y h 4 div add M + x w 4 div add y lineto + w 4 div h 8 div rlineto stroke + grestore + } { + % do nothing + } ifelse + } ifelse +} def + +% EPSF import. + +/BeginEPSF { + /b4_Inc_state save def % Save state for cleanup + /dict_count countdictstack def % Count objects on dict stack + /op_count count 1 sub def % Count objects on operand stack + userdict begin + /showpage { } def + 0 setgray 0 setlinecap + 1 setlinewidth 0 setlinejoin + 10 setmiterlimit [ ] 0 setdash newpath + /languagelevel where { + pop languagelevel + 1 ne { + false setstrokeadjust false setoverprint + } if + } if +} bind def + +/EndEPSF { + count op_count sub { pos } repeat % Clean up stacks + countdictstack dict_count sub { end } repeat + b4_Inc_state restore +} bind def + +% Check PostScript language level. +/languagelevel where { + pop /gs_languagelevel languagelevel def +} { + /gs_languagelevel 1 def +} ifelse +%%EndResource +%%BeginResource: procset Enscript-Encoding-88591 1.6 1 +/encoding_vector [ +/.notdef /.notdef /.notdef /.notdef +/.notdef /.notdef /.notdef /.notdef +/.notdef /.notdef /.notdef /.notdef +/.notdef /.notdef /.notdef /.notdef +/.notdef /.notdef /.notdef /.notdef +/.notdef /.notdef /.notdef /.notdef +/.notdef /.notdef /.notdef /.notdef +/.notdef /.notdef /.notdef /.notdef +/space /exclam /quotedbl /numbersign +/dollar /percent /ampersand /quoteright +/parenleft /parenright /asterisk /plus +/comma /hyphen /period /slash +/zero /one /two /three +/four /five /six /seven +/eight /nine /colon /semicolon +/less /equal /greater /question +/at /A /B /C +/D /E /F /G +/H /I /J /K +/L /M /N /O +/P /Q /R /S +/T /U /V /W +/X /Y /Z /bracketleft +/backslash /bracketright /asciicircum /underscore +/quoteleft /a /b /c +/d /e /f /g +/h /i /j /k +/l /m /n /o +/p /q /r /s +/t /u /v /w +/x /y /z /braceleft +/bar /braceright /tilde /.notdef +/.notdef /.notdef /.notdef /.notdef +/.notdef /.notdef /.notdef /.notdef +/.notdef /.notdef /.notdef /.notdef +/.notdef /.notdef /.notdef /.notdef +/.notdef /.notdef /.notdef /.notdef +/.notdef /.notdef /.notdef /.notdef +/.notdef /.notdef /.notdef /.notdef +/.notdef /.notdef /.notdef /.notdef +/space /exclamdown /cent /sterling +/currency /yen /brokenbar /section +/dieresis /copyright /ordfeminine /guillemotleft +/logicalnot /hyphen /registered /macron +/degree /plusminus /twosuperior /threesuperior +/acute /mu /paragraph /bullet +/cedilla /onesuperior /ordmasculine /guillemotright +/onequarter /onehalf /threequarters /questiondown +/Agrave /Aacute /Acircumflex /Atilde +/Adieresis /Aring /AE /Ccedilla +/Egrave /Eacute /Ecircumflex /Edieresis +/Igrave /Iacute /Icircumflex /Idieresis +/Eth /Ntilde /Ograve /Oacute +/Ocircumflex /Otilde /Odieresis /multiply +/Oslash /Ugrave /Uacute /Ucircumflex +/Udieresis /Yacute /Thorn /germandbls +/agrave /aacute /acircumflex /atilde +/adieresis /aring /ae /ccedilla +/egrave /eacute /ecircumflex /edieresis +/igrave /iacute /icircumflex /idieresis +/eth /ntilde /ograve /oacute +/ocircumflex /otilde /odieresis /divide +/oslash /ugrave /uacute /ucircumflex +/udieresis /yacute /thorn /ydieresis +] def +%%EndResource +%%EndProlog +%%BeginSetup +%%IncludeResource: font Courier-Bold +%%IncludeResource: font Courier +/HFpt_w 10 def +/HFpt_h 10 def +/Courier-Bold /HF-gs-font MF +/HF /HF-gs-font findfont [HFpt_w 0 0 HFpt_h 0 0] makefont def +/Courier /F-gs-font MF +/F-gs-font 10 10 SF +/#copies 1 def +/d_page_w 520 def +/d_page_h 747 def +/d_header_x 0 def +/d_header_y 747 def +/d_header_w 520 def +/d_header_h 0 def +/d_footer_x 0 def +/d_footer_y 0 def +/d_footer_w 520 def +/d_footer_h 0 def +/d_output_w 520 def +/d_output_h 747 def +/cols 1 def +userdict/PStoPSxform PStoPSmatrix matrix currentmatrix + matrix invertmatrix matrix concatmatrix + matrix invertmatrix put +%%EndSetup +%%Page: (0,1) 1 +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 0.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +/showpage{}def/copypage{}def/erasepage{}def +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 1 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 701 M +(Network Working Group T. Ylonen) s +5 690 M +(Internet-Draft SSH Communications Security Corp) s +5 679 M +(Expires: March 31, 2004 D. Moffat, Ed.) s +5 668 M +( Sun Microsystems, Inc) s +5 657 M +( Oct 2003) s +5 624 M +( SSH Protocol Architecture) s +5 613 M +( draft-ietf-secsh-architecture-15.txt) s +5 591 M +(Status of this Memo) s +5 569 M +( This document is an Internet-Draft and is in full conformance with) s +5 558 M +( all provisions of Section 10 of RFC2026.) s +5 536 M +( Internet-Drafts are working documents of the Internet Engineering) s +5 525 M +( Task Force \(IETF\), its areas, and its working groups. Note that other) s +5 514 M +( groups may also distribute working documents as Internet-Drafts.) s +5 492 M +( Internet-Drafts are draft documents valid for a maximum of six months) s +5 481 M +( and may be updated, replaced, or obsoleted by other documents at any) s +5 470 M +( time. It is inappropriate to use Internet-Drafts as reference) s +5 459 M +( material or to cite them other than as "work in progress.") s +5 437 M +( The list of current Internet-Drafts can be accessed at http://) s +5 426 M +( www.ietf.org/ietf/1id-abstracts.txt.) s +5 404 M +( The list of Internet-Draft Shadow Directories can be accessed at) s +5 393 M +( http://www.ietf.org/shadow.html.) s +5 371 M +( This Internet-Draft will expire on March 31, 2004.) s +5 349 M +(Copyright Notice) s +5 327 M +( Copyright \(C\) The Internet Society \(2003\). All Rights Reserved.) s +5 305 M +(Abstract) s +5 283 M +( SSH is a protocol for secure remote login and other secure network) s +5 272 M +( services over an insecure network. This document describes the) s +5 261 M +( architecture of the SSH protocol, as well as the notation and) s +5 250 M +( terminology used in SSH protocol documents. It also discusses the SSH) s +5 239 M +( algorithm naming system that allows local extensions. The SSH) s +5 228 M +( protocol consists of three major components: The Transport Layer) s +5 217 M +( Protocol provides server authentication, confidentiality, and) s +5 206 M +( integrity with perfect forward secrecy. The User Authentication) s +5 195 M +( Protocol authenticates the client to the server. The Connection) s +5 184 M +( Protocol multiplexes the encrypted tunnel into several logical) s +5 173 M +( channels. Details of these protocols are described in separate) s +5 129 M +(Ylonen & Moffat Expires March 31, 2004 [Page 1]) s +_R +S +PStoPSsaved restore +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 421.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 2 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH Protocol Architecture Oct 2003) s +5 690 M +( documents.) s +5 668 M +(Table of Contents) s +5 646 M +( 1. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 3) s +5 635 M +( 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3) s +5 624 M +( 3. Specification of Requirements . . . . . . . . . . . . . . . 3) s +5 613 M +( 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 3) s +5 602 M +( 4.1 Host Keys . . . . . . . . . . . . . . . . . . . . . . . . . 4) s +5 591 M +( 4.2 Extensibility . . . . . . . . . . . . . . . . . . . . . . . 5) s +5 580 M +( 4.3 Policy Issues . . . . . . . . . . . . . . . . . . . . . . . 5) s +5 569 M +( 4.4 Security Properties . . . . . . . . . . . . . . . . . . . . 6) s +5 558 M +( 4.5 Packet Size and Overhead . . . . . . . . . . . . . . . . . . 6) s +5 547 M +( 4.6 Localization and Character Set Support . . . . . . . . . . . 7) s +5 536 M +( 5. Data Type Representations Used in the SSH Protocols . . . . 8) s +5 525 M +( 6. Algorithm Naming . . . . . . . . . . . . . . . . . . . . . . 10) s +5 514 M +( 7. Message Numbers . . . . . . . . . . . . . . . . . . . . . . 11) s +5 503 M +( 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 11) s +5 492 M +( 9. Security Considerations . . . . . . . . . . . . . . . . . . 12) s +5 481 M +( 9.1 Pseudo-Random Number Generation . . . . . . . . . . . . . . 12) s +5 470 M +( 9.2 Transport . . . . . . . . . . . . . . . . . . . . . . . . . 13) s +5 459 M +( 9.2.1 Confidentiality . . . . . . . . . . . . . . . . . . . . . . 13) s +5 448 M +( 9.2.2 Data Integrity . . . . . . . . . . . . . . . . . . . . . . . 16) s +5 437 M +( 9.2.3 Replay . . . . . . . . . . . . . . . . . . . . . . . . . . . 16) s +5 426 M +( 9.2.4 Man-in-the-middle . . . . . . . . . . . . . . . . . . . . . 17) s +5 415 M +( 9.2.5 Denial-of-service . . . . . . . . . . . . . . . . . . . . . 19) s +5 404 M +( 9.2.6 Covert Channels . . . . . . . . . . . . . . . . . . . . . . 19) s +5 393 M +( 9.2.7 Forward Secrecy . . . . . . . . . . . . . . . . . . . . . . 20) s +5 382 M +( 9.3 Authentication Protocol . . . . . . . . . . . . . . . . . . 20) s +5 371 M +( 9.3.1 Weak Transport . . . . . . . . . . . . . . . . . . . . . . . 21) s +5 360 M +( 9.3.2 Debug messages . . . . . . . . . . . . . . . . . . . . . . . 21) s +5 349 M +( 9.3.3 Local security policy . . . . . . . . . . . . . . . . . . . 21) s +5 338 M +( 9.3.4 Public key authentication . . . . . . . . . . . . . . . . . 22) s +5 327 M +( 9.3.5 Password authentication . . . . . . . . . . . . . . . . . . 22) s +5 316 M +( 9.3.6 Host based authentication . . . . . . . . . . . . . . . . . 23) s +5 305 M +( 9.4 Connection protocol . . . . . . . . . . . . . . . . . . . . 23) s +5 294 M +( 9.4.1 End point security . . . . . . . . . . . . . . . . . . . . . 23) s +5 283 M +( 9.4.2 Proxy forwarding . . . . . . . . . . . . . . . . . . . . . . 23) s +5 272 M +( 9.4.3 X11 forwarding . . . . . . . . . . . . . . . . . . . . . . . 24) s +5 261 M +( Normative References . . . . . . . . . . . . . . . . . . . . 24) s +5 250 M +( Informative References . . . . . . . . . . . . . . . . . . . 25) s +5 239 M +( Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 27) s +5 228 M +( Intellectual Property and Copyright Statements . . . . . . . 28) s +5 129 M +(Ylonen & Moffat Expires March 31, 2004 [Page 2]) s +_R +S +PStoPSsaved restore +%%Page: (2,3) 2 +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 0.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +/showpage{}def/copypage{}def/erasepage{}def +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 3 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH Protocol Architecture Oct 2003) s +5 690 M +(1. Contributors) s +5 668 M +( The major original contributors of this document were: Tatu Ylonen,) s +5 657 M +( Tero Kivinen, Timo J. Rinne, Sami Lehtinen \(all of SSH Communications) s +5 646 M +( Security Corp\), and Markku-Juhani O. Saarinen \(University of) s +5 635 M +( Jyvaskyla\)) s +5 613 M +( The document editor is: [email protected]. Comments on this) s +5 602 M +( internet draft should be sent to the IETF SECSH working group,) s +5 591 M +( details at: http://ietf.org/html.charters/secsh-charter.html) s +5 569 M +(2. Introduction) s +5 547 M +( SSH is a protocol for secure remote login and other secure network) s +5 536 M +( services over an insecure network. It consists of three major) s +5 525 M +( components:) s +5 514 M +( o The Transport Layer Protocol [SSH-TRANS] provides server) s +5 503 M +( authentication, confidentiality, and integrity. It may optionally) s +5 492 M +( also provide compression. The transport layer will typically be) s +5 481 M +( run over a TCP/IP connection, but might also be used on top of any) s +5 470 M +( other reliable data stream.) s +5 459 M +( o The User Authentication Protocol [SSH-USERAUTH] authenticates the) s +5 448 M +( client-side user to the server. It runs over the transport layer) s +5 437 M +( protocol.) s +5 426 M +( o The Connection Protocol [SSH-CONNECT] multiplexes the encrypted) s +5 415 M +( tunnel into several logical channels. It runs over the user) s +5 404 M +( authentication protocol.) s +5 382 M +( The client sends a service request once a secure transport layer) s +5 371 M +( connection has been established. A second service request is sent) s +5 360 M +( after user authentication is complete. This allows new protocols to) s +5 349 M +( be defined and coexist with the protocols listed above.) s +5 327 M +( The connection protocol provides channels that can be used for a wide) s +5 316 M +( range of purposes. Standard methods are provided for setting up) s +5 305 M +( secure interactive shell sessions and for forwarding \("tunneling"\)) s +5 294 M +( arbitrary TCP/IP ports and X11 connections.) s +5 272 M +(3. Specification of Requirements) s +5 250 M +( All documents related to the SSH protocols shall use the keywords) s +5 239 M +( "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",) s +5 228 M +( "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" to describe) s +5 217 M +( requirements. They are to be interpreted as described in [RFC2119].) s +5 195 M +(4. Architecture) s +5 129 M +(Ylonen & Moffat Expires March 31, 2004 [Page 3]) s +_R +S +PStoPSsaved restore +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 421.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 4 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH Protocol Architecture Oct 2003) s +5 690 M +(4.1 Host Keys) s +5 668 M +( Each server host SHOULD have a host key. Hosts MAY have multiple) s +5 657 M +( host keys using multiple different algorithms. Multiple hosts MAY) s +5 646 M +( share the same host key. If a host has keys at all, it MUST have at) s +5 635 M +( least one key using each REQUIRED public key algorithm \(DSS) s +5 624 M +( [FIPS-186]\).) s +5 602 M +( The server host key is used during key exchange to verify that the) s +5 591 M +( client is really talking to the correct server. For this to be) s +5 580 M +( possible, the client must have a priori knowledge of the server's) s +5 569 M +( public host key.) s +5 547 M +( Two different trust models can be used:) s +5 536 M +( o The client has a local database that associates each host name \(as) s +5 525 M +( typed by the user\) with the corresponding public host key. This) s +5 514 M +( method requires no centrally administered infrastructure, and no) s +5 503 M +( third-party coordination. The downside is that the database of) s +5 492 M +( name-to-key associations may become burdensome to maintain.) s +5 481 M +( o The host name-to-key association is certified by some trusted) s +5 470 M +( certification authority. The client only knows the CA root key,) s +5 459 M +( and can verify the validity of all host keys certified by accepted) s +5 448 M +( CAs.) s +5 426 M +( The second alternative eases the maintenance problem, since) s +5 415 M +( ideally only a single CA key needs to be securely stored on the) s +5 404 M +( client. On the other hand, each host key must be appropriately) s +5 393 M +( certified by a central authority before authorization is possible.) s +5 382 M +( Also, a lot of trust is placed on the central infrastructure.) s +5 360 M +( The protocol provides the option that the server name - host key) s +5 349 M +( association is not checked when connecting to the host for the first) s +5 338 M +( time. This allows communication without prior communication of host) s +5 327 M +( keys or certification. The connection still provides protection) s +5 316 M +( against passive listening; however, it becomes vulnerable to active) s +5 305 M +( man-in-the-middle attacks. Implementations SHOULD NOT normally allow) s +5 294 M +( such connections by default, as they pose a potential security) s +5 283 M +( problem. However, as there is no widely deployed key infrastructure) s +5 272 M +( available on the Internet yet, this option makes the protocol much) s +5 261 M +( more usable during the transition time until such an infrastructure) s +5 250 M +( emerges, while still providing a much higher level of security than) s +5 239 M +( that offered by older solutions \(e.g. telnet [RFC-854] and rlogin) s +5 228 M +( [RFC-1282]\).) s +5 206 M +( Implementations SHOULD try to make the best effort to check host) s +5 195 M +( keys. An example of a possible strategy is to only accept a host key) s +5 184 M +( without checking the first time a host is connected, save the key in) s +5 173 M +( a local database, and compare against that key on all future) s +5 129 M +(Ylonen & Moffat Expires March 31, 2004 [Page 4]) s +_R +S +PStoPSsaved restore +%%Page: (4,5) 3 +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 0.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +/showpage{}def/copypage{}def/erasepage{}def +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 5 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH Protocol Architecture Oct 2003) s +5 690 M +( connections to that host.) s +5 668 M +( Implementations MAY provide additional methods for verifying the) s +5 657 M +( correctness of host keys, e.g. a hexadecimal fingerprint derived from) s +5 646 M +( the SHA-1 hash of the public key. Such fingerprints can easily be) s +5 635 M +( verified by using telephone or other external communication channels.) s +5 613 M +( All implementations SHOULD provide an option to not accept host keys) s +5 602 M +( that cannot be verified.) s +5 580 M +( We believe that ease of use is critical to end-user acceptance of) s +5 569 M +( security solutions, and no improvement in security is gained if the) s +5 558 M +( new solutions are not used. Thus, providing the option not to check) s +5 547 M +( the server host key is believed to improve the overall security of) s +5 536 M +( the Internet, even though it reduces the security of the protocol in) s +5 525 M +( configurations where it is allowed.) s +5 503 M +(4.2 Extensibility) s +5 481 M +( We believe that the protocol will evolve over time, and some) s +5 470 M +( organizations will want to use their own encryption, authentication) s +5 459 M +( and/or key exchange methods. Central registration of all extensions) s +5 448 M +( is cumbersome, especially for experimental or classified features.) s +5 437 M +( On the other hand, having no central registration leads to conflicts) s +5 426 M +( in method identifiers, making interoperability difficult.) s +5 404 M +( We have chosen to identify algorithms, methods, formats, and) s +5 393 M +( extension protocols with textual names that are of a specific format.) s +5 382 M +( DNS names are used to create local namespaces where experimental or) s +5 371 M +( classified extensions can be defined without fear of conflicts with) s +5 360 M +( other implementations.) s +5 338 M +( One design goal has been to keep the base protocol as simple as) s +5 327 M +( possible, and to require as few algorithms as possible. However, all) s +5 316 M +( implementations MUST support a minimal set of algorithms to ensure) s +5 305 M +( interoperability \(this does not imply that the local policy on all) s +5 294 M +( hosts would necessary allow these algorithms\). The mandatory) s +5 283 M +( algorithms are specified in the relevant protocol documents.) s +5 261 M +( Additional algorithms, methods, formats, and extension protocols can) s +5 250 M +( be defined in separate drafts. See Section Algorithm Naming \(Section) s +5 239 M +( 6\) for more information.) s +5 217 M +(4.3 Policy Issues) s +5 195 M +( The protocol allows full negotiation of encryption, integrity, key) s +5 184 M +( exchange, compression, and public key algorithms and formats.) s +5 173 M +( Encryption, integrity, public key, and compression algorithms can be) s +5 129 M +(Ylonen & Moffat Expires March 31, 2004 [Page 5]) s +_R +S +PStoPSsaved restore +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 421.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 6 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH Protocol Architecture Oct 2003) s +5 690 M +( different for each direction.) s +5 668 M +( The following policy issues SHOULD be addressed in the configuration) s +5 657 M +( mechanisms of each implementation:) s +5 646 M +( o Encryption, integrity, and compression algorithms, separately for) s +5 635 M +( each direction. The policy MUST specify which is the preferred) s +5 624 M +( algorithm \(e.g. the first algorithm listed in each category\).) s +5 613 M +( o Public key algorithms and key exchange method to be used for host) s +5 602 M +( authentication. The existence of trusted host keys for different) s +5 591 M +( public key algorithms also affects this choice.) s +5 580 M +( o The authentication methods that are to be required by the server) s +5 569 M +( for each user. The server's policy MAY require multiple) s +5 558 M +( authentication for some or all users. The required algorithms MAY) s +5 547 M +( depend on the location where the user is trying to log in from.) s +5 536 M +( o The operations that the user is allowed to perform using the) s +5 525 M +( connection protocol. Some issues are related to security; for) s +5 514 M +( example, the policy SHOULD NOT allow the server to start sessions) s +5 503 M +( or run commands on the client machine, and MUST NOT allow) s +5 492 M +( connections to the authentication agent unless forwarding such) s +5 481 M +( connections has been requested. Other issues, such as which TCP/) s +5 470 M +( IP ports can be forwarded and by whom, are clearly issues of local) s +5 459 M +( policy. Many of these issues may involve traversing or bypassing) s +5 448 M +( firewalls, and are interrelated with the local security policy.) s +5 426 M +(4.4 Security Properties) s +5 404 M +( The primary goal of the SSH protocol is improved security on the) s +5 393 M +( Internet. It attempts to do this in a way that is easy to deploy,) s +5 382 M +( even at the cost of absolute security.) s +5 371 M +( o All encryption, integrity, and public key algorithms used are) s +5 360 M +( well-known, well-established algorithms.) s +5 349 M +( o All algorithms are used with cryptographically sound key sizes) s +5 338 M +( that are believed to provide protection against even the strongest) s +5 327 M +( cryptanalytic attacks for decades.) s +5 316 M +( o All algorithms are negotiated, and in case some algorithm is) s +5 305 M +( broken, it is easy to switch to some other algorithm without) s +5 294 M +( modifying the base protocol.) s +5 272 M +( Specific concessions were made to make wide-spread fast deployment) s +5 261 M +( easier. The particular case where this comes up is verifying that) s +5 250 M +( the server host key really belongs to the desired host; the protocol) s +5 239 M +( allows the verification to be left out \(but this is NOT RECOMMENDED\).) s +5 228 M +( This is believed to significantly improve usability in the short) s +5 217 M +( term, until widespread Internet public key infrastructures emerge.) s +5 195 M +(4.5 Packet Size and Overhead) s +5 173 M +( Some readers will worry about the increase in packet size due to new) s +5 129 M +(Ylonen & Moffat Expires March 31, 2004 [Page 6]) s +_R +S +PStoPSsaved restore +%%Page: (6,7) 4 +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 0.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +/showpage{}def/copypage{}def/erasepage{}def +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 7 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH Protocol Architecture Oct 2003) s +5 690 M +( headers, padding, and MAC. The minimum packet size is in the order) s +5 679 M +( of 28 bytes \(depending on negotiated algorithms\). The increase is) s +5 668 M +( negligible for large packets, but very significant for one-byte) s +5 657 M +( packets \(telnet-type sessions\). There are, however, several factors) s +5 646 M +( that make this a non-issue in almost all cases:) s +5 635 M +( o The minimum size of a TCP/IP header is 32 bytes. Thus, the) s +5 624 M +( increase is actually from 33 to 51 bytes \(roughly\).) s +5 613 M +( o The minimum size of the data field of an Ethernet packet is 46) s +5 602 M +( bytes [RFC-894]. Thus, the increase is no more than 5 bytes. When) s +5 591 M +( Ethernet headers are considered, the increase is less than 10) s +5 580 M +( percent.) s +5 569 M +( o The total fraction of telnet-type data in the Internet is) s +5 558 M +( negligible, even with increased packet sizes.) s +5 536 M +( The only environment where the packet size increase is likely to have) s +5 525 M +( a significant effect is PPP [RFC-1134] over slow modem lines \(PPP) s +5 514 M +( compresses the TCP/IP headers, emphasizing the increase in packet) s +5 503 M +( size\). However, with modern modems, the time needed to transfer is in) s +5 492 M +( the order of 2 milliseconds, which is a lot faster than people can) s +5 481 M +( type.) s +5 459 M +( There are also issues related to the maximum packet size. To) s +5 448 M +( minimize delays in screen updates, one does not want excessively) s +5 437 M +( large packets for interactive sessions. The maximum packet size is) s +5 426 M +( negotiated separately for each channel.) s +5 404 M +(4.6 Localization and Character Set Support) s +5 382 M +( For the most part, the SSH protocols do not directly pass text that) s +5 371 M +( would be displayed to the user. However, there are some places where) s +5 360 M +( such data might be passed. When applicable, the character set for the) s +5 349 M +( data MUST be explicitly specified. In most places, ISO 10646 with) s +5 338 M +( UTF-8 encoding is used [RFC-2279]. When applicable, a field is also) s +5 327 M +( provided for a language tag [RFC-3066].) s +5 305 M +( One big issue is the character set of the interactive session. There) s +5 294 M +( is no clear solution, as different applications may display data in) s +5 283 M +( different formats. Different types of terminal emulation may also be) s +5 272 M +( employed in the client, and the character set to be used is) s +5 261 M +( effectively determined by the terminal emulation. Thus, no place is) s +5 250 M +( provided for directly specifying the character set or encoding for) s +5 239 M +( terminal session data. However, the terminal emulation type \(e.g.) s +5 228 M +( "vt100"\) is transmitted to the remote site, and it implicitly) s +5 217 M +( specifies the character set and encoding. Applications typically use) s +5 206 M +( the terminal type to determine what character set they use, or the) s +5 195 M +( character set is determined using some external means. The terminal) s +5 184 M +( emulation may also allow configuring the default character set. In) s +5 173 M +( any case, the character set for the terminal session is considered) s +5 129 M +(Ylonen & Moffat Expires March 31, 2004 [Page 7]) s +_R +S +PStoPSsaved restore +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 421.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 8 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH Protocol Architecture Oct 2003) s +5 690 M +( primarily a client local issue.) s +5 668 M +( Internal names used to identify algorithms or protocols are normally) s +5 657 M +( never displayed to users, and must be in US-ASCII.) s +5 635 M +( The client and server user names are inherently constrained by what) s +5 624 M +( the server is prepared to accept. They might, however, occasionally) s +5 613 M +( be displayed in logs, reports, etc. They MUST be encoded using ISO) s +5 602 M +( 10646 UTF-8, but other encodings may be required in some cases. It) s +5 591 M +( is up to the server to decide how to map user names to accepted user) s +5 580 M +( names. Straight bit-wise binary comparison is RECOMMENDED.) s +5 558 M +( For localization purposes, the protocol attempts to minimize the) s +5 547 M +( number of textual messages transmitted. When present, such messages) s +5 536 M +( typically relate to errors, debugging information, or some externally) s +5 525 M +( configured data. For data that is normally displayed, it SHOULD be) s +5 514 M +( possible to fetch a localized message instead of the transmitted) s +5 503 M +( message by using a numerical code. The remaining messages SHOULD be) s +5 492 M +( configurable.) s +5 470 M +(5. Data Type Representations Used in the SSH Protocols) s +5 459 M +( byte) s +5 437 M +( A byte represents an arbitrary 8-bit value \(octet\) [RFC-1700].) s +5 426 M +( Fixed length data is sometimes represented as an array of bytes,) s +5 415 M +( written byte[n], where n is the number of bytes in the array.) s +5 393 M +( boolean) s +5 371 M +( A boolean value is stored as a single byte. The value 0) s +5 360 M +( represents FALSE, and the value 1 represents TRUE. All non-zero) s +5 349 M +( values MUST be interpreted as TRUE; however, applications MUST NOT) s +5 338 M +( store values other than 0 and 1.) s +5 316 M +( uint32) s +5 294 M +( Represents a 32-bit unsigned integer. Stored as four bytes in the) s +5 283 M +( order of decreasing significance \(network byte order\). For) s +5 272 M +( example, the value 699921578 \(0x29b7f4aa\) is stored as 29 b7 f4) s +5 261 M +( aa.) s +5 239 M +( uint64) s +5 217 M +( Represents a 64-bit unsigned integer. Stored as eight bytes in) s +5 206 M +( the order of decreasing significance \(network byte order\).) s +5 129 M +(Ylonen & Moffat Expires March 31, 2004 [Page 8]) s +_R +S +PStoPSsaved restore +%%Page: (8,9) 5 +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 0.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +/showpage{}def/copypage{}def/erasepage{}def +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 9 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH Protocol Architecture Oct 2003) s +5 690 M +( string) s +5 668 M +( Arbitrary length binary string. Strings are allowed to contain) s +5 657 M +( arbitrary binary data, including null characters and 8-bit) s +5 646 M +( characters. They are stored as a uint32 containing its length) s +5 635 M +( \(number of bytes that follow\) and zero \(= empty string\) or more) s +5 624 M +( bytes that are the value of the string. Terminating null) s +5 613 M +( characters are not used.) s +5 591 M +( Strings are also used to store text. In that case, US-ASCII is) s +5 580 M +( used for internal names, and ISO-10646 UTF-8 for text that might) s +5 569 M +( be displayed to the user. The terminating null character SHOULD) s +5 558 M +( NOT normally be stored in the string.) s +5 536 M +( For example, the US-ASCII string "testing" is represented as 00 00) s +5 525 M +( 00 07 t e s t i n g. The UTF8 mapping does not alter the encoding) s +5 514 M +( of US-ASCII characters.) s +5 492 M +( mpint) s +5 470 M +( Represents multiple precision integers in two's complement format,) s +5 459 M +( stored as a string, 8 bits per byte, MSB first. Negative numbers) s +5 448 M +( have the value 1 as the most significant bit of the first byte of) s +5 437 M +( the data partition. If the most significant bit would be set for a) s +5 426 M +( positive number, the number MUST be preceded by a zero byte.) s +5 415 M +( Unnecessary leading bytes with the value 0 or 255 MUST NOT be) s +5 404 M +( included. The value zero MUST be stored as a string with zero) s +5 393 M +( bytes of data.) s +5 371 M +( By convention, a number that is used in modular computations in) s +5 360 M +( Z_n SHOULD be represented in the range 0 <= x < n.) s +5 338 M +( Examples:) s +5 327 M +( value \(hex\) representation \(hex\)) s +5 316 M +( ---------------------------------------------------------------) s +5 305 M +( 0 00 00 00 00) s +5 294 M +( 9a378f9b2e332a7 00 00 00 08 09 a3 78 f9 b2 e3 32 a7) s +5 283 M +( 80 00 00 00 02 00 80) s +5 272 M +( -1234 00 00 00 02 ed cc) s +5 261 M +( -deadbeef 00 00 00 05 ff 21 52 41 11) s +5 217 M +( name-list) s +5 195 M +( A string containing a comma separated list of names. A name list) s +5 184 M +( is represented as a uint32 containing its length \(number of bytes) s +5 173 M +( that follow\) followed by a comma-separated list of zero or more) s +5 129 M +(Ylonen & Moffat Expires March 31, 2004 [Page 9]) s +_R +S +PStoPSsaved restore +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 421.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 10 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH Protocol Architecture Oct 2003) s +5 690 M +( names. A name MUST be non-zero length, and it MUST NOT contain a) s +5 679 M +( comma \(','\). Context may impose additional restrictions on the) s +5 668 M +( names; for example, the names in a list may have to be valid) s +5 657 M +( algorithm identifier \(see Algorithm Naming below\), or [RFC-3066]) s +5 646 M +( language tags. The order of the names in a list may or may not be) s +5 635 M +( significant, also depending on the context where the list is is) s +5 624 M +( used. Terminating NUL characters are not used, neither for the) s +5 613 M +( individual names, nor for the list as a whole.) s +5 591 M +( Examples:) s +5 580 M +( value representation \(hex\)) s +5 569 M +( ---------------------------------------) s +5 558 M +( \(\), the empty list 00 00 00 00) s +5 547 M +( \("zlib"\) 00 00 00 04 7a 6c 69 62) s +5 536 M +( \("zlib", "none"\) 00 00 00 09 7a 6c 69 62 2c 6e 6f 6e 65) s +5 481 M +(6. Algorithm Naming) s +5 459 M +( The SSH protocols refer to particular hash, encryption, integrity,) s +5 448 M +( compression, and key exchange algorithms or protocols by names.) s +5 437 M +( There are some standard algorithms that all implementations MUST) s +5 426 M +( support. There are also algorithms that are defined in the protocol) s +5 415 M +( specification but are OPTIONAL. Furthermore, it is expected that) s +5 404 M +( some organizations will want to use their own algorithms.) s +5 382 M +( In this protocol, all algorithm identifiers MUST be printable) s +5 371 M +( US-ASCII non-empty strings no longer than 64 characters. Names MUST) s +5 360 M +( be case-sensitive.) s +5 338 M +( There are two formats for algorithm names:) s +5 327 M +( o Names that do not contain an at-sign \(@\) are reserved to be) s +5 316 M +( assigned by IETF consensus \(RFCs\). Examples include `3des-cbc',) s +5 305 M +( `sha-1', `hmac-sha1', and `zlib' \(the quotes are not part of the) s +5 294 M +( name\). Names of this format MUST NOT be used without first) s +5 283 M +( registering them. Registered names MUST NOT contain an at-sign) s +5 272 M +( \(@\) or a comma \(,\).) s +5 261 M +( o Anyone can define additional algorithms by using names in the) s +5 250 M +( format name@domainname, e.g. "[email protected]". The) s +5 239 M +( format of the part preceding the at sign is not specified; it MUST) s +5 228 M +( consist of US-ASCII characters except at-sign and comma. The part) s +5 217 M +( following the at-sign MUST be a valid fully qualified internet) s +5 206 M +( domain name [RFC-1034] controlled by the person or organization) s +5 195 M +( defining the name. It is up to each domain how it manages its) s +5 184 M +( local namespace.) s +5 129 M +(Ylonen & Moffat Expires March 31, 2004 [Page 10]) s +_R +S +PStoPSsaved restore +%%Page: (10,11) 6 +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 0.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +/showpage{}def/copypage{}def/erasepage{}def +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 11 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH Protocol Architecture Oct 2003) s +5 690 M +(7. Message Numbers) s +5 668 M +( SSH packets have message numbers in the range 1 to 255. These numbers) s +5 657 M +( have been allocated as follows:) s +5 624 M +( Transport layer protocol:) s +5 602 M +( 1 to 19 Transport layer generic \(e.g. disconnect, ignore, debug,) s +5 591 M +( etc.\)) s +5 580 M +( 20 to 29 Algorithm negotiation) s +5 569 M +( 30 to 49 Key exchange method specific \(numbers can be reused for) s +5 558 M +( different authentication methods\)) s +5 536 M +( User authentication protocol:) s +5 514 M +( 50 to 59 User authentication generic) s +5 503 M +( 60 to 79 User authentication method specific \(numbers can be) s +5 492 M +( reused for different authentication methods\)) s +5 470 M +( Connection protocol:) s +5 448 M +( 80 to 89 Connection protocol generic) s +5 437 M +( 90 to 127 Channel related messages) s +5 415 M +( Reserved for client protocols:) s +5 393 M +( 128 to 191 Reserved) s +5 371 M +( Local extensions:) s +5 349 M +( 192 to 255 Local extensions) s +5 305 M +(8. IANA Considerations) s +5 283 M +( The initial state of the IANA registry is detailed in [SSH-NUMBERS].) s +5 261 M +( Allocation of the following types of names in the SSH protocols is) s +5 250 M +( assigned by IETF consensus:) s +5 239 M +( o SSH encryption algorithm names,) s +5 228 M +( o SSH MAC algorithm names,) s +5 217 M +( o SSH public key algorithm names \(public key algorithm also implies) s +5 206 M +( encoding and signature/encryption capability\),) s +5 195 M +( o SSH key exchange method names, and) s +5 184 M +( o SSH protocol \(service\) names.) s +5 129 M +(Ylonen & Moffat Expires March 31, 2004 [Page 11]) s +_R +S +PStoPSsaved restore +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 421.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 12 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH Protocol Architecture Oct 2003) s +5 690 M +( These names MUST be printable US-ASCII strings, and MUST NOT contain) s +5 679 M +( the characters at-sign \('@'\), comma \(','\), or whitespace or control) s +5 668 M +( characters \(ASCII codes 32 or less\). Names are case-sensitive, and) s +5 657 M +( MUST NOT be longer than 64 characters.) s +5 635 M +( Names with the at-sign \('@'\) in them are allocated by the owner of) s +5 624 M +( DNS name after the at-sign \(hierarchical allocation in [RFC-2343]\),) s +5 613 M +( otherwise the same restrictions as above.) s +5 591 M +( Each category of names listed above has a separate namespace.) s +5 580 M +( However, using the same name in multiple categories SHOULD be avoided) s +5 569 M +( to minimize confusion.) s +5 547 M +( Message numbers \(see Section Message Numbers \(Section 7\)\) in the) s +5 536 M +( range of 0..191 are allocated via IETF consensus; message numbers in) s +5 525 M +( the 192..255 range \(the "Local extensions" set\) are reserved for) s +5 514 M +( private use.) s +5 492 M +(9. Security Considerations) s +5 470 M +( In order to make the entire body of Security Considerations more) s +5 459 M +( accessible, Security Considerations for the transport,) s +5 448 M +( authentication, and connection documents have been gathered here.) s +5 426 M +( The transport protocol [1] provides a confidential channel over an) s +5 415 M +( insecure network. It performs server host authentication, key) s +5 404 M +( exchange, encryption, and integrity protection. It also derives a) s +5 393 M +( unique session id that may be used by higher-level protocols.) s +5 371 M +( The authentication protocol [2] provides a suite of mechanisms which) s +5 360 M +( can be used to authenticate the client user to the server.) s +5 349 M +( Individual mechanisms specified in the in authentication protocol use) s +5 338 M +( the session id provided by the transport protocol and/or depend on) s +5 327 M +( the security and integrity guarantees of the transport protocol.) s +5 305 M +( The connection protocol [3] specifies a mechanism to multiplex) s +5 294 M +( multiple streams [channels] of data over the confidential and) s +5 283 M +( authenticated transport. It also specifies channels for accessing an) s +5 272 M +( interactive shell, for 'proxy-forwarding' various external protocols) s +5 261 M +( over the secure transport \(including arbitrary TCP/IP protocols\), and) s +5 250 M +( for accessing secure 'subsystems' on the server host.) s +5 228 M +(9.1 Pseudo-Random Number Generation) s +5 206 M +( This protocol binds each session key to the session by including) s +5 195 M +( random, session specific data in the hash used to produce session) s +5 184 M +( keys. Special care should be taken to ensure that all of the random) s +5 173 M +( numbers are of good quality. If the random data here \(e.g., DH) s +5 129 M +(Ylonen & Moffat Expires March 31, 2004 [Page 12]) s +_R +S +PStoPSsaved restore +%%Page: (12,13) 7 +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 0.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +/showpage{}def/copypage{}def/erasepage{}def +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 13 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH Protocol Architecture Oct 2003) s +5 690 M +( parameters\) are pseudo-random then the pseudo-random number generator) s +5 679 M +( should be cryptographically secure \(i.e., its next output not easily) s +5 668 M +( guessed even when knowing all previous outputs\) and, furthermore,) s +5 657 M +( proper entropy needs to be added to the pseudo-random number) s +5 646 M +( generator. RFC 1750 [1750] offers suggestions for sources of random) s +5 635 M +( numbers and entropy. Implementors should note the importance of) s +5 624 M +( entropy and the well-meant, anecdotal warning about the difficulty in) s +5 613 M +( properly implementing pseudo-random number generating functions.) s +5 591 M +( The amount of entropy available to a given client or server may) s +5 580 M +( sometimes be less than what is required. In this case one must) s +5 569 M +( either resort to pseudo-random number generation regardless of) s +5 558 M +( insufficient entropy or refuse to run the protocol. The latter is) s +5 547 M +( preferable.) s +5 525 M +(9.2 Transport) s +5 503 M +(9.2.1 Confidentiality) s +5 481 M +( It is beyond the scope of this document and the Secure Shell Working) s +5 470 M +( Group to analyze or recommend specific ciphers other than the ones) s +5 459 M +( which have been established and accepted within the industry. At the) s +5 448 M +( time of this writing, ciphers commonly in use include 3DES, ARCFOUR,) s +5 437 M +( twofish, serpent and blowfish. AES has been accepted by The) s +5 426 M +( published as a US Federal Information Processing Standards [FIPS-197]) s +5 415 M +( and the cryptographic community as being acceptable for this purpose) s +5 404 M +( as well has accepted AES. As always, implementors and users should) s +5 393 M +( check current literature to ensure that no recent vulnerabilities) s +5 382 M +( have been found in ciphers used within products. Implementors should) s +5 371 M +( also check to see which ciphers are considered to be relatively) s +5 360 M +( stronger than others and should recommend their use to users over) s +5 349 M +( relatively weaker ciphers. It would be considered good form for an) s +5 338 M +( implementation to politely and unobtrusively notify a user that a) s +5 327 M +( stronger cipher is available and should be used when a weaker one is) s +5 316 M +( actively chosen.) s +5 294 M +( The "none" cipher is provided for debugging and SHOULD NOT be used) s +5 283 M +( except for that purpose. It's cryptographic properties are) s +5 272 M +( sufficiently described in RFC 2410, which will show that its use does) s +5 261 M +( not meet the intent of this protocol.) s +5 239 M +( The relative merits of these and other ciphers may also be found in) s +5 228 M +( current literature. Two references that may provide information on) s +5 217 M +( the subject are [SCHNEIER] and [KAUFMAN,PERLMAN,SPECINER]. Both of) s +5 206 M +( these describe the CBC mode of operation of certain ciphers and the) s +5 195 M +( weakness of this scheme. Essentially, this mode is theoretically) s +5 184 M +( vulnerable to chosen cipher-text attacks because of the high) s +5 173 M +( predictability of the start of packet sequence. However, this attack) s +5 129 M +(Ylonen & Moffat Expires March 31, 2004 [Page 13]) s +_R +S +PStoPSsaved restore +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 421.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 14 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH Protocol Architecture Oct 2003) s +5 690 M +( is still deemed difficult and not considered fully practicable) s +5 679 M +( especially if relatively longer block sizes are used.) s +5 657 M +( Additionally, another CBC mode attack may be mitigated through the) s +5 646 M +( insertion of packets containing SSH_MSG_IGNORE. Without this) s +5 635 M +( technique, a specific attack may be successful. For this attack) s +5 624 M +( \(commonly known as the Rogaway attack) s +5 613 M +( [ROGAWAY],[DAI],[BELLARE,KOHNO,NAMPREMPRE]\) to work, the attacker) s +5 602 M +( would need to know the IV of the next block that is going to be) s +5 591 M +( encrypted. In CBC mode that is the output of the encryption of the) s +5 580 M +( previous block. If the attacker does not have any way to see the) s +5 569 M +( packet yet \(i.e it is in the internal buffers of the ssh) s +5 558 M +( implementation or even in the kernel\) then this attack will not work.) s +5 547 M +( If the last packet has been sent out to the network \(i.e the attacker) s +5 536 M +( has access to it\) then he can use the attack.) s +5 514 M +( In the optimal case an implementor would need to add an extra packet) s +5 503 M +( only if the packet has been sent out onto the network and there are) s +5 492 M +( no other packets waiting for transmission. Implementors may wish to) s +5 481 M +( check to see if there are any unsent packets awaiting transmission,) s +5 470 M +( but unfortunately it is not normally easy to obtain this information) s +5 459 M +( from the kernel or buffers. If there are not, then a packet) s +5 448 M +( containing SSH_MSG_IGNORE SHOULD be sent. If a new packet is added) s +5 437 M +( to the stream every time the attacker knows the IV that is supposed) s +5 426 M +( to be used for the next packet, then the attacker will not be able to) s +5 415 M +( guess the correct IV, thus the attack will never be successfull.) s +5 393 M +( As an example, consider the following case:) s +5 360 M +( Client Server) s +5 349 M +( ------ ------) s +5 338 M +( TCP\(seq=x, len=500\) ->) s +5 327 M +( contains Record 1) s +5 305 M +( [500 ms passes, no ACK]) s +5 283 M +( TCP\(seq=x, len=1000\) ->) s +5 272 M +( contains Records 1,2) s +5 250 M +( ACK) s +5 217 M +( 1. The Nagle algorithm + TCP retransmits mean that the two records) s +5 206 M +( get coalesced into a single TCP segment) s +5 195 M +( 2. Record 2 is *not* at the beginning of the TCP segment and never) s +5 184 M +( will be, since it gets ACKed.) s +5 129 M +(Ylonen & Moffat Expires March 31, 2004 [Page 14]) s +_R +S +PStoPSsaved restore +%%Page: (14,15) 8 +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 0.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +/showpage{}def/copypage{}def/erasepage{}def +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 15 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH Protocol Architecture Oct 2003) s +5 690 M +( 3. Yet, the attack is possible because Record 1 has already been) s +5 679 M +( seen.) s +5 657 M +( As this example indicates, it's totally unsafe to use the existence) s +5 646 M +( of unflushed data in the TCP buffers proper as a guide to whether you) s +5 635 M +( need an empty packet, since when you do the second write\(\), the) s +5 624 M +( buffers will contain the un-ACKed Record 1.) s +5 129 M +(Ylonen & Moffat Expires March 31, 2004 [Page 15]) s +_R +S +PStoPSsaved restore +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 421.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 16 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH Protocol Architecture Oct 2003) s +5 690 M +( On the other hand, it's perfectly safe to have the following) s +5 679 M +( situation:) s +5 646 M +( Client Server) s +5 635 M +( ------ ------) s +5 624 M +( TCP\(seq=x, len=500\) ->) s +5 613 M +( contains SSH_MSG_IGNORE) s +5 591 M +( TCP\(seq=y, len=500\) ->) s +5 580 M +( contains Data) s +5 558 M +( Provided that the IV for second SSH Record is fixed after the data for) s +5 547 M +( the Data packet is determined -i.e. you do:) s +5 536 M +( read from user) s +5 525 M +( encrypt null packet) s +5 514 M +( encrypt data packet) s +5 481 M +(9.2.2 Data Integrity) s +5 459 M +( This protocol does allow the Data Integrity mechanism to be disabled.) s +5 448 M +( Implementors SHOULD be wary of exposing this feature for any purpose) s +5 437 M +( other than debugging. Users and administrators SHOULD be explicitly) s +5 426 M +( warned anytime the "none" MAC is enabled.) s +5 404 M +( So long as the "none" MAC is not used, this protocol provides data) s +5 393 M +( integrity.) s +5 371 M +( Because MACs use a 32 bit sequence number, they might start to leak) s +5 360 M +( information after 2**32 packets have been sent. However, following) s +5 349 M +( the rekeying recommendations should prevent this attack. The) s +5 338 M +( transport protocol [1] recommends rekeying after one gigabyte of) s +5 327 M +( data, and the smallest possible packet is 16 bytes. Therefore,) s +5 316 M +( rekeying SHOULD happen after 2**28 packets at the very most.) s +5 294 M +(9.2.3 Replay) s +5 272 M +( The use of a MAC other than 'none' provides integrity and) s +5 261 M +( authentication. In addition, the transport protocol provides a) s +5 250 M +( unique session identifier \(bound in part to pseudo-random data that) s +5 239 M +( is part of the algorithm and key exchange process\) that can be used) s +5 228 M +( by higher level protocols to bind data to a given session and prevent) s +5 217 M +( replay of data from prior sessions. For example, the authentication) s +5 206 M +( protocol uses this to prevent replay of signatures from previous) s +5 195 M +( sessions. Because public key authentication exchanges are) s +5 184 M +( cryptographically bound to the session \(i.e., to the initial key) s +5 173 M +( exchange\) they cannot be successfully replayed in other sessions.) s +5 129 M +(Ylonen & Moffat Expires March 31, 2004 [Page 16]) s +_R +S +PStoPSsaved restore +%%Page: (16,17) 9 +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 0.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +/showpage{}def/copypage{}def/erasepage{}def +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 17 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH Protocol Architecture Oct 2003) s +5 690 M +( Note that the session ID can be made public without harming the) s +5 679 M +( security of the protocol.) s +5 657 M +( If two session happen to have the same session ID [hash of key) s +5 646 M +( exchanges] then packets from one can be replayed against the other.) s +5 635 M +( It must be stressed that the chances of such an occurrence are,) s +5 624 M +( needless to say, minimal when using modern cryptographic methods.) s +5 613 M +( This is all the more so true when specifying larger hash function) s +5 602 M +( outputs and DH parameters.) s +5 580 M +( Replay detection using monotonically increasing sequence numbers as) s +5 569 M +( input to the MAC, or HMAC in some cases, is described in [RFC2085] />) s +5 558 M +( [RFC2246], [RFC2743], [RFC1964], [RFC2025], and [RFC1510]. The) s +5 547 M +( underlying construct is discussed in [RFC2104]. Essentially a) s +5 536 M +( different sequence number in each packet ensures that at least this) s +5 525 M +( one input to the MAC function will be unique and will provide a) s +5 514 M +( nonrecurring MAC output that is not predictable to an attacker. If) s +5 503 M +( the session stays active long enough, however, this sequence number) s +5 492 M +( will wrap. This event may provide an attacker an opportunity to) s +5 481 M +( replay a previously recorded packet with an identical sequence number) s +5 470 M +( but only if the peers have not rekeyed since the transmission of the) s +5 459 M +( first packet with that sequence number. If the peers have rekeyed,) s +5 448 M +( then the replay will be detected as the MAC check will fail. For) s +5 437 M +( this reason, it must be emphasized that peers MUST rekey before a) s +5 426 M +( wrap of the sequence numbers. Naturally, if an attacker does attempt) s +5 415 M +( to replay a captured packet before the peers have rekeyed, then the) s +5 404 M +( receiver of the duplicate packet will not be able to validate the MAC) s +5 393 M +( and it will be discarded. The reason that the MAC will fail is) s +5 382 M +( because the receiver will formulate a MAC based upon the packet) s +5 371 M +( contents, the shared secret, and the expected sequence number. Since) s +5 360 M +( the replayed packet will not be using that expected sequence number) s +5 349 M +( \(the sequence number of the replayed packet will have already been) s +5 338 M +( passed by the receiver\) then the calculated MAC will not match the) s +5 327 M +( MAC received with the packet.) s +5 305 M +(9.2.4 Man-in-the-middle) s +5 283 M +( This protocol makes no assumptions nor provisions for an) s +5 272 M +( infrastructure or means for distributing the public keys of hosts. It) s +5 261 M +( is expected that this protocol will sometimes be used without first) s +5 250 M +( verifying the association between the server host key and the server) s +5 239 M +( host name. Such usage is vulnerable to man-in-the-middle attacks.) s +5 228 M +( This section describes this and encourages administrators and users) s +5 217 M +( to understand the importance of verifying this association before any) s +5 206 M +( session is initiated.) s +5 184 M +( There are three cases of man-in-the-middle attacks to consider. The) s +5 173 M +( first is where an attacker places a device between the client and the) s +5 129 M +(Ylonen & Moffat Expires March 31, 2004 [Page 17]) s +_R +S +PStoPSsaved restore +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 421.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 18 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH Protocol Architecture Oct 2003) s +5 690 M +( server before the session is initiated. In this case, the attack) s +5 679 M +( device is trying to mimic the legitimate server and will offer its) s +5 668 M +( public key to the client when the client initiates a session. If it) s +5 657 M +( were to offer the public key of the server, then it would not be able) s +5 646 M +( to decrypt or sign the transmissions between the legitimate server) s +5 635 M +( and the client unless it also had access to the private-key of the) s +5 624 M +( host. The attack device will also, simultaneously to this, initiate) s +5 613 M +( a session to the legitimate server masquerading itself as the client.) s +5 602 M +( If the public key of the server had been securely distributed to the) s +5 591 M +( client prior to that session initiation, the key offered to the) s +5 580 M +( client by the attack device will not match the key stored on the) s +5 569 M +( client. In that case, the user SHOULD be given a warning that the) s +5 558 M +( offered host key does not match the host key cached on the client.) s +5 547 M +( As described in Section 3.1 of [ARCH], the user may be free to accept) s +5 536 M +( the new key and continue the session. It is RECOMMENDED that the) s +5 525 M +( warning provide sufficient information to the user of the client) s +5 514 M +( device so they may make an informed decision. If the user chooses to) s +5 503 M +( continue the session with the stored public-key of the server \(not) s +5 492 M +( the public-key offered at the start of the session\), then the session) s +5 481 M +( specific data between the attacker and server will be different) s +5 470 M +( between the client-to-attacker session and the attacker-to-server) s +5 459 M +( sessions due to the randomness discussed above. From this, the) s +5 448 M +( attacker will not be able to make this attack work since the attacker) s +5 437 M +( will not be able to correctly sign packets containing this session) s +5 426 M +( specific data from the server since he does not have the private key) s +5 415 M +( of that server.) s +5 393 M +( The second case that should be considered is similar to the first) s +5 382 M +( case in that it also happens at the time of connection but this case) s +5 371 M +( points out the need for the secure distribution of server public) s +5 360 M +( keys. If the server public keys are not securely distributed then) s +5 349 M +( the client cannot know if it is talking to the intended server. An) s +5 338 M +( attacker may use social engineering techniques to pass off server) s +5 327 M +( keys to unsuspecting users and may then place a man-in-the-middle) s +5 316 M +( attack device between the legitimate server and the clients. If this) s +5 305 M +( is allowed to happen then the clients will form client-to-attacker) s +5 294 M +( sessions and the attacker will form attacker-to-server sessions and) s +5 283 M +( will be able to monitor and manipulate all of the traffic between the) s +5 272 M +( clients and the legitimate servers. Server administrators are) s +5 261 M +( encouraged to make host key fingerprints available for checking by) s +5 250 M +( some means whose security does not rely on the integrity of the) s +5 239 M +( actual host keys. Possible mechanisms are discussed in Section 3.1) s +5 228 M +( of [SSH-ARCH] and may also include secured Web pages, physical pieces) s +5 217 M +( of paper, etc. Implementors SHOULD provide recommendations on how) s +5 206 M +( best to do this with their implementation. Because the protocol is) s +5 195 M +( extensible, future extensions to the protocol may provide better) s +5 184 M +( mechanisms for dealing with the need to know the server's host key) s +5 173 M +( before connecting. For example, making the host key fingerprint) s +5 129 M +(Ylonen & Moffat Expires March 31, 2004 [Page 18]) s +_R +S +PStoPSsaved restore +%%Page: (18,19) 10 +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 0.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +/showpage{}def/copypage{}def/erasepage{}def +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 19 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH Protocol Architecture Oct 2003) s +5 690 M +( available through a secure DNS lookup, or using kerberos over gssapi) s +5 679 M +( during key exchange to authenticate the server are possibilities.) s +5 657 M +( In the third man-in-the-middle case, attackers may attempt to) s +5 646 M +( manipulate packets in transit between peers after the session has) s +5 635 M +( been established. As described in the Replay part of this section, a) s +5 624 M +( successful attack of this nature is very improbable. As in the) s +5 613 M +( Replay section, this reasoning does assume that the MAC is secure and) s +5 602 M +( that it is infeasible to construct inputs to a MAC algorithm to give) s +5 591 M +( a known output. This is discussed in much greater detail in Section) s +5 580 M +( 6 of RFC 2104. If the MAC algorithm has a vulnerability or is weak) s +5 569 M +( enough, then the attacker may be able to specify certain inputs to) s +5 558 M +( yield a known MAC. With that they may be able to alter the contents) s +5 547 M +( of a packet in transit. Alternatively the attacker may be able to) s +5 536 M +( exploit the algorithm vulnerability or weakness to find the shared) s +5 525 M +( secret by reviewing the MACs from captured packets. In either of) s +5 514 M +( those cases, an attacker could construct a packet or packets that) s +5 503 M +( could be inserted into an SSH stream. To prevent that, implementors) s +5 492 M +( are encouraged to utilize commonly accepted MAC algorithms and) s +5 481 M +( administrators are encouraged to watch current literature and) s +5 470 M +( discussions of cryptography to ensure that they are not using a MAC) s +5 459 M +( algorithm that has a recently found vulnerability or weakness.) s +5 437 M +( In summary, the use of this protocol without a reliable association) s +5 426 M +( of the binding between a host and its host keys is inherently) s +5 415 M +( insecure and is NOT RECOMMENDED. It may however be necessary in) s +5 404 M +( non-security critical environments, and will still provide protection) s +5 393 M +( against passive attacks. Implementors of protocols and applications) s +5 382 M +( running on top of this protocol should keep this possibility in mind.) s +5 360 M +(9.2.5 Denial-of-service) s +5 338 M +( This protocol is designed to be used over a reliable transport. If) s +5 327 M +( transmission errors or message manipulation occur, the connection is) s +5 316 M +( closed. The connection SHOULD be re-established if this occurs.) s +5 305 M +( Denial of service attacks of this type \("wire cutter"\) are almost) s +5 294 M +( impossible to avoid.) s +5 272 M +( In addition, this protocol is vulnerable to Denial of Service attacks) s +5 261 M +( because an attacker can force the server to go through the CPU and) s +5 250 M +( memory intensive tasks of connection setup and key exchange without) s +5 239 M +( authenticating. Implementors SHOULD provide features that make this) s +5 228 M +( more difficult. For example, only allowing connections from a subset) s +5 217 M +( of IPs known to have valid users.) s +5 195 M +(9.2.6 Covert Channels) s +5 173 M +( The protocol was not designed to eliminate covert channels. For) s +5 129 M +(Ylonen & Moffat Expires March 31, 2004 [Page 19]) s +_R +S +PStoPSsaved restore +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 421.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 20 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH Protocol Architecture Oct 2003) s +5 690 M +( example, the padding, SSH_MSG_IGNORE messages, and several other) s +5 679 M +( places in the protocol can be used to pass covert information, and) s +5 668 M +( the recipient has no reliable way to verify whether such information) s +5 657 M +( is being sent.) s +5 635 M +(9.2.7 Forward Secrecy) s +5 613 M +( It should be noted that the Diffie-Hellman key exchanges may provide) s +5 602 M +( perfect forward secrecy \(PFS\). PFS is essentially defined as the) s +5 591 M +( cryptographic property of a key-establishment protocol in which the) s +5 580 M +( compromise of a session key or long-term private key after a given) s +5 569 M +( session does not cause the compromise of any earlier session. [ANSI) s +5 558 M +( T1.523-2001] SSHv2 sessions resulting from a key exchange using) s +5 547 M +( diffie-hellman-group1-sha1 are secure even if private keying/) s +5 536 M +( authentication material is later revealed, but not if the session) s +5 525 M +( keys are revealed. So, given this definition of PFS, SSHv2 does have) s +5 514 M +( PFS. It is hoped that all other key exchange mechanisms proposed and) s +5 503 M +( used in the future will also provide PFS. This property is not) s +5 492 M +( commuted to any of the applications or protocols using SSH as a) s +5 481 M +( transport however. The transport layer of SSH provides) s +5 470 M +( confidentiality for password authentication and other methods that) s +5 459 M +( rely on secret data.) s +5 437 M +( Of course, if the DH private parameters for the client and server are) s +5 426 M +( revealed then the session key is revealed, but these items can be) s +5 415 M +( thrown away after the key exchange completes. It's worth pointing) s +5 404 M +( out that these items should not be allowed to end up on swap space) s +5 393 M +( and that they should be erased from memory as soon as the key) s +5 382 M +( exchange completes.) s +5 360 M +(9.3 Authentication Protocol) s +5 338 M +( The purpose of this protocol is to perform client user) s +5 327 M +( authentication. It assumes that this run over a secure transport) s +5 316 M +( layer protocol, which has already authenticated the server machine,) s +5 305 M +( established an encrypted communications channel, and computed a) s +5 294 M +( unique session identifier for this session.) s +5 272 M +( Several authentication methods with different security) s +5 261 M +( characteristics are allowed. It is up to the server's local policy) s +5 250 M +( to decide which methods \(or combinations of methods\) it is willing to) s +5 239 M +( accept for each user. Authentication is no stronger than the weakest) s +5 228 M +( combination allowed.) s +5 206 M +( The server may go into a "sleep" period after repeated unsuccessful) s +5 195 M +( authentication attempts to make key search more difficult for) s +5 184 M +( attackers. Care should be taken so that this doesn't become a) s +5 173 M +( self-denial of service vector.) s +5 129 M +(Ylonen & Moffat Expires March 31, 2004 [Page 20]) s +_R +S +PStoPSsaved restore +%%Page: (20,21) 11 +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 0.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +/showpage{}def/copypage{}def/erasepage{}def +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 21 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH Protocol Architecture Oct 2003) s +5 690 M +(9.3.1 Weak Transport) s +5 668 M +( If the transport layer does not provide confidentiality,) s +5 657 M +( authentication methods that rely on secret data SHOULD be disabled.) s +5 646 M +( If it does not provide strong integrity protection, requests to) s +5 635 M +( change authentication data \(e.g. a password change\) SHOULD be) s +5 624 M +( disabled to prevent an attacker from modifying the ciphertext) s +5 613 M +( without being noticed, or rendering the new authentication data) s +5 602 M +( unusable \(denial of service\).) s +5 580 M +( The assumption as stated above that the Authentication Protocol only) s +5 569 M +( run over a secure transport that has previously authenticated the) s +5 558 M +( server is very important to note. People deploying SSH are reminded) s +5 547 M +( of the consequences of man-in-the-middle attacks if the client does) s +5 536 M +( not have a very strong a priori association of the server with the) s +5 525 M +( host key of that server. Specifically for the case of the) s +5 514 M +( Authentication Protocol the client may form a session to a) s +5 503 M +( man-in-the-middle attack device and divulge user credentials such as) s +5 492 M +( their username and password. Even in the cases of authentication) s +5 481 M +( where no user credentials are divulged, an attacker may still gain) s +5 470 M +( information they shouldn't have by capturing key-strokes in much the) s +5 459 M +( same way that a honeypot works.) s +5 437 M +(9.3.2 Debug messages) s +5 415 M +( Special care should be taken when designing debug messages. These) s +5 404 M +( messages may reveal surprising amounts of information about the host) s +5 393 M +( if not properly designed. Debug messages can be disabled \(during) s +5 382 M +( user authentication phase\) if high security is required.) s +5 371 M +( Administrators of host machines should make all attempts to) s +5 360 M +( compartmentalize all event notification messages and protect them) s +5 349 M +( from unwarranted observation. Developers should be aware of the) s +5 338 M +( sensitive nature of some of the normal event messages and debug) s +5 327 M +( messages and may want to provide guidance to administrators on ways) s +5 316 M +( to keep this information away from unauthorized people. Developers) s +5 305 M +( should consider minimizing the amount of sensitive information) s +5 294 M +( obtainable by users during the authentication phase in accordance) s +5 283 M +( with the local policies. For this reason, it is RECOMMENDED that) s +5 272 M +( debug messages be initially disabled at the time of deployment and) s +5 261 M +( require an active decision by an administrator to allow them to be) s +5 250 M +( enabled. It is also RECOMMENDED that a message expressing this) s +5 239 M +( concern be presented to the administrator of a system when the action) s +5 228 M +( is taken to enable debugging messages.) s +5 206 M +(9.3.3 Local security policy) s +5 184 M +( Implementer MUST ensure that the credentials provided validate the) s +5 173 M +( professed user and also MUST ensure that the local policy of the) s +5 129 M +(Ylonen & Moffat Expires March 31, 2004 [Page 21]) s +_R +S +PStoPSsaved restore +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 421.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 22 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH Protocol Architecture Oct 2003) s +5 690 M +( server permits the user the access requested. In particular, because) s +5 679 M +( of the flexible nature of the SSH connection protocol, it may not be) s +5 668 M +( possible to determine the local security policy, if any, that should) s +5 657 M +( apply at the time of authentication because the kind of service being) s +5 646 M +( requested is not clear at that instant. For example, local policy) s +5 635 M +( might allow a user to access files on the server, but not start an) s +5 624 M +( interactive shell. However, during the authentication protocol, it is) s +5 613 M +( not known whether the user will be accessing files or attempting to) s +5 602 M +( use an interactive shell, or even both. In any event, where local) s +5 591 M +( security policy for the server host exists, it MUST be applied and) s +5 580 M +( enforced correctly.) s +5 558 M +( Implementors are encouraged to provide a default local policy and) s +5 547 M +( make its parameters known to administrators and users. At the) s +5 536 M +( discretion of the implementors, this default policy may be along the) s +5 525 M +( lines of 'anything goes' where there are no restrictions placed upon) s +5 514 M +( users, or it may be along the lines of 'excessively restrictive' in) s +5 503 M +( which case the administrators will have to actively make changes to) s +5 492 M +( this policy to meet their needs. Alternatively, it may be some) s +5 481 M +( attempt at providing something practical and immediately useful to) s +5 470 M +( the administrators of the system so they don't have to put in much) s +5 459 M +( effort to get SSH working. Whatever choice is made MUST be applied) s +5 448 M +( and enforced as required above.) s +5 426 M +(9.3.4 Public key authentication) s +5 404 M +( The use of public-key authentication assumes that the client host has) s +5 393 M +( not been compromised. It also assumes that the private-key of the) s +5 382 M +( server host has not been compromised.) s +5 360 M +( This risk can be mitigated by the use of passphrases on private keys;) s +5 349 M +( however, this is not an enforceable policy. The use of smartcards,) s +5 338 M +( or other technology to make passphrases an enforceable policy is) s +5 327 M +( suggested.) s +5 305 M +( The server could require both password and public-key authentication,) s +5 294 M +( however, this requires the client to expose its password to the) s +5 283 M +( server \(see section on password authentication below.\)) s +5 261 M +(9.3.5 Password authentication) s +5 239 M +( The password mechanism as specified in the authentication protocol) s +5 228 M +( assumes that the server has not been compromised. If the server has) s +5 217 M +( been compromised, using password authentication will reveal a valid) s +5 206 M +( username / password combination to the attacker, which may lead to) s +5 195 M +( further compromises.) s +5 173 M +( This vulnerability can be mitigated by using an alternative form of) s +5 129 M +(Ylonen & Moffat Expires March 31, 2004 [Page 22]) s +_R +S +PStoPSsaved restore +%%Page: (22,23) 12 +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 0.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +/showpage{}def/copypage{}def/erasepage{}def +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 23 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH Protocol Architecture Oct 2003) s +5 690 M +( authentication. For example, public-key authentication makes no) s +5 679 M +( assumptions about security on the server.) s +5 657 M +(9.3.6 Host based authentication) s +5 635 M +( Host based authentication assumes that the client has not been) s +5 624 M +( compromised. There are no mitigating strategies, other than to use) s +5 613 M +( host based authentication in combination with another authentication) s +5 602 M +( method.) s +5 580 M +(9.4 Connection protocol) s +5 558 M +(9.4.1 End point security) s +5 536 M +( End point security is assumed by the connection protocol. If the) s +5 525 M +( server has been compromised, any terminal sessions, port forwarding,) s +5 514 M +( or systems accessed on the host are compromised. There are no) s +5 503 M +( mitigating factors for this.) s +5 481 M +( If the client end point has been compromised, and the server fails to) s +5 470 M +( stop the attacker at the authentication protocol, all services) s +5 459 M +( exposed \(either as subsystems or through forwarding\) will be) s +5 448 M +( vulnerable to attack. Implementors SHOULD provide mechanisms for) s +5 437 M +( administrators to control which services are exposed to limit the) s +5 426 M +( vulnerability of other services.) s +5 404 M +( These controls might include controlling which machines and ports can) s +5 393 M +( be target in 'port-forwarding' operations, which users are allowed to) s +5 382 M +( use interactive shell facilities, or which users are allowed to use) s +5 371 M +( exposed subsystems.) s +5 349 M +(9.4.2 Proxy forwarding) s +5 327 M +( The SSH connection protocol allows for proxy forwarding of other) s +5 316 M +( protocols such as SNMP, POP3, and HTTP. This may be a concern for) s +5 305 M +( network administrators who wish to control the access of certain) s +5 294 M +( applications by users located outside of their physical location.) s +5 283 M +( Essentially, the forwarding of these protocols may violate site) s +5 272 M +( specific security policies as they may be undetectably tunneled) s +5 261 M +( through a firewall. Implementors SHOULD provide an administrative) s +5 250 M +( mechanism to control the proxy forwarding functionality so that site) s +5 239 M +( specific security policies may be upheld.) s +5 217 M +( In addition, a reverse proxy forwarding functionality is available,) s +5 206 M +( which again can be used to bypass firewall controls.) s +5 184 M +( As indicated above, end-point security is assumed during proxy) s +5 173 M +( forwarding operations. Failure of end-point security will compromise) s +5 129 M +(Ylonen & Moffat Expires March 31, 2004 [Page 23]) s +_R +S +PStoPSsaved restore +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 421.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 24 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH Protocol Architecture Oct 2003) s +5 690 M +( all data passed over proxy forwarding.) s +5 668 M +(9.4.3 X11 forwarding) s +5 646 M +( Another form of proxy forwarding provided by the ssh connection) s +5 635 M +( protocol is the forwarding of the X11 protocol. If end-point) s +5 624 M +( security has been compromised, X11 forwarding may allow attacks) s +5 613 M +( against the X11 server. Users and administrators should, as a matter) s +5 602 M +( of course, use appropriate X11 security mechanisms to prevent) s +5 591 M +( unauthorized use of the X11 server. Implementors, administrators and) s +5 580 M +( users who wish to further explore the security mechanisms of X11 are) s +5 569 M +( invited to read [SCHEIFLER] and analyze previously reported problems) s +5 558 M +( with the interactions between SSH forwarding and X11 in CERT) s +5 547 M +( vulnerabilities VU#363181 and VU#118892 [CERT].) s +5 525 M +( X11 display forwarding with SSH, by itself, is not sufficient to) s +5 514 M +( correct well known problems with X11 security [VENEMA]. However, X11) s +5 503 M +( display forwarding in SSHv2 \(or other, secure protocols\), combined) s +5 492 M +( with actual and pseudo-displays which accept connections only over) s +5 481 M +( local IPC mechanisms authorized by permissions or ACLs, does correct) s +5 470 M +( many X11 security problems as long as the "none" MAC is not used. It) s +5 459 M +( is RECOMMENDED that X11 display implementations default to allowing) s +5 448 M +( display opens only over local IPC. It is RECOMMENDED that SSHv2) s +5 437 M +( server implementations that support X11 forwarding default to) s +5 426 M +( allowing display opens only over local IPC. On single-user systems) s +5 415 M +( it might be reasonable to default to allowing local display opens) s +5 404 M +( over TCP/IP.) s +5 382 M +( Implementors of the X11 forwarding protocol SHOULD implement the) s +5 371 M +( magic cookie access checking spoofing mechanism as described in) s +5 360 M +( [ssh-connect] as an additional mechanism to prevent unauthorized use) s +5 349 M +( of the proxy.) s +5 327 M +(Normative References) s +5 305 M +( [SSH-ARCH]) s +5 294 M +( Ylonen, T., "SSH Protocol Architecture", I-D) s +5 283 M +( draft-ietf-architecture-15.txt, Oct 2003.) s +5 261 M +( [SSH-TRANS]) s +5 250 M +( Ylonen, T., "SSH Transport Layer Protocol", I-D) s +5 239 M +( draft-ietf-transport-17.txt, Oct 2003.) s +5 217 M +( [SSH-USERAUTH]) s +5 206 M +( Ylonen, T., "SSH Authentication Protocol", I-D) s +5 195 M +( draft-ietf-userauth-18.txt, Oct 2003.) s +5 173 M +( [SSH-CONNECT]) s +5 129 M +(Ylonen & Moffat Expires March 31, 2004 [Page 24]) s +_R +S +PStoPSsaved restore +%%Page: (24,25) 13 +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 0.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +/showpage{}def/copypage{}def/erasepage{}def +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 25 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH Protocol Architecture Oct 2003) s +5 690 M +( Ylonen, T., "SSH Connection Protocol", I-D) s +5 679 M +( draft-ietf-connect-18.txt, Oct 2003.) s +5 657 M +( [SSH-NUMBERS]) s +5 646 M +( Lehtinen, S. and D. Moffat, "SSH Protocol Assigned) s +5 635 M +( Numbers", I-D draft-ietf-secsh-assignednumbers-05.txt, Oct) s +5 624 M +( 2003.) s +5 602 M +( [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate) s +5 591 M +( Requirement Levels", BCP 14, RFC 2119, March 1997.) s +5 569 M +(Informative References) s +5 547 M +( [FIPS-186]) s +5 536 M +( Federal Information Processing Standards Publication,) s +5 525 M +( "FIPS PUB 186, Digital Signature Standard", May 1994.) s +5 503 M +( [FIPS-197]) s +5 492 M +( National Institue of Standards and Technology, "FIPS 197,) s +5 481 M +( Specification for the Advanced Encryption Standard",) s +5 470 M +( November 2001.) s +5 448 M +( [ANSI T1.523-2001]) s +5 437 M +( American National Standards Insitute, Inc., "Telecom) s +5 426 M +( Glossary 2000", February 2001.) s +5 404 M +( [SCHEIFLER]) s +5 393 M +( Scheifler, R., "X Window System : The Complete Reference) s +5 382 M +( to Xlib, X Protocol, Icccm, Xlfd, 3rd edition.", Digital) s +5 371 M +( Press ISBN 1555580882, Feburary 1992.) s +5 349 M +( [RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol) s +5 338 M +( Specification", STD 8, RFC 854, May 1983.) s +5 316 M +( [RFC0894] Hornig, C., "Standard for the transmission of IP datagrams) s +5 305 M +( over Ethernet networks", STD 41, RFC 894, April 1984.) s +5 283 M +( [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",) s +5 272 M +( STD 13, RFC 1034, November 1987.) s +5 250 M +( [RFC1134] Perkins, D., "Point-to-Point Protocol: A proposal for) s +5 239 M +( multi-protocol transmission of datagrams over) s +5 228 M +( Point-to-Point links", RFC 1134, November 1989.) s +5 206 M +( [RFC1282] Kantor, B., "BSD Rlogin", RFC 1282, December 1991.) s +5 184 M +( [RFC1510] Kohl, J. and B. Neuman, "The Kerberos Network) s +5 173 M +( Authentication Service \(V5\)", RFC 1510, September 1993.) s +5 129 M +(Ylonen & Moffat Expires March 31, 2004 [Page 25]) s +_R +S +PStoPSsaved restore +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 421.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 26 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH Protocol Architecture Oct 2003) s +5 690 M +( [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700,) s +5 679 M +( October 1994.) s +5 657 M +( [RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness) s +5 646 M +( Recommendations for Security", RFC 1750, December 1994.) s +5 624 M +( [RFC3066] Alvestrand, H., "Tags for the Identification of) s +5 613 M +( Languages", BCP 47, RFC 3066, January 2001.) s +5 591 M +( [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC) s +5 580 M +( 1964, June 1996.) s +5 558 M +( [RFC2025] Adams, C., "The Simple Public-Key GSS-API Mechanism) s +5 547 M +( \(SPKM\)", RFC 2025, October 1996.) s +5 525 M +( [RFC2085] Oehler, M. and R. Glenn, "HMAC-MD5 IP Authentication with) s +5 514 M +( Replay Prevention", RFC 2085, February 1997.) s +5 492 M +( [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC:) s +5 481 M +( Keyed-Hashing for Message Authentication", RFC 2104,) s +5 470 M +( February 1997.) s +5 448 M +( [RFC2246] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A.) s +5 437 M +( and P. Kocher, "The TLS Protocol Version 1.0", RFC 2246,) s +5 426 M +( January 1999.) s +5 404 M +( [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO) s +5 393 M +( 10646", RFC 2279, January 1998.) s +5 371 M +( [RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and) s +5 360 M +( Its Use With IPsec", RFC 2410, November 1998.) s +5 338 M +( [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an) s +5 327 M +( IANA Considerations Section in RFCs", BCP 26, RFC 2434,) s +5 316 M +( October 1998.) s +5 294 M +( [RFC2743] Linn, J., "Generic Security Service Application Program) s +5 283 M +( Interface Version 2, Update 1", RFC 2743, January 2000.) s +5 261 M +( [SCHNEIER]) s +5 250 M +( Schneier, B., "Applied Cryptography Second Edition:) s +5 239 M +( protocols algorithms and source in code in C", 1996.) s +5 217 M +( [KAUFMAN,PERLMAN,SPECINER]) s +5 206 M +( Kaufman, C., Perlman, R. and M. Speciner, "Network) s +5 195 M +( Security: PRIVATE Communication in a PUBLIC World", 1995.) s +5 173 M +( [CERT] CERT Coordination Center, The., "http://www.cert.org/nav/) s +5 129 M +(Ylonen & Moffat Expires March 31, 2004 [Page 26]) s +_R +S +PStoPSsaved restore +%%Page: (26,27) 14 +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 0.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +/showpage{}def/copypage{}def/erasepage{}def +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 27 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH Protocol Architecture Oct 2003) s +5 690 M +( index_red.html".) s +5 668 M +( [VENEMA] Venema, W., "Murphy's Law and Computer Security",) s +5 657 M +( Proceedings of 6th USENIX Security Symposium, San Jose CA) s +5 646 M +( http://www.usenix.org/publications/library/proceedings/) s +5 635 M +( sec96/venema.html, July 1996.) s +5 613 M +( [ROGAWAY] Rogaway, P., "Problems with Proposed IP Cryptography",) s +5 602 M +( Unpublished paper http://www.cs.ucdavis.edu/~rogaway/) s +5 591 M +( papers/draft-rogaway-ipsec-comments-00.txt, 1996.) s +5 569 M +( [DAI] Dai, W., "An attack against SSH2 protocol", Email to the) s +5 558 M +( SECSH Working Group [email protected] ftp://) s +5 547 M +( ftp.ietf.org/ietf-mail-archive/secsh/2002-02.mail, Feb) s +5 536 M +( 2002.) s +5 514 M +( [BELLARE,KOHNO,NAMPREMPRE]) s +5 503 M +( Bellaire, M., Kohno, T. and C. Namprempre, "Authenticated) s +5 492 M +( Encryption in SSH: Fixing the SSH Binary Packet Protocol",) s +5 481 M +( , Sept 2002.) s +5 448 M +(Authors' Addresses) s +5 426 M +( Tatu Ylonen) s +5 415 M +( SSH Communications Security Corp) s +5 404 M +( Fredrikinkatu 42) s +5 393 M +( HELSINKI FIN-00100) s +5 382 M +( Finland) s +5 360 M +( EMail: [email protected]) s +5 327 M +( Darren J. Moffat \(editor\)) s +5 316 M +( Sun Microsystems, Inc) s +5 305 M +( 17 Network Circle) s +5 294 M +( Menlo Park CA 94025) s +5 283 M +( USA) s +5 261 M +( EMail: [email protected]) s +5 129 M +(Ylonen & Moffat Expires March 31, 2004 [Page 27]) s +_R +S +PStoPSsaved restore +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 421.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 28 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH Protocol Architecture Oct 2003) s +5 690 M +(Intellectual Property Statement) s +5 668 M +( The IETF takes no position regarding the validity or scope of any) s +5 657 M +( intellectual property or other rights that might be claimed to) s +5 646 M +( pertain to the implementation or use of the technology described in) s +5 635 M +( this document or the extent to which any license under such rights) s +5 624 M +( might or might not be available; neither does it represent that it) s +5 613 M +( has made any effort to identify any such rights. Information on the) s +5 602 M +( IETF's procedures with respect to rights in standards-track and) s +5 591 M +( standards-related documentation can be found in BCP-11. Copies of) s +5 580 M +( claims of rights made available for publication and any assurances of) s +5 569 M +( licenses to be made available, or the result of an attempt made to) s +5 558 M +( obtain a general license or permission for the use of such) s +5 547 M +( proprietary rights by implementors or users of this specification can) s +5 536 M +( be obtained from the IETF Secretariat.) s +5 514 M +( The IETF invites any interested party to bring to its attention any) s +5 503 M +( copyrights, patents or patent applications, or other proprietary) s +5 492 M +( rights which may cover technology that may be required to practice) s +5 481 M +( this standard. Please address the information to the IETF Executive) s +5 470 M +( Director.) s +5 448 M +( The IETF has been notified of intellectual property rights claimed in) s +5 437 M +( regard to some or all of the specification contained in this) s +5 426 M +( document. For more information consult the online list of claimed) s +5 415 M +( rights.) s +5 382 M +(Full Copyright Statement) s +5 360 M +( Copyright \(C\) The Internet Society \(2003\). All Rights Reserved.) s +5 338 M +( This document and translations of it may be copied and furnished to) s +5 327 M +( others, and derivative works that comment on or otherwise explain it) s +5 316 M +( or assist in its implementation may be prepared, copied, published) s +5 305 M +( and distributed, in whole or in part, without restriction of any) s +5 294 M +( kind, provided that the above copyright notice and this paragraph are) s +5 283 M +( included on all such copies and derivative works. However, this) s +5 272 M +( document itself may not be modified in any way, such as by removing) s +5 261 M +( the copyright notice or references to the Internet Society or other) s +5 250 M +( Internet organizations, except as needed for the purpose of) s +5 239 M +( developing Internet standards in which case the procedures for) s +5 228 M +( copyrights defined in the Internet Standards process must be) s +5 217 M +( followed, or as required to translate it into languages other than) s +5 206 M +( English.) s +5 184 M +( The limited permissions granted above are perpetual and will not be) s +5 173 M +( revoked by the Internet Society or its successors or assignees.) s +5 129 M +(Ylonen & Moffat Expires March 31, 2004 [Page 28]) s +_R +S +PStoPSsaved restore +%%Page: (28,29) 15 +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 0.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +/showpage{}def/copypage{}def/erasepage{}def +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 29 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH Protocol Architecture Oct 2003) s +5 690 M +( This document and the information contained herein is provided on an) s +5 679 M +( "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING) s +5 668 M +( TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING) s +5 657 M +( BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION) s +5 646 M +( HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF) s +5 635 M +( MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.) s +5 602 M +(Acknowledgment) s +5 580 M +( Funding for the RFC Editor function is currently provided by the) s +5 569 M +( Internet Society.) s +5 129 M +(Ylonen & Moffat Expires March 31, 2004 [Page 29]) s +_R +S +PStoPSsaved restore +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 421.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +PStoPSxform concat +showpage +PStoPSsaved restore +%%Trailer +%%Pages: 29 +%%DocumentNeededResources: font Courier-Bold Courier +%%EOF diff --git a/lib/ssh/doc/standard/draft-ietf-secsh-architecture-15.txt b/lib/ssh/doc/standard/draft-ietf-secsh-architecture-15.txt new file mode 100644 index 0000000000..18070e8485 --- /dev/null +++ b/lib/ssh/doc/standard/draft-ietf-secsh-architecture-15.txt @@ -0,0 +1,1624 @@ + + + +Network Working Group T. Ylonen +Internet-Draft SSH Communications Security Corp +Expires: March 31, 2004 D. Moffat, Ed. + Sun Microsystems, Inc + Oct 2003 + + + SSH Protocol Architecture + draft-ietf-secsh-architecture-15.txt + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that other + groups may also distribute working documents as Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at http:// + www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on March 31, 2004. + +Copyright Notice + + Copyright (C) The Internet Society (2003). All Rights Reserved. + +Abstract + + SSH is a protocol for secure remote login and other secure network + services over an insecure network. This document describes the + architecture of the SSH protocol, as well as the notation and + terminology used in SSH protocol documents. It also discusses the SSH + algorithm naming system that allows local extensions. The SSH + protocol consists of three major components: The Transport Layer + Protocol provides server authentication, confidentiality, and + integrity with perfect forward secrecy. The User Authentication + Protocol authenticates the client to the server. The Connection + Protocol multiplexes the encrypted tunnel into several logical + channels. Details of these protocols are described in separate + + + +Ylonen & Moffat Expires March 31, 2004 [Page 1] + +Internet-Draft SSH Protocol Architecture Oct 2003 + + + documents. + +Table of Contents + + 1. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3. Specification of Requirements . . . . . . . . . . . . . . . 3 + 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 3 + 4.1 Host Keys . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 4.2 Extensibility . . . . . . . . . . . . . . . . . . . . . . . 5 + 4.3 Policy Issues . . . . . . . . . . . . . . . . . . . . . . . 5 + 4.4 Security Properties . . . . . . . . . . . . . . . . . . . . 6 + 4.5 Packet Size and Overhead . . . . . . . . . . . . . . . . . . 6 + 4.6 Localization and Character Set Support . . . . . . . . . . . 7 + 5. Data Type Representations Used in the SSH Protocols . . . . 8 + 6. Algorithm Naming . . . . . . . . . . . . . . . . . . . . . . 10 + 7. Message Numbers . . . . . . . . . . . . . . . . . . . . . . 11 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 11 + 9. Security Considerations . . . . . . . . . . . . . . . . . . 12 + 9.1 Pseudo-Random Number Generation . . . . . . . . . . . . . . 12 + 9.2 Transport . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 9.2.1 Confidentiality . . . . . . . . . . . . . . . . . . . . . . 13 + 9.2.2 Data Integrity . . . . . . . . . . . . . . . . . . . . . . . 16 + 9.2.3 Replay . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 + 9.2.4 Man-in-the-middle . . . . . . . . . . . . . . . . . . . . . 17 + 9.2.5 Denial-of-service . . . . . . . . . . . . . . . . . . . . . 19 + 9.2.6 Covert Channels . . . . . . . . . . . . . . . . . . . . . . 19 + 9.2.7 Forward Secrecy . . . . . . . . . . . . . . . . . . . . . . 20 + 9.3 Authentication Protocol . . . . . . . . . . . . . . . . . . 20 + 9.3.1 Weak Transport . . . . . . . . . . . . . . . . . . . . . . . 21 + 9.3.2 Debug messages . . . . . . . . . . . . . . . . . . . . . . . 21 + 9.3.3 Local security policy . . . . . . . . . . . . . . . . . . . 21 + 9.3.4 Public key authentication . . . . . . . . . . . . . . . . . 22 + 9.3.5 Password authentication . . . . . . . . . . . . . . . . . . 22 + 9.3.6 Host based authentication . . . . . . . . . . . . . . . . . 23 + 9.4 Connection protocol . . . . . . . . . . . . . . . . . . . . 23 + 9.4.1 End point security . . . . . . . . . . . . . . . . . . . . . 23 + 9.4.2 Proxy forwarding . . . . . . . . . . . . . . . . . . . . . . 23 + 9.4.3 X11 forwarding . . . . . . . . . . . . . . . . . . . . . . . 24 + Normative References . . . . . . . . . . . . . . . . . . . . 24 + Informative References . . . . . . . . . . . . . . . . . . . 25 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 27 + Intellectual Property and Copyright Statements . . . . . . . 28 + + + + + + + + +Ylonen & Moffat Expires March 31, 2004 [Page 2] + +Internet-Draft SSH Protocol Architecture Oct 2003 + + +1. Contributors + + The major original contributors of this document were: Tatu Ylonen, + Tero Kivinen, Timo J. Rinne, Sami Lehtinen (all of SSH Communications + Security Corp), and Markku-Juhani O. Saarinen (University of + Jyvaskyla) + + The document editor is: [email protected]. Comments on this + internet draft should be sent to the IETF SECSH working group, + details at: http://ietf.org/html.charters/secsh-charter.html + +2. Introduction + + SSH is a protocol for secure remote login and other secure network + services over an insecure network. It consists of three major + components: + o The Transport Layer Protocol [SSH-TRANS] provides server + authentication, confidentiality, and integrity. It may optionally + also provide compression. The transport layer will typically be + run over a TCP/IP connection, but might also be used on top of any + other reliable data stream. + o The User Authentication Protocol [SSH-USERAUTH] authenticates the + client-side user to the server. It runs over the transport layer + protocol. + o The Connection Protocol [SSH-CONNECT] multiplexes the encrypted + tunnel into several logical channels. It runs over the user + authentication protocol. + + The client sends a service request once a secure transport layer + connection has been established. A second service request is sent + after user authentication is complete. This allows new protocols to + be defined and coexist with the protocols listed above. + + The connection protocol provides channels that can be used for a wide + range of purposes. Standard methods are provided for setting up + secure interactive shell sessions and for forwarding ("tunneling") + arbitrary TCP/IP ports and X11 connections. + +3. Specification of Requirements + + All documents related to the SSH protocols shall use the keywords + "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", + "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" to describe + requirements. They are to be interpreted as described in [RFC2119]. + +4. Architecture + + + + + +Ylonen & Moffat Expires March 31, 2004 [Page 3] + +Internet-Draft SSH Protocol Architecture Oct 2003 + + +4.1 Host Keys + + Each server host SHOULD have a host key. Hosts MAY have multiple + host keys using multiple different algorithms. Multiple hosts MAY + share the same host key. If a host has keys at all, it MUST have at + least one key using each REQUIRED public key algorithm (DSS + [FIPS-186]). + + The server host key is used during key exchange to verify that the + client is really talking to the correct server. For this to be + possible, the client must have a priori knowledge of the server's + public host key. + + Two different trust models can be used: + o The client has a local database that associates each host name (as + typed by the user) with the corresponding public host key. This + method requires no centrally administered infrastructure, and no + third-party coordination. The downside is that the database of + name-to-key associations may become burdensome to maintain. + o The host name-to-key association is certified by some trusted + certification authority. The client only knows the CA root key, + and can verify the validity of all host keys certified by accepted + CAs. + + The second alternative eases the maintenance problem, since + ideally only a single CA key needs to be securely stored on the + client. On the other hand, each host key must be appropriately + certified by a central authority before authorization is possible. + Also, a lot of trust is placed on the central infrastructure. + + The protocol provides the option that the server name - host key + association is not checked when connecting to the host for the first + time. This allows communication without prior communication of host + keys or certification. The connection still provides protection + against passive listening; however, it becomes vulnerable to active + man-in-the-middle attacks. Implementations SHOULD NOT normally allow + such connections by default, as they pose a potential security + problem. However, as there is no widely deployed key infrastructure + available on the Internet yet, this option makes the protocol much + more usable during the transition time until such an infrastructure + emerges, while still providing a much higher level of security than + that offered by older solutions (e.g. telnet [RFC-854] and rlogin + [RFC-1282]). + + Implementations SHOULD try to make the best effort to check host + keys. An example of a possible strategy is to only accept a host key + without checking the first time a host is connected, save the key in + a local database, and compare against that key on all future + + + +Ylonen & Moffat Expires March 31, 2004 [Page 4] + +Internet-Draft SSH Protocol Architecture Oct 2003 + + + connections to that host. + + Implementations MAY provide additional methods for verifying the + correctness of host keys, e.g. a hexadecimal fingerprint derived from + the SHA-1 hash of the public key. Such fingerprints can easily be + verified by using telephone or other external communication channels. + + All implementations SHOULD provide an option to not accept host keys + that cannot be verified. + + We believe that ease of use is critical to end-user acceptance of + security solutions, and no improvement in security is gained if the + new solutions are not used. Thus, providing the option not to check + the server host key is believed to improve the overall security of + the Internet, even though it reduces the security of the protocol in + configurations where it is allowed. + +4.2 Extensibility + + We believe that the protocol will evolve over time, and some + organizations will want to use their own encryption, authentication + and/or key exchange methods. Central registration of all extensions + is cumbersome, especially for experimental or classified features. + On the other hand, having no central registration leads to conflicts + in method identifiers, making interoperability difficult. + + We have chosen to identify algorithms, methods, formats, and + extension protocols with textual names that are of a specific format. + DNS names are used to create local namespaces where experimental or + classified extensions can be defined without fear of conflicts with + other implementations. + + One design goal has been to keep the base protocol as simple as + possible, and to require as few algorithms as possible. However, all + implementations MUST support a minimal set of algorithms to ensure + interoperability (this does not imply that the local policy on all + hosts would necessary allow these algorithms). The mandatory + algorithms are specified in the relevant protocol documents. + + Additional algorithms, methods, formats, and extension protocols can + be defined in separate drafts. See Section Algorithm Naming (Section + 6) for more information. + +4.3 Policy Issues + + The protocol allows full negotiation of encryption, integrity, key + exchange, compression, and public key algorithms and formats. + Encryption, integrity, public key, and compression algorithms can be + + + +Ylonen & Moffat Expires March 31, 2004 [Page 5] + +Internet-Draft SSH Protocol Architecture Oct 2003 + + + different for each direction. + + The following policy issues SHOULD be addressed in the configuration + mechanisms of each implementation: + o Encryption, integrity, and compression algorithms, separately for + each direction. The policy MUST specify which is the preferred + algorithm (e.g. the first algorithm listed in each category). + o Public key algorithms and key exchange method to be used for host + authentication. The existence of trusted host keys for different + public key algorithms also affects this choice. + o The authentication methods that are to be required by the server + for each user. The server's policy MAY require multiple + authentication for some or all users. The required algorithms MAY + depend on the location where the user is trying to log in from. + o The operations that the user is allowed to perform using the + connection protocol. Some issues are related to security; for + example, the policy SHOULD NOT allow the server to start sessions + or run commands on the client machine, and MUST NOT allow + connections to the authentication agent unless forwarding such + connections has been requested. Other issues, such as which TCP/ + IP ports can be forwarded and by whom, are clearly issues of local + policy. Many of these issues may involve traversing or bypassing + firewalls, and are interrelated with the local security policy. + +4.4 Security Properties + + The primary goal of the SSH protocol is improved security on the + Internet. It attempts to do this in a way that is easy to deploy, + even at the cost of absolute security. + o All encryption, integrity, and public key algorithms used are + well-known, well-established algorithms. + o All algorithms are used with cryptographically sound key sizes + that are believed to provide protection against even the strongest + cryptanalytic attacks for decades. + o All algorithms are negotiated, and in case some algorithm is + broken, it is easy to switch to some other algorithm without + modifying the base protocol. + + Specific concessions were made to make wide-spread fast deployment + easier. The particular case where this comes up is verifying that + the server host key really belongs to the desired host; the protocol + allows the verification to be left out (but this is NOT RECOMMENDED). + This is believed to significantly improve usability in the short + term, until widespread Internet public key infrastructures emerge. + +4.5 Packet Size and Overhead + + Some readers will worry about the increase in packet size due to new + + + +Ylonen & Moffat Expires March 31, 2004 [Page 6] + +Internet-Draft SSH Protocol Architecture Oct 2003 + + + headers, padding, and MAC. The minimum packet size is in the order + of 28 bytes (depending on negotiated algorithms). The increase is + negligible for large packets, but very significant for one-byte + packets (telnet-type sessions). There are, however, several factors + that make this a non-issue in almost all cases: + o The minimum size of a TCP/IP header is 32 bytes. Thus, the + increase is actually from 33 to 51 bytes (roughly). + o The minimum size of the data field of an Ethernet packet is 46 + bytes [RFC-894]. Thus, the increase is no more than 5 bytes. When + Ethernet headers are considered, the increase is less than 10 + percent. + o The total fraction of telnet-type data in the Internet is + negligible, even with increased packet sizes. + + The only environment where the packet size increase is likely to have + a significant effect is PPP [RFC-1134] over slow modem lines (PPP + compresses the TCP/IP headers, emphasizing the increase in packet + size). However, with modern modems, the time needed to transfer is in + the order of 2 milliseconds, which is a lot faster than people can + type. + + There are also issues related to the maximum packet size. To + minimize delays in screen updates, one does not want excessively + large packets for interactive sessions. The maximum packet size is + negotiated separately for each channel. + +4.6 Localization and Character Set Support + + For the most part, the SSH protocols do not directly pass text that + would be displayed to the user. However, there are some places where + such data might be passed. When applicable, the character set for the + data MUST be explicitly specified. In most places, ISO 10646 with + UTF-8 encoding is used [RFC-2279]. When applicable, a field is also + provided for a language tag [RFC-3066]. + + One big issue is the character set of the interactive session. There + is no clear solution, as different applications may display data in + different formats. Different types of terminal emulation may also be + employed in the client, and the character set to be used is + effectively determined by the terminal emulation. Thus, no place is + provided for directly specifying the character set or encoding for + terminal session data. However, the terminal emulation type (e.g. + "vt100") is transmitted to the remote site, and it implicitly + specifies the character set and encoding. Applications typically use + the terminal type to determine what character set they use, or the + character set is determined using some external means. The terminal + emulation may also allow configuring the default character set. In + any case, the character set for the terminal session is considered + + + +Ylonen & Moffat Expires March 31, 2004 [Page 7] + +Internet-Draft SSH Protocol Architecture Oct 2003 + + + primarily a client local issue. + + Internal names used to identify algorithms or protocols are normally + never displayed to users, and must be in US-ASCII. + + The client and server user names are inherently constrained by what + the server is prepared to accept. They might, however, occasionally + be displayed in logs, reports, etc. They MUST be encoded using ISO + 10646 UTF-8, but other encodings may be required in some cases. It + is up to the server to decide how to map user names to accepted user + names. Straight bit-wise binary comparison is RECOMMENDED. + + For localization purposes, the protocol attempts to minimize the + number of textual messages transmitted. When present, such messages + typically relate to errors, debugging information, or some externally + configured data. For data that is normally displayed, it SHOULD be + possible to fetch a localized message instead of the transmitted + message by using a numerical code. The remaining messages SHOULD be + configurable. + +5. Data Type Representations Used in the SSH Protocols + byte + + A byte represents an arbitrary 8-bit value (octet) [RFC-1700]. + Fixed length data is sometimes represented as an array of bytes, + written byte[n], where n is the number of bytes in the array. + + boolean + + A boolean value is stored as a single byte. The value 0 + represents FALSE, and the value 1 represents TRUE. All non-zero + values MUST be interpreted as TRUE; however, applications MUST NOT + store values other than 0 and 1. + + uint32 + + Represents a 32-bit unsigned integer. Stored as four bytes in the + order of decreasing significance (network byte order). For + example, the value 699921578 (0x29b7f4aa) is stored as 29 b7 f4 + aa. + + uint64 + + Represents a 64-bit unsigned integer. Stored as eight bytes in + the order of decreasing significance (network byte order). + + + + + + +Ylonen & Moffat Expires March 31, 2004 [Page 8] + +Internet-Draft SSH Protocol Architecture Oct 2003 + + + string + + Arbitrary length binary string. Strings are allowed to contain + arbitrary binary data, including null characters and 8-bit + characters. They are stored as a uint32 containing its length + (number of bytes that follow) and zero (= empty string) or more + bytes that are the value of the string. Terminating null + characters are not used. + + Strings are also used to store text. In that case, US-ASCII is + used for internal names, and ISO-10646 UTF-8 for text that might + be displayed to the user. The terminating null character SHOULD + NOT normally be stored in the string. + + For example, the US-ASCII string "testing" is represented as 00 00 + 00 07 t e s t i n g. The UTF8 mapping does not alter the encoding + of US-ASCII characters. + + mpint + + Represents multiple precision integers in two's complement format, + stored as a string, 8 bits per byte, MSB first. Negative numbers + have the value 1 as the most significant bit of the first byte of + the data partition. If the most significant bit would be set for a + positive number, the number MUST be preceded by a zero byte. + Unnecessary leading bytes with the value 0 or 255 MUST NOT be + included. The value zero MUST be stored as a string with zero + bytes of data. + + By convention, a number that is used in modular computations in + Z_n SHOULD be represented in the range 0 <= x < n. + + Examples: + value (hex) representation (hex) + --------------------------------------------------------------- + 0 00 00 00 00 + 9a378f9b2e332a7 00 00 00 08 09 a3 78 f9 b2 e3 32 a7 + 80 00 00 00 02 00 80 + -1234 00 00 00 02 ed cc + -deadbeef 00 00 00 05 ff 21 52 41 11 + + + + name-list + + A string containing a comma separated list of names. A name list + is represented as a uint32 containing its length (number of bytes + that follow) followed by a comma-separated list of zero or more + + + +Ylonen & Moffat Expires March 31, 2004 [Page 9] + +Internet-Draft SSH Protocol Architecture Oct 2003 + + + names. A name MUST be non-zero length, and it MUST NOT contain a + comma (','). Context may impose additional restrictions on the + names; for example, the names in a list may have to be valid + algorithm identifier (see Algorithm Naming below), or [RFC-3066] + language tags. The order of the names in a list may or may not be + significant, also depending on the context where the list is is + used. Terminating NUL characters are not used, neither for the + individual names, nor for the list as a whole. + + Examples: + value representation (hex) + --------------------------------------- + (), the empty list 00 00 00 00 + ("zlib") 00 00 00 04 7a 6c 69 62 + ("zlib", "none") 00 00 00 09 7a 6c 69 62 2c 6e 6f 6e 65 + + + + +6. Algorithm Naming + + The SSH protocols refer to particular hash, encryption, integrity, + compression, and key exchange algorithms or protocols by names. + There are some standard algorithms that all implementations MUST + support. There are also algorithms that are defined in the protocol + specification but are OPTIONAL. Furthermore, it is expected that + some organizations will want to use their own algorithms. + + In this protocol, all algorithm identifiers MUST be printable + US-ASCII non-empty strings no longer than 64 characters. Names MUST + be case-sensitive. + + There are two formats for algorithm names: + o Names that do not contain an at-sign (@) are reserved to be + assigned by IETF consensus (RFCs). Examples include `3des-cbc', + `sha-1', `hmac-sha1', and `zlib' (the quotes are not part of the + name). Names of this format MUST NOT be used without first + registering them. Registered names MUST NOT contain an at-sign + (@) or a comma (,). + o Anyone can define additional algorithms by using names in the + format name@domainname, e.g. "[email protected]". The + format of the part preceding the at sign is not specified; it MUST + consist of US-ASCII characters except at-sign and comma. The part + following the at-sign MUST be a valid fully qualified internet + domain name [RFC-1034] controlled by the person or organization + defining the name. It is up to each domain how it manages its + local namespace. + + + + +Ylonen & Moffat Expires March 31, 2004 [Page 10] + +Internet-Draft SSH Protocol Architecture Oct 2003 + + +7. Message Numbers + + SSH packets have message numbers in the range 1 to 255. These numbers + have been allocated as follows: + + + Transport layer protocol: + + 1 to 19 Transport layer generic (e.g. disconnect, ignore, debug, + etc.) + 20 to 29 Algorithm negotiation + 30 to 49 Key exchange method specific (numbers can be reused for + different authentication methods) + + User authentication protocol: + + 50 to 59 User authentication generic + 60 to 79 User authentication method specific (numbers can be + reused for different authentication methods) + + Connection protocol: + + 80 to 89 Connection protocol generic + 90 to 127 Channel related messages + + Reserved for client protocols: + + 128 to 191 Reserved + + Local extensions: + + 192 to 255 Local extensions + + + +8. IANA Considerations + + The initial state of the IANA registry is detailed in [SSH-NUMBERS]. + + Allocation of the following types of names in the SSH protocols is + assigned by IETF consensus: + o SSH encryption algorithm names, + o SSH MAC algorithm names, + o SSH public key algorithm names (public key algorithm also implies + encoding and signature/encryption capability), + o SSH key exchange method names, and + o SSH protocol (service) names. + + + + +Ylonen & Moffat Expires March 31, 2004 [Page 11] + +Internet-Draft SSH Protocol Architecture Oct 2003 + + + These names MUST be printable US-ASCII strings, and MUST NOT contain + the characters at-sign ('@'), comma (','), or whitespace or control + characters (ASCII codes 32 or less). Names are case-sensitive, and + MUST NOT be longer than 64 characters. + + Names with the at-sign ('@') in them are allocated by the owner of + DNS name after the at-sign (hierarchical allocation in [RFC-2343]), + otherwise the same restrictions as above. + + Each category of names listed above has a separate namespace. + However, using the same name in multiple categories SHOULD be avoided + to minimize confusion. + + Message numbers (see Section Message Numbers (Section 7)) in the + range of 0..191 are allocated via IETF consensus; message numbers in + the 192..255 range (the "Local extensions" set) are reserved for + private use. + +9. Security Considerations + + In order to make the entire body of Security Considerations more + accessible, Security Considerations for the transport, + authentication, and connection documents have been gathered here. + + The transport protocol [1] provides a confidential channel over an + insecure network. It performs server host authentication, key + exchange, encryption, and integrity protection. It also derives a + unique session id that may be used by higher-level protocols. + + The authentication protocol [2] provides a suite of mechanisms which + can be used to authenticate the client user to the server. + Individual mechanisms specified in the in authentication protocol use + the session id provided by the transport protocol and/or depend on + the security and integrity guarantees of the transport protocol. + + The connection protocol [3] specifies a mechanism to multiplex + multiple streams [channels] of data over the confidential and + authenticated transport. It also specifies channels for accessing an + interactive shell, for 'proxy-forwarding' various external protocols + over the secure transport (including arbitrary TCP/IP protocols), and + for accessing secure 'subsystems' on the server host. + +9.1 Pseudo-Random Number Generation + + This protocol binds each session key to the session by including + random, session specific data in the hash used to produce session + keys. Special care should be taken to ensure that all of the random + numbers are of good quality. If the random data here (e.g., DH + + + +Ylonen & Moffat Expires March 31, 2004 [Page 12] + +Internet-Draft SSH Protocol Architecture Oct 2003 + + + parameters) are pseudo-random then the pseudo-random number generator + should be cryptographically secure (i.e., its next output not easily + guessed even when knowing all previous outputs) and, furthermore, + proper entropy needs to be added to the pseudo-random number + generator. RFC 1750 [1750] offers suggestions for sources of random + numbers and entropy. Implementors should note the importance of + entropy and the well-meant, anecdotal warning about the difficulty in + properly implementing pseudo-random number generating functions. + + The amount of entropy available to a given client or server may + sometimes be less than what is required. In this case one must + either resort to pseudo-random number generation regardless of + insufficient entropy or refuse to run the protocol. The latter is + preferable. + +9.2 Transport + +9.2.1 Confidentiality + + It is beyond the scope of this document and the Secure Shell Working + Group to analyze or recommend specific ciphers other than the ones + which have been established and accepted within the industry. At the + time of this writing, ciphers commonly in use include 3DES, ARCFOUR, + twofish, serpent and blowfish. AES has been accepted by The + published as a US Federal Information Processing Standards [FIPS-197] + and the cryptographic community as being acceptable for this purpose + as well has accepted AES. As always, implementors and users should + check current literature to ensure that no recent vulnerabilities + have been found in ciphers used within products. Implementors should + also check to see which ciphers are considered to be relatively + stronger than others and should recommend their use to users over + relatively weaker ciphers. It would be considered good form for an + implementation to politely and unobtrusively notify a user that a + stronger cipher is available and should be used when a weaker one is + actively chosen. + + The "none" cipher is provided for debugging and SHOULD NOT be used + except for that purpose. It's cryptographic properties are + sufficiently described in RFC 2410, which will show that its use does + not meet the intent of this protocol. + + The relative merits of these and other ciphers may also be found in + current literature. Two references that may provide information on + the subject are [SCHNEIER] and [KAUFMAN,PERLMAN,SPECINER]. Both of + these describe the CBC mode of operation of certain ciphers and the + weakness of this scheme. Essentially, this mode is theoretically + vulnerable to chosen cipher-text attacks because of the high + predictability of the start of packet sequence. However, this attack + + + +Ylonen & Moffat Expires March 31, 2004 [Page 13] + +Internet-Draft SSH Protocol Architecture Oct 2003 + + + is still deemed difficult and not considered fully practicable + especially if relatively longer block sizes are used. + + Additionally, another CBC mode attack may be mitigated through the + insertion of packets containing SSH_MSG_IGNORE. Without this + technique, a specific attack may be successful. For this attack + (commonly known as the Rogaway attack + [ROGAWAY],[DAI],[BELLARE,KOHNO,NAMPREMPRE]) to work, the attacker + would need to know the IV of the next block that is going to be + encrypted. In CBC mode that is the output of the encryption of the + previous block. If the attacker does not have any way to see the + packet yet (i.e it is in the internal buffers of the ssh + implementation or even in the kernel) then this attack will not work. + If the last packet has been sent out to the network (i.e the attacker + has access to it) then he can use the attack. + + In the optimal case an implementor would need to add an extra packet + only if the packet has been sent out onto the network and there are + no other packets waiting for transmission. Implementors may wish to + check to see if there are any unsent packets awaiting transmission, + but unfortunately it is not normally easy to obtain this information + from the kernel or buffers. If there are not, then a packet + containing SSH_MSG_IGNORE SHOULD be sent. If a new packet is added + to the stream every time the attacker knows the IV that is supposed + to be used for the next packet, then the attacker will not be able to + guess the correct IV, thus the attack will never be successfull. + + As an example, consider the following case: + + + Client Server + ------ ------ + TCP(seq=x, len=500) -> + contains Record 1 + + [500 ms passes, no ACK] + + TCP(seq=x, len=1000) -> + contains Records 1,2 + + ACK + + + 1. The Nagle algorithm + TCP retransmits mean that the two records + get coalesced into a single TCP segment + 2. Record 2 is *not* at the beginning of the TCP segment and never + will be, since it gets ACKed. + + + + +Ylonen & Moffat Expires March 31, 2004 [Page 14] + +Internet-Draft SSH Protocol Architecture Oct 2003 + + + 3. Yet, the attack is possible because Record 1 has already been + seen. + + As this example indicates, it's totally unsafe to use the existence + of unflushed data in the TCP buffers proper as a guide to whether you + need an empty packet, since when you do the second write(), the + buffers will contain the un-ACKed Record 1. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Ylonen & Moffat Expires March 31, 2004 [Page 15] + +Internet-Draft SSH Protocol Architecture Oct 2003 + + + On the other hand, it's perfectly safe to have the following + situation: + + + Client Server + ------ ------ + TCP(seq=x, len=500) -> + contains SSH_MSG_IGNORE + + TCP(seq=y, len=500) -> + contains Data + + Provided that the IV for second SSH Record is fixed after the data for + the Data packet is determined -i.e. you do: + read from user + encrypt null packet + encrypt data packet + + +9.2.2 Data Integrity + + This protocol does allow the Data Integrity mechanism to be disabled. + Implementors SHOULD be wary of exposing this feature for any purpose + other than debugging. Users and administrators SHOULD be explicitly + warned anytime the "none" MAC is enabled. + + So long as the "none" MAC is not used, this protocol provides data + integrity. + + Because MACs use a 32 bit sequence number, they might start to leak + information after 2**32 packets have been sent. However, following + the rekeying recommendations should prevent this attack. The + transport protocol [1] recommends rekeying after one gigabyte of + data, and the smallest possible packet is 16 bytes. Therefore, + rekeying SHOULD happen after 2**28 packets at the very most. + +9.2.3 Replay + + The use of a MAC other than 'none' provides integrity and + authentication. In addition, the transport protocol provides a + unique session identifier (bound in part to pseudo-random data that + is part of the algorithm and key exchange process) that can be used + by higher level protocols to bind data to a given session and prevent + replay of data from prior sessions. For example, the authentication + protocol uses this to prevent replay of signatures from previous + sessions. Because public key authentication exchanges are + cryptographically bound to the session (i.e., to the initial key + exchange) they cannot be successfully replayed in other sessions. + + + +Ylonen & Moffat Expires March 31, 2004 [Page 16] + +Internet-Draft SSH Protocol Architecture Oct 2003 + + + Note that the session ID can be made public without harming the + security of the protocol. + + If two session happen to have the same session ID [hash of key + exchanges] then packets from one can be replayed against the other. + It must be stressed that the chances of such an occurrence are, + needless to say, minimal when using modern cryptographic methods. + This is all the more so true when specifying larger hash function + outputs and DH parameters. + + Replay detection using monotonically increasing sequence numbers as + input to the MAC, or HMAC in some cases, is described in [RFC2085] /> + [RFC2246], [RFC2743], [RFC1964], [RFC2025], and [RFC1510]. The + underlying construct is discussed in [RFC2104]. Essentially a + different sequence number in each packet ensures that at least this + one input to the MAC function will be unique and will provide a + nonrecurring MAC output that is not predictable to an attacker. If + the session stays active long enough, however, this sequence number + will wrap. This event may provide an attacker an opportunity to + replay a previously recorded packet with an identical sequence number + but only if the peers have not rekeyed since the transmission of the + first packet with that sequence number. If the peers have rekeyed, + then the replay will be detected as the MAC check will fail. For + this reason, it must be emphasized that peers MUST rekey before a + wrap of the sequence numbers. Naturally, if an attacker does attempt + to replay a captured packet before the peers have rekeyed, then the + receiver of the duplicate packet will not be able to validate the MAC + and it will be discarded. The reason that the MAC will fail is + because the receiver will formulate a MAC based upon the packet + contents, the shared secret, and the expected sequence number. Since + the replayed packet will not be using that expected sequence number + (the sequence number of the replayed packet will have already been + passed by the receiver) then the calculated MAC will not match the + MAC received with the packet. + +9.2.4 Man-in-the-middle + + This protocol makes no assumptions nor provisions for an + infrastructure or means for distributing the public keys of hosts. It + is expected that this protocol will sometimes be used without first + verifying the association between the server host key and the server + host name. Such usage is vulnerable to man-in-the-middle attacks. + This section describes this and encourages administrators and users + to understand the importance of verifying this association before any + session is initiated. + + There are three cases of man-in-the-middle attacks to consider. The + first is where an attacker places a device between the client and the + + + +Ylonen & Moffat Expires March 31, 2004 [Page 17] + +Internet-Draft SSH Protocol Architecture Oct 2003 + + + server before the session is initiated. In this case, the attack + device is trying to mimic the legitimate server and will offer its + public key to the client when the client initiates a session. If it + were to offer the public key of the server, then it would not be able + to decrypt or sign the transmissions between the legitimate server + and the client unless it also had access to the private-key of the + host. The attack device will also, simultaneously to this, initiate + a session to the legitimate server masquerading itself as the client. + If the public key of the server had been securely distributed to the + client prior to that session initiation, the key offered to the + client by the attack device will not match the key stored on the + client. In that case, the user SHOULD be given a warning that the + offered host key does not match the host key cached on the client. + As described in Section 3.1 of [ARCH], the user may be free to accept + the new key and continue the session. It is RECOMMENDED that the + warning provide sufficient information to the user of the client + device so they may make an informed decision. If the user chooses to + continue the session with the stored public-key of the server (not + the public-key offered at the start of the session), then the session + specific data between the attacker and server will be different + between the client-to-attacker session and the attacker-to-server + sessions due to the randomness discussed above. From this, the + attacker will not be able to make this attack work since the attacker + will not be able to correctly sign packets containing this session + specific data from the server since he does not have the private key + of that server. + + The second case that should be considered is similar to the first + case in that it also happens at the time of connection but this case + points out the need for the secure distribution of server public + keys. If the server public keys are not securely distributed then + the client cannot know if it is talking to the intended server. An + attacker may use social engineering techniques to pass off server + keys to unsuspecting users and may then place a man-in-the-middle + attack device between the legitimate server and the clients. If this + is allowed to happen then the clients will form client-to-attacker + sessions and the attacker will form attacker-to-server sessions and + will be able to monitor and manipulate all of the traffic between the + clients and the legitimate servers. Server administrators are + encouraged to make host key fingerprints available for checking by + some means whose security does not rely on the integrity of the + actual host keys. Possible mechanisms are discussed in Section 3.1 + of [SSH-ARCH] and may also include secured Web pages, physical pieces + of paper, etc. Implementors SHOULD provide recommendations on how + best to do this with their implementation. Because the protocol is + extensible, future extensions to the protocol may provide better + mechanisms for dealing with the need to know the server's host key + before connecting. For example, making the host key fingerprint + + + +Ylonen & Moffat Expires March 31, 2004 [Page 18] + +Internet-Draft SSH Protocol Architecture Oct 2003 + + + available through a secure DNS lookup, or using kerberos over gssapi + during key exchange to authenticate the server are possibilities. + + In the third man-in-the-middle case, attackers may attempt to + manipulate packets in transit between peers after the session has + been established. As described in the Replay part of this section, a + successful attack of this nature is very improbable. As in the + Replay section, this reasoning does assume that the MAC is secure and + that it is infeasible to construct inputs to a MAC algorithm to give + a known output. This is discussed in much greater detail in Section + 6 of RFC 2104. If the MAC algorithm has a vulnerability or is weak + enough, then the attacker may be able to specify certain inputs to + yield a known MAC. With that they may be able to alter the contents + of a packet in transit. Alternatively the attacker may be able to + exploit the algorithm vulnerability or weakness to find the shared + secret by reviewing the MACs from captured packets. In either of + those cases, an attacker could construct a packet or packets that + could be inserted into an SSH stream. To prevent that, implementors + are encouraged to utilize commonly accepted MAC algorithms and + administrators are encouraged to watch current literature and + discussions of cryptography to ensure that they are not using a MAC + algorithm that has a recently found vulnerability or weakness. + + In summary, the use of this protocol without a reliable association + of the binding between a host and its host keys is inherently + insecure and is NOT RECOMMENDED. It may however be necessary in + non-security critical environments, and will still provide protection + against passive attacks. Implementors of protocols and applications + running on top of this protocol should keep this possibility in mind. + +9.2.5 Denial-of-service + + This protocol is designed to be used over a reliable transport. If + transmission errors or message manipulation occur, the connection is + closed. The connection SHOULD be re-established if this occurs. + Denial of service attacks of this type ("wire cutter") are almost + impossible to avoid. + + In addition, this protocol is vulnerable to Denial of Service attacks + because an attacker can force the server to go through the CPU and + memory intensive tasks of connection setup and key exchange without + authenticating. Implementors SHOULD provide features that make this + more difficult. For example, only allowing connections from a subset + of IPs known to have valid users. + +9.2.6 Covert Channels + + The protocol was not designed to eliminate covert channels. For + + + +Ylonen & Moffat Expires March 31, 2004 [Page 19] + +Internet-Draft SSH Protocol Architecture Oct 2003 + + + example, the padding, SSH_MSG_IGNORE messages, and several other + places in the protocol can be used to pass covert information, and + the recipient has no reliable way to verify whether such information + is being sent. + +9.2.7 Forward Secrecy + + It should be noted that the Diffie-Hellman key exchanges may provide + perfect forward secrecy (PFS). PFS is essentially defined as the + cryptographic property of a key-establishment protocol in which the + compromise of a session key or long-term private key after a given + session does not cause the compromise of any earlier session. [ANSI + T1.523-2001] SSHv2 sessions resulting from a key exchange using + diffie-hellman-group1-sha1 are secure even if private keying/ + authentication material is later revealed, but not if the session + keys are revealed. So, given this definition of PFS, SSHv2 does have + PFS. It is hoped that all other key exchange mechanisms proposed and + used in the future will also provide PFS. This property is not + commuted to any of the applications or protocols using SSH as a + transport however. The transport layer of SSH provides + confidentiality for password authentication and other methods that + rely on secret data. + + Of course, if the DH private parameters for the client and server are + revealed then the session key is revealed, but these items can be + thrown away after the key exchange completes. It's worth pointing + out that these items should not be allowed to end up on swap space + and that they should be erased from memory as soon as the key + exchange completes. + +9.3 Authentication Protocol + + The purpose of this protocol is to perform client user + authentication. It assumes that this run over a secure transport + layer protocol, which has already authenticated the server machine, + established an encrypted communications channel, and computed a + unique session identifier for this session. + + Several authentication methods with different security + characteristics are allowed. It is up to the server's local policy + to decide which methods (or combinations of methods) it is willing to + accept for each user. Authentication is no stronger than the weakest + combination allowed. + + The server may go into a "sleep" period after repeated unsuccessful + authentication attempts to make key search more difficult for + attackers. Care should be taken so that this doesn't become a + self-denial of service vector. + + + +Ylonen & Moffat Expires March 31, 2004 [Page 20] + +Internet-Draft SSH Protocol Architecture Oct 2003 + + +9.3.1 Weak Transport + + If the transport layer does not provide confidentiality, + authentication methods that rely on secret data SHOULD be disabled. + If it does not provide strong integrity protection, requests to + change authentication data (e.g. a password change) SHOULD be + disabled to prevent an attacker from modifying the ciphertext + without being noticed, or rendering the new authentication data + unusable (denial of service). + + The assumption as stated above that the Authentication Protocol only + run over a secure transport that has previously authenticated the + server is very important to note. People deploying SSH are reminded + of the consequences of man-in-the-middle attacks if the client does + not have a very strong a priori association of the server with the + host key of that server. Specifically for the case of the + Authentication Protocol the client may form a session to a + man-in-the-middle attack device and divulge user credentials such as + their username and password. Even in the cases of authentication + where no user credentials are divulged, an attacker may still gain + information they shouldn't have by capturing key-strokes in much the + same way that a honeypot works. + +9.3.2 Debug messages + + Special care should be taken when designing debug messages. These + messages may reveal surprising amounts of information about the host + if not properly designed. Debug messages can be disabled (during + user authentication phase) if high security is required. + Administrators of host machines should make all attempts to + compartmentalize all event notification messages and protect them + from unwarranted observation. Developers should be aware of the + sensitive nature of some of the normal event messages and debug + messages and may want to provide guidance to administrators on ways + to keep this information away from unauthorized people. Developers + should consider minimizing the amount of sensitive information + obtainable by users during the authentication phase in accordance + with the local policies. For this reason, it is RECOMMENDED that + debug messages be initially disabled at the time of deployment and + require an active decision by an administrator to allow them to be + enabled. It is also RECOMMENDED that a message expressing this + concern be presented to the administrator of a system when the action + is taken to enable debugging messages. + +9.3.3 Local security policy + + Implementer MUST ensure that the credentials provided validate the + professed user and also MUST ensure that the local policy of the + + + +Ylonen & Moffat Expires March 31, 2004 [Page 21] + +Internet-Draft SSH Protocol Architecture Oct 2003 + + + server permits the user the access requested. In particular, because + of the flexible nature of the SSH connection protocol, it may not be + possible to determine the local security policy, if any, that should + apply at the time of authentication because the kind of service being + requested is not clear at that instant. For example, local policy + might allow a user to access files on the server, but not start an + interactive shell. However, during the authentication protocol, it is + not known whether the user will be accessing files or attempting to + use an interactive shell, or even both. In any event, where local + security policy for the server host exists, it MUST be applied and + enforced correctly. + + Implementors are encouraged to provide a default local policy and + make its parameters known to administrators and users. At the + discretion of the implementors, this default policy may be along the + lines of 'anything goes' where there are no restrictions placed upon + users, or it may be along the lines of 'excessively restrictive' in + which case the administrators will have to actively make changes to + this policy to meet their needs. Alternatively, it may be some + attempt at providing something practical and immediately useful to + the administrators of the system so they don't have to put in much + effort to get SSH working. Whatever choice is made MUST be applied + and enforced as required above. + +9.3.4 Public key authentication + + The use of public-key authentication assumes that the client host has + not been compromised. It also assumes that the private-key of the + server host has not been compromised. + + This risk can be mitigated by the use of passphrases on private keys; + however, this is not an enforceable policy. The use of smartcards, + or other technology to make passphrases an enforceable policy is + suggested. + + The server could require both password and public-key authentication, + however, this requires the client to expose its password to the + server (see section on password authentication below.) + +9.3.5 Password authentication + + The password mechanism as specified in the authentication protocol + assumes that the server has not been compromised. If the server has + been compromised, using password authentication will reveal a valid + username / password combination to the attacker, which may lead to + further compromises. + + This vulnerability can be mitigated by using an alternative form of + + + +Ylonen & Moffat Expires March 31, 2004 [Page 22] + +Internet-Draft SSH Protocol Architecture Oct 2003 + + + authentication. For example, public-key authentication makes no + assumptions about security on the server. + +9.3.6 Host based authentication + + Host based authentication assumes that the client has not been + compromised. There are no mitigating strategies, other than to use + host based authentication in combination with another authentication + method. + +9.4 Connection protocol + +9.4.1 End point security + + End point security is assumed by the connection protocol. If the + server has been compromised, any terminal sessions, port forwarding, + or systems accessed on the host are compromised. There are no + mitigating factors for this. + + If the client end point has been compromised, and the server fails to + stop the attacker at the authentication protocol, all services + exposed (either as subsystems or through forwarding) will be + vulnerable to attack. Implementors SHOULD provide mechanisms for + administrators to control which services are exposed to limit the + vulnerability of other services. + + These controls might include controlling which machines and ports can + be target in 'port-forwarding' operations, which users are allowed to + use interactive shell facilities, or which users are allowed to use + exposed subsystems. + +9.4.2 Proxy forwarding + + The SSH connection protocol allows for proxy forwarding of other + protocols such as SNMP, POP3, and HTTP. This may be a concern for + network administrators who wish to control the access of certain + applications by users located outside of their physical location. + Essentially, the forwarding of these protocols may violate site + specific security policies as they may be undetectably tunneled + through a firewall. Implementors SHOULD provide an administrative + mechanism to control the proxy forwarding functionality so that site + specific security policies may be upheld. + + In addition, a reverse proxy forwarding functionality is available, + which again can be used to bypass firewall controls. + + As indicated above, end-point security is assumed during proxy + forwarding operations. Failure of end-point security will compromise + + + +Ylonen & Moffat Expires March 31, 2004 [Page 23] + +Internet-Draft SSH Protocol Architecture Oct 2003 + + + all data passed over proxy forwarding. + +9.4.3 X11 forwarding + + Another form of proxy forwarding provided by the ssh connection + protocol is the forwarding of the X11 protocol. If end-point + security has been compromised, X11 forwarding may allow attacks + against the X11 server. Users and administrators should, as a matter + of course, use appropriate X11 security mechanisms to prevent + unauthorized use of the X11 server. Implementors, administrators and + users who wish to further explore the security mechanisms of X11 are + invited to read [SCHEIFLER] and analyze previously reported problems + with the interactions between SSH forwarding and X11 in CERT + vulnerabilities VU#363181 and VU#118892 [CERT]. + + X11 display forwarding with SSH, by itself, is not sufficient to + correct well known problems with X11 security [VENEMA]. However, X11 + display forwarding in SSHv2 (or other, secure protocols), combined + with actual and pseudo-displays which accept connections only over + local IPC mechanisms authorized by permissions or ACLs, does correct + many X11 security problems as long as the "none" MAC is not used. It + is RECOMMENDED that X11 display implementations default to allowing + display opens only over local IPC. It is RECOMMENDED that SSHv2 + server implementations that support X11 forwarding default to + allowing display opens only over local IPC. On single-user systems + it might be reasonable to default to allowing local display opens + over TCP/IP. + + Implementors of the X11 forwarding protocol SHOULD implement the + magic cookie access checking spoofing mechanism as described in + [ssh-connect] as an additional mechanism to prevent unauthorized use + of the proxy. + +Normative References + + [SSH-ARCH] + Ylonen, T., "SSH Protocol Architecture", I-D + draft-ietf-architecture-15.txt, Oct 2003. + + [SSH-TRANS] + Ylonen, T., "SSH Transport Layer Protocol", I-D + draft-ietf-transport-17.txt, Oct 2003. + + [SSH-USERAUTH] + Ylonen, T., "SSH Authentication Protocol", I-D + draft-ietf-userauth-18.txt, Oct 2003. + + [SSH-CONNECT] + + + +Ylonen & Moffat Expires March 31, 2004 [Page 24] + +Internet-Draft SSH Protocol Architecture Oct 2003 + + + Ylonen, T., "SSH Connection Protocol", I-D + draft-ietf-connect-18.txt, Oct 2003. + + [SSH-NUMBERS] + Lehtinen, S. and D. Moffat, "SSH Protocol Assigned + Numbers", I-D draft-ietf-secsh-assignednumbers-05.txt, Oct + 2003. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + +Informative References + + [FIPS-186] + Federal Information Processing Standards Publication, + "FIPS PUB 186, Digital Signature Standard", May 1994. + + [FIPS-197] + National Institue of Standards and Technology, "FIPS 197, + Specification for the Advanced Encryption Standard", + November 2001. + + [ANSI T1.523-2001] + American National Standards Insitute, Inc., "Telecom + Glossary 2000", February 2001. + + [SCHEIFLER] + Scheifler, R., "X Window System : The Complete Reference + to Xlib, X Protocol, Icccm, Xlfd, 3rd edition.", Digital + Press ISBN 1555580882, Feburary 1992. + + [RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol + Specification", STD 8, RFC 854, May 1983. + + [RFC0894] Hornig, C., "Standard for the transmission of IP datagrams + over Ethernet networks", STD 41, RFC 894, April 1984. + + [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", + STD 13, RFC 1034, November 1987. + + [RFC1134] Perkins, D., "Point-to-Point Protocol: A proposal for + multi-protocol transmission of datagrams over + Point-to-Point links", RFC 1134, November 1989. + + [RFC1282] Kantor, B., "BSD Rlogin", RFC 1282, December 1991. + + [RFC1510] Kohl, J. and B. Neuman, "The Kerberos Network + Authentication Service (V5)", RFC 1510, September 1993. + + + +Ylonen & Moffat Expires March 31, 2004 [Page 25] + +Internet-Draft SSH Protocol Architecture Oct 2003 + + + [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, + October 1994. + + [RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness + Recommendations for Security", RFC 1750, December 1994. + + [RFC3066] Alvestrand, H., "Tags for the Identification of + Languages", BCP 47, RFC 3066, January 2001. + + [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC + 1964, June 1996. + + [RFC2025] Adams, C., "The Simple Public-Key GSS-API Mechanism + (SPKM)", RFC 2025, October 1996. + + [RFC2085] Oehler, M. and R. Glenn, "HMAC-MD5 IP Authentication with + Replay Prevention", RFC 2085, February 1997. + + [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: + Keyed-Hashing for Message Authentication", RFC 2104, + February 1997. + + [RFC2246] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. + and P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, + January 1999. + + [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO + 10646", RFC 2279, January 1998. + + [RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and + Its Use With IPsec", RFC 2410, November 1998. + + [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 2434, + October 1998. + + [RFC2743] Linn, J., "Generic Security Service Application Program + Interface Version 2, Update 1", RFC 2743, January 2000. + + [SCHNEIER] + Schneier, B., "Applied Cryptography Second Edition: + protocols algorithms and source in code in C", 1996. + + [KAUFMAN,PERLMAN,SPECINER] + Kaufman, C., Perlman, R. and M. Speciner, "Network + Security: PRIVATE Communication in a PUBLIC World", 1995. + + [CERT] CERT Coordination Center, The., "http://www.cert.org/nav/ + + + +Ylonen & Moffat Expires March 31, 2004 [Page 26] + +Internet-Draft SSH Protocol Architecture Oct 2003 + + + index_red.html". + + [VENEMA] Venema, W., "Murphy's Law and Computer Security", + Proceedings of 6th USENIX Security Symposium, San Jose CA + http://www.usenix.org/publications/library/proceedings/ + sec96/venema.html, July 1996. + + [ROGAWAY] Rogaway, P., "Problems with Proposed IP Cryptography", + Unpublished paper http://www.cs.ucdavis.edu/~rogaway/ + papers/draft-rogaway-ipsec-comments-00.txt, 1996. + + [DAI] Dai, W., "An attack against SSH2 protocol", Email to the + SECSH Working Group [email protected] ftp:// + ftp.ietf.org/ietf-mail-archive/secsh/2002-02.mail, Feb + 2002. + + [BELLARE,KOHNO,NAMPREMPRE] + Bellaire, M., Kohno, T. and C. Namprempre, "Authenticated + Encryption in SSH: Fixing the SSH Binary Packet Protocol", + , Sept 2002. + + +Authors' Addresses + + Tatu Ylonen + SSH Communications Security Corp + Fredrikinkatu 42 + HELSINKI FIN-00100 + Finland + + EMail: [email protected] + + + Darren J. Moffat (editor) + Sun Microsystems, Inc + 17 Network Circle + Menlo Park CA 94025 + USA + + EMail: [email protected] + + + + + + + + + + + +Ylonen & Moffat Expires March 31, 2004 [Page 27] + +Internet-Draft SSH Protocol Architecture Oct 2003 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + intellectual property or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; neither does it represent that it + has made any effort to identify any such rights. Information on the + IETF's procedures with respect to rights in standards-track and + standards-related documentation can be found in BCP-11. Copies of + claims of rights made available for publication and any assurances of + licenses to be made available, or the result of an attempt made to + obtain a general license or permission for the use of such + proprietary rights by implementors or users of this specification can + be obtained from the IETF Secretariat. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights which may cover technology that may be required to practice + this standard. Please address the information to the IETF Executive + Director. + + The IETF has been notified of intellectual property rights claimed in + regard to some or all of the specification contained in this + document. For more information consult the online list of claimed + rights. + + +Full Copyright Statement + + Copyright (C) The Internet Society (2003). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assignees. + + + +Ylonen & Moffat Expires March 31, 2004 [Page 28] + +Internet-Draft SSH Protocol Architecture Oct 2003 + + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Ylonen & Moffat Expires March 31, 2004 [Page 29]
\ No newline at end of file diff --git a/lib/ssh/doc/standard/draft-ietf-secsh-connect-18.2.ps b/lib/ssh/doc/standard/draft-ietf-secsh-connect-18.2.ps new file mode 100644 index 0000000000..7a386724c2 --- /dev/null +++ b/lib/ssh/doc/standard/draft-ietf-secsh-connect-18.2.ps @@ -0,0 +1,2557 @@ +%!PS-Adobe-3.0 +%%BoundingBox: 75 0 595 747 +%%Title: Enscript Output +%%For: Magnus Thoang +%%Creator: GNU enscript 1.6.1 +%%CreationDate: Fri Oct 31 13:33:02 2003 +%%Orientation: Portrait +%%Pages: 11 0 +%%DocumentMedia: A4 595 842 0 () () +%%DocumentNeededResources: (atend) +%%EndComments +%%BeginProlog +%%BeginProcSet: PStoPS 1 15 +userdict begin +[/showpage/erasepage/copypage]{dup where{pop dup load + type/operatortype eq{1 array cvx dup 0 3 index cvx put + bind def}{pop}ifelse}{pop}ifelse}forall +[/letter/legal/executivepage/a4/a4small/b5/com10envelope + /monarchenvelope/c5envelope/dlenvelope/lettersmall/note + /folio/quarto/a5]{dup where{dup wcheck{exch{}put} + {pop{}def}ifelse}{pop}ifelse}forall +/setpagedevice {pop}bind 1 index where{dup wcheck{3 1 roll put} + {pop def}ifelse}{def}ifelse +/PStoPSmatrix matrix currentmatrix def +/PStoPSxform matrix def/PStoPSclip{clippath}def +/defaultmatrix{PStoPSmatrix exch PStoPSxform exch concatmatrix}bind def +/initmatrix{matrix defaultmatrix setmatrix}bind def +/initclip[{matrix currentmatrix PStoPSmatrix setmatrix + [{currentpoint}stopped{$error/newerror false put{newpath}} + {/newpath cvx 3 1 roll/moveto cvx 4 array astore cvx}ifelse] + {[/newpath cvx{/moveto cvx}{/lineto cvx} + {/curveto cvx}{/closepath cvx}pathforall]cvx exch pop} + stopped{$error/errorname get/invalidaccess eq{cleartomark + $error/newerror false put cvx exec}{stop}ifelse}if}bind aload pop + /initclip dup load dup type dup/operatortype eq{pop exch pop} + {dup/arraytype eq exch/packedarraytype eq or + {dup xcheck{exch pop aload pop}{pop cvx}ifelse} + {pop cvx}ifelse}ifelse + {newpath PStoPSclip clip newpath exec setmatrix} bind aload pop]cvx def +/initgraphics{initmatrix newpath initclip 1 setlinewidth + 0 setlinecap 0 setlinejoin []0 setdash 0 setgray + 10 setmiterlimit}bind def +end +%%EndProcSet +%%BeginResource: procset Enscript-Prolog 1.6 1 +% +% Procedures. +% + +/_S { % save current state + /_s save def +} def +/_R { % restore from saved state + _s restore +} def + +/S { % showpage protecting gstate + gsave + showpage + grestore +} bind def + +/MF { % fontname newfontname -> - make a new encoded font + /newfontname exch def + /fontname exch def + + /fontdict fontname findfont def + /newfont fontdict maxlength dict def + + fontdict { + exch + dup /FID eq { + % skip FID pair + pop pop + } { + % copy to the new font dictionary + exch newfont 3 1 roll put + } ifelse + } forall + + newfont /FontName newfontname put + + % insert only valid encoding vectors + encoding_vector length 256 eq { + newfont /Encoding encoding_vector put + } if + + newfontname newfont definefont pop +} def + +/SF { % fontname width height -> - set a new font + /height exch def + /width exch def + + findfont + [width 0 0 height 0 0] makefont setfont +} def + +/SUF { % fontname width height -> - set a new user font + /height exch def + /width exch def + + /F-gs-user-font MF + /F-gs-user-font width height SF +} def + +/M {moveto} bind def +/s {show} bind def + +/Box { % x y w h -> - define box path + /d_h exch def /d_w exch def /d_y exch def /d_x exch def + d_x d_y moveto + d_w 0 rlineto + 0 d_h rlineto + d_w neg 0 rlineto + closepath +} def + +/bgs { % x y height blskip gray str -> - show string with bg color + /str exch def + /gray exch def + /blskip exch def + /height exch def + /y exch def + /x exch def + + gsave + x y blskip sub str stringwidth pop height Box + gray setgray + fill + grestore + x y M str s +} def + +% Highlight bars. +/highlight_bars { % nlines lineheight output_y_margin gray -> - + gsave + setgray + /ymarg exch def + /lineheight exch def + /nlines exch def + + % This 2 is just a magic number to sync highlight lines to text. + 0 d_header_y ymarg sub 2 sub translate + + /cw d_output_w cols div def + /nrows d_output_h ymarg 2 mul sub lineheight div cvi def + + % for each column + 0 1 cols 1 sub { + cw mul /xp exch def + + % for each rows + 0 1 nrows 1 sub { + /rn exch def + rn lineheight mul neg /yp exch def + rn nlines idiv 2 mod 0 eq { + % Draw highlight bar. 4 is just a magic indentation. + xp 4 add yp cw 8 sub lineheight neg Box fill + } if + } for + } for + + grestore +} def + +% Line highlight bar. +/line_highlight { % x y width height gray -> - + gsave + /gray exch def + Box gray setgray fill + grestore +} def + +% Column separator lines. +/column_lines { + gsave + .1 setlinewidth + 0 d_footer_h translate + /cw d_output_w cols div def + 1 1 cols 1 sub { + cw mul 0 moveto + 0 d_output_h rlineto stroke + } for + grestore +} def + +% Column borders. +/column_borders { + gsave + .1 setlinewidth + 0 d_footer_h moveto + 0 d_output_h rlineto + d_output_w 0 rlineto + 0 d_output_h neg rlineto + closepath stroke + grestore +} def + +% Do the actual underlay drawing +/draw_underlay { + ul_style 0 eq { + ul_str true charpath stroke + } { + ul_str show + } ifelse +} def + +% Underlay +/underlay { % - -> - + gsave + 0 d_page_h translate + d_page_h neg d_page_w atan rotate + + ul_gray setgray + ul_font setfont + /dw d_page_h dup mul d_page_w dup mul add sqrt def + ul_str stringwidth pop dw exch sub 2 div ul_h_ptsize -2 div moveto + draw_underlay + grestore +} def + +/user_underlay { % - -> - + gsave + ul_x ul_y translate + ul_angle rotate + ul_gray setgray + ul_font setfont + 0 0 ul_h_ptsize 2 div sub moveto + draw_underlay + grestore +} def + +% Page prefeed +/page_prefeed { % bool -> - + statusdict /prefeed known { + statusdict exch /prefeed exch put + } { + pop + } ifelse +} def + +% Wrapped line markers +/wrapped_line_mark { % x y charwith charheight type -> - + /type exch def + /h exch def + /w exch def + /y exch def + /x exch def + + type 2 eq { + % Black boxes (like TeX does) + gsave + 0 setlinewidth + x w 4 div add y M + 0 h rlineto w 2 div 0 rlineto 0 h neg rlineto + closepath fill + grestore + } { + type 3 eq { + % Small arrows + gsave + .2 setlinewidth + x w 2 div add y h 2 div add M + w 4 div 0 rlineto + x w 4 div add y lineto stroke + + x w 4 div add w 8 div add y h 4 div add M + x w 4 div add y lineto + w 4 div h 8 div rlineto stroke + grestore + } { + % do nothing + } ifelse + } ifelse +} def + +% EPSF import. + +/BeginEPSF { + /b4_Inc_state save def % Save state for cleanup + /dict_count countdictstack def % Count objects on dict stack + /op_count count 1 sub def % Count objects on operand stack + userdict begin + /showpage { } def + 0 setgray 0 setlinecap + 1 setlinewidth 0 setlinejoin + 10 setmiterlimit [ ] 0 setdash newpath + /languagelevel where { + pop languagelevel + 1 ne { + false setstrokeadjust false setoverprint + } if + } if +} bind def + +/EndEPSF { + count op_count sub { pos } repeat % Clean up stacks + countdictstack dict_count sub { end } repeat + b4_Inc_state restore +} bind def + +% Check PostScript language level. +/languagelevel where { + pop /gs_languagelevel languagelevel def +} { + /gs_languagelevel 1 def +} ifelse +%%EndResource +%%BeginResource: procset Enscript-Encoding-88591 1.6 1 +/encoding_vector [ +/.notdef /.notdef /.notdef /.notdef +/.notdef /.notdef /.notdef /.notdef +/.notdef /.notdef /.notdef /.notdef +/.notdef /.notdef /.notdef /.notdef +/.notdef /.notdef /.notdef /.notdef +/.notdef /.notdef /.notdef /.notdef +/.notdef /.notdef /.notdef /.notdef +/.notdef /.notdef /.notdef /.notdef +/space /exclam /quotedbl /numbersign +/dollar /percent /ampersand /quoteright +/parenleft /parenright /asterisk /plus +/comma /hyphen /period /slash +/zero /one /two /three +/four /five /six /seven +/eight /nine /colon /semicolon +/less /equal /greater /question +/at /A /B /C +/D /E /F /G +/H /I /J /K +/L /M /N /O +/P /Q /R /S +/T /U /V /W +/X /Y /Z /bracketleft +/backslash /bracketright /asciicircum /underscore +/quoteleft /a /b /c +/d /e /f /g +/h /i /j /k +/l /m /n /o +/p /q /r /s +/t /u /v /w +/x /y /z /braceleft +/bar /braceright /tilde /.notdef +/.notdef /.notdef /.notdef /.notdef +/.notdef /.notdef /.notdef /.notdef +/.notdef /.notdef /.notdef /.notdef +/.notdef /.notdef /.notdef /.notdef +/.notdef /.notdef /.notdef /.notdef +/.notdef /.notdef /.notdef /.notdef +/.notdef /.notdef /.notdef /.notdef +/.notdef /.notdef /.notdef /.notdef +/space /exclamdown /cent /sterling +/currency /yen /brokenbar /section +/dieresis /copyright /ordfeminine /guillemotleft +/logicalnot /hyphen /registered /macron +/degree /plusminus /twosuperior /threesuperior +/acute /mu /paragraph /bullet +/cedilla /onesuperior /ordmasculine /guillemotright +/onequarter /onehalf /threequarters /questiondown +/Agrave /Aacute /Acircumflex /Atilde +/Adieresis /Aring /AE /Ccedilla +/Egrave /Eacute /Ecircumflex /Edieresis +/Igrave /Iacute /Icircumflex /Idieresis +/Eth /Ntilde /Ograve /Oacute +/Ocircumflex /Otilde /Odieresis /multiply +/Oslash /Ugrave /Uacute /Ucircumflex +/Udieresis /Yacute /Thorn /germandbls +/agrave /aacute /acircumflex /atilde +/adieresis /aring /ae /ccedilla +/egrave /eacute /ecircumflex /edieresis +/igrave /iacute /icircumflex /idieresis +/eth /ntilde /ograve /oacute +/ocircumflex /otilde /odieresis /divide +/oslash /ugrave /uacute /ucircumflex +/udieresis /yacute /thorn /ydieresis +] def +%%EndResource +%%EndProlog +%%BeginSetup +%%IncludeResource: font Courier-Bold +%%IncludeResource: font Courier +/HFpt_w 10 def +/HFpt_h 10 def +/Courier-Bold /HF-gs-font MF +/HF /HF-gs-font findfont [HFpt_w 0 0 HFpt_h 0 0] makefont def +/Courier /F-gs-font MF +/F-gs-font 10 10 SF +/#copies 1 def +/d_page_w 520 def +/d_page_h 747 def +/d_header_x 0 def +/d_header_y 747 def +/d_header_w 520 def +/d_header_h 0 def +/d_footer_x 0 def +/d_footer_y 0 def +/d_footer_w 520 def +/d_footer_h 0 def +/d_output_w 520 def +/d_output_h 747 def +/cols 1 def +userdict/PStoPSxform PStoPSmatrix matrix currentmatrix + matrix invertmatrix matrix concatmatrix + matrix invertmatrix put +%%EndSetup +%%Page: (0,1) 1 +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 0.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +/showpage{}def/copypage{}def/erasepage{}def +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 1 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 701 M +(Network Working Group T. Ylonen) s +5 690 M +(Internet-Draft SSH Communications Security Corp) s +5 679 M +(Expires: March 31, 2004 D. Moffat, Editor, Ed.) s +5 668 M +( Sun Microsystems, Inc) s +5 657 M +( Oct 2003) s +5 624 M +( SSH Connection Protocol) s +5 613 M +( draft-ietf-secsh-connect-18.txt) s +5 591 M +(Status of this Memo) s +5 569 M +( This document is an Internet-Draft and is in full conformance with) s +5 558 M +( all provisions of Section 10 of RFC2026.) s +5 536 M +( Internet-Drafts are working documents of the Internet Engineering) s +5 525 M +( Task Force \(IETF\), its areas, and its working groups. Note that other) s +5 514 M +( groups may also distribute working documents as Internet-Drafts.) s +5 492 M +( Internet-Drafts are draft documents valid for a maximum of six months) s +5 481 M +( and may be updated, replaced, or obsoleted by other documents at any) s +5 470 M +( time. It is inappropriate to use Internet-Drafts as reference) s +5 459 M +( material or to cite them other than as "work in progress.") s +5 437 M +( The list of current Internet-Drafts can be accessed at http://) s +5 426 M +( www.ietf.org/ietf/1id-abstracts.txt.) s +5 404 M +( The list of Internet-Draft Shadow Directories can be accessed at) s +5 393 M +( http://www.ietf.org/shadow.html.) s +5 371 M +( This Internet-Draft will expire on March 31, 2004.) s +5 349 M +(Copyright Notice) s +5 327 M +( Copyright \(C\) The Internet Society \(2003\). All Rights Reserved.) s +5 305 M +(Abstract) s +5 283 M +( SSH is a protocol for secure remote login and other secure network) s +5 272 M +( services over an insecure network.) s +5 250 M +( This document describes the SSH Connection Protocol. It provides) s +5 239 M +( interactive login sessions, remote execution of commands, forwarded) s +5 228 M +( TCP/IP connections, and forwarded X11 connections. All of these) s +5 217 M +( channels are multiplexed into a single encrypted tunnel.) s +5 195 M +( The SSH Connection Protocol has been designed to run on top of the) s +5 184 M +( SSH transport layer and user authentication protocols.) s +5 129 M +(Ylonen & Moffat, Editor Expires March 31, 2004 [Page 1]) s +_R +S +PStoPSsaved restore +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 421.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 2 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH Connection Protocol Oct 2003) s +5 690 M +(Table of Contents) s +5 668 M +( 1. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 3) s +5 657 M +( 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3) s +5 646 M +( 3. Conventions Used in This Document . . . . . . . . . . . . . 3) s +5 635 M +( 4. Global Requests . . . . . . . . . . . . . . . . . . . . . . 3) s +5 624 M +( 5. Channel Mechanism . . . . . . . . . . . . . . . . . . . . . 4) s +5 613 M +( 5.1 Opening a Channel . . . . . . . . . . . . . . . . . . . . . 4) s +5 602 M +( 5.2 Data Transfer . . . . . . . . . . . . . . . . . . . . . . . 5) s +5 591 M +( 5.3 Closing a Channel . . . . . . . . . . . . . . . . . . . . . 6) s +5 580 M +( 5.4 Channel-Specific Requests . . . . . . . . . . . . . . . . . 7) s +5 569 M +( 6. Interactive Sessions . . . . . . . . . . . . . . . . . . . . 8) s +5 558 M +( 6.1 Opening a Session . . . . . . . . . . . . . . . . . . . . . 8) s +5 547 M +( 6.2 Requesting a Pseudo-Terminal . . . . . . . . . . . . . . . . 8) s +5 536 M +( 6.3 X11 Forwarding . . . . . . . . . . . . . . . . . . . . . . . 9) s +5 525 M +( 6.3.1 Requesting X11 Forwarding . . . . . . . . . . . . . . . . . 9) s +5 514 M +( 6.3.2 X11 Channels . . . . . . . . . . . . . . . . . . . . . . . . 10) s +5 503 M +( 6.4 Environment Variable Passing . . . . . . . . . . . . . . . . 10) s +5 492 M +( 6.5 Starting a Shell or a Command . . . . . . . . . . . . . . . 10) s +5 481 M +( 6.6 Session Data Transfer . . . . . . . . . . . . . . . . . . . 11) s +5 470 M +( 6.7 Window Dimension Change Message . . . . . . . . . . . . . . 12) s +5 459 M +( 6.8 Local Flow Control . . . . . . . . . . . . . . . . . . . . . 12) s +5 448 M +( 6.9 Signals . . . . . . . . . . . . . . . . . . . . . . . . . . 12) s +5 437 M +( 6.10 Returning Exit Status . . . . . . . . . . . . . . . . . . . 13) s +5 426 M +( 7. TCP/IP Port Forwarding . . . . . . . . . . . . . . . . . . . 14) s +5 415 M +( 7.1 Requesting Port Forwarding . . . . . . . . . . . . . . . . . 14) s +5 404 M +( 7.2 TCP/IP Forwarding Channels . . . . . . . . . . . . . . . . . 15) s +5 393 M +( 8. Encoding of Terminal Modes . . . . . . . . . . . . . . . . . 16) s +5 382 M +( 9. Summary of Message Numbers . . . . . . . . . . . . . . . . . 18) s +5 371 M +( 10. Security Considerations . . . . . . . . . . . . . . . . . . 18) s +5 360 M +( 11. iana cONSiderations . . . . . . . . . . . . . . . . . . . . 19) s +5 349 M +( 12. Intellectual Property . . . . . . . . . . . . . . . . . . . 19) s +5 338 M +( Normative References . . . . . . . . . . . . . . . . . . . . 19) s +5 327 M +( Informative References . . . . . . . . . . . . . . . . . . . 20) s +5 316 M +( Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 20) s +5 305 M +( Intellectual Property and Copyright Statements . . . . . . . 21) s +5 129 M +(Ylonen & Moffat, Editor Expires March 31, 2004 [Page 2]) s +_R +S +PStoPSsaved restore +%%Page: (2,3) 2 +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 0.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +/showpage{}def/copypage{}def/erasepage{}def +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 3 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH Connection Protocol Oct 2003) s +5 690 M +(1. Contributors) s +5 668 M +( The major original contributors of this document were: Tatu Ylonen,) s +5 657 M +( Tero Kivinen, Timo J. Rinne, Sami Lehtinen \(all of SSH Communications) s +5 646 M +( Security Corp\), and Markku-Juhani O. Saarinen \(University of) s +5 635 M +( Jyvaskyla\)) s +5 613 M +( The document editor is: [email protected]. Comments on this) s +5 602 M +( internet draft should be sent to the IETF SECSH working group,) s +5 591 M +( details at: http://ietf.org/html.charters/secsh-charter.html) s +5 569 M +(2. Introduction) s +5 547 M +( The SSH Connection Protocol has been designed to run on top of the) s +5 536 M +( SSH transport layer and user authentication protocols. It provides) s +5 525 M +( interactive login sessions, remote execution of commands, forwarded) s +5 514 M +( TCP/IP connections, and forwarded X11 connections. The service name) s +5 503 M +( for this protocol is "ssh-connection".) s +5 481 M +( This document should be read only after reading the SSH architecture) s +5 470 M +( document [SSH-ARCH]. This document freely uses terminology and) s +5 459 M +( notation from the architecture document without reference or further) s +5 448 M +( explanation.) s +5 426 M +(3. Conventions Used in This Document) s +5 404 M +( The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",) s +5 393 M +( and "MAY" that appear in this document are to be interpreted as) s +5 382 M +( described in [RFC2119].) s +5 360 M +( The used data types and terminology are specified in the architecture) s +5 349 M +( document [SSH-ARCH].) s +5 327 M +( The architecture document also discusses the algorithm naming) s +5 316 M +( conventions that MUST be used with the SSH protocols.) s +5 294 M +(4. Global Requests) s +5 272 M +( There are several kinds of requests that affect the state of the) s +5 261 M +( remote end "globally", independent of any channels. An example is a) s +5 250 M +( request to start TCP/IP forwarding for a specific port. All such) s +5 239 M +( requests use the following format.) s +5 217 M +( byte SSH_MSG_GLOBAL_REQUEST) s +5 206 M +( string request name \(restricted to US-ASCII\)) s +5 195 M +( boolean want reply) s +5 184 M +( ... request-specific data follows) s +5 129 M +(Ylonen & Moffat, Editor Expires March 31, 2004 [Page 3]) s +_R +S +PStoPSsaved restore +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 421.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 4 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH Connection Protocol Oct 2003) s +5 690 M +( Request names follow the DNS extensibility naming convention outlined) s +5 679 M +( in [SSH-ARCH].) s +5 657 M +( The recipient will respond to this message with) s +5 646 M +( SSH_MSG_REQUEST_SUCCESS or SSH_MSG_REQUEST_FAILURE if `want reply' is) s +5 635 M +( TRUE.) s +5 613 M +( byte SSH_MSG_REQUEST_SUCCESS) s +5 602 M +( ..... response specific data) s +5 580 M +( Usually the response specific data is non-existent.) s +5 558 M +( If the recipient does not recognize or support the request, it simply) s +5 547 M +( responds with SSH_MSG_REQUEST_FAILURE.) s +5 525 M +( byte SSH_MSG_REQUEST_FAILURE) s +5 492 M +(5. Channel Mechanism) s +5 470 M +( All terminal sessions, forwarded connections, etc. are channels.) s +5 459 M +( Either side may open a channel. Multiple channels are multiplexed) s +5 448 M +( into a single connection.) s +5 426 M +( Channels are identified by numbers at each end. The number referring) s +5 415 M +( to a channel may be different on each side. Requests to open a) s +5 404 M +( channel contain the sender's channel number. Any other) s +5 393 M +( channel-related messages contain the recipient's channel number for) s +5 382 M +( the channel.) s +5 360 M +( Channels are flow-controlled. No data may be sent to a channel until) s +5 349 M +( a message is received to indicate that window space is available.) s +5 327 M +(5.1 Opening a Channel) s +5 305 M +( When either side wishes to open a new channel, it allocates a local) s +5 294 M +( number for the channel. It then sends the following message to the) s +5 283 M +( other side, and includes the local channel number and initial window) s +5 272 M +( size in the message.) s +5 250 M +( byte SSH_MSG_CHANNEL_OPEN) s +5 239 M +( string channel type \(restricted to US-ASCII\)) s +5 228 M +( uint32 sender channel) s +5 217 M +( uint32 initial window size) s +5 206 M +( uint32 maximum packet size) s +5 195 M +( ... channel type specific data follows) s +5 173 M +( The channel type is a name as described in the SSH architecture) s +5 129 M +(Ylonen & Moffat, Editor Expires March 31, 2004 [Page 4]) s +_R +S +PStoPSsaved restore +%%Page: (4,5) 3 +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 0.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +/showpage{}def/copypage{}def/erasepage{}def +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 5 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH Connection Protocol Oct 2003) s +5 690 M +( document, with similar extension mechanisms. `sender channel' is a) s +5 679 M +( local identifier for the channel used by the sender of this message.) s +5 668 M +( `initial window size' specifies how many bytes of channel data can be) s +5 657 M +( sent to the sender of this message without adjusting the window.) s +5 646 M +( `Maximum packet size' specifies the maximum size of an individual) s +5 635 M +( data packet that can be sent to the sender \(for example, one might) s +5 624 M +( want to use smaller packets for interactive connections to get better) s +5 613 M +( interactive response on slow links\).) s +5 591 M +( The remote side then decides whether it can open the channel, and) s +5 580 M +( responds with either) s +5 558 M +( byte SSH_MSG_CHANNEL_OPEN_CONFIRMATION) s +5 547 M +( uint32 recipient channel) s +5 536 M +( uint32 sender channel) s +5 525 M +( uint32 initial window size) s +5 514 M +( uint32 maximum packet size) s +5 503 M +( ... channel type specific data follows) s +5 481 M +( where `recipient channel' is the channel number given in the original) s +5 470 M +( open request, and `sender channel' is the channel number allocated by) s +5 459 M +( the other side, or) s +5 437 M +( byte SSH_MSG_CHANNEL_OPEN_FAILURE) s +5 426 M +( uint32 recipient channel) s +5 415 M +( uint32 reason code) s +5 404 M +( string additional textual information \(ISO-10646 UTF-8 [RFC2279]\)) s +5 393 M +( string language tag \(as defined in [RFC3066]\)) s +5 371 M +( If the recipient of the SSH_MSG_CHANNEL_OPEN message does not support) s +5 360 M +( the specified channel type, it simply responds with) s +5 349 M +( SSH_MSG_CHANNEL_OPEN_FAILURE. The client MAY show the additional) s +5 338 M +( information to the user. If this is done, the client software should) s +5 327 M +( take the precautions discussed in [SSH-ARCH].) s +5 305 M +( The following reason codes are defined:) s +5 283 M +( #define SSH_OPEN_ADMINISTRATIVELY_PROHIBITED 1) s +5 272 M +( #define SSH_OPEN_CONNECT_FAILED 2) s +5 261 M +( #define SSH_OPEN_UNKNOWN_CHANNEL_TYPE 3) s +5 250 M +( #define SSH_OPEN_RESOURCE_SHORTAGE 4) s +5 217 M +(5.2 Data Transfer) s +5 195 M +( The window size specifies how many bytes the other party can send) s +5 184 M +( before it must wait for the window to be adjusted. Both parties use) s +5 173 M +( the following message to adjust the window.) s +5 129 M +(Ylonen & Moffat, Editor Expires March 31, 2004 [Page 5]) s +_R +S +PStoPSsaved restore +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 421.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 6 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH Connection Protocol Oct 2003) s +5 690 M +( byte SSH_MSG_CHANNEL_WINDOW_ADJUST) s +5 679 M +( uint32 recipient channel) s +5 668 M +( uint32 bytes to add) s +5 646 M +( After receiving this message, the recipient MAY send the given number) s +5 635 M +( of bytes more than it was previously allowed to send; the window size) s +5 624 M +( is incremented.) s +5 602 M +( Data transfer is done with messages of the following type.) s +5 580 M +( byte SSH_MSG_CHANNEL_DATA) s +5 569 M +( uint32 recipient channel) s +5 558 M +( string data) s +5 536 M +( The maximum amount of data allowed is the current window size. The) s +5 525 M +( window size is decremented by the amount of data sent. Both parties) s +5 514 M +( MAY ignore all extra data sent after the allowed window is empty.) s +5 492 M +( Additionally, some channels can transfer several types of data. An) s +5 481 M +( example of this is stderr data from interactive sessions. Such data) s +5 470 M +( can be passed with SSH_MSG_CHANNEL_EXTENDED_DATA messages, where a) s +5 459 M +( separate integer specifies the type of the data. The available types) s +5 448 M +( and their interpretation depend on the type of the channel.) s +5 426 M +( byte SSH_MSG_CHANNEL_EXTENDED_DATA) s +5 415 M +( uint32 recipient_channel) s +5 404 M +( uint32 data_type_code) s +5 393 M +( string data) s +5 371 M +( Data sent with these messages consumes the same window as ordinary) s +5 360 M +( data.) s +5 338 M +( Currently, only the following type is defined.) s +5 316 M +( #define SSH_EXTENDED_DATA_STDERR 1) s +5 283 M +(5.3 Closing a Channel) s +5 261 M +( When a party will no longer send more data to a channel, it SHOULD) s +5 250 M +( send SSH_MSG_CHANNEL_EOF.) s +5 228 M +( byte SSH_MSG_CHANNEL_EOF) s +5 217 M +( uint32 recipient_channel) s +5 195 M +( No explicit response is sent to this message; however, the) s +5 184 M +( application may send EOF to whatever is at the other end of the) s +5 173 M +( channel. Note that the channel remains open after this message, and) s +5 129 M +(Ylonen & Moffat, Editor Expires March 31, 2004 [Page 6]) s +_R +S +PStoPSsaved restore +%%Page: (6,7) 4 +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 0.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +/showpage{}def/copypage{}def/erasepage{}def +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 7 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH Connection Protocol Oct 2003) s +5 690 M +( more data may still be sent in the other direction. This message) s +5 679 M +( does not consume window space and can be sent even if no window space) s +5 668 M +( is available.) s +5 646 M +( When either party wishes to terminate the channel, it sends) s +5 635 M +( SSH_MSG_CHANNEL_CLOSE. Upon receiving this message, a party MUST) s +5 624 M +( send back a SSH_MSG_CHANNEL_CLOSE unless it has already sent this) s +5 613 M +( message for the channel. The channel is considered closed for a) s +5 602 M +( party when it has both sent and received SSH_MSG_CHANNEL_CLOSE, and) s +5 591 M +( the party may then reuse the channel number. A party MAY send) s +5 580 M +( SSH_MSG_CHANNEL_CLOSE without having sent or received) s +5 569 M +( SSH_MSG_CHANNEL_EOF.) s +5 547 M +( byte SSH_MSG_CHANNEL_CLOSE) s +5 536 M +( uint32 recipient_channel) s +5 514 M +( This message does not consume window space and can be sent even if no) s +5 503 M +( window space is available.) s +5 481 M +( It is recommended that any data sent before this message is delivered) s +5 470 M +( to the actual destination, if possible.) s +5 448 M +(5.4 Channel-Specific Requests) s +5 426 M +( Many channel types have extensions that are specific to that) s +5 415 M +( particular channel type. An example is requesting a pty \(pseudo) s +5 404 M +( terminal\) for an interactive session.) s +5 382 M +( All channel-specific requests use the following format.) s +5 360 M +( byte SSH_MSG_CHANNEL_REQUEST) s +5 349 M +( uint32 recipient channel) s +5 338 M +( string request type \(restricted to US-ASCII\)) s +5 327 M +( boolean want reply) s +5 316 M +( ... type-specific data) s +5 294 M +( If want reply is FALSE, no response will be sent to the request.) s +5 283 M +( Otherwise, the recipient responds with either SSH_MSG_CHANNEL_SUCCESS) s +5 272 M +( or SSH_MSG_CHANNEL_FAILURE, or request-specific continuation) s +5 261 M +( messages. If the request is not recognized or is not supported for) s +5 250 M +( the channel, SSH_MSG_CHANNEL_FAILURE is returned.) s +5 228 M +( This message does not consume window space and can be sent even if no) s +5 217 M +( window space is available. Request types are local to each channel) s +5 206 M +( type.) s +5 184 M +( The client is allowed to send further messages without waiting for) s +5 173 M +( the response to the request.) s +5 129 M +(Ylonen & Moffat, Editor Expires March 31, 2004 [Page 7]) s +_R +S +PStoPSsaved restore +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 421.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 8 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH Connection Protocol Oct 2003) s +5 690 M +( request type names follow the DNS extensibility naming convention) s +5 679 M +( outlined in [SSH-ARCH]) s +5 657 M +( byte SSH_MSG_CHANNEL_SUCCESS) s +5 646 M +( uint32 recipient_channel) s +5 613 M +( byte SSH_MSG_CHANNEL_FAILURE) s +5 602 M +( uint32 recipient_channel) s +5 580 M +( These messages do not consume window space and can be sent even if no) s +5 569 M +( window space is available.) s +5 547 M +(6. Interactive Sessions) s +5 525 M +( A session is a remote execution of a program. The program may be a) s +5 514 M +( shell, an application, a system command, or some built-in subsystem.) s +5 503 M +( It may or may not have a tty, and may or may not involve X11) s +5 492 M +( forwarding. Multiple sessions can be active simultaneously.) s +5 470 M +(6.1 Opening a Session) s +5 448 M +( A session is started by sending the following message.) s +5 426 M +( byte SSH_MSG_CHANNEL_OPEN) s +5 415 M +( string "session") s +5 404 M +( uint32 sender channel) s +5 393 M +( uint32 initial window size) s +5 382 M +( uint32 maximum packet size) s +5 360 M +( Client implementations SHOULD reject any session channel open) s +5 349 M +( requests to make it more difficult for a corrupt server to attack the) s +5 338 M +( client.) s +5 316 M +(6.2 Requesting a Pseudo-Terminal) s +5 294 M +( A pseudo-terminal can be allocated for the session by sending the) s +5 283 M +( following message.) s +5 261 M +( byte SSH_MSG_CHANNEL_REQUEST) s +5 250 M +( uint32 recipient_channel) s +5 239 M +( string "pty-req") s +5 228 M +( boolean want_reply) s +5 217 M +( string TERM environment variable value \(e.g., vt100\)) s +5 206 M +( uint32 terminal width, characters \(e.g., 80\)) s +5 195 M +( uint32 terminal height, rows \(e.g., 24\)) s +5 184 M +( uint32 terminal width, pixels \(e.g., 640\)) s +5 173 M +( uint32 terminal height, pixels \(e.g., 480\)) s +5 129 M +(Ylonen & Moffat, Editor Expires March 31, 2004 [Page 8]) s +_R +S +PStoPSsaved restore +%%Page: (8,9) 5 +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 0.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +/showpage{}def/copypage{}def/erasepage{}def +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 9 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH Connection Protocol Oct 2003) s +5 690 M +( string encoded terminal modes) s +5 668 M +( The encoding of terminal modes is described in Section Encoding of) s +5 657 M +( Terminal Modes \(Section 8\). Zero dimension parameters MUST be) s +5 646 M +( ignored. The character/row dimensions override the pixel dimensions) s +5 635 M +( \(when nonzero\). Pixel dimensions refer to the drawable area of the) s +5 624 M +( window.) s +5 602 M +( The dimension parameters are only informational.) s +5 580 M +( The client SHOULD ignore pty requests.) s +5 558 M +(6.3 X11 Forwarding) s +5 536 M +(6.3.1 Requesting X11 Forwarding) s +5 514 M +( X11 forwarding may be requested for a session by sending) s +5 492 M +( byte SSH_MSG_CHANNEL_REQUEST) s +5 481 M +( uint32 recipient channel) s +5 470 M +( string "x11-req") s +5 459 M +( boolean want reply) s +5 448 M +( boolean single connection) s +5 437 M +( string x11 authentication protocol) s +5 426 M +( string x11 authentication cookie) s +5 415 M +( uint32 x11 screen number) s +5 393 M +( It is recommended that the authentication cookie that is sent be a) s +5 382 M +( fake, random cookie, and that the cookie is checked and replaced by) s +5 371 M +( the real cookie when a connection request is received.) s +5 349 M +( X11 connection forwarding should stop when the session channel is) s +5 338 M +( closed; however, already opened forwardings should not be) s +5 327 M +( automatically closed when the session channel is closed.) s +5 305 M +( If `single connection' is TRUE, only a single connection should be) s +5 294 M +( forwarded. No more connections will be forwarded after the first, or) s +5 283 M +( after the session channel has been closed.) s +5 261 M +( The "x11 authentication protocol" is the name of the X11) s +5 250 M +( authentication method used, e.g. "MIT-MAGIC-COOKIE-1".) s +5 228 M +( The x11 authentication cookie MUST be hexadecimal encoded.) s +5 206 M +( X Protocol is documented in [SCHEIFLER].) s +5 129 M +(Ylonen & Moffat, Editor Expires March 31, 2004 [Page 9]) s +_R +S +PStoPSsaved restore +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 421.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 10 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH Connection Protocol Oct 2003) s +5 690 M +(6.3.2 X11 Channels) s +5 668 M +( X11 channels are opened with a channel open request. The resulting) s +5 657 M +( channels are independent of the session, and closing the session) s +5 646 M +( channel does not close the forwarded X11 channels.) s +5 624 M +( byte SSH_MSG_CHANNEL_OPEN) s +5 613 M +( string "x11") s +5 602 M +( uint32 sender channel) s +5 591 M +( uint32 initial window size) s +5 580 M +( uint32 maximum packet size) s +5 569 M +( string originator address \(e.g. "192.168.7.38"\)) s +5 558 M +( uint32 originator port) s +5 536 M +( The recipient should respond with SSH_MSG_CHANNEL_OPEN_CONFIRMATION) s +5 525 M +( or SSH_MSG_CHANNEL_OPEN_FAILURE.) s +5 503 M +( Implementations MUST reject any X11 channel open requests if they) s +5 492 M +( have not requested X11 forwarding.) s +5 470 M +(6.4 Environment Variable Passing) s +5 448 M +( Environment variables may be passed to the shell/command to be) s +5 437 M +( started later. Uncontrolled setting of environment variables in a) s +5 426 M +( privileged process can be a security hazard. It is recommended that) s +5 415 M +( implementations either maintain a list of allowable variable names or) s +5 404 M +( only set environment variables after the server process has dropped) s +5 393 M +( sufficient privileges.) s +5 371 M +( byte SSH_MSG_CHANNEL_REQUEST) s +5 360 M +( uint32 recipient channel) s +5 349 M +( string "env") s +5 338 M +( boolean want reply) s +5 327 M +( string variable name) s +5 316 M +( string variable value) s +5 283 M +(6.5 Starting a Shell or a Command) s +5 261 M +( Once the session has been set up, a program is started at the remote) s +5 250 M +( end. The program can be a shell, an application program or a) s +5 239 M +( subsystem with a host-independent name. Only one of these requests) s +5 228 M +( can succeed per channel.) s +5 206 M +( byte SSH_MSG_CHANNEL_REQUEST) s +5 195 M +( uint32 recipient channel) s +5 184 M +( string "shell") s +5 173 M +( boolean want reply) s +5 129 M +(Ylonen & Moffat, Editor Expires March 31, 2004 [Page 10]) s +_R +S +PStoPSsaved restore +%%Page: (10,11) 6 +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 0.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +/showpage{}def/copypage{}def/erasepage{}def +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 11 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH Connection Protocol Oct 2003) s +5 690 M +( This message will request the user's default shell \(typically defined) s +5 679 M +( in /etc/passwd in UNIX systems\) to be started at the other end.) s +5 657 M +( byte SSH_MSG_CHANNEL_REQUEST) s +5 646 M +( uint32 recipient channel) s +5 635 M +( string "exec") s +5 624 M +( boolean want reply) s +5 613 M +( string command) s +5 591 M +( This message will request the server to start the execution of the) s +5 580 M +( given command. The command string may contain a path. Normal) s +5 569 M +( precautions MUST be taken to prevent the execution of unauthorized) s +5 558 M +( commands.) s +5 536 M +( byte SSH_MSG_CHANNEL_REQUEST) s +5 525 M +( uint32 recipient channel) s +5 514 M +( string "subsystem") s +5 503 M +( boolean want reply) s +5 492 M +( string subsystem name) s +5 470 M +( This last form executes a predefined subsystem. It is expected that) s +5 459 M +( these will include a general file transfer mechanism, and possibly) s +5 448 M +( other features. Implementations may also allow configuring more such) s +5 437 M +( mechanisms. As the user's shell is usually used to execute the) s +5 426 M +( subsystem, it is advisable for the subsystem protocol to have a) s +5 415 M +( "magic cookie" at the beginning of the protocol transaction to) s +5 404 M +( distinguish it from arbitrary output generated by shell) s +5 393 M +( initialization scripts etc. This spurious output from the shell may) s +5 382 M +( be filtered out either at the server or at the client.) s +5 360 M +( The server SHOULD not halt the execution of the protocol stack when) s +5 349 M +( starting a shell or a program. All input and output from these SHOULD) s +5 338 M +( be redirected to the channel or to the encrypted tunnel.) s +5 316 M +( It is RECOMMENDED to request and check the reply for these messages.) s +5 305 M +( The client SHOULD ignore these messages.) s +5 283 M +( Subsystem names follow the DNS extensibility naming convention) s +5 272 M +( outlined in [SSH-ARCH].) s +5 250 M +(6.6 Session Data Transfer) s +5 228 M +( Data transfer for a session is done using SSH_MSG_CHANNEL_DATA and) s +5 217 M +( SSH_MSG_CHANNEL_EXTENDED_DATA packets and the window mechanism. The) s +5 206 M +( extended data type SSH_EXTENDED_DATA_STDERR has been defined for) s +5 195 M +( stderr data.) s +5 129 M +(Ylonen & Moffat, Editor Expires March 31, 2004 [Page 11]) s +_R +S +PStoPSsaved restore +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 421.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 12 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH Connection Protocol Oct 2003) s +5 690 M +(6.7 Window Dimension Change Message) s +5 668 M +( When the window \(terminal\) size changes on the client side, it MAY) s +5 657 M +( send a message to the other side to inform it of the new dimensions.) s +5 635 M +( byte SSH_MSG_CHANNEL_REQUEST) s +5 624 M +( uint32 recipient_channel) s +5 613 M +( string "window-change") s +5 602 M +( boolean FALSE) s +5 591 M +( uint32 terminal width, columns) s +5 580 M +( uint32 terminal height, rows) s +5 569 M +( uint32 terminal width, pixels) s +5 558 M +( uint32 terminal height, pixels) s +5 536 M +( No response SHOULD be sent to this message.) s +5 514 M +(6.8 Local Flow Control) s +5 492 M +( On many systems, it is possible to determine if a pseudo-terminal is) s +5 481 M +( using control-S/control-Q flow control. When flow control is) s +5 470 M +( allowed, it is often desirable to do the flow control at the client) s +5 459 M +( end to speed up responses to user requests. This is facilitated by) s +5 448 M +( the following notification. Initially, the server is responsible for) s +5 437 M +( flow control. \(Here, again, client means the side originating the) s +5 426 M +( session, and server means the other side.\)) s +5 404 M +( The message below is used by the server to inform the client when it) s +5 393 M +( can or cannot perform flow control \(control-S/control-Q processing\).) s +5 382 M +( If `client can do' is TRUE, the client is allowed to do flow control) s +5 371 M +( using control-S and control-Q. The client MAY ignore this message.) s +5 349 M +( byte SSH_MSG_CHANNEL_REQUEST) s +5 338 M +( uint32 recipient channel) s +5 327 M +( string "xon-xoff") s +5 316 M +( boolean FALSE) s +5 305 M +( boolean client can do) s +5 283 M +( No response is sent to this message.) s +5 261 M +(6.9 Signals) s +5 239 M +( A signal can be delivered to the remote process/service using the) s +5 228 M +( following message. Some systems may not implement signals, in which) s +5 217 M +( case they SHOULD ignore this message.) s +5 195 M +( byte SSH_MSG_CHANNEL_REQUEST) s +5 184 M +( uint32 recipient channel) s +5 173 M +( string "signal") s +5 129 M +(Ylonen & Moffat, Editor Expires March 31, 2004 [Page 12]) s +_R +S +PStoPSsaved restore +%%Page: (12,13) 7 +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 0.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +/showpage{}def/copypage{}def/erasepage{}def +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 13 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH Connection Protocol Oct 2003) s +5 690 M +( boolean FALSE) s +5 679 M +( string signal name without the "SIG" prefix.) s +5 657 M +( Signal names will be encoded as discussed in the "exit-signal") s +5 646 M +( SSH_MSG_CHANNEL_REQUEST.) s +5 624 M +(6.10 Returning Exit Status) s +5 602 M +( When the command running at the other end terminates, the following) s +5 591 M +( message can be sent to return the exit status of the command.) s +5 580 M +( Returning the status is RECOMMENDED. No acknowledgment is sent for) s +5 569 M +( this message. The channel needs to be closed with) s +5 558 M +( SSH_MSG_CHANNEL_CLOSE after this message.) s +5 536 M +( The client MAY ignore these messages.) s +5 514 M +( byte SSH_MSG_CHANNEL_REQUEST) s +5 503 M +( uint32 recipient_channel) s +5 492 M +( string "exit-status") s +5 481 M +( boolean FALSE) s +5 470 M +( uint32 exit_status) s +5 448 M +( The remote command may also terminate violently due to a signal.) s +5 437 M +( Such a condition can be indicated by the following message. A zero) s +5 426 M +( exit_status usually means that the command terminated successfully.) s +5 404 M +( byte SSH_MSG_CHANNEL_REQUEST) s +5 393 M +( uint32 recipient channel) s +5 382 M +( string "exit-signal") s +5 371 M +( boolean FALSE) s +5 360 M +( string signal name without the "SIG" prefix.) s +5 349 M +( boolean core dumped) s +5 338 M +( string error message \(ISO-10646 UTF-8\)) s +5 327 M +( string language tag \(as defined in [RFC3066]\)) s +5 305 M +( The signal name is one of the following \(these are from [POSIX]\)) s +5 283 M +( ABRT) s +5 272 M +( ALRM) s +5 261 M +( FPE) s +5 250 M +( HUP) s +5 239 M +( ILL) s +5 228 M +( INT) s +5 217 M +( KILL) s +5 206 M +( PIPE) s +5 195 M +( QUIT) s +5 184 M +( SEGV) s +5 173 M +( TERM) s +5 129 M +(Ylonen & Moffat, Editor Expires March 31, 2004 [Page 13]) s +_R +S +PStoPSsaved restore +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 421.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 14 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH Connection Protocol Oct 2003) s +5 690 M +( USR1) s +5 679 M +( USR2) s +5 657 M +( Additional signal names MAY be sent in the format "sig-name@xyz",) s +5 646 M +( where `sig-name' and `xyz' may be anything a particular implementor) s +5 635 M +( wants \(except the `@' sign\). However, it is suggested that if a) s +5 624 M +( `configure' script is used, the non-standard signal names it finds be) s +5 613 M +( encoded as "[email protected]", where `SIG' is the signal name) s +5 602 M +( without the "SIG" prefix, and `xyz' be the host type, as determined) s +5 591 M +( by `config.guess'.) s +5 569 M +( The `error message' contains an additional explanation of the error) s +5 558 M +( message. The message may consist of multiple lines. The client) s +5 547 M +( software MAY display this message to the user. If this is done, the) s +5 536 M +( client software should take the precautions discussed in [SSH-ARCH].) s +5 514 M +(7. TCP/IP Port Forwarding) s +5 492 M +(7.1 Requesting Port Forwarding) s +5 470 M +( A party need not explicitly request forwardings from its own end to) s +5 459 M +( the other direction. However, if it wishes that connections to a) s +5 448 M +( port on the other side be forwarded to the local side, it must) s +5 437 M +( explicitly request this.) s +5 404 M +( byte SSH_MSG_GLOBAL_REQUEST) s +5 393 M +( string "tcpip-forward") s +5 382 M +( boolean want reply) s +5 371 M +( string address to bind \(e.g. "0.0.0.0"\)) s +5 360 M +( uint32 port number to bind) s +5 338 M +( `Address to bind' and `port number to bind' specify the IP address) s +5 327 M +( and port to which the socket to be listened is bound. The address) s +5 316 M +( should be "0.0.0.0" if connections are allowed from anywhere. \(Note) s +5 305 M +( that the client can still filter connections based on information) s +5 294 M +( passed in the open request.\)) s +5 272 M +( Implementations should only allow forwarding privileged ports if the) s +5 261 M +( user has been authenticated as a privileged user.) s +5 239 M +( Client implementations SHOULD reject these messages; they are) s +5 228 M +( normally only sent by the client.) s +5 195 M +( If a client passes 0 as port number to bind and has want reply TRUE) s +5 184 M +( then the server allocates the next available unprivileged port number) s +5 173 M +( and replies with the following message, otherwise there is no) s +5 129 M +(Ylonen & Moffat, Editor Expires March 31, 2004 [Page 14]) s +_R +S +PStoPSsaved restore +%%Page: (14,15) 8 +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 0.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +/showpage{}def/copypage{}def/erasepage{}def +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 15 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH Connection Protocol Oct 2003) s +5 690 M +( response specific data.) s +5 657 M +( byte SSH_MSG_GLOBAL_REQUEST_SUCCESS) s +5 646 M +( uint32 port that was bound on the server) s +5 624 M +( A port forwarding can be cancelled with the following message. Note) s +5 613 M +( that channel open requests may be received until a reply to this) s +5 602 M +( message is received.) s +5 580 M +( byte SSH_MSG_GLOBAL_REQUEST) s +5 569 M +( string "cancel-tcpip-forward") s +5 558 M +( boolean want reply) s +5 547 M +( string address_to_bind \(e.g. "127.0.0.1"\)) s +5 536 M +( uint32 port number to bind) s +5 514 M +( Client implementations SHOULD reject these messages; they are) s +5 503 M +( normally only sent by the client.) s +5 481 M +(7.2 TCP/IP Forwarding Channels) s +5 459 M +( When a connection comes to a port for which remote forwarding has) s +5 448 M +( been requested, a channel is opened to forward the port to the other) s +5 437 M +( side.) s +5 415 M +( byte SSH_MSG_CHANNEL_OPEN) s +5 404 M +( string "forwarded-tcpip") s +5 393 M +( uint32 sender channel) s +5 382 M +( uint32 initial window size) s +5 371 M +( uint32 maximum packet size) s +5 360 M +( string address that was connected) s +5 349 M +( uint32 port that was connected) s +5 338 M +( string originator IP address) s +5 327 M +( uint32 originator port) s +5 305 M +( Implementations MUST reject these messages unless they have) s +5 294 M +( previously requested a remote TCP/IP port forwarding with the given) s +5 283 M +( port number.) s +5 261 M +( When a connection comes to a locally forwarded TCP/IP port, the) s +5 250 M +( following packet is sent to the other side. Note that these messages) s +5 239 M +( MAY be sent also for ports for which no forwarding has been) s +5 228 M +( explicitly requested. The receiving side must decide whether to) s +5 217 M +( allow the forwarding.) s +5 195 M +( byte SSH_MSG_CHANNEL_OPEN) s +5 184 M +( string "direct-tcpip") s +5 173 M +( uint32 sender channel) s +5 129 M +(Ylonen & Moffat, Editor Expires March 31, 2004 [Page 15]) s +_R +S +PStoPSsaved restore +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 421.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 16 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH Connection Protocol Oct 2003) s +5 690 M +( uint32 initial window size) s +5 679 M +( uint32 maximum packet size) s +5 668 M +( string host to connect) s +5 657 M +( uint32 port to connect) s +5 646 M +( string originator IP address) s +5 635 M +( uint32 originator port) s +5 613 M +( `Host to connect' and `port to connect' specify the TCP/IP host and) s +5 602 M +( port where the recipient should connect the channel. `Host to) s +5 591 M +( connect' may be either a domain name or a numeric IP address.) s +5 569 M +( `Originator IP address' is the numeric IP address of the machine) s +5 558 M +( where the connection request comes from, and `originator port' is the) s +5 547 M +( port on the originator host from where the connection came from.) s +5 525 M +( Forwarded TCP/IP channels are independent of any sessions, and) s +5 514 M +( closing a session channel does not in any way imply that forwarded) s +5 503 M +( connections should be closed.) s +5 481 M +( Client implementations SHOULD reject direct TCP/IP open requests for) s +5 470 M +( security reasons.) s +5 448 M +(8. Encoding of Terminal Modes) s +5 426 M +( Terminal modes \(as passed in a pty request\) are encoded into a byte) s +5 415 M +( stream. It is intended that the coding be portable across different) s +5 404 M +( environments.) s +5 382 M +( The tty mode description is a stream of bytes. The stream consists) s +5 371 M +( of opcode-argument pairs. It is terminated by opcode TTY_OP_END \(0\).) s +5 360 M +( Opcodes 1 to 159 have a single uint32 argument. Opcodes 160 to 255) s +5 349 M +( are not yet defined, and cause parsing to stop \(they should only be) s +5 338 M +( used after any other data\).) s +5 316 M +( The client SHOULD put in the stream any modes it knows about, and the) s +5 305 M +( server MAY ignore any modes it does not know about. This allows some) s +5 294 M +( degree of machine-independence, at least between systems that use a) s +5 283 M +( POSIX-like tty interface. The protocol can support other systems as) s +5 272 M +( well, but the client may need to fill reasonable values for a number) s +5 261 M +( of parameters so the server pty gets set to a reasonable mode \(the) s +5 250 M +( server leaves all unspecified mode bits in their default values, and) s +5 239 M +( only some combinations make sense\).) s +5 217 M +( The following opcodes have been defined. The naming of opcodes) s +5 206 M +( mostly follows the POSIX terminal mode flags.) s +5 184 M +( 0 TTY_OP_END Indicates end of options.) s +5 173 M +( 1 VINTR Interrupt character; 255 if none. Similarly for the) s +5 129 M +(Ylonen & Moffat, Editor Expires March 31, 2004 [Page 16]) s +_R +S +PStoPSsaved restore +%%Page: (16,17) 9 +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 0.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +/showpage{}def/copypage{}def/erasepage{}def +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 17 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH Connection Protocol Oct 2003) s +5 690 M +( other characters. Not all of these characters are) s +5 679 M +( supported on all systems.) s +5 668 M +( 2 VQUIT The quit character \(sends SIGQUIT signal on POSIX) s +5 657 M +( systems\).) s +5 646 M +( 3 VERASE Erase the character to left of the cursor.) s +5 635 M +( 4 VKILL Kill the current input line.) s +5 624 M +( 5 VEOF End-of-file character \(sends EOF from the terminal\).) s +5 613 M +( 6 VEOL End-of-line character in addition to carriage return) s +5 602 M +( and/or linefeed.) s +5 591 M +( 7 VEOL2 Additional end-of-line character.) s +5 580 M +( 8 VSTART Continues paused output \(normally control-Q\).) s +5 569 M +( 9 VSTOP Pauses output \(normally control-S\).) s +5 558 M +( 10 VSUSP Suspends the current program.) s +5 547 M +( 11 VDSUSP Another suspend character.) s +5 536 M +( 12 VREPRINT Reprints the current input line.) s +5 525 M +( 13 VWERASE Erases a word left of cursor.) s +5 514 M +( 14 VLNEXT Enter the next character typed literally, even if it) s +5 503 M +( is a special character) s +5 492 M +( 15 VFLUSH Character to flush output.) s +5 481 M +( 16 VSWTCH Switch to a different shell layer.) s +5 470 M +( 17 VSTATUS Prints system status line \(load, command, pid etc\).) s +5 459 M +( 18 VDISCARD Toggles the flushing of terminal output.) s +5 448 M +( 30 IGNPAR The ignore parity flag. The parameter SHOULD be 0 if) s +5 437 M +( this flag is FALSE set, and 1 if it is TRUE.) s +5 426 M +( 31 PARMRK Mark parity and framing errors.) s +5 415 M +( 32 INPCK Enable checking of parity errors.) s +5 404 M +( 33 ISTRIP Strip 8th bit off characters.) s +5 393 M +( 34 INLCR Map NL into CR on input.) s +5 382 M +( 35 IGNCR Ignore CR on input.) s +5 371 M +( 36 ICRNL Map CR to NL on input.) s +5 360 M +( 37 IUCLC Translate uppercase characters to lowercase.) s +5 349 M +( 38 IXON Enable output flow control.) s +5 338 M +( 39 IXANY Any char will restart after stop.) s +5 327 M +( 40 IXOFF Enable input flow control.) s +5 316 M +( 41 IMAXBEL Ring bell on input queue full.) s +5 305 M +( 50 ISIG Enable signals INTR, QUIT, [D]SUSP.) s +5 294 M +( 51 ICANON Canonicalize input lines.) s +5 283 M +( 52 XCASE Enable input and output of uppercase characters by) s +5 272 M +( preceding their lowercase equivalents with `\\'.) s +5 261 M +( 53 ECHO Enable echoing.) s +5 250 M +( 54 ECHOE Visually erase chars.) s +5 239 M +( 55 ECHOK Kill character discards current line.) s +5 228 M +( 56 ECHONL Echo NL even if ECHO is off.) s +5 217 M +( 57 NOFLSH Don't flush after interrupt.) s +5 206 M +( 58 TOSTOP Stop background jobs from output.) s +5 195 M +( 59 IEXTEN Enable extensions.) s +5 184 M +( 60 ECHOCTL Echo control characters as ^\(Char\).) s +5 173 M +( 61 ECHOKE Visual erase for line kill.) s +5 129 M +(Ylonen & Moffat, Editor Expires March 31, 2004 [Page 17]) s +_R +S +PStoPSsaved restore +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 421.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 18 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH Connection Protocol Oct 2003) s +5 690 M +( 62 PENDIN Retype pending input.) s +5 679 M +( 70 OPOST Enable output processing.) s +5 668 M +( 71 OLCUC Convert lowercase to uppercase.) s +5 657 M +( 72 ONLCR Map NL to CR-NL.) s +5 646 M +( 73 OCRNL Translate carriage return to newline \(output\).) s +5 635 M +( 74 ONOCR Translate newline to carriage return-newline) s +5 624 M +( \(output\).) s +5 613 M +( 75 ONLRET Newline performs a carriage return \(output\).) s +5 602 M +( 90 CS7 7 bit mode.) s +5 591 M +( 91 CS8 8 bit mode.) s +5 580 M +( 92 PARENB Parity enable.) s +5 569 M +( 93 PARODD Odd parity, else even.) s +5 547 M +( 128 TTY_OP_ISPEED Specifies the input baud rate in bits per second.) s +5 536 M +( 129 TTY_OP_OSPEED Specifies the output baud rate in bits per second.) s +5 503 M +(9. Summary of Message Numbers) s +5 481 M +( #define SSH_MSG_GLOBAL_REQUEST 80) s +5 470 M +( #define SSH_MSG_REQUEST_SUCCESS 81) s +5 459 M +( #define SSH_MSG_REQUEST_FAILURE 82) s +5 448 M +( #define SSH_MSG_CHANNEL_OPEN 90) s +5 437 M +( #define SSH_MSG_CHANNEL_OPEN_CONFIRMATION 91) s +5 426 M +( #define SSH_MSG_CHANNEL_OPEN_FAILURE 92) s +5 415 M +( #define SSH_MSG_CHANNEL_WINDOW_ADJUST 93) s +5 404 M +( #define SSH_MSG_CHANNEL_DATA 94) s +5 393 M +( #define SSH_MSG_CHANNEL_EXTENDED_DATA 95) s +5 382 M +( #define SSH_MSG_CHANNEL_EOF 96) s +5 371 M +( #define SSH_MSG_CHANNEL_CLOSE 97) s +5 360 M +( #define SSH_MSG_CHANNEL_REQUEST 98) s +5 349 M +( #define SSH_MSG_CHANNEL_SUCCESS 99) s +5 338 M +( #define SSH_MSG_CHANNEL_FAILURE 100) s +5 305 M +(10. Security Considerations) s +5 283 M +( This protocol is assumed to run on top of a secure, authenticated) s +5 272 M +( transport. User authentication and protection against network-level) s +5 261 M +( attacks are assumed to be provided by the underlying protocols.) s +5 239 M +( It is RECOMMENDED that implementations disable all the potentially) s +5 228 M +( dangerous features \(e.g. agent forwarding, X11 forwarding, and TCP/IP) s +5 217 M +( forwarding\) if the host key has changed.) s +5 195 M +( Full security considerations for this protocol are provided in) s +5 184 M +( Section 8 of [SSH-ARCH]) s +5 129 M +(Ylonen & Moffat, Editor Expires March 31, 2004 [Page 18]) s +_R +S +PStoPSsaved restore +%%Page: (18,19) 10 +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 0.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +/showpage{}def/copypage{}def/erasepage{}def +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 19 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH Connection Protocol Oct 2003) s +5 690 M +(11. iana cONSiderations) s +5 668 M +( This document is part of a set, the IANA considerations for the SSH) s +5 657 M +( protocol as defined in [SSH-ARCH], [SSH-TRANS], [SSH-USERAUTH],) s +5 646 M +( [SSH-CONNECT] are detailed in [SSH-NUMBERS].) s +5 624 M +(12. Intellectual Property) s +5 602 M +( The IETF takes no position regarding the validity or scope of any) s +5 591 M +( intellectual property or other rights that might be claimed to) s +5 580 M +( pertain to the implementation or use of the technology described in) s +5 569 M +( this document or the extent to which any license under such rights) s +5 558 M +( might or might not be available; neither does it represent that it) s +5 547 M +( has made any effort to identify any such rights. Information on the) s +5 536 M +( IETF's procedures with respect to rights in standards-track and) s +5 525 M +( standards-related documentation can be found in BCP-11. Copies of) s +5 514 M +( claims of rights made available for publication and any assurances of) s +5 503 M +( licenses to be made available, or the result of an attempt made to) s +5 492 M +( obtain a general license or permission for the use of such) s +5 481 M +( proprietary rights by implementers or users of this specification can) s +5 470 M +( be obtained from the IETF Secretariat.) s +5 448 M +( The IETF has been notified of intellectual property rights claimed in) s +5 437 M +( regard to some or all of the specification contained in this) s +5 426 M +( document. For more information consult the online list of claimed) s +5 415 M +( rights.) s +5 393 M +(Normative References) s +5 371 M +( [SSH-ARCH]) s +5 360 M +( Ylonen, T., "SSH Protocol Architecture", I-D) s +5 349 M +( draft-ietf-architecture-15.txt, Oct 2003.) s +5 327 M +( [SSH-TRANS]) s +5 316 M +( Ylonen, T., "SSH Transport Layer Protocol", I-D) s +5 305 M +( draft-ietf-transport-17.txt, Oct 2003.) s +5 283 M +( [SSH-USERAUTH]) s +5 272 M +( Ylonen, T., "SSH Authentication Protocol", I-D) s +5 261 M +( draft-ietf-userauth-18.txt, Oct 2003.) s +5 239 M +( [SSH-CONNECT]) s +5 228 M +( Ylonen, T., "SSH Connection Protocol", I-D) s +5 217 M +( draft-ietf-connect-18.txt, Oct 2003.) s +5 195 M +( [SSH-NUMBERS]) s +5 184 M +( Lehtinen, S. and D. Moffat, "SSH Protocol Assigned) s +5 173 M +( Numbers", I-D draft-ietf-secsh-assignednumbers-05.txt, Oct) s +5 129 M +(Ylonen & Moffat, Editor Expires March 31, 2004 [Page 19]) s +_R +S +PStoPSsaved restore +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 421.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 20 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH Connection Protocol Oct 2003) s +5 690 M +( 2003.) s +5 668 M +( [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate) s +5 657 M +( Requirement Levels", BCP 14, RFC 2119, March 1997.) s +5 635 M +(Informative References) s +5 613 M +( [RFC3066] Alvestrand, H., "Tags for the Identification of) s +5 602 M +( Languages", BCP 47, RFC 3066, January 2001.) s +5 580 M +( [RFC1884] Hinden, R. and S. Deering, "IP Version 6 Addressing) s +5 569 M +( Architecture", RFC 1884, December 1995.) s +5 547 M +( [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO) s +5 536 M +( 10646", RFC 2279, January 1998.) s +5 514 M +( [SCHEIFLER]) s +5 503 M +( Scheifler, R., "X Window System : The Complete Reference) s +5 492 M +( to Xlib, X Protocol, Icccm, Xlfd, 3rd edition.", Digital) s +5 481 M +( Press ISBN 1555580882, Feburary 1992.) s +5 459 M +( [POSIX] ISO/IEC, 9945-1., "Information technology -- Portable) s +5 448 M +( Operating System Interface \(POSIX\)-Part 1: System) s +5 437 M +( Application Program Interface \(API\) C Language", ANSI/IEE) s +5 426 M +( Std 1003.1, July 1996.) s +5 393 M +(Authors' Addresses) s +5 371 M +( Tatu Ylonen) s +5 360 M +( SSH Communications Security Corp) s +5 349 M +( Fredrikinkatu 42) s +5 338 M +( HELSINKI FIN-00100) s +5 327 M +( Finland) s +5 305 M +( EMail: [email protected]) s +5 272 M +( Darren J. Moffat \(editor\)) s +5 261 M +( Sun Microsystems, Inc) s +5 250 M +( 17 Network Circle) s +5 239 M +( Menlo Park CA 94025) s +5 228 M +( USA) s +5 206 M +( EMail: [email protected]) s +5 129 M +(Ylonen & Moffat, Editor Expires March 31, 2004 [Page 20]) s +_R +S +PStoPSsaved restore +%%Page: (20,21) 11 +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 0.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +/showpage{}def/copypage{}def/erasepage{}def +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 21 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH Connection Protocol Oct 2003) s +5 690 M +(Intellectual Property Statement) s +5 668 M +( The IETF takes no position regarding the validity or scope of any) s +5 657 M +( intellectual property or other rights that might be claimed to) s +5 646 M +( pertain to the implementation or use of the technology described in) s +5 635 M +( this document or the extent to which any license under such rights) s +5 624 M +( might or might not be available; neither does it represent that it) s +5 613 M +( has made any effort to identify any such rights. Information on the) s +5 602 M +( IETF's procedures with respect to rights in standards-track and) s +5 591 M +( standards-related documentation can be found in BCP-11. Copies of) s +5 580 M +( claims of rights made available for publication and any assurances of) s +5 569 M +( licenses to be made available, or the result of an attempt made to) s +5 558 M +( obtain a general license or permission for the use of such) s +5 547 M +( proprietary rights by implementors or users of this specification can) s +5 536 M +( be obtained from the IETF Secretariat.) s +5 514 M +( The IETF invites any interested party to bring to its attention any) s +5 503 M +( copyrights, patents or patent applications, or other proprietary) s +5 492 M +( rights which may cover technology that may be required to practice) s +5 481 M +( this standard. Please address the information to the IETF Executive) s +5 470 M +( Director.) s +5 448 M +( The IETF has been notified of intellectual property rights claimed in) s +5 437 M +( regard to some or all of the specification contained in this) s +5 426 M +( document. For more information consult the online list of claimed) s +5 415 M +( rights.) s +5 382 M +(Full Copyright Statement) s +5 360 M +( Copyright \(C\) The Internet Society \(2003\). All Rights Reserved.) s +5 338 M +( This document and translations of it may be copied and furnished to) s +5 327 M +( others, and derivative works that comment on or otherwise explain it) s +5 316 M +( or assist in its implementation may be prepared, copied, published) s +5 305 M +( and distributed, in whole or in part, without restriction of any) s +5 294 M +( kind, provided that the above copyright notice and this paragraph are) s +5 283 M +( included on all such copies and derivative works. However, this) s +5 272 M +( document itself may not be modified in any way, such as by removing) s +5 261 M +( the copyright notice or references to the Internet Society or other) s +5 250 M +( Internet organizations, except as needed for the purpose of) s +5 239 M +( developing Internet standards in which case the procedures for) s +5 228 M +( copyrights defined in the Internet Standards process must be) s +5 217 M +( followed, or as required to translate it into languages other than) s +5 206 M +( English.) s +5 184 M +( The limited permissions granted above are perpetual and will not be) s +5 173 M +( revoked by the Internet Society or its successors or assignees.) s +5 129 M +(Ylonen & Moffat, Editor Expires March 31, 2004 [Page 21]) s +_R +S +PStoPSsaved restore +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 421.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 22 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH Connection Protocol Oct 2003) s +5 690 M +( This document and the information contained herein is provided on an) s +5 679 M +( "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING) s +5 668 M +( TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING) s +5 657 M +( BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION) s +5 646 M +( HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF) s +5 635 M +( MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.) s +5 602 M +(Acknowledgment) s +5 580 M +( Funding for the RFC Editor function is currently provided by the) s +5 569 M +( Internet Society.) s +5 129 M +(Ylonen & Moffat, Editor Expires March 31, 2004 [Page 22]) s +_R +S +PStoPSsaved restore +%%Trailer +%%Pages: 22 +%%DocumentNeededResources: font Courier-Bold Courier +%%EOF diff --git a/lib/ssh/doc/standard/draft-ietf-secsh-connect-18.txt b/lib/ssh/doc/standard/draft-ietf-secsh-connect-18.txt new file mode 100644 index 0000000000..1cb8ad6409 --- /dev/null +++ b/lib/ssh/doc/standard/draft-ietf-secsh-connect-18.txt @@ -0,0 +1,1232 @@ + + + +Network Working Group T. Ylonen +Internet-Draft SSH Communications Security Corp +Expires: March 31, 2004 D. Moffat, Editor, Ed. + Sun Microsystems, Inc + Oct 2003 + + + SSH Connection Protocol + draft-ietf-secsh-connect-18.txt + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that other + groups may also distribute working documents as Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at http:// + www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on March 31, 2004. + +Copyright Notice + + Copyright (C) The Internet Society (2003). All Rights Reserved. + +Abstract + + SSH is a protocol for secure remote login and other secure network + services over an insecure network. + + This document describes the SSH Connection Protocol. It provides + interactive login sessions, remote execution of commands, forwarded + TCP/IP connections, and forwarded X11 connections. All of these + channels are multiplexed into a single encrypted tunnel. + + The SSH Connection Protocol has been designed to run on top of the + SSH transport layer and user authentication protocols. + + + + +Ylonen & Moffat, Editor Expires March 31, 2004 [Page 1] + +Internet-Draft SSH Connection Protocol Oct 2003 + + +Table of Contents + + 1. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3. Conventions Used in This Document . . . . . . . . . . . . . 3 + 4. Global Requests . . . . . . . . . . . . . . . . . . . . . . 3 + 5. Channel Mechanism . . . . . . . . . . . . . . . . . . . . . 4 + 5.1 Opening a Channel . . . . . . . . . . . . . . . . . . . . . 4 + 5.2 Data Transfer . . . . . . . . . . . . . . . . . . . . . . . 5 + 5.3 Closing a Channel . . . . . . . . . . . . . . . . . . . . . 6 + 5.4 Channel-Specific Requests . . . . . . . . . . . . . . . . . 7 + 6. Interactive Sessions . . . . . . . . . . . . . . . . . . . . 8 + 6.1 Opening a Session . . . . . . . . . . . . . . . . . . . . . 8 + 6.2 Requesting a Pseudo-Terminal . . . . . . . . . . . . . . . . 8 + 6.3 X11 Forwarding . . . . . . . . . . . . . . . . . . . . . . . 9 + 6.3.1 Requesting X11 Forwarding . . . . . . . . . . . . . . . . . 9 + 6.3.2 X11 Channels . . . . . . . . . . . . . . . . . . . . . . . . 10 + 6.4 Environment Variable Passing . . . . . . . . . . . . . . . . 10 + 6.5 Starting a Shell or a Command . . . . . . . . . . . . . . . 10 + 6.6 Session Data Transfer . . . . . . . . . . . . . . . . . . . 11 + 6.7 Window Dimension Change Message . . . . . . . . . . . . . . 12 + 6.8 Local Flow Control . . . . . . . . . . . . . . . . . . . . . 12 + 6.9 Signals . . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 6.10 Returning Exit Status . . . . . . . . . . . . . . . . . . . 13 + 7. TCP/IP Port Forwarding . . . . . . . . . . . . . . . . . . . 14 + 7.1 Requesting Port Forwarding . . . . . . . . . . . . . . . . . 14 + 7.2 TCP/IP Forwarding Channels . . . . . . . . . . . . . . . . . 15 + 8. Encoding of Terminal Modes . . . . . . . . . . . . . . . . . 16 + 9. Summary of Message Numbers . . . . . . . . . . . . . . . . . 18 + 10. Security Considerations . . . . . . . . . . . . . . . . . . 18 + 11. iana cONSiderations . . . . . . . . . . . . . . . . . . . . 19 + 12. Intellectual Property . . . . . . . . . . . . . . . . . . . 19 + Normative References . . . . . . . . . . . . . . . . . . . . 19 + Informative References . . . . . . . . . . . . . . . . . . . 20 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 20 + Intellectual Property and Copyright Statements . . . . . . . 21 + + + + + + + + + + + + + + + +Ylonen & Moffat, Editor Expires March 31, 2004 [Page 2] + +Internet-Draft SSH Connection Protocol Oct 2003 + + +1. Contributors + + The major original contributors of this document were: Tatu Ylonen, + Tero Kivinen, Timo J. Rinne, Sami Lehtinen (all of SSH Communications + Security Corp), and Markku-Juhani O. Saarinen (University of + Jyvaskyla) + + The document editor is: [email protected]. Comments on this + internet draft should be sent to the IETF SECSH working group, + details at: http://ietf.org/html.charters/secsh-charter.html + +2. Introduction + + The SSH Connection Protocol has been designed to run on top of the + SSH transport layer and user authentication protocols. It provides + interactive login sessions, remote execution of commands, forwarded + TCP/IP connections, and forwarded X11 connections. The service name + for this protocol is "ssh-connection". + + This document should be read only after reading the SSH architecture + document [SSH-ARCH]. This document freely uses terminology and + notation from the architecture document without reference or further + explanation. + +3. Conventions Used in This Document + + The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", + and "MAY" that appear in this document are to be interpreted as + described in [RFC2119]. + + The used data types and terminology are specified in the architecture + document [SSH-ARCH]. + + The architecture document also discusses the algorithm naming + conventions that MUST be used with the SSH protocols. + +4. Global Requests + + There are several kinds of requests that affect the state of the + remote end "globally", independent of any channels. An example is a + request to start TCP/IP forwarding for a specific port. All such + requests use the following format. + + byte SSH_MSG_GLOBAL_REQUEST + string request name (restricted to US-ASCII) + boolean want reply + ... request-specific data follows + + + + +Ylonen & Moffat, Editor Expires March 31, 2004 [Page 3] + +Internet-Draft SSH Connection Protocol Oct 2003 + + + Request names follow the DNS extensibility naming convention outlined + in [SSH-ARCH]. + + The recipient will respond to this message with + SSH_MSG_REQUEST_SUCCESS or SSH_MSG_REQUEST_FAILURE if `want reply' is + TRUE. + + byte SSH_MSG_REQUEST_SUCCESS + ..... response specific data + + Usually the response specific data is non-existent. + + If the recipient does not recognize or support the request, it simply + responds with SSH_MSG_REQUEST_FAILURE. + + byte SSH_MSG_REQUEST_FAILURE + + +5. Channel Mechanism + + All terminal sessions, forwarded connections, etc. are channels. + Either side may open a channel. Multiple channels are multiplexed + into a single connection. + + Channels are identified by numbers at each end. The number referring + to a channel may be different on each side. Requests to open a + channel contain the sender's channel number. Any other + channel-related messages contain the recipient's channel number for + the channel. + + Channels are flow-controlled. No data may be sent to a channel until + a message is received to indicate that window space is available. + +5.1 Opening a Channel + + When either side wishes to open a new channel, it allocates a local + number for the channel. It then sends the following message to the + other side, and includes the local channel number and initial window + size in the message. + + byte SSH_MSG_CHANNEL_OPEN + string channel type (restricted to US-ASCII) + uint32 sender channel + uint32 initial window size + uint32 maximum packet size + ... channel type specific data follows + + The channel type is a name as described in the SSH architecture + + + +Ylonen & Moffat, Editor Expires March 31, 2004 [Page 4] + +Internet-Draft SSH Connection Protocol Oct 2003 + + + document, with similar extension mechanisms. `sender channel' is a + local identifier for the channel used by the sender of this message. + `initial window size' specifies how many bytes of channel data can be + sent to the sender of this message without adjusting the window. + `Maximum packet size' specifies the maximum size of an individual + data packet that can be sent to the sender (for example, one might + want to use smaller packets for interactive connections to get better + interactive response on slow links). + + The remote side then decides whether it can open the channel, and + responds with either + + byte SSH_MSG_CHANNEL_OPEN_CONFIRMATION + uint32 recipient channel + uint32 sender channel + uint32 initial window size + uint32 maximum packet size + ... channel type specific data follows + + where `recipient channel' is the channel number given in the original + open request, and `sender channel' is the channel number allocated by + the other side, or + + byte SSH_MSG_CHANNEL_OPEN_FAILURE + uint32 recipient channel + uint32 reason code + string additional textual information (ISO-10646 UTF-8 [RFC2279]) + string language tag (as defined in [RFC3066]) + + If the recipient of the SSH_MSG_CHANNEL_OPEN message does not support + the specified channel type, it simply responds with + SSH_MSG_CHANNEL_OPEN_FAILURE. The client MAY show the additional + information to the user. If this is done, the client software should + take the precautions discussed in [SSH-ARCH]. + + The following reason codes are defined: + + #define SSH_OPEN_ADMINISTRATIVELY_PROHIBITED 1 + #define SSH_OPEN_CONNECT_FAILED 2 + #define SSH_OPEN_UNKNOWN_CHANNEL_TYPE 3 + #define SSH_OPEN_RESOURCE_SHORTAGE 4 + + +5.2 Data Transfer + + The window size specifies how many bytes the other party can send + before it must wait for the window to be adjusted. Both parties use + the following message to adjust the window. + + + +Ylonen & Moffat, Editor Expires March 31, 2004 [Page 5] + +Internet-Draft SSH Connection Protocol Oct 2003 + + + byte SSH_MSG_CHANNEL_WINDOW_ADJUST + uint32 recipient channel + uint32 bytes to add + + After receiving this message, the recipient MAY send the given number + of bytes more than it was previously allowed to send; the window size + is incremented. + + Data transfer is done with messages of the following type. + + byte SSH_MSG_CHANNEL_DATA + uint32 recipient channel + string data + + The maximum amount of data allowed is the current window size. The + window size is decremented by the amount of data sent. Both parties + MAY ignore all extra data sent after the allowed window is empty. + + Additionally, some channels can transfer several types of data. An + example of this is stderr data from interactive sessions. Such data + can be passed with SSH_MSG_CHANNEL_EXTENDED_DATA messages, where a + separate integer specifies the type of the data. The available types + and their interpretation depend on the type of the channel. + + byte SSH_MSG_CHANNEL_EXTENDED_DATA + uint32 recipient_channel + uint32 data_type_code + string data + + Data sent with these messages consumes the same window as ordinary + data. + + Currently, only the following type is defined. + + #define SSH_EXTENDED_DATA_STDERR 1 + + +5.3 Closing a Channel + + When a party will no longer send more data to a channel, it SHOULD + send SSH_MSG_CHANNEL_EOF. + + byte SSH_MSG_CHANNEL_EOF + uint32 recipient_channel + + No explicit response is sent to this message; however, the + application may send EOF to whatever is at the other end of the + channel. Note that the channel remains open after this message, and + + + +Ylonen & Moffat, Editor Expires March 31, 2004 [Page 6] + +Internet-Draft SSH Connection Protocol Oct 2003 + + + more data may still be sent in the other direction. This message + does not consume window space and can be sent even if no window space + is available. + + When either party wishes to terminate the channel, it sends + SSH_MSG_CHANNEL_CLOSE. Upon receiving this message, a party MUST + send back a SSH_MSG_CHANNEL_CLOSE unless it has already sent this + message for the channel. The channel is considered closed for a + party when it has both sent and received SSH_MSG_CHANNEL_CLOSE, and + the party may then reuse the channel number. A party MAY send + SSH_MSG_CHANNEL_CLOSE without having sent or received + SSH_MSG_CHANNEL_EOF. + + byte SSH_MSG_CHANNEL_CLOSE + uint32 recipient_channel + + This message does not consume window space and can be sent even if no + window space is available. + + It is recommended that any data sent before this message is delivered + to the actual destination, if possible. + +5.4 Channel-Specific Requests + + Many channel types have extensions that are specific to that + particular channel type. An example is requesting a pty (pseudo + terminal) for an interactive session. + + All channel-specific requests use the following format. + + byte SSH_MSG_CHANNEL_REQUEST + uint32 recipient channel + string request type (restricted to US-ASCII) + boolean want reply + ... type-specific data + + If want reply is FALSE, no response will be sent to the request. + Otherwise, the recipient responds with either SSH_MSG_CHANNEL_SUCCESS + or SSH_MSG_CHANNEL_FAILURE, or request-specific continuation + messages. If the request is not recognized or is not supported for + the channel, SSH_MSG_CHANNEL_FAILURE is returned. + + This message does not consume window space and can be sent even if no + window space is available. Request types are local to each channel + type. + + The client is allowed to send further messages without waiting for + the response to the request. + + + +Ylonen & Moffat, Editor Expires March 31, 2004 [Page 7] + +Internet-Draft SSH Connection Protocol Oct 2003 + + + request type names follow the DNS extensibility naming convention + outlined in [SSH-ARCH] + + byte SSH_MSG_CHANNEL_SUCCESS + uint32 recipient_channel + + + byte SSH_MSG_CHANNEL_FAILURE + uint32 recipient_channel + + These messages do not consume window space and can be sent even if no + window space is available. + +6. Interactive Sessions + + A session is a remote execution of a program. The program may be a + shell, an application, a system command, or some built-in subsystem. + It may or may not have a tty, and may or may not involve X11 + forwarding. Multiple sessions can be active simultaneously. + +6.1 Opening a Session + + A session is started by sending the following message. + + byte SSH_MSG_CHANNEL_OPEN + string "session" + uint32 sender channel + uint32 initial window size + uint32 maximum packet size + + Client implementations SHOULD reject any session channel open + requests to make it more difficult for a corrupt server to attack the + client. + +6.2 Requesting a Pseudo-Terminal + + A pseudo-terminal can be allocated for the session by sending the + following message. + + byte SSH_MSG_CHANNEL_REQUEST + uint32 recipient_channel + string "pty-req" + boolean want_reply + string TERM environment variable value (e.g., vt100) + uint32 terminal width, characters (e.g., 80) + uint32 terminal height, rows (e.g., 24) + uint32 terminal width, pixels (e.g., 640) + uint32 terminal height, pixels (e.g., 480) + + + +Ylonen & Moffat, Editor Expires March 31, 2004 [Page 8] + +Internet-Draft SSH Connection Protocol Oct 2003 + + + string encoded terminal modes + + The encoding of terminal modes is described in Section Encoding of + Terminal Modes (Section 8). Zero dimension parameters MUST be + ignored. The character/row dimensions override the pixel dimensions + (when nonzero). Pixel dimensions refer to the drawable area of the + window. + + The dimension parameters are only informational. + + The client SHOULD ignore pty requests. + +6.3 X11 Forwarding + +6.3.1 Requesting X11 Forwarding + + X11 forwarding may be requested for a session by sending + + byte SSH_MSG_CHANNEL_REQUEST + uint32 recipient channel + string "x11-req" + boolean want reply + boolean single connection + string x11 authentication protocol + string x11 authentication cookie + uint32 x11 screen number + + It is recommended that the authentication cookie that is sent be a + fake, random cookie, and that the cookie is checked and replaced by + the real cookie when a connection request is received. + + X11 connection forwarding should stop when the session channel is + closed; however, already opened forwardings should not be + automatically closed when the session channel is closed. + + If `single connection' is TRUE, only a single connection should be + forwarded. No more connections will be forwarded after the first, or + after the session channel has been closed. + + The "x11 authentication protocol" is the name of the X11 + authentication method used, e.g. "MIT-MAGIC-COOKIE-1". + + The x11 authentication cookie MUST be hexadecimal encoded. + + X Protocol is documented in [SCHEIFLER]. + + + + + + +Ylonen & Moffat, Editor Expires March 31, 2004 [Page 9] + +Internet-Draft SSH Connection Protocol Oct 2003 + + +6.3.2 X11 Channels + + X11 channels are opened with a channel open request. The resulting + channels are independent of the session, and closing the session + channel does not close the forwarded X11 channels. + + byte SSH_MSG_CHANNEL_OPEN + string "x11" + uint32 sender channel + uint32 initial window size + uint32 maximum packet size + string originator address (e.g. "192.168.7.38") + uint32 originator port + + The recipient should respond with SSH_MSG_CHANNEL_OPEN_CONFIRMATION + or SSH_MSG_CHANNEL_OPEN_FAILURE. + + Implementations MUST reject any X11 channel open requests if they + have not requested X11 forwarding. + +6.4 Environment Variable Passing + + Environment variables may be passed to the shell/command to be + started later. Uncontrolled setting of environment variables in a + privileged process can be a security hazard. It is recommended that + implementations either maintain a list of allowable variable names or + only set environment variables after the server process has dropped + sufficient privileges. + + byte SSH_MSG_CHANNEL_REQUEST + uint32 recipient channel + string "env" + boolean want reply + string variable name + string variable value + + +6.5 Starting a Shell or a Command + + Once the session has been set up, a program is started at the remote + end. The program can be a shell, an application program or a + subsystem with a host-independent name. Only one of these requests + can succeed per channel. + + byte SSH_MSG_CHANNEL_REQUEST + uint32 recipient channel + string "shell" + boolean want reply + + + +Ylonen & Moffat, Editor Expires March 31, 2004 [Page 10] + +Internet-Draft SSH Connection Protocol Oct 2003 + + + This message will request the user's default shell (typically defined + in /etc/passwd in UNIX systems) to be started at the other end. + + byte SSH_MSG_CHANNEL_REQUEST + uint32 recipient channel + string "exec" + boolean want reply + string command + + This message will request the server to start the execution of the + given command. The command string may contain a path. Normal + precautions MUST be taken to prevent the execution of unauthorized + commands. + + byte SSH_MSG_CHANNEL_REQUEST + uint32 recipient channel + string "subsystem" + boolean want reply + string subsystem name + + This last form executes a predefined subsystem. It is expected that + these will include a general file transfer mechanism, and possibly + other features. Implementations may also allow configuring more such + mechanisms. As the user's shell is usually used to execute the + subsystem, it is advisable for the subsystem protocol to have a + "magic cookie" at the beginning of the protocol transaction to + distinguish it from arbitrary output generated by shell + initialization scripts etc. This spurious output from the shell may + be filtered out either at the server or at the client. + + The server SHOULD not halt the execution of the protocol stack when + starting a shell or a program. All input and output from these SHOULD + be redirected to the channel or to the encrypted tunnel. + + It is RECOMMENDED to request and check the reply for these messages. + The client SHOULD ignore these messages. + + Subsystem names follow the DNS extensibility naming convention + outlined in [SSH-ARCH]. + +6.6 Session Data Transfer + + Data transfer for a session is done using SSH_MSG_CHANNEL_DATA and + SSH_MSG_CHANNEL_EXTENDED_DATA packets and the window mechanism. The + extended data type SSH_EXTENDED_DATA_STDERR has been defined for + stderr data. + + + + + +Ylonen & Moffat, Editor Expires March 31, 2004 [Page 11] + +Internet-Draft SSH Connection Protocol Oct 2003 + + +6.7 Window Dimension Change Message + + When the window (terminal) size changes on the client side, it MAY + send a message to the other side to inform it of the new dimensions. + + byte SSH_MSG_CHANNEL_REQUEST + uint32 recipient_channel + string "window-change" + boolean FALSE + uint32 terminal width, columns + uint32 terminal height, rows + uint32 terminal width, pixels + uint32 terminal height, pixels + + No response SHOULD be sent to this message. + +6.8 Local Flow Control + + On many systems, it is possible to determine if a pseudo-terminal is + using control-S/control-Q flow control. When flow control is + allowed, it is often desirable to do the flow control at the client + end to speed up responses to user requests. This is facilitated by + the following notification. Initially, the server is responsible for + flow control. (Here, again, client means the side originating the + session, and server means the other side.) + + The message below is used by the server to inform the client when it + can or cannot perform flow control (control-S/control-Q processing). + If `client can do' is TRUE, the client is allowed to do flow control + using control-S and control-Q. The client MAY ignore this message. + + byte SSH_MSG_CHANNEL_REQUEST + uint32 recipient channel + string "xon-xoff" + boolean FALSE + boolean client can do + + No response is sent to this message. + +6.9 Signals + + A signal can be delivered to the remote process/service using the + following message. Some systems may not implement signals, in which + case they SHOULD ignore this message. + + byte SSH_MSG_CHANNEL_REQUEST + uint32 recipient channel + string "signal" + + + +Ylonen & Moffat, Editor Expires March 31, 2004 [Page 12] + +Internet-Draft SSH Connection Protocol Oct 2003 + + + boolean FALSE + string signal name without the "SIG" prefix. + + Signal names will be encoded as discussed in the "exit-signal" + SSH_MSG_CHANNEL_REQUEST. + +6.10 Returning Exit Status + + When the command running at the other end terminates, the following + message can be sent to return the exit status of the command. + Returning the status is RECOMMENDED. No acknowledgment is sent for + this message. The channel needs to be closed with + SSH_MSG_CHANNEL_CLOSE after this message. + + The client MAY ignore these messages. + + byte SSH_MSG_CHANNEL_REQUEST + uint32 recipient_channel + string "exit-status" + boolean FALSE + uint32 exit_status + + The remote command may also terminate violently due to a signal. + Such a condition can be indicated by the following message. A zero + exit_status usually means that the command terminated successfully. + + byte SSH_MSG_CHANNEL_REQUEST + uint32 recipient channel + string "exit-signal" + boolean FALSE + string signal name without the "SIG" prefix. + boolean core dumped + string error message (ISO-10646 UTF-8) + string language tag (as defined in [RFC3066]) + + The signal name is one of the following (these are from [POSIX]) + + ABRT + ALRM + FPE + HUP + ILL + INT + KILL + PIPE + QUIT + SEGV + TERM + + + +Ylonen & Moffat, Editor Expires March 31, 2004 [Page 13] + +Internet-Draft SSH Connection Protocol Oct 2003 + + + USR1 + USR2 + + Additional signal names MAY be sent in the format "sig-name@xyz", + where `sig-name' and `xyz' may be anything a particular implementor + wants (except the `@' sign). However, it is suggested that if a + `configure' script is used, the non-standard signal names it finds be + encoded as "[email protected]", where `SIG' is the signal name + without the "SIG" prefix, and `xyz' be the host type, as determined + by `config.guess'. + + The `error message' contains an additional explanation of the error + message. The message may consist of multiple lines. The client + software MAY display this message to the user. If this is done, the + client software should take the precautions discussed in [SSH-ARCH]. + +7. TCP/IP Port Forwarding + +7.1 Requesting Port Forwarding + + A party need not explicitly request forwardings from its own end to + the other direction. However, if it wishes that connections to a + port on the other side be forwarded to the local side, it must + explicitly request this. + + + byte SSH_MSG_GLOBAL_REQUEST + string "tcpip-forward" + boolean want reply + string address to bind (e.g. "0.0.0.0") + uint32 port number to bind + + `Address to bind' and `port number to bind' specify the IP address + and port to which the socket to be listened is bound. The address + should be "0.0.0.0" if connections are allowed from anywhere. (Note + that the client can still filter connections based on information + passed in the open request.) + + Implementations should only allow forwarding privileged ports if the + user has been authenticated as a privileged user. + + Client implementations SHOULD reject these messages; they are + normally only sent by the client. + + + If a client passes 0 as port number to bind and has want reply TRUE + then the server allocates the next available unprivileged port number + and replies with the following message, otherwise there is no + + + +Ylonen & Moffat, Editor Expires March 31, 2004 [Page 14] + +Internet-Draft SSH Connection Protocol Oct 2003 + + + response specific data. + + + byte SSH_MSG_GLOBAL_REQUEST_SUCCESS + uint32 port that was bound on the server + + A port forwarding can be cancelled with the following message. Note + that channel open requests may be received until a reply to this + message is received. + + byte SSH_MSG_GLOBAL_REQUEST + string "cancel-tcpip-forward" + boolean want reply + string address_to_bind (e.g. "127.0.0.1") + uint32 port number to bind + + Client implementations SHOULD reject these messages; they are + normally only sent by the client. + +7.2 TCP/IP Forwarding Channels + + When a connection comes to a port for which remote forwarding has + been requested, a channel is opened to forward the port to the other + side. + + byte SSH_MSG_CHANNEL_OPEN + string "forwarded-tcpip" + uint32 sender channel + uint32 initial window size + uint32 maximum packet size + string address that was connected + uint32 port that was connected + string originator IP address + uint32 originator port + + Implementations MUST reject these messages unless they have + previously requested a remote TCP/IP port forwarding with the given + port number. + + When a connection comes to a locally forwarded TCP/IP port, the + following packet is sent to the other side. Note that these messages + MAY be sent also for ports for which no forwarding has been + explicitly requested. The receiving side must decide whether to + allow the forwarding. + + byte SSH_MSG_CHANNEL_OPEN + string "direct-tcpip" + uint32 sender channel + + + +Ylonen & Moffat, Editor Expires March 31, 2004 [Page 15] + +Internet-Draft SSH Connection Protocol Oct 2003 + + + uint32 initial window size + uint32 maximum packet size + string host to connect + uint32 port to connect + string originator IP address + uint32 originator port + + `Host to connect' and `port to connect' specify the TCP/IP host and + port where the recipient should connect the channel. `Host to + connect' may be either a domain name or a numeric IP address. + + `Originator IP address' is the numeric IP address of the machine + where the connection request comes from, and `originator port' is the + port on the originator host from where the connection came from. + + Forwarded TCP/IP channels are independent of any sessions, and + closing a session channel does not in any way imply that forwarded + connections should be closed. + + Client implementations SHOULD reject direct TCP/IP open requests for + security reasons. + +8. Encoding of Terminal Modes + + Terminal modes (as passed in a pty request) are encoded into a byte + stream. It is intended that the coding be portable across different + environments. + + The tty mode description is a stream of bytes. The stream consists + of opcode-argument pairs. It is terminated by opcode TTY_OP_END (0). + Opcodes 1 to 159 have a single uint32 argument. Opcodes 160 to 255 + are not yet defined, and cause parsing to stop (they should only be + used after any other data). + + The client SHOULD put in the stream any modes it knows about, and the + server MAY ignore any modes it does not know about. This allows some + degree of machine-independence, at least between systems that use a + POSIX-like tty interface. The protocol can support other systems as + well, but the client may need to fill reasonable values for a number + of parameters so the server pty gets set to a reasonable mode (the + server leaves all unspecified mode bits in their default values, and + only some combinations make sense). + + The following opcodes have been defined. The naming of opcodes + mostly follows the POSIX terminal mode flags. + + 0 TTY_OP_END Indicates end of options. + 1 VINTR Interrupt character; 255 if none. Similarly for the + + + +Ylonen & Moffat, Editor Expires March 31, 2004 [Page 16] + +Internet-Draft SSH Connection Protocol Oct 2003 + + + other characters. Not all of these characters are + supported on all systems. + 2 VQUIT The quit character (sends SIGQUIT signal on POSIX + systems). + 3 VERASE Erase the character to left of the cursor. + 4 VKILL Kill the current input line. + 5 VEOF End-of-file character (sends EOF from the terminal). + 6 VEOL End-of-line character in addition to carriage return + and/or linefeed. + 7 VEOL2 Additional end-of-line character. + 8 VSTART Continues paused output (normally control-Q). + 9 VSTOP Pauses output (normally control-S). + 10 VSUSP Suspends the current program. + 11 VDSUSP Another suspend character. + 12 VREPRINT Reprints the current input line. + 13 VWERASE Erases a word left of cursor. + 14 VLNEXT Enter the next character typed literally, even if it + is a special character + 15 VFLUSH Character to flush output. + 16 VSWTCH Switch to a different shell layer. + 17 VSTATUS Prints system status line (load, command, pid etc). + 18 VDISCARD Toggles the flushing of terminal output. + 30 IGNPAR The ignore parity flag. The parameter SHOULD be 0 if + this flag is FALSE set, and 1 if it is TRUE. + 31 PARMRK Mark parity and framing errors. + 32 INPCK Enable checking of parity errors. + 33 ISTRIP Strip 8th bit off characters. + 34 INLCR Map NL into CR on input. + 35 IGNCR Ignore CR on input. + 36 ICRNL Map CR to NL on input. + 37 IUCLC Translate uppercase characters to lowercase. + 38 IXON Enable output flow control. + 39 IXANY Any char will restart after stop. + 40 IXOFF Enable input flow control. + 41 IMAXBEL Ring bell on input queue full. + 50 ISIG Enable signals INTR, QUIT, [D]SUSP. + 51 ICANON Canonicalize input lines. + 52 XCASE Enable input and output of uppercase characters by + preceding their lowercase equivalents with `\'. + 53 ECHO Enable echoing. + 54 ECHOE Visually erase chars. + 55 ECHOK Kill character discards current line. + 56 ECHONL Echo NL even if ECHO is off. + 57 NOFLSH Don't flush after interrupt. + 58 TOSTOP Stop background jobs from output. + 59 IEXTEN Enable extensions. + 60 ECHOCTL Echo control characters as ^(Char). + 61 ECHOKE Visual erase for line kill. + + + +Ylonen & Moffat, Editor Expires March 31, 2004 [Page 17] + +Internet-Draft SSH Connection Protocol Oct 2003 + + + 62 PENDIN Retype pending input. + 70 OPOST Enable output processing. + 71 OLCUC Convert lowercase to uppercase. + 72 ONLCR Map NL to CR-NL. + 73 OCRNL Translate carriage return to newline (output). + 74 ONOCR Translate newline to carriage return-newline + (output). + 75 ONLRET Newline performs a carriage return (output). + 90 CS7 7 bit mode. + 91 CS8 8 bit mode. + 92 PARENB Parity enable. + 93 PARODD Odd parity, else even. + + 128 TTY_OP_ISPEED Specifies the input baud rate in bits per second. + 129 TTY_OP_OSPEED Specifies the output baud rate in bits per second. + + +9. Summary of Message Numbers + + #define SSH_MSG_GLOBAL_REQUEST 80 + #define SSH_MSG_REQUEST_SUCCESS 81 + #define SSH_MSG_REQUEST_FAILURE 82 + #define SSH_MSG_CHANNEL_OPEN 90 + #define SSH_MSG_CHANNEL_OPEN_CONFIRMATION 91 + #define SSH_MSG_CHANNEL_OPEN_FAILURE 92 + #define SSH_MSG_CHANNEL_WINDOW_ADJUST 93 + #define SSH_MSG_CHANNEL_DATA 94 + #define SSH_MSG_CHANNEL_EXTENDED_DATA 95 + #define SSH_MSG_CHANNEL_EOF 96 + #define SSH_MSG_CHANNEL_CLOSE 97 + #define SSH_MSG_CHANNEL_REQUEST 98 + #define SSH_MSG_CHANNEL_SUCCESS 99 + #define SSH_MSG_CHANNEL_FAILURE 100 + + +10. Security Considerations + + This protocol is assumed to run on top of a secure, authenticated + transport. User authentication and protection against network-level + attacks are assumed to be provided by the underlying protocols. + + It is RECOMMENDED that implementations disable all the potentially + dangerous features (e.g. agent forwarding, X11 forwarding, and TCP/IP + forwarding) if the host key has changed. + + Full security considerations for this protocol are provided in + Section 8 of [SSH-ARCH] + + + + +Ylonen & Moffat, Editor Expires March 31, 2004 [Page 18] + +Internet-Draft SSH Connection Protocol Oct 2003 + + +11. iana cONSiderations + + This document is part of a set, the IANA considerations for the SSH + protocol as defined in [SSH-ARCH], [SSH-TRANS], [SSH-USERAUTH], + [SSH-CONNECT] are detailed in [SSH-NUMBERS]. + +12. Intellectual Property + + The IETF takes no position regarding the validity or scope of any + intellectual property or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; neither does it represent that it + has made any effort to identify any such rights. Information on the + IETF's procedures with respect to rights in standards-track and + standards-related documentation can be found in BCP-11. Copies of + claims of rights made available for publication and any assurances of + licenses to be made available, or the result of an attempt made to + obtain a general license or permission for the use of such + proprietary rights by implementers or users of this specification can + be obtained from the IETF Secretariat. + + The IETF has been notified of intellectual property rights claimed in + regard to some or all of the specification contained in this + document. For more information consult the online list of claimed + rights. + +Normative References + + [SSH-ARCH] + Ylonen, T., "SSH Protocol Architecture", I-D + draft-ietf-architecture-15.txt, Oct 2003. + + [SSH-TRANS] + Ylonen, T., "SSH Transport Layer Protocol", I-D + draft-ietf-transport-17.txt, Oct 2003. + + [SSH-USERAUTH] + Ylonen, T., "SSH Authentication Protocol", I-D + draft-ietf-userauth-18.txt, Oct 2003. + + [SSH-CONNECT] + Ylonen, T., "SSH Connection Protocol", I-D + draft-ietf-connect-18.txt, Oct 2003. + + [SSH-NUMBERS] + Lehtinen, S. and D. Moffat, "SSH Protocol Assigned + Numbers", I-D draft-ietf-secsh-assignednumbers-05.txt, Oct + + + +Ylonen & Moffat, Editor Expires March 31, 2004 [Page 19] + +Internet-Draft SSH Connection Protocol Oct 2003 + + + 2003. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + +Informative References + + [RFC3066] Alvestrand, H., "Tags for the Identification of + Languages", BCP 47, RFC 3066, January 2001. + + [RFC1884] Hinden, R. and S. Deering, "IP Version 6 Addressing + Architecture", RFC 1884, December 1995. + + [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO + 10646", RFC 2279, January 1998. + + [SCHEIFLER] + Scheifler, R., "X Window System : The Complete Reference + to Xlib, X Protocol, Icccm, Xlfd, 3rd edition.", Digital + Press ISBN 1555580882, Feburary 1992. + + [POSIX] ISO/IEC, 9945-1., "Information technology -- Portable + Operating System Interface (POSIX)-Part 1: System + Application Program Interface (API) C Language", ANSI/IEE + Std 1003.1, July 1996. + + +Authors' Addresses + + Tatu Ylonen + SSH Communications Security Corp + Fredrikinkatu 42 + HELSINKI FIN-00100 + Finland + + EMail: [email protected] + + + Darren J. Moffat (editor) + Sun Microsystems, Inc + 17 Network Circle + Menlo Park CA 94025 + USA + + EMail: [email protected] + + + + + + +Ylonen & Moffat, Editor Expires March 31, 2004 [Page 20] + +Internet-Draft SSH Connection Protocol Oct 2003 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + intellectual property or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; neither does it represent that it + has made any effort to identify any such rights. Information on the + IETF's procedures with respect to rights in standards-track and + standards-related documentation can be found in BCP-11. Copies of + claims of rights made available for publication and any assurances of + licenses to be made available, or the result of an attempt made to + obtain a general license or permission for the use of such + proprietary rights by implementors or users of this specification can + be obtained from the IETF Secretariat. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights which may cover technology that may be required to practice + this standard. Please address the information to the IETF Executive + Director. + + The IETF has been notified of intellectual property rights claimed in + regard to some or all of the specification contained in this + document. For more information consult the online list of claimed + rights. + + +Full Copyright Statement + + Copyright (C) The Internet Society (2003). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assignees. + + + +Ylonen & Moffat, Editor Expires March 31, 2004 [Page 21] + +Internet-Draft SSH Connection Protocol Oct 2003 + + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Ylonen & Moffat, Editor Expires March 31, 2004 [Page 22]
\ No newline at end of file diff --git a/lib/ssh/doc/standard/draft-ietf-secsh-filexfer-02.2.ps b/lib/ssh/doc/standard/draft-ietf-secsh-filexfer-02.2.ps new file mode 100644 index 0000000000..06c91bf8cd --- /dev/null +++ b/lib/ssh/doc/standard/draft-ietf-secsh-filexfer-02.2.ps @@ -0,0 +1,2853 @@ +%!PS-Adobe-3.0 +%%BoundingBox: 75 0 595 747 +%%Title: Enscript Output +%%For: Magnus Thoang +%%Creator: GNU enscript 1.6.1 +%%CreationDate: Wed Nov 12 12:26:07 2003 +%%Orientation: Portrait +%%Pages: 15 0 +%%DocumentMedia: A4 595 842 0 () () +%%DocumentNeededResources: (atend) +%%EndComments +%%BeginProlog +%%BeginProcSet: PStoPS 1 15 +userdict begin +[/showpage/erasepage/copypage]{dup where{pop dup load + type/operatortype eq{1 array cvx dup 0 3 index cvx put + bind def}{pop}ifelse}{pop}ifelse}forall +[/letter/legal/executivepage/a4/a4small/b5/com10envelope + /monarchenvelope/c5envelope/dlenvelope/lettersmall/note + /folio/quarto/a5]{dup where{dup wcheck{exch{}put} + {pop{}def}ifelse}{pop}ifelse}forall +/setpagedevice {pop}bind 1 index where{dup wcheck{3 1 roll put} + {pop def}ifelse}{def}ifelse +/PStoPSmatrix matrix currentmatrix def +/PStoPSxform matrix def/PStoPSclip{clippath}def +/defaultmatrix{PStoPSmatrix exch PStoPSxform exch concatmatrix}bind def +/initmatrix{matrix defaultmatrix setmatrix}bind def +/initclip[{matrix currentmatrix PStoPSmatrix setmatrix + [{currentpoint}stopped{$error/newerror false put{newpath}} + {/newpath cvx 3 1 roll/moveto cvx 4 array astore cvx}ifelse] + {[/newpath cvx{/moveto cvx}{/lineto cvx} + {/curveto cvx}{/closepath cvx}pathforall]cvx exch pop} + stopped{$error/errorname get/invalidaccess eq{cleartomark + $error/newerror false put cvx exec}{stop}ifelse}if}bind aload pop + /initclip dup load dup type dup/operatortype eq{pop exch pop} + {dup/arraytype eq exch/packedarraytype eq or + {dup xcheck{exch pop aload pop}{pop cvx}ifelse} + {pop cvx}ifelse}ifelse + {newpath PStoPSclip clip newpath exec setmatrix} bind aload pop]cvx def +/initgraphics{initmatrix newpath initclip 1 setlinewidth + 0 setlinecap 0 setlinejoin []0 setdash 0 setgray + 10 setmiterlimit}bind def +end +%%EndProcSet +%%BeginResource: procset Enscript-Prolog 1.6 1 +% +% Procedures. +% + +/_S { % save current state + /_s save def +} def +/_R { % restore from saved state + _s restore +} def + +/S { % showpage protecting gstate + gsave + showpage + grestore +} bind def + +/MF { % fontname newfontname -> - make a new encoded font + /newfontname exch def + /fontname exch def + + /fontdict fontname findfont def + /newfont fontdict maxlength dict def + + fontdict { + exch + dup /FID eq { + % skip FID pair + pop pop + } { + % copy to the new font dictionary + exch newfont 3 1 roll put + } ifelse + } forall + + newfont /FontName newfontname put + + % insert only valid encoding vectors + encoding_vector length 256 eq { + newfont /Encoding encoding_vector put + } if + + newfontname newfont definefont pop +} def + +/SF { % fontname width height -> - set a new font + /height exch def + /width exch def + + findfont + [width 0 0 height 0 0] makefont setfont +} def + +/SUF { % fontname width height -> - set a new user font + /height exch def + /width exch def + + /F-gs-user-font MF + /F-gs-user-font width height SF +} def + +/M {moveto} bind def +/s {show} bind def + +/Box { % x y w h -> - define box path + /d_h exch def /d_w exch def /d_y exch def /d_x exch def + d_x d_y moveto + d_w 0 rlineto + 0 d_h rlineto + d_w neg 0 rlineto + closepath +} def + +/bgs { % x y height blskip gray str -> - show string with bg color + /str exch def + /gray exch def + /blskip exch def + /height exch def + /y exch def + /x exch def + + gsave + x y blskip sub str stringwidth pop height Box + gray setgray + fill + grestore + x y M str s +} def + +% Highlight bars. +/highlight_bars { % nlines lineheight output_y_margin gray -> - + gsave + setgray + /ymarg exch def + /lineheight exch def + /nlines exch def + + % This 2 is just a magic number to sync highlight lines to text. + 0 d_header_y ymarg sub 2 sub translate + + /cw d_output_w cols div def + /nrows d_output_h ymarg 2 mul sub lineheight div cvi def + + % for each column + 0 1 cols 1 sub { + cw mul /xp exch def + + % for each rows + 0 1 nrows 1 sub { + /rn exch def + rn lineheight mul neg /yp exch def + rn nlines idiv 2 mod 0 eq { + % Draw highlight bar. 4 is just a magic indentation. + xp 4 add yp cw 8 sub lineheight neg Box fill + } if + } for + } for + + grestore +} def + +% Line highlight bar. +/line_highlight { % x y width height gray -> - + gsave + /gray exch def + Box gray setgray fill + grestore +} def + +% Column separator lines. +/column_lines { + gsave + .1 setlinewidth + 0 d_footer_h translate + /cw d_output_w cols div def + 1 1 cols 1 sub { + cw mul 0 moveto + 0 d_output_h rlineto stroke + } for + grestore +} def + +% Column borders. +/column_borders { + gsave + .1 setlinewidth + 0 d_footer_h moveto + 0 d_output_h rlineto + d_output_w 0 rlineto + 0 d_output_h neg rlineto + closepath stroke + grestore +} def + +% Do the actual underlay drawing +/draw_underlay { + ul_style 0 eq { + ul_str true charpath stroke + } { + ul_str show + } ifelse +} def + +% Underlay +/underlay { % - -> - + gsave + 0 d_page_h translate + d_page_h neg d_page_w atan rotate + + ul_gray setgray + ul_font setfont + /dw d_page_h dup mul d_page_w dup mul add sqrt def + ul_str stringwidth pop dw exch sub 2 div ul_h_ptsize -2 div moveto + draw_underlay + grestore +} def + +/user_underlay { % - -> - + gsave + ul_x ul_y translate + ul_angle rotate + ul_gray setgray + ul_font setfont + 0 0 ul_h_ptsize 2 div sub moveto + draw_underlay + grestore +} def + +% Page prefeed +/page_prefeed { % bool -> - + statusdict /prefeed known { + statusdict exch /prefeed exch put + } { + pop + } ifelse +} def + +% Wrapped line markers +/wrapped_line_mark { % x y charwith charheight type -> - + /type exch def + /h exch def + /w exch def + /y exch def + /x exch def + + type 2 eq { + % Black boxes (like TeX does) + gsave + 0 setlinewidth + x w 4 div add y M + 0 h rlineto w 2 div 0 rlineto 0 h neg rlineto + closepath fill + grestore + } { + type 3 eq { + % Small arrows + gsave + .2 setlinewidth + x w 2 div add y h 2 div add M + w 4 div 0 rlineto + x w 4 div add y lineto stroke + + x w 4 div add w 8 div add y h 4 div add M + x w 4 div add y lineto + w 4 div h 8 div rlineto stroke + grestore + } { + % do nothing + } ifelse + } ifelse +} def + +% EPSF import. + +/BeginEPSF { + /b4_Inc_state save def % Save state for cleanup + /dict_count countdictstack def % Count objects on dict stack + /op_count count 1 sub def % Count objects on operand stack + userdict begin + /showpage { } def + 0 setgray 0 setlinecap + 1 setlinewidth 0 setlinejoin + 10 setmiterlimit [ ] 0 setdash newpath + /languagelevel where { + pop languagelevel + 1 ne { + false setstrokeadjust false setoverprint + } if + } if +} bind def + +/EndEPSF { + count op_count sub { pos } repeat % Clean up stacks + countdictstack dict_count sub { end } repeat + b4_Inc_state restore +} bind def + +% Check PostScript language level. +/languagelevel where { + pop /gs_languagelevel languagelevel def +} { + /gs_languagelevel 1 def +} ifelse +%%EndResource +%%BeginResource: procset Enscript-Encoding-88591 1.6 1 +/encoding_vector [ +/.notdef /.notdef /.notdef /.notdef +/.notdef /.notdef /.notdef /.notdef +/.notdef /.notdef /.notdef /.notdef +/.notdef /.notdef /.notdef /.notdef +/.notdef /.notdef /.notdef /.notdef +/.notdef /.notdef /.notdef /.notdef +/.notdef /.notdef /.notdef /.notdef +/.notdef /.notdef /.notdef /.notdef +/space /exclam /quotedbl /numbersign +/dollar /percent /ampersand /quoteright +/parenleft /parenright /asterisk /plus +/comma /hyphen /period /slash +/zero /one /two /three +/four /five /six /seven +/eight /nine /colon /semicolon +/less /equal /greater /question +/at /A /B /C +/D /E /F /G +/H /I /J /K +/L /M /N /O +/P /Q /R /S +/T /U /V /W +/X /Y /Z /bracketleft +/backslash /bracketright /asciicircum /underscore +/quoteleft /a /b /c +/d /e /f /g +/h /i /j /k +/l /m /n /o +/p /q /r /s +/t /u /v /w +/x /y /z /braceleft +/bar /braceright /tilde /.notdef +/.notdef /.notdef /.notdef /.notdef +/.notdef /.notdef /.notdef /.notdef +/.notdef /.notdef /.notdef /.notdef +/.notdef /.notdef /.notdef /.notdef +/.notdef /.notdef /.notdef /.notdef +/.notdef /.notdef /.notdef /.notdef +/.notdef /.notdef /.notdef /.notdef +/.notdef /.notdef /.notdef /.notdef +/space /exclamdown /cent /sterling +/currency /yen /brokenbar /section +/dieresis /copyright /ordfeminine /guillemotleft +/logicalnot /hyphen /registered /macron +/degree /plusminus /twosuperior /threesuperior +/acute /mu /paragraph /bullet +/cedilla /onesuperior /ordmasculine /guillemotright +/onequarter /onehalf /threequarters /questiondown +/Agrave /Aacute /Acircumflex /Atilde +/Adieresis /Aring /AE /Ccedilla +/Egrave /Eacute /Ecircumflex /Edieresis +/Igrave /Iacute /Icircumflex /Idieresis +/Eth /Ntilde /Ograve /Oacute +/Ocircumflex /Otilde /Odieresis /multiply +/Oslash /Ugrave /Uacute /Ucircumflex +/Udieresis /Yacute /Thorn /germandbls +/agrave /aacute /acircumflex /atilde +/adieresis /aring /ae /ccedilla +/egrave /eacute /ecircumflex /edieresis +/igrave /iacute /icircumflex /idieresis +/eth /ntilde /ograve /oacute +/ocircumflex /otilde /odieresis /divide +/oslash /ugrave /uacute /ucircumflex +/udieresis /yacute /thorn /ydieresis +] def +%%EndResource +%%EndProlog +%%BeginSetup +%%IncludeResource: font Courier-Bold +%%IncludeResource: font Courier +/HFpt_w 10 def +/HFpt_h 10 def +/Courier-Bold /HF-gs-font MF +/HF /HF-gs-font findfont [HFpt_w 0 0 HFpt_h 0 0] makefont def +/Courier /F-gs-font MF +/F-gs-font 10 10 SF +/#copies 1 def +/d_page_w 520 def +/d_page_h 747 def +/d_header_x 0 def +/d_header_y 747 def +/d_header_w 520 def +/d_header_h 0 def +/d_footer_x 0 def +/d_footer_y 0 def +/d_footer_w 520 def +/d_footer_h 0 def +/d_output_w 520 def +/d_output_h 747 def +/cols 1 def +userdict/PStoPSxform PStoPSmatrix matrix currentmatrix + matrix invertmatrix matrix concatmatrix + matrix invertmatrix put +%%EndSetup +%%Page: (0,1) 1 +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 0.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +/showpage{}def/copypage{}def/erasepage{}def +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 1 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 701 M +(Network Working Group T. Ylonen) s +5 690 M +(Internet-Draft S. Lehtinen) s +5 679 M +(Expires: April 1, 2002 SSH Communications Security Corp) s +5 668 M +( October 2001) s +5 635 M +( SSH File Transfer Protocol) s +5 624 M +( draft-ietf-secsh-filexfer-02.txt) s +5 602 M +(Status of this Memo) s +5 580 M +( This document is an Internet-Draft and is in full conformance with) s +5 569 M +( all provisions of Section 10 of RFC2026.) s +5 547 M +( Internet-Drafts are working documents of the Internet Engineering) s +5 536 M +( Task Force \(IETF\), its areas, and its working groups. Note that) s +5 525 M +( other groups may also distribute working documents as Internet-) s +5 514 M +( Drafts.) s +5 492 M +( Internet-Drafts are draft documents valid for a maximum of six months) s +5 481 M +( and may be updated, replaced, or obsoleted by other documents at any) s +5 470 M +( time. It is inappropriate to use Internet-Drafts as reference) s +5 459 M +( material or to cite them other than as "work in progress.") s +5 437 M +( The list of current Internet-Drafts can be accessed at http://) s +5 426 M +( www.ietf.org/ietf/1id-abstracts.txt.) s +5 404 M +( The list of Internet-Draft Shadow Directories can be accessed at) s +5 393 M +( http://www.ietf.org/shadow.html.) s +5 371 M +( This Internet-Draft will expire on April 1, 2002.) s +5 349 M +(Copyright Notice) s +5 327 M +( Copyright \(C\) The Internet Society \(2001\). All Rights Reserved.) s +5 305 M +(Abstract) s +5 283 M +( The SSH File Transfer Protocol provides secure file transfer) s +5 272 M +( functionality over any reliable data stream. It is the standard file) s +5 261 M +( transfer protocol for use with the SSH2 protocol. This document) s +5 250 M +( describes the file transfer protocol and its interface to the SSH2) s +5 239 M +( protocol suite.) s +5 129 M +(Ylonen & Lehtinen Expires April 1, 2002 [Page 1]) s +_R +S +PStoPSsaved restore +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 421.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 2 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH File Transfer Protocol October 2001) s +5 690 M +(Table of Contents) s +5 668 M +( 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3) s +5 657 M +( 2. Use with the SSH Connection Protocol . . . . . . . . . . . . 4) s +5 646 M +( 3. General Packet Format . . . . . . . . . . . . . . . . . . . 5) s +5 635 M +( 4. Protocol Initialization . . . . . . . . . . . . . . . . . . 7) s +5 624 M +( 5. File Attributes . . . . . . . . . . . . . . . . . . . . . . 8) s +5 613 M +( 6. Requests From the Client to the Server . . . . . . . . . . . 10) s +5 602 M +( 6.1 Request Synchronization and Reordering . . . . . . . . . . . 10) s +5 591 M +( 6.2 File Names . . . . . . . . . . . . . . . . . . . . . . . . . 11) s +5 580 M +( 6.3 Opening, Creating, and Closing Files . . . . . . . . . . . . 11) s +5 569 M +( 6.4 Reading and Writing . . . . . . . . . . . . . . . . . . . . 13) s +5 558 M +( 6.5 Removing and Renaming Files . . . . . . . . . . . . . . . . 14) s +5 547 M +( 6.6 Creating and Deleting Directories . . . . . . . . . . . . . 15) s +5 536 M +( 6.7 Scanning Directories . . . . . . . . . . . . . . . . . . . . 15) s +5 525 M +( 6.8 Retrieving File Attributes . . . . . . . . . . . . . . . . . 16) s +5 514 M +( 6.9 Setting File Attributes . . . . . . . . . . . . . . . . . . 17) s +5 503 M +( 6.10 Dealing with Symbolic links . . . . . . . . . . . . . . . . 18) s +5 492 M +( 6.11 Canonicalizing the Server-Side Path Name . . . . . . . . . . 18) s +5 481 M +( 7. Responses from the Server to the Client . . . . . . . . . . 20) s +5 470 M +( 8. Vendor-Specific Extensions . . . . . . . . . . . . . . . . . 24) s +5 459 M +( 9. Security Considerations . . . . . . . . . . . . . . . . . . 25) s +5 448 M +( 10. Changes from previous protocol versions . . . . . . . . . . 26) s +5 437 M +( 10.1 Changes between versions 3 and 2 . . . . . . . . . . . . . . 26) s +5 426 M +( 10.2 Changes between versions 2 and 1 . . . . . . . . . . . . . . 26) s +5 415 M +( 10.3 Changes between versions 1 and 0 . . . . . . . . . . . . . . 26) s +5 404 M +( 11. Trademark Issues . . . . . . . . . . . . . . . . . . . . . . 27) s +5 393 M +( References . . . . . . . . . . . . . . . . . . . . . . . . . 28) s +5 382 M +( Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 28) s +5 371 M +( Full Copyright Statement . . . . . . . . . . . . . . . . . . 29) s +5 129 M +(Ylonen & Lehtinen Expires April 1, 2002 [Page 2]) s +_R +S +PStoPSsaved restore +%%Page: (2,3) 2 +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 0.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +/showpage{}def/copypage{}def/erasepage{}def +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 3 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH File Transfer Protocol October 2001) s +5 690 M +(1. Introduction) s +5 668 M +( This protocol provides secure file transfer \(and more generally file) s +5 657 M +( system access\) functionality over a reliable data stream, such as a) s +5 646 M +( channel in the SSH2 protocol [3].) s +5 624 M +( This protocol is designed so that it could be used to implement a) s +5 613 M +( secure remote file system service, as well as a secure file transfer) s +5 602 M +( service.) s +5 580 M +( This protocol assumes that it runs over a secure channel, and that) s +5 569 M +( the server has already authenticated the user at the client end, and) s +5 558 M +( that the identity of the client user is externally available to the) s +5 547 M +( server implementation.) s +5 525 M +( In general, this protocol follows a simple request-response model.) s +5 514 M +( Each request and response contains a sequence number and multiple) s +5 503 M +( requests may be pending simultaneously. There are a relatively large) s +5 492 M +( number of different request messages, but a small number of possible) s +5 481 M +( response messages. Each request has one or more response messages) s +5 470 M +( that may be returned in result \(e.g., a read either returns data or) s +5 459 M +( reports error status\).) s +5 437 M +( The packet format descriptions in this specification follow the) s +5 426 M +( notation presented in the secsh architecture draft.[3].) s +5 404 M +( Even though this protocol is described in the context of the SSH2) s +5 393 M +( protocol, this protocol is general and independent of the rest of the) s +5 382 M +( SSH2 protocol suite. It could be used in a number of different) s +5 371 M +( applications, such as secure file transfer over TLS RFC 2246 [1] and) s +5 360 M +( transfer of management information in VPN applications.) s +5 129 M +(Ylonen & Lehtinen Expires April 1, 2002 [Page 3]) s +_R +S +PStoPSsaved restore +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 421.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 4 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH File Transfer Protocol October 2001) s +5 690 M +(2. Use with the SSH Connection Protocol) s +5 668 M +( When used with the SSH2 Protocol suite, this protocol is intended to) s +5 657 M +( be used from the SSH Connection Protocol [5] as a subsystem, as) s +5 646 M +( described in section ``Starting a Shell or a Command''. The) s +5 635 M +( subsystem name used with this protocol is "sftp".) s +5 129 M +(Ylonen & Lehtinen Expires April 1, 2002 [Page 4]) s +_R +S +PStoPSsaved restore +%%Page: (4,5) 3 +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 0.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +/showpage{}def/copypage{}def/erasepage{}def +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 5 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH File Transfer Protocol October 2001) s +5 690 M +(3. General Packet Format) s +5 668 M +( All packets transmitted over the secure connection are of the) s +5 657 M +( following format:) s +5 635 M +( uint32 length) s +5 624 M +( byte type) s +5 613 M +( byte[length - 1] data payload) s +5 591 M +( That is, they are just data preceded by 32-bit length and 8-bit type) s +5 580 M +( fields. The `length' is the length of the data area, and does not) s +5 569 M +( include the `length' field itself. The format and interpretation of) s +5 558 M +( the data area depends on the packet type.) s +5 536 M +( All packet descriptions below only specify the packet type and the) s +5 525 M +( data that goes into the data field. Thus, they should be prefixed by) s +5 514 M +( the `length' and `type' fields.) s +5 492 M +( The maximum size of a packet is in practice determined by the client) s +5 481 M +( \(the maximum size of read or write requests that it sends, plus a few) s +5 470 M +( bytes of packet overhead\). All servers SHOULD support packets of at) s +5 459 M +( least 34000 bytes \(where the packet size refers to the full length,) s +5 448 M +( including the header above\). This should allow for reads and writes) s +5 437 M +( of at most 32768 bytes.) s +5 415 M +( There is no limit on the number of outstanding \(non-acknowledged\)) s +5 404 M +( requests that the client may send to the server. In practice this is) s +5 393 M +( limited by the buffering available on the data stream and the queuing) s +5 382 M +( performed by the server. If the server's queues are full, it should) s +5 371 M +( not read any more data from the stream, and flow control will prevent) s +5 360 M +( the client from sending more requests. Note, however, that while) s +5 349 M +( there is no restriction on the protocol level, the client's API may) s +5 338 M +( provide a limit in order to prevent infinite queuing of outgoing) s +5 327 M +( requests at the client.) s +5 129 M +(Ylonen & Lehtinen Expires April 1, 2002 [Page 5]) s +_R +S +PStoPSsaved restore +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 421.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 6 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH File Transfer Protocol October 2001) s +5 690 M +( The following values are defined for packet types.) s +5 668 M +( #define SSH_FXP_INIT 1) s +5 657 M +( #define SSH_FXP_VERSION 2) s +5 646 M +( #define SSH_FXP_OPEN 3) s +5 635 M +( #define SSH_FXP_CLOSE 4) s +5 624 M +( #define SSH_FXP_READ 5) s +5 613 M +( #define SSH_FXP_WRITE 6) s +5 602 M +( #define SSH_FXP_LSTAT 7) s +5 591 M +( #define SSH_FXP_FSTAT 8) s +5 580 M +( #define SSH_FXP_SETSTAT 9) s +5 569 M +( #define SSH_FXP_FSETSTAT 10) s +5 558 M +( #define SSH_FXP_OPENDIR 11) s +5 547 M +( #define SSH_FXP_READDIR 12) s +5 536 M +( #define SSH_FXP_REMOVE 13) s +5 525 M +( #define SSH_FXP_MKDIR 14) s +5 514 M +( #define SSH_FXP_RMDIR 15) s +5 503 M +( #define SSH_FXP_REALPATH 16) s +5 492 M +( #define SSH_FXP_STAT 17) s +5 481 M +( #define SSH_FXP_RENAME 18) s +5 470 M +( #define SSH_FXP_READLINK 19) s +5 459 M +( #define SSH_FXP_SYMLINK 20) s +5 448 M +( #define SSH_FXP_STATUS 101) s +5 437 M +( #define SSH_FXP_HANDLE 102) s +5 426 M +( #define SSH_FXP_DATA 103) s +5 415 M +( #define SSH_FXP_NAME 104) s +5 404 M +( #define SSH_FXP_ATTRS 105) s +5 393 M +( #define SSH_FXP_EXTENDED 200) s +5 382 M +( #define SSH_FXP_EXTENDED_REPLY 201) s +5 360 M +( Additional packet types should only be defined if the protocol) s +5 349 M +( version number \(see Section ``Protocol Initialization''\) is) s +5 338 M +( incremented, and their use MUST be negotiated using the version) s +5 327 M +( number. However, the SSH_FXP_EXTENDED and SSH_FXP_EXTENDED_REPLY) s +5 316 M +( packets can be used to implement vendor-specific extensions. See) s +5 305 M +( Section ``Vendor-Specific-Extensions'' for more details.) s +5 129 M +(Ylonen & Lehtinen Expires April 1, 2002 [Page 6]) s +_R +S +PStoPSsaved restore +%%Page: (6,7) 4 +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 0.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +/showpage{}def/copypage{}def/erasepage{}def +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 7 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH File Transfer Protocol October 2001) s +5 690 M +(4. Protocol Initialization) s +5 668 M +( When the file transfer protocol starts, it first sends a SSH_FXP_INIT) s +5 657 M +( \(including its version number\) packet to the server. The server) s +5 646 M +( responds with a SSH_FXP_VERSION packet, supplying the lowest of its) s +5 635 M +( own and the client's version number. Both parties should from then) s +5 624 M +( on adhere to particular version of the protocol.) s +5 602 M +( The SSH_FXP_INIT packet \(from client to server\) has the following) s +5 591 M +( data:) s +5 569 M +( uint32 version) s +5 558 M +( <extension data>) s +5 536 M +( The SSH_FXP_VERSION packet \(from server to client\) has the following) s +5 525 M +( data:) s +5 503 M +( uint32 version) s +5 492 M +( <extension data>) s +5 470 M +( The version number of the protocol specified in this document is 3.) s +5 459 M +( The version number should be incremented for each incompatible) s +5 448 M +( revision of this protocol.) s +5 426 M +( The extension data in the above packets may be empty, or may be a) s +5 415 M +( sequence of) s +5 393 M +( string extension_name) s +5 382 M +( string extension_data) s +5 360 M +( pairs \(both strings MUST always be present if one is, but the) s +5 349 M +( `extension_data' string may be of zero length\). If present, these) s +5 338 M +( strings indicate extensions to the baseline protocol. The) s +5 327 M +( `extension_name' field\(s\) identify the name of the extension. The) s +5 316 M +( name should be of the form "name@domain", where the domain is the DNS) s +5 305 M +( domain name of the organization defining the extension. Additional) s +5 294 M +( names that are not of this format may be defined later by the IETF.) s +5 283 M +( Implementations MUST silently ignore any extensions whose name they) s +5 272 M +( do not recognize.) s +5 129 M +(Ylonen & Lehtinen Expires April 1, 2002 [Page 7]) s +_R +S +PStoPSsaved restore +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 421.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 8 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH File Transfer Protocol October 2001) s +5 690 M +(5. File Attributes) s +5 668 M +( A new compound data type is defined for encoding file attributes. It) s +5 657 M +( is basically just a combination of elementary types, but is defined) s +5 646 M +( once because of the non-trivial description of the fields and to) s +5 635 M +( ensure maintainability.) s +5 613 M +( The same encoding is used both when returning file attributes from) s +5 602 M +( the server and when sending file attributes to the server. When) s +5 591 M +( sending it to the server, the flags field specifies which attributes) s +5 580 M +( are included, and the server will use default values for the) s +5 569 M +( remaining attributes \(or will not modify the values of remaining) s +5 558 M +( attributes\). When receiving attributes from the server, the flags) s +5 547 M +( specify which attributes are included in the returned data. The) s +5 536 M +( server normally returns all attributes it knows about.) s +5 514 M +( uint32 flags) s +5 503 M +( uint64 size present only if flag SSH_FILEXFER_ATTR_SIZE) s +5 492 M +( uint32 uid present only if flag SSH_FILEXFER_ATTR_UIDGID) s +5 481 M +( uint32 gid present only if flag SSH_FILEXFER_ATTR_UIDGID) s +5 470 M +( uint32 permissions present only if flag SSH_FILEXFER_ATTR_PERMISSIONS) s +5 459 M +( uint32 atime present only if flag SSH_FILEXFER_ACMODTIME) s +5 448 M +( uint32 mtime present only if flag SSH_FILEXFER_ACMODTIME) s +5 437 M +( uint32 extended_count present only if flag SSH_FILEXFER_ATTR_EXTENDED) s +5 426 M +( string extended_type) s +5 415 M +( string extended_data) s +5 404 M +( ... more extended data \(extended_type - extended_data pairs\),) s +5 393 M +( so that number of pairs equals extended_count) s +5 371 M +( The `flags' specify which of the fields are present. Those fields) s +5 360 M +( for which the corresponding flag is not set are not present \(not) s +5 349 M +( included in the packet\). New flags can only be added by incrementing) s +5 338 M +( the protocol version number \(or by using the extension mechanism) s +5 327 M +( described below\).) s +5 305 M +( The `size' field specifies the size of the file in bytes.) s +5 283 M +( The `uid' and `gid' fields contain numeric Unix-like user and group) s +5 272 M +( identifiers, respectively.) s +5 250 M +( The `permissions' field contains a bit mask of file permissions as) s +5 239 M +( defined by posix [1].) s +5 217 M +( The `atime' and `mtime' contain the access and modification times of) s +5 206 M +( the files, respectively. They are represented as seconds from Jan 1,) s +5 195 M +( 1970 in UTC.) s +5 173 M +( The SSH_FILEXFER_ATTR_EXTENDED flag provides a general extension) s +5 129 M +(Ylonen & Lehtinen Expires April 1, 2002 [Page 8]) s +_R +S +PStoPSsaved restore +%%Page: (8,9) 5 +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 0.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +/showpage{}def/copypage{}def/erasepage{}def +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 9 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH File Transfer Protocol October 2001) s +5 690 M +( mechanism for vendor-specific extensions. If the flag is specified,) s +5 679 M +( then the `extended_count' field is present. It specifies the number) s +5 668 M +( of extended_type-extended_data pairs that follow. Each of these) s +5 657 M +( pairs specifies an extended attribute. For each of the attributes,) s +5 646 M +( the extended_type field should be a string of the format) s +5 635 M +( "name@domain", where "domain" is a valid, registered domain name and) s +5 624 M +( "name" identifies the method. The IETF may later standardize certain) s +5 613 M +( names that deviate from this format \(e.g., that do not contain the) s +5 602 M +( "@" sign\). The interpretation of `extended_data' depends on the) s +5 591 M +( type. Implementations SHOULD ignore extended data fields that they) s +5 580 M +( do not understand.) s +5 558 M +( Additional fields can be added to the attributes by either defining) s +5 547 M +( additional bits to the flags field to indicate their presence, or by) s +5 536 M +( defining extended attributes for them. The extended attributes) s +5 525 M +( mechanism is recommended for most purposes; additional flags bits) s +5 514 M +( should only be defined by an IETF standards action that also) s +5 503 M +( increments the protocol version number. The use of such new fields) s +5 492 M +( MUST be negotiated by the version number in the protocol exchange.) s +5 481 M +( It is a protocol error if a packet with unsupported protocol bits is) s +5 470 M +( received.) s +5 448 M +( The flags bits are defined to have the following values:) s +5 426 M +( #define SSH_FILEXFER_ATTR_SIZE 0x00000001) s +5 415 M +( #define SSH_FILEXFER_ATTR_UIDGID 0x00000002) s +5 404 M +( #define SSH_FILEXFER_ATTR_PERMISSIONS 0x00000004) s +5 393 M +( #define SSH_FILEXFER_ATTR_ACMODTIME 0x00000008) s +5 382 M +( #define SSH_FILEXFER_ATTR_EXTENDED 0x80000000) s +5 129 M +(Ylonen & Lehtinen Expires April 1, 2002 [Page 9]) s +_R +S +PStoPSsaved restore +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 421.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 10 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH File Transfer Protocol October 2001) s +5 690 M +(6. Requests From the Client to the Server) s +5 668 M +( Requests from the client to the server represent the various file) s +5 657 M +( system operations. Each request begins with an `id' field, which is) s +5 646 M +( a 32-bit identifier identifying the request \(selected by the client\).) s +5 635 M +( The same identifier will be returned in the response to the request.) s +5 624 M +( One possible implementation of it is a monotonically increasing) s +5 613 M +( request sequence number \(modulo 2^32\).) s +5 591 M +( Many operations in the protocol operate on open files. The) s +5 580 M +( SSH_FXP_OPEN request can return a file handle \(which is an opaque) s +5 569 M +( variable-length string\) which may be used to access the file later) s +5 558 M +( \(e.g. in a read operation\). The client MUST NOT send requests the) s +5 547 M +( server with bogus or closed handles. However, the server MUST) s +5 536 M +( perform adequate checks on the handle in order to avoid security) s +5 525 M +( risks due to fabricated handles.) s +5 503 M +( This design allows either stateful and stateless server) s +5 492 M +( implementation, as well as an implementation which caches state) s +5 481 M +( between requests but may also flush it. The contents of the file) s +5 470 M +( handle string are entirely up to the server and its design. The) s +5 459 M +( client should not modify or attempt to interpret the file handle) s +5 448 M +( strings.) s +5 426 M +( The file handle strings MUST NOT be longer than 256 bytes.) s +5 404 M +(6.1 Request Synchronization and Reordering) s +5 382 M +( The protocol and implementations MUST process requests relating to) s +5 371 M +( the same file in the order in which they are received. In other) s +5 360 M +( words, if an application submits multiple requests to the server, the) s +5 349 M +( results in the responses will be the same as if it had sent the) s +5 338 M +( requests one at a time and waited for the response in each case. For) s +5 327 M +( example, the server may process non-overlapping read/write requests) s +5 316 M +( to the same file in parallel, but overlapping reads and writes cannot) s +5 305 M +( be reordered or parallelized. However, there are no ordering) s +5 294 M +( restrictions on the server for processing requests from two different) s +5 283 M +( file transfer connections. The server may interleave and parallelize) s +5 272 M +( them at will.) s +5 250 M +( There are no restrictions on the order in which responses to) s +5 239 M +( outstanding requests are delivered to the client, except that the) s +5 228 M +( server must ensure fairness in the sense that processing of no) s +5 217 M +( request will be indefinitely delayed even if the client is sending) s +5 206 M +( other requests so that there are multiple outstanding requests all) s +5 195 M +( the time.) s +5 129 M +(Ylonen & Lehtinen Expires April 1, 2002 [Page 10]) s +_R +S +PStoPSsaved restore +%%Page: (10,11) 6 +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 0.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +/showpage{}def/copypage{}def/erasepage{}def +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 11 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH File Transfer Protocol October 2001) s +5 690 M +(6.2 File Names) s +5 668 M +( This protocol represents file names as strings. File names are) s +5 657 M +( assumed to use the slash \('/'\) character as a directory separator.) s +5 635 M +( File names starting with a slash are "absolute", and are relative to) s +5 624 M +( the root of the file system. Names starting with any other character) s +5 613 M +( are relative to the user's default directory \(home directory\). Note) s +5 602 M +( that identifying the user is assumed to take place outside of this) s +5 591 M +( protocol.) s +5 569 M +( Servers SHOULD interpret a path name component ".." as referring to) s +5 558 M +( the parent directory, and "." as referring to the current directory.) s +5 547 M +( If the server implementation limits access to certain parts of the) s +5 536 M +( file system, it must be extra careful in parsing file names when) s +5 525 M +( enforcing such restrictions. There have been numerous reported) s +5 514 M +( security bugs where a ".." in a path name has allowed access outside) s +5 503 M +( the intended area.) s +5 481 M +( An empty path name is valid, and it refers to the user's default) s +5 470 M +( directory \(usually the user's home directory\).) s +5 448 M +( Otherwise, no syntax is defined for file names by this specification.) s +5 437 M +( Clients should not make any other assumptions; however, they can) s +5 426 M +( splice path name components returned by SSH_FXP_READDIR together) s +5 415 M +( using a slash \('/'\) as the separator, and that will work as expected.) s +5 393 M +( It is understood that the lack of well-defined semantics for file) s +5 382 M +( names may cause interoperability problems between clients and servers) s +5 371 M +( using radically different operating systems. However, this approach) s +5 360 M +( is known to work acceptably with most systems, and alternative) s +5 349 M +( approaches that e.g. treat file names as sequences of structured) s +5 338 M +( components are quite complicated.) s +5 316 M +(6.3 Opening, Creating, and Closing Files) s +5 294 M +( Files are opened and created using the SSH_FXP_OPEN message, whose) s +5 283 M +( data part is as follows:) s +5 261 M +( uint32 id) s +5 250 M +( string filename) s +5 239 M +( uint32 pflags) s +5 228 M +( ATTRS attrs) s +5 206 M +( The `id' field is the request identifier as for all requests.) s +5 184 M +( The `filename' field specifies the file name. See Section ``File) s +5 173 M +( Names'' for more information.) s +5 129 M +(Ylonen & Lehtinen Expires April 1, 2002 [Page 11]) s +_R +S +PStoPSsaved restore +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 421.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 12 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH File Transfer Protocol October 2001) s +5 690 M +( The `pflags' field is a bitmask. The following bits have been) s +5 679 M +( defined.) s +5 657 M +( #define SSH_FXF_READ 0x00000001) s +5 646 M +( #define SSH_FXF_WRITE 0x00000002) s +5 635 M +( #define SSH_FXF_APPEND 0x00000004) s +5 624 M +( #define SSH_FXF_CREAT 0x00000008) s +5 613 M +( #define SSH_FXF_TRUNC 0x00000010) s +5 602 M +( #define SSH_FXF_EXCL 0x00000020) s +5 580 M +( These have the following meanings:) s +5 558 M +( SSH_FXF_READ) s +5 547 M +( Open the file for reading.) s +5 525 M +( SSH_FXF_WRITE) s +5 514 M +( Open the file for writing. If both this and SSH_FXF_READ are) s +5 503 M +( specified, the file is opened for both reading and writing.) s +5 481 M +( SSH_FXF_APPEND) s +5 470 M +( Force all writes to append data at the end of the file.) s +5 448 M +( SSH_FXF_CREAT) s +5 437 M +( If this flag is specified, then a new file will be created if one) s +5 426 M +( does not already exist \(if O_TRUNC is specified, the new file will) s +5 415 M +( be truncated to zero length if it previously exists\).) s +5 393 M +( SSH_FXF_TRUNC) s +5 382 M +( Forces an existing file with the same name to be truncated to zero) s +5 371 M +( length when creating a file by specifying SSH_FXF_CREAT.) s +5 360 M +( SSH_FXF_CREAT MUST also be specified if this flag is used.) s +5 338 M +( SSH_FXF_EXCL) s +5 327 M +( Causes the request to fail if the named file already exists.) s +5 316 M +( SSH_FXF_CREAT MUST also be specified if this flag is used.) s +5 294 M +( The `attrs' field specifies the initial attributes for the file.) s +5 283 M +( Default values will be used for those attributes that are not) s +5 272 M +( specified. See Section ``File Attributes'' for more information.) s +5 250 M +( Regardless the server operating system, the file will always be) s +5 239 M +( opened in "binary" mode \(i.e., no translations between different) s +5 228 M +( character sets and newline encodings\).) s +5 206 M +( The response to this message will be either SSH_FXP_HANDLE \(if the) s +5 195 M +( operation is successful\) or SSH_FXP_STATUS \(if the operation fails\).) s +5 129 M +(Ylonen & Lehtinen Expires April 1, 2002 [Page 12]) s +_R +S +PStoPSsaved restore +%%Page: (12,13) 7 +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 0.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +/showpage{}def/copypage{}def/erasepage{}def +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 13 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH File Transfer Protocol October 2001) s +5 690 M +( A file is closed by using the SSH_FXP_CLOSE request. Its data field) s +5 679 M +( has the following format:) s +5 657 M +( uint32 id) s +5 646 M +( string handle) s +5 624 M +( where `id' is the request identifier, and `handle' is a handle) s +5 613 M +( previously returned in the response to SSH_FXP_OPEN or) s +5 602 M +( SSH_FXP_OPENDIR. The handle becomes invalid immediately after this) s +5 591 M +( request has been sent.) s +5 569 M +( The response to this request will be a SSH_FXP_STATUS message. One) s +5 558 M +( should note that on some server platforms even a close can fail.) s +5 547 M +( This can happen e.g. if the server operating system caches writes,) s +5 536 M +( and an error occurs while flushing cached writes during the close.) s +5 514 M +(6.4 Reading and Writing) s +5 492 M +( Once a file has been opened, it can be read using the SSH_FXP_READ) s +5 481 M +( message, which has the following format:) s +5 459 M +( uint32 id) s +5 448 M +( string handle) s +5 437 M +( uint64 offset) s +5 426 M +( uint32 len) s +5 404 M +( where `id' is the request identifier, `handle' is an open file handle) s +5 393 M +( returned by SSH_FXP_OPEN, `offset' is the offset \(in bytes\) relative) s +5 382 M +( to the beginning of the file from where to start reading, and `len') s +5 371 M +( is the maximum number of bytes to read.) s +5 349 M +( In response to this request, the server will read as many bytes as it) s +5 338 M +( can from the file \(up to `len'\), and return them in a SSH_FXP_DATA) s +5 327 M +( message. If an error occurs or EOF is encountered before reading any) s +5 316 M +( data, the server will respond with SSH_FXP_STATUS. For normal disk) s +5 305 M +( files, it is guaranteed that this will read the specified number of) s +5 294 M +( bytes, or up to end of file. For e.g. device files this may return) s +5 283 M +( fewer bytes than requested.) s +5 261 M +( Writing to a file is achieved using the SSH_FXP_WRITE message, which) s +5 250 M +( has the following format:) s +5 228 M +( uint32 id) s +5 217 M +( string handle) s +5 206 M +( uint64 offset) s +5 195 M +( string data) s +5 173 M +( where `id' is a request identifier, `handle' is a file handle) s +5 129 M +(Ylonen & Lehtinen Expires April 1, 2002 [Page 13]) s +_R +S +PStoPSsaved restore +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 421.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 14 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH File Transfer Protocol October 2001) s +5 690 M +( returned by SSH_FXP_OPEN, `offset' is the offset \(in bytes\) from the) s +5 679 M +( beginning of the file where to start writing, and `data' is the data) s +5 668 M +( to be written.) s +5 646 M +( The write will extend the file if writing beyond the end of the file.) s +5 635 M +( It is legal to write way beyond the end of the file; the semantics) s +5 624 M +( are to write zeroes from the end of the file to the specified offset) s +5 613 M +( and then the data. On most operating systems, such writes do not) s +5 602 M +( allocate disk space but instead leave "holes" in the file.) s +5 580 M +( The server responds to a write request with a SSH_FXP_STATUS message.) s +5 558 M +(6.5 Removing and Renaming Files) s +5 536 M +( Files can be removed using the SSH_FXP_REMOVE message. It has the) s +5 525 M +( following format:) s +5 503 M +( uint32 id) s +5 492 M +( string filename) s +5 470 M +( where `id' is the request identifier and `filename' is the name of) s +5 459 M +( the file to be removed. See Section ``File Names'' for more) s +5 448 M +( information. This request cannot be used to remove directories.) s +5 426 M +( The server will respond to this request with a SSH_FXP_STATUS) s +5 415 M +( message.) s +5 393 M +( Files \(and directories\) can be renamed using the SSH_FXP_RENAME) s +5 382 M +( message. Its data is as follows:) s +5 360 M +( uint32 id) s +5 349 M +( string oldpath) s +5 338 M +( string newpath) s +5 316 M +( where `id' is the request identifier, `oldpath' is the name of an) s +5 305 M +( existing file or directory, and `newpath' is the new name for the) s +5 294 M +( file or directory. It is an error if there already exists a file) s +5 283 M +( with the name specified by newpath. The server may also fail rename) s +5 272 M +( requests in other situations, for example if `oldpath' and `newpath') s +5 261 M +( point to different file systems on the server.) s +5 239 M +( The server will respond to this request with a SSH_FXP_STATUS) s +5 228 M +( message.) s +5 129 M +(Ylonen & Lehtinen Expires April 1, 2002 [Page 14]) s +_R +S +PStoPSsaved restore +%%Page: (14,15) 8 +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 0.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +/showpage{}def/copypage{}def/erasepage{}def +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 15 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH File Transfer Protocol October 2001) s +5 690 M +(6.6 Creating and Deleting Directories) s +5 668 M +( New directories can be created using the SSH_FXP_MKDIR request. It) s +5 657 M +( has the following format:) s +5 635 M +( uint32 id) s +5 624 M +( string path) s +5 613 M +( ATTRS attrs) s +5 591 M +( where `id' is the request identifier, `path' and `attrs' specifies) s +5 580 M +( the modifications to be made to its attributes. See Section ``File) s +5 569 M +( Names'' for more information on file names. Attributes are discussed) s +5 558 M +( in more detail in Section ``File Attributes''. specifies the) s +5 547 M +( directory to be created. An error will be returned if a file or) s +5 536 M +( directory with the specified path already exists. The server will) s +5 525 M +( respond to this request with a SSH_FXP_STATUS message.) s +5 503 M +( Directories can be removed using the SSH_FXP_RMDIR request, which) s +5 492 M +( has the following format:) s +5 470 M +( uint32 id) s +5 459 M +( string path) s +5 437 M +( where `id' is the request identifier, and `path' specifies the) s +5 426 M +( directory to be removed. See Section ``File Names'' for more) s +5 415 M +( information on file names. An error will be returned if no directory) s +5 404 M +( with the specified path exists, or if the specified directory is not) s +5 393 M +( empty, or if the path specified a file system object other than a) s +5 382 M +( directory. The server responds to this request with a SSH_FXP_STATUS) s +5 371 M +( message.) s +5 349 M +(6.7 Scanning Directories) s +5 327 M +( The files in a directory can be listed using the SSH_FXP_OPENDIR and) s +5 316 M +( SSH_FXP_READDIR requests. Each SSH_FXP_READDIR request returns one) s +5 305 M +( or more file names with full file attributes for each file. The) s +5 294 M +( client should call SSH_FXP_READDIR repeatedly until it has found the) s +5 283 M +( file it is looking for or until the server responds with a) s +5 272 M +( SSH_FXP_STATUS message indicating an error \(normally SSH_FX_EOF if) s +5 261 M +( there are no more files in the directory\). The client should then) s +5 250 M +( close the handle using the SSH_FXP_CLOSE request.) s +5 129 M +(Ylonen & Lehtinen Expires April 1, 2002 [Page 15]) s +_R +S +PStoPSsaved restore +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 421.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 16 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH File Transfer Protocol October 2001) s +5 690 M +( The SSH_FXP_OPENDIR opens a directory for reading. It has the) s +5 679 M +( following format:) s +5 657 M +( uint32 id) s +5 646 M +( string path) s +5 624 M +( where `id' is the request identifier and `path' is the path name of) s +5 613 M +( the directory to be listed \(without any trailing slash\). See Section) s +5 602 M +( ``File Names'' for more information on file names. This will return) s +5 591 M +( an error if the path does not specify a directory or if the directory) s +5 580 M +( is not readable. The server will respond to this request with either) s +5 569 M +( a SSH_FXP_HANDLE or a SSH_FXP_STATUS message.) s +5 547 M +( Once the directory has been successfully opened, files \(and) s +5 536 M +( directories\) contained in it can be listed using SSH_FXP_READDIR) s +5 525 M +( requests. These are of the format) s +5 503 M +( uint32 id) s +5 492 M +( string handle) s +5 470 M +( where `id' is the request identifier, and `handle' is a handle) s +5 459 M +( returned by SSH_FXP_OPENDIR. \(It is a protocol error to attempt to) s +5 448 M +( use an ordinary file handle returned by SSH_FXP_OPEN.\)) s +5 426 M +( The server responds to this request with either a SSH_FXP_NAME or a) s +5 415 M +( SSH_FXP_STATUS message. One or more names may be returned at a time.) s +5 404 M +( Full status information is returned for each name in order to speed) s +5 393 M +( up typical directory listings.) s +5 371 M +( When the client no longer wishes to read more names from the) s +5 360 M +( directory, it SHOULD call SSH_FXP_CLOSE for the handle. The handle) s +5 349 M +( should be closed regardless of whether an error has occurred or not.) s +5 327 M +(6.8 Retrieving File Attributes) s +5 305 M +( Very often, file attributes are automatically returned by) s +5 294 M +( SSH_FXP_READDIR. However, sometimes there is need to specifically) s +5 283 M +( retrieve the attributes for a named file. This can be done using the) s +5 272 M +( SSH_FXP_STAT, SSH_FXP_LSTAT and SSH_FXP_FSTAT requests.) s +5 250 M +( SSH_FXP_STAT and SSH_FXP_LSTAT only differ in that SSH_FXP_STAT) s +5 239 M +( follows symbolic links on the server, whereas SSH_FXP_LSTAT does not) s +5 228 M +( follow symbolic links. Both have the same format:) s +5 206 M +( uint32 id) s +5 195 M +( string path) s +5 173 M +( where `id' is the request identifier, and `path' specifies the file) s +5 129 M +(Ylonen & Lehtinen Expires April 1, 2002 [Page 16]) s +_R +S +PStoPSsaved restore +%%Page: (16,17) 9 +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 0.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +/showpage{}def/copypage{}def/erasepage{}def +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 17 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH File Transfer Protocol October 2001) s +5 690 M +( system object for which status is to be returned. The server) s +5 679 M +( responds to this request with either SSH_FXP_ATTRS or SSH_FXP_STATUS.) s +5 657 M +( SSH_FXP_FSTAT differs from the others in that it returns status) s +5 646 M +( information for an open file \(identified by the file handle\). Its) s +5 635 M +( format is as follows:) s +5 613 M +( uint32 id) s +5 602 M +( string handle) s +5 580 M +( where `id' is the request identifier and `handle' is a file handle) s +5 569 M +( returned by SSH_FXP_OPEN. The server responds to this request with) s +5 558 M +( SSH_FXP_ATTRS or SSH_FXP_STATUS.) s +5 536 M +(6.9 Setting File Attributes) s +5 514 M +( File attributes may be modified using the SSH_FXP_SETSTAT and) s +5 503 M +( SSH_FXP_FSETSTAT requests. These requests are used for operations) s +5 492 M +( such as changing the ownership, permissions or access times, as well) s +5 481 M +( as for truncating a file.) s +5 459 M +( The SSH_FXP_SETSTAT request is of the following format:) s +5 437 M +( uint32 id) s +5 426 M +( string path) s +5 415 M +( ATTRS attrs) s +5 393 M +( where `id' is the request identifier, `path' specifies the file) s +5 382 M +( system object \(e.g. file or directory\) whose attributes are to be) s +5 371 M +( modified, and `attrs' specifies the modifications to be made to its) s +5 360 M +( attributes. Attributes are discussed in more detail in Section) s +5 349 M +( ``File Attributes''.) s +5 327 M +( An error will be returned if the specified file system object does) s +5 316 M +( not exist or the user does not have sufficient rights to modify the) s +5 305 M +( specified attributes. The server responds to this request with a) s +5 294 M +( SSH_FXP_STATUS message.) s +5 272 M +( The SSH_FXP_FSETSTAT request modifies the attributes of a file which) s +5 261 M +( is already open. It has the following format:) s +5 239 M +( uint32 id) s +5 228 M +( string handle) s +5 217 M +( ATTRS attrs) s +5 195 M +( where `id' is the request identifier, `handle' \(MUST be returned by) s +5 184 M +( SSH_FXP_OPEN\) identifies the file whose attributes are to be) s +5 173 M +( modified, and `attrs' specifies the modifications to be made to its) s +5 129 M +(Ylonen & Lehtinen Expires April 1, 2002 [Page 17]) s +_R +S +PStoPSsaved restore +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 421.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 18 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH File Transfer Protocol October 2001) s +5 690 M +( attributes. Attributes are discussed in more detail in Section) s +5 679 M +( ``File Attributes''. The server will respond to this request with) s +5 668 M +( SSH_FXP_STATUS.) s +5 646 M +(6.10 Dealing with Symbolic links) s +5 624 M +( The SSH_FXP_READLINK request may be used to read the target of a) s +5 613 M +( symbolic link. It would have a data part as follows:) s +5 591 M +( uint32 id) s +5 580 M +( string path) s +5 558 M +( where `id' is the request identifier and `path' specifies the path) s +5 547 M +( name of the symlink to be read.) s +5 525 M +( The server will respond with a SSH_FXP_NAME packet containing only) s +5 514 M +( one name and a dummy attributes value. The name in the returned) s +5 503 M +( packet contains the target of the link. If an error occurs, the) s +5 492 M +( server may respond with SSH_FXP_STATUS.) s +5 470 M +( The SSH_FXP_SYMLINK request will create a symbolic link on the) s +5 459 M +( server. It is of the following format) s +5 437 M +( uint32 id) s +5 426 M +( string linkpath) s +5 415 M +( string targetpath) s +5 393 M +( where `id' is the request identifier, `linkpath' specifies the path) s +5 382 M +( name of the symlink to be created and `targetpath' specifies the) s +5 371 M +( target of the symlink. The server shall respond with a) s +5 360 M +( SSH_FXP_STATUS indicating either success \(SSH_FX_OK\) or an error) s +5 349 M +( condition.) s +5 327 M +(6.11 Canonicalizing the Server-Side Path Name) s +5 305 M +( The SSH_FXP_REALPATH request can be used to have the server) s +5 294 M +( canonicalize any given path name to an absolute path. This is useful) s +5 283 M +( for converting path names containing ".." components or relative) s +5 272 M +( pathnames without a leading slash into absolute paths. The format of) s +5 261 M +( the request is as follows:) s +5 239 M +( uint32 id) s +5 228 M +( string path) s +5 206 M +( where `id' is the request identifier and `path' specifies the path) s +5 195 M +( name to be canonicalized. The server will respond with a) s +5 184 M +( SSH_FXP_NAME packet containing only one name and a dummy attributes) s +5 173 M +( value. The name is the returned packet will be in canonical form.) s +5 129 M +(Ylonen & Lehtinen Expires April 1, 2002 [Page 18]) s +_R +S +PStoPSsaved restore +%%Page: (18,19) 10 +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 0.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +/showpage{}def/copypage{}def/erasepage{}def +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 19 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH File Transfer Protocol October 2001) s +5 690 M +( If an error occurs, the server may also respond with SSH_FXP_STATUS.) s +5 129 M +(Ylonen & Lehtinen Expires April 1, 2002 [Page 19]) s +_R +S +PStoPSsaved restore +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 421.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 20 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH File Transfer Protocol October 2001) s +5 690 M +(7. Responses from the Server to the Client) s +5 668 M +( The server responds to the client using one of a few response) s +5 657 M +( packets. All requests can return a SSH_FXP_STATUS response upon) s +5 646 M +( failure. When the operation is successful, any of the responses may) s +5 635 M +( be returned \(depending on the operation\). If no data needs to be) s +5 624 M +( returned to the client, the SSH_FXP_STATUS response with SSH_FX_OK) s +5 613 M +( status is appropriate. Otherwise, the SSH_FXP_HANDLE message is used) s +5 602 M +( to return a file handle \(for SSH_FXP_OPEN and SSH_FXP_OPENDIR) s +5 591 M +( requests\), SSH_FXP_DATA is used to return data from SSH_FXP_READ,) s +5 580 M +( SSH_FXP_NAME is used to return one or more file names from a) s +5 569 M +( SSH_FXP_READDIR or SSH_FXP_REALPATH request, and SSH_FXP_ATTRS is) s +5 558 M +( used to return file attributes from SSH_FXP_STAT, SSH_FXP_LSTAT, and) s +5 547 M +( SSH_FXP_FSTAT requests.) s +5 525 M +( Exactly one response will be returned for each request. Each) s +5 514 M +( response packet contains a request identifier which can be used to) s +5 503 M +( match each response with the corresponding request. Note that it is) s +5 492 M +( legal to have several requests outstanding simultaneously, and the) s +5 481 M +( server is allowed to send responses to them in a different order from) s +5 470 M +( the order in which the requests were sent \(the result of their) s +5 459 M +( execution, however, is guaranteed to be as if they had been processed) s +5 448 M +( one at a time in the order in which the requests were sent\).) s +5 426 M +( Response packets are of the same general format as request packets.) s +5 415 M +( Each response packet begins with the request identifier.) s +5 393 M +( The format of the data portion of the SSH_FXP_STATUS response is as) s +5 382 M +( follows:) s +5 360 M +( uint32 id) s +5 349 M +( uint32 error/status code) s +5 338 M +( string error message \(ISO-10646 UTF-8 [RFC-2279]\)) s +5 327 M +( string language tag \(as defined in [RFC-1766]\)) s +5 305 M +( where `id' is the request identifier, and `error/status code') s +5 294 M +( indicates the result of the requested operation. The value SSH_FX_OK) s +5 283 M +( indicates success, and all other values indicate failure.) s +5 129 M +(Ylonen & Lehtinen Expires April 1, 2002 [Page 20]) s +_R +S +PStoPSsaved restore +%%Page: (20,21) 11 +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 0.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +/showpage{}def/copypage{}def/erasepage{}def +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 21 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH File Transfer Protocol October 2001) s +5 690 M +( Currently, the following values are defined \(other values may be) s +5 679 M +( defined by future versions of this protocol\):) s +5 657 M +( #define SSH_FX_OK 0) s +5 646 M +( #define SSH_FX_EOF 1) s +5 635 M +( #define SSH_FX_NO_SUCH_FILE 2) s +5 624 M +( #define SSH_FX_PERMISSION_DENIED 3) s +5 613 M +( #define SSH_FX_FAILURE 4) s +5 602 M +( #define SSH_FX_BAD_MESSAGE 5) s +5 591 M +( #define SSH_FX_NO_CONNECTION 6) s +5 580 M +( #define SSH_FX_CONNECTION_LOST 7) s +5 569 M +( #define SSH_FX_OP_UNSUPPORTED 8) s +5 547 M +( SSH_FX_OK) s +5 536 M +( Indicates successful completion of the operation.) s +5 514 M +( SSH_FX_EOF) s +5 503 M +( indicates end-of-file condition; for SSH_FX_READ it means that no) s +5 492 M +( more data is available in the file, and for SSH_FX_READDIR it) s +5 481 M +( indicates that no more files are contained in the directory.) s +5 459 M +( SSH_FX_NO_SUCH_FILE) s +5 448 M +( is returned when a reference is made to a file which should exist) s +5 437 M +( but doesn't.) s +5 415 M +( SSH_FX_PERMISSION_DENIED) s +5 404 M +( is returned when the authenticated user does not have sufficient) s +5 393 M +( permissions to perform the operation.) s +5 371 M +( SSH_FX_FAILURE) s +5 360 M +( is a generic catch-all error message; it should be returned if an) s +5 349 M +( error occurs for which there is no more specific error code) s +5 338 M +( defined.) s +5 316 M +( SSH_FX_BAD_MESSAGE) s +5 305 M +( may be returned if a badly formatted packet or protocol) s +5 294 M +( incompatibility is detected.) s +5 272 M +( SSH_FX_NO_CONNECTION) s +5 261 M +( is a pseudo-error which indicates that the client has no) s +5 250 M +( connection to the server \(it can only be generated locally by the) s +5 239 M +( client, and MUST NOT be returned by servers\).) s +5 217 M +( SSH_FX_CONNECTION_LOST) s +5 206 M +( is a pseudo-error which indicates that the connection to the) s +5 195 M +( server has been lost \(it can only be generated locally by the) s +5 184 M +( client, and MUST NOT be returned by servers\).) s +5 129 M +(Ylonen & Lehtinen Expires April 1, 2002 [Page 21]) s +_R +S +PStoPSsaved restore +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 421.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 22 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH File Transfer Protocol October 2001) s +5 690 M +( SSH_FX_OP_UNSUPPORTED) s +5 679 M +( indicates that an attempt was made to perform an operation which) s +5 668 M +( is not supported for the server \(it may be generated locally by) s +5 657 M +( the client if e.g. the version number exchange indicates that a) s +5 646 M +( required feature is not supported by the server, or it may be) s +5 635 M +( returned by the server if the server does not implement an) s +5 624 M +( operation\).) s +5 602 M +( The SSH_FXP_HANDLE response has the following format:) s +5 580 M +( uint32 id) s +5 569 M +( string handle) s +5 547 M +( where `id' is the request identifier, and `handle' is an arbitrary) s +5 536 M +( string that identifies an open file or directory on the server. The) s +5 525 M +( handle is opaque to the client; the client MUST NOT attempt to) s +5 514 M +( interpret or modify it in any way. The length of the handle string) s +5 503 M +( MUST NOT exceed 256 data bytes.) s +5 481 M +( The SSH_FXP_DATA response has the following format:) s +5 459 M +( uint32 id) s +5 448 M +( string data) s +5 426 M +( where `id' is the request identifier, and `data' is an arbitrary byte) s +5 415 M +( string containing the requested data. The data string may be at most) s +5 404 M +( the number of bytes requested in a SSH_FXP_READ request, but may also) s +5 393 M +( be shorter if end of file is reached or if the read is from something) s +5 382 M +( other than a regular file.) s +5 360 M +( The SSH_FXP_NAME response has the following format:) s +5 338 M +( uint32 id) s +5 327 M +( uint32 count) s +5 316 M +( repeats count times:) s +5 305 M +( string filename) s +5 294 M +( string longname) s +5 283 M +( ATTRS attrs) s +5 261 M +( where `id' is the request identifier, `count' is the number of names) s +5 250 M +( returned in this response, and the remaining fields repeat `count') s +5 239 M +( times \(so that all three fields are first included for the first) s +5 228 M +( file, then for the second file, etc\). In the repeated part,) s +5 217 M +( `filename' is a file name being returned \(for SSH_FXP_READDIR, it) s +5 206 M +( will be a relative name within the directory, without any path) s +5 195 M +( components; for SSH_FXP_REALPATH it will be an absolute path name\),) s +5 184 M +( `longname' is an expanded format for the file name, similar to what) s +5 173 M +( is returned by "ls -l" on Unix systems, and `attrs' is the attributes) s +5 129 M +(Ylonen & Lehtinen Expires April 1, 2002 [Page 22]) s +_R +S +PStoPSsaved restore +%%Page: (22,23) 12 +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 0.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +/showpage{}def/copypage{}def/erasepage{}def +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 23 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH File Transfer Protocol October 2001) s +5 690 M +( of the file as described in Section ``File Attributes''.) s +5 668 M +( The format of the `longname' field is unspecified by this protocol.) s +5 657 M +( It MUST be suitable for use in the output of a directory listing) s +5 646 M +( command \(in fact, the recommended operation for a directory listing) s +5 635 M +( command is to simply display this data\). However, clients SHOULD NOT) s +5 624 M +( attempt to parse the longname field for file attributes; they SHOULD) s +5 613 M +( use the attrs field instead.) s +5 591 M +( The recommended format for the longname field is as follows:) s +5 569 M +( -rwxr-xr-x 1 mjos staff 348911 Mar 25 14:29 t-filexfer) s +5 558 M +( 1234567890 123 12345678 12345678 12345678 123456789012) s +5 536 M +( Here, the first line is sample output, and the second field indicates) s +5 525 M +( widths of the various fields. Fields are separated by spaces. The) s +5 514 M +( first field lists file permissions for user, group, and others; the) s +5 503 M +( second field is link count; the third field is the name of the user) s +5 492 M +( who owns the file; the fourth field is the name of the group that) s +5 481 M +( owns the file; the fifth field is the size of the file in bytes; the) s +5 470 M +( sixth field \(which actually may contain spaces, but is fixed to 12) s +5 459 M +( characters\) is the file modification time, and the seventh field is) s +5 448 M +( the file name. Each field is specified to be a minimum of certain) s +5 437 M +( number of character positions \(indicated by the second line above\),) s +5 426 M +( but may also be longer if the data does not fit in the specified) s +5 415 M +( length.) s +5 393 M +( The SSH_FXP_ATTRS response has the following format:) s +5 371 M +( uint32 id) s +5 360 M +( ATTRS attrs) s +5 338 M +( where `id' is the request identifier, and `attrs' is the returned) s +5 327 M +( file attributes as described in Section ``File Attributes''.) s +5 129 M +(Ylonen & Lehtinen Expires April 1, 2002 [Page 23]) s +_R +S +PStoPSsaved restore +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 421.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 24 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH File Transfer Protocol October 2001) s +5 690 M +(8. Vendor-Specific Extensions) s +5 668 M +( The SSH_FXP_EXTENDED request provides a generic extension mechanism) s +5 657 M +( for adding vendor-specific commands. The request has the following) s +5 646 M +( format:) s +5 624 M +( uint32 id) s +5 613 M +( string extended-request) s +5 602 M +( ... any request-specific data ...) s +5 580 M +( where `id' is the request identifier, and `extended-request' is a) s +5 569 M +( string of the format "name@domain", where domain is an internet) s +5 558 M +( domain name of the vendor defining the request. The rest of the) s +5 547 M +( request is completely vendor-specific, and servers should only) s +5 536 M +( attempt to interpret it if they recognize the `extended-request') s +5 525 M +( name.) s +5 503 M +( The server may respond to such requests using any of the response) s +5 492 M +( packets defined in Section ``Responses from the Server to the) s +5 481 M +( Client''. Additionally, the server may also respond with a) s +5 470 M +( SSH_FXP_EXTENDED_REPLY packet, as defined below. If the server does) s +5 459 M +( not recognize the `extended-request' name, then the server MUST) s +5 448 M +( respond with SSH_FXP_STATUS with error/status set to) s +5 437 M +( SSH_FX_OP_UNSUPPORTED.) s +5 415 M +( The SSH_FXP_EXTENDED_REPLY packet can be used to carry arbitrary) s +5 404 M +( extension-specific data from the server to the client. It is of the) s +5 393 M +( following format:) s +5 371 M +( uint32 id) s +5 360 M +( ... any request-specific data ...) s +5 129 M +(Ylonen & Lehtinen Expires April 1, 2002 [Page 24]) s +_R +S +PStoPSsaved restore +%%Page: (24,25) 13 +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 0.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +/showpage{}def/copypage{}def/erasepage{}def +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 25 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH File Transfer Protocol October 2001) s +5 690 M +(9. Security Considerations) s +5 668 M +( This protocol assumes that it is run over a secure channel and that) s +5 657 M +( the endpoints of the channel have been authenticated. Thus, this) s +5 646 M +( protocol assumes that it is externally protected from network-level) s +5 635 M +( attacks.) s +5 613 M +( This protocol provides file system access to arbitrary files on the) s +5 602 M +( server \(only constrained by the server implementation\). It is the) s +5 591 M +( responsibility of the server implementation to enforce any access) s +5 580 M +( controls that may be required to limit the access allowed for any) s +5 569 M +( particular user \(the user being authenticated externally to this) s +5 558 M +( protocol, typically using the SSH User Authentication Protocol [6].) s +5 536 M +( Care must be taken in the server implementation to check the validity) s +5 525 M +( of received file handle strings. The server should not rely on them) s +5 514 M +( directly; it MUST check the validity of each handle before relying on) s +5 503 M +( it.) s +5 129 M +(Ylonen & Lehtinen Expires April 1, 2002 [Page 25]) s +_R +S +PStoPSsaved restore +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 421.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 26 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH File Transfer Protocol October 2001) s +5 690 M +(10. Changes from previous protocol versions) s +5 668 M +( The SSH File Transfer Protocol has changed over time, before it's) s +5 657 M +( standardization. The following is a description of the incompatible) s +5 646 M +( changes between different versions.) s +5 624 M +(10.1 Changes between versions 3 and 2) s +5 602 M +( o The SSH_FXP_READLINK and SSH_FXP_SYMLINK messages were added.) s +5 580 M +( o The SSH_FXP_EXTENDED and SSH_FXP_EXTENDED_REPLY messages were) s +5 569 M +( added.) s +5 547 M +( o The SSH_FXP_STATUS message was changed to include fields `error) s +5 536 M +( message' and `language tag'.) s +5 503 M +(10.2 Changes between versions 2 and 1) s +5 481 M +( o The SSH_FXP_RENAME message was added.) s +5 448 M +(10.3 Changes between versions 1 and 0) s +5 426 M +( o Implementation changes, no actual protocol changes.) s +5 129 M +(Ylonen & Lehtinen Expires April 1, 2002 [Page 26]) s +_R +S +PStoPSsaved restore +%%Page: (26,27) 14 +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 0.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +/showpage{}def/copypage{}def/erasepage{}def +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 27 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH File Transfer Protocol October 2001) s +5 690 M +(11. Trademark Issues) s +5 668 M +( "ssh" is a registered trademark of SSH Communications Security Corp) s +5 657 M +( in the United States and/or other countries.) s +5 129 M +(Ylonen & Lehtinen Expires April 1, 2002 [Page 27]) s +_R +S +PStoPSsaved restore +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 421.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 28 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH File Transfer Protocol October 2001) s +5 690 M +(References) s +5 668 M +( [1] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and) s +5 657 M +( P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January) s +5 646 M +( 1999.) s +5 624 M +( [2] Institute of Electrical and Electronics Engineers, "Information) s +5 613 M +( Technology - Portable Operating System Interface \(POSIX\) - Part) s +5 602 M +( 1: System Application Program Interface \(API\) [C Language]",) s +5 591 M +( IEEE Standard 1003.2, 1996.) s +5 569 M +( [3] Rinne, T., Ylonen, T., Kivinen, T., Saarinen, M. and S.) s +5 558 M +( Lehtinen, "SSH Protocol Architecture", draft-ietf-secsh-) s +5 547 M +( architecture-09 \(work in progress\), July 2001.) s +5 525 M +( [4] Rinne, T., Ylonen, T., Kivinen, T., Saarinen, M. and S.) s +5 514 M +( Lehtinen, "SSH Protocol Transport Protocol", draft-ietf-secsh-) s +5 503 M +( architecture-09 \(work in progress\), July 2001.) s +5 481 M +( [5] Rinne, T., Ylonen, T., Kivinen, T., Saarinen, M. and S.) s +5 470 M +( Lehtinen, "SSH Connection Protocol", draft-ietf-secsh-connect-11) s +5 459 M +( \(work in progress\), July 2001.) s +5 437 M +( [6] Rinne, T., Ylonen, T., Kivinen, T., Saarinen, M. and S.) s +5 426 M +( Lehtinen, "SSH Authentication Protocol", draft-ietf-secsh-) s +5 415 M +( userauth-11 \(work in progress\), July 2001.) s +5 382 M +(Authors' Addresses) s +5 360 M +( Tatu Ylonen) s +5 349 M +( SSH Communications Security Corp) s +5 338 M +( Fredrikinkatu 42) s +5 327 M +( HELSINKI FIN-00100) s +5 316 M +( Finland) s +5 294 M +( EMail: [email protected]) s +5 261 M +( Sami Lehtinen) s +5 250 M +( SSH Communications Security Corp) s +5 239 M +( Fredrikinkatu 42) s +5 228 M +( HELSINKI FIN-00100) s +5 217 M +( Finland) s +5 195 M +( EMail: [email protected]) s +5 129 M +(Ylonen & Lehtinen Expires April 1, 2002 [Page 28]) s +_R +S +PStoPSsaved restore +%%Page: (28,29) 15 +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 0.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +/showpage{}def/copypage{}def/erasepage{}def +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 29 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH File Transfer Protocol October 2001) s +5 690 M +(Full Copyright Statement) s +5 668 M +( Copyright \(C\) The Internet Society \(2001\). All Rights Reserved.) s +5 646 M +( This document and translations of it may be copied and furnished to) s +5 635 M +( others, and derivative works that comment on or otherwise explain it) s +5 624 M +( or assist in its implementation may be prepared, copied, published) s +5 613 M +( and distributed, in whole or in part, without restriction of any) s +5 602 M +( kind, provided that the above copyright notice and this paragraph are) s +5 591 M +( included on all such copies and derivative works. However, this) s +5 580 M +( document itself may not be modified in any way, such as by removing) s +5 569 M +( the copyright notice or references to the Internet Society or other) s +5 558 M +( Internet organizations, except as needed for the purpose of) s +5 547 M +( developing Internet standards in which case the procedures for) s +5 536 M +( copyrights defined in the Internet Standards process must be) s +5 525 M +( followed, or as required to translate it into languages other than) s +5 514 M +( English.) s +5 492 M +( The limited permissions granted above are perpetual and will not be) s +5 481 M +( revoked by the Internet Society or its successors or assigns.) s +5 459 M +( This document and the information contained herein is provided on an) s +5 448 M +( "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING) s +5 437 M +( TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING) s +5 426 M +( BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION) s +5 415 M +( HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF) s +5 404 M +( MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.) s +5 382 M +(Acknowledgement) s +5 360 M +( Funding for the RFC Editor function is currently provided by the) s +5 349 M +( Internet Society.) s +5 129 M +(Ylonen & Lehtinen Expires April 1, 2002 [Page 29]) s +_R +S +PStoPSsaved restore +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 421.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 30 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +_R +S +PStoPSsaved restore +%%Trailer +%%Pages: 30 +%%DocumentNeededResources: font Courier-Bold Courier +%%EOF diff --git a/lib/ssh/doc/standard/draft-ietf-secsh-filexfer-02.txt b/lib/ssh/doc/standard/draft-ietf-secsh-filexfer-02.txt new file mode 100644 index 0000000000..c4ec8c1125 --- /dev/null +++ b/lib/ssh/doc/standard/draft-ietf-secsh-filexfer-02.txt @@ -0,0 +1,1627 @@ + + + +Network Working Group T. Ylonen +Internet-Draft S. Lehtinen +Expires: April 1, 2002 SSH Communications Security Corp + October 2001 + + + SSH File Transfer Protocol + draft-ietf-secsh-filexfer-02.txt + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at http:// + www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on April 1, 2002. + +Copyright Notice + + Copyright (C) The Internet Society (2001). All Rights Reserved. + +Abstract + + The SSH File Transfer Protocol provides secure file transfer + functionality over any reliable data stream. It is the standard file + transfer protocol for use with the SSH2 protocol. This document + describes the file transfer protocol and its interface to the SSH2 + protocol suite. + + + + + + + + + +Ylonen & Lehtinen Expires April 1, 2002 [Page 1] + +Internet-Draft SSH File Transfer Protocol October 2001 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Use with the SSH Connection Protocol . . . . . . . . . . . . 4 + 3. General Packet Format . . . . . . . . . . . . . . . . . . . 5 + 4. Protocol Initialization . . . . . . . . . . . . . . . . . . 7 + 5. File Attributes . . . . . . . . . . . . . . . . . . . . . . 8 + 6. Requests From the Client to the Server . . . . . . . . . . . 10 + 6.1 Request Synchronization and Reordering . . . . . . . . . . . 10 + 6.2 File Names . . . . . . . . . . . . . . . . . . . . . . . . . 11 + 6.3 Opening, Creating, and Closing Files . . . . . . . . . . . . 11 + 6.4 Reading and Writing . . . . . . . . . . . . . . . . . . . . 13 + 6.5 Removing and Renaming Files . . . . . . . . . . . . . . . . 14 + 6.6 Creating and Deleting Directories . . . . . . . . . . . . . 15 + 6.7 Scanning Directories . . . . . . . . . . . . . . . . . . . . 15 + 6.8 Retrieving File Attributes . . . . . . . . . . . . . . . . . 16 + 6.9 Setting File Attributes . . . . . . . . . . . . . . . . . . 17 + 6.10 Dealing with Symbolic links . . . . . . . . . . . . . . . . 18 + 6.11 Canonicalizing the Server-Side Path Name . . . . . . . . . . 18 + 7. Responses from the Server to the Client . . . . . . . . . . 20 + 8. Vendor-Specific Extensions . . . . . . . . . . . . . . . . . 24 + 9. Security Considerations . . . . . . . . . . . . . . . . . . 25 + 10. Changes from previous protocol versions . . . . . . . . . . 26 + 10.1 Changes between versions 3 and 2 . . . . . . . . . . . . . . 26 + 10.2 Changes between versions 2 and 1 . . . . . . . . . . . . . . 26 + 10.3 Changes between versions 1 and 0 . . . . . . . . . . . . . . 26 + 11. Trademark Issues . . . . . . . . . . . . . . . . . . . . . . 27 + References . . . . . . . . . . . . . . . . . . . . . . . . . 28 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 28 + Full Copyright Statement . . . . . . . . . . . . . . . . . . 29 + + + + + + + + + + + + + + + + + + + + + +Ylonen & Lehtinen Expires April 1, 2002 [Page 2] + +Internet-Draft SSH File Transfer Protocol October 2001 + + +1. Introduction + + This protocol provides secure file transfer (and more generally file + system access) functionality over a reliable data stream, such as a + channel in the SSH2 protocol [3]. + + This protocol is designed so that it could be used to implement a + secure remote file system service, as well as a secure file transfer + service. + + This protocol assumes that it runs over a secure channel, and that + the server has already authenticated the user at the client end, and + that the identity of the client user is externally available to the + server implementation. + + In general, this protocol follows a simple request-response model. + Each request and response contains a sequence number and multiple + requests may be pending simultaneously. There are a relatively large + number of different request messages, but a small number of possible + response messages. Each request has one or more response messages + that may be returned in result (e.g., a read either returns data or + reports error status). + + The packet format descriptions in this specification follow the + notation presented in the secsh architecture draft.[3]. + + Even though this protocol is described in the context of the SSH2 + protocol, this protocol is general and independent of the rest of the + SSH2 protocol suite. It could be used in a number of different + applications, such as secure file transfer over TLS RFC 2246 [1] and + transfer of management information in VPN applications. + + + + + + + + + + + + + + + + + + + + +Ylonen & Lehtinen Expires April 1, 2002 [Page 3] + +Internet-Draft SSH File Transfer Protocol October 2001 + + +2. Use with the SSH Connection Protocol + + When used with the SSH2 Protocol suite, this protocol is intended to + be used from the SSH Connection Protocol [5] as a subsystem, as + described in section ``Starting a Shell or a Command''. The + subsystem name used with this protocol is "sftp". + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Ylonen & Lehtinen Expires April 1, 2002 [Page 4] + +Internet-Draft SSH File Transfer Protocol October 2001 + + +3. General Packet Format + + All packets transmitted over the secure connection are of the + following format: + + uint32 length + byte type + byte[length - 1] data payload + + That is, they are just data preceded by 32-bit length and 8-bit type + fields. The `length' is the length of the data area, and does not + include the `length' field itself. The format and interpretation of + the data area depends on the packet type. + + All packet descriptions below only specify the packet type and the + data that goes into the data field. Thus, they should be prefixed by + the `length' and `type' fields. + + The maximum size of a packet is in practice determined by the client + (the maximum size of read or write requests that it sends, plus a few + bytes of packet overhead). All servers SHOULD support packets of at + least 34000 bytes (where the packet size refers to the full length, + including the header above). This should allow for reads and writes + of at most 32768 bytes. + + There is no limit on the number of outstanding (non-acknowledged) + requests that the client may send to the server. In practice this is + limited by the buffering available on the data stream and the queuing + performed by the server. If the server's queues are full, it should + not read any more data from the stream, and flow control will prevent + the client from sending more requests. Note, however, that while + there is no restriction on the protocol level, the client's API may + provide a limit in order to prevent infinite queuing of outgoing + requests at the client. + + + + + + + + + + + + + + + + + +Ylonen & Lehtinen Expires April 1, 2002 [Page 5] + +Internet-Draft SSH File Transfer Protocol October 2001 + + + The following values are defined for packet types. + + #define SSH_FXP_INIT 1 + #define SSH_FXP_VERSION 2 + #define SSH_FXP_OPEN 3 + #define SSH_FXP_CLOSE 4 + #define SSH_FXP_READ 5 + #define SSH_FXP_WRITE 6 + #define SSH_FXP_LSTAT 7 + #define SSH_FXP_FSTAT 8 + #define SSH_FXP_SETSTAT 9 + #define SSH_FXP_FSETSTAT 10 + #define SSH_FXP_OPENDIR 11 + #define SSH_FXP_READDIR 12 + #define SSH_FXP_REMOVE 13 + #define SSH_FXP_MKDIR 14 + #define SSH_FXP_RMDIR 15 + #define SSH_FXP_REALPATH 16 + #define SSH_FXP_STAT 17 + #define SSH_FXP_RENAME 18 + #define SSH_FXP_READLINK 19 + #define SSH_FXP_SYMLINK 20 + #define SSH_FXP_STATUS 101 + #define SSH_FXP_HANDLE 102 + #define SSH_FXP_DATA 103 + #define SSH_FXP_NAME 104 + #define SSH_FXP_ATTRS 105 + #define SSH_FXP_EXTENDED 200 + #define SSH_FXP_EXTENDED_REPLY 201 + + Additional packet types should only be defined if the protocol + version number (see Section ``Protocol Initialization'') is + incremented, and their use MUST be negotiated using the version + number. However, the SSH_FXP_EXTENDED and SSH_FXP_EXTENDED_REPLY + packets can be used to implement vendor-specific extensions. See + Section ``Vendor-Specific-Extensions'' for more details. + + + + + + + + + + + + + + + +Ylonen & Lehtinen Expires April 1, 2002 [Page 6] + +Internet-Draft SSH File Transfer Protocol October 2001 + + +4. Protocol Initialization + + When the file transfer protocol starts, it first sends a SSH_FXP_INIT + (including its version number) packet to the server. The server + responds with a SSH_FXP_VERSION packet, supplying the lowest of its + own and the client's version number. Both parties should from then + on adhere to particular version of the protocol. + + The SSH_FXP_INIT packet (from client to server) has the following + data: + + uint32 version + <extension data> + + The SSH_FXP_VERSION packet (from server to client) has the following + data: + + uint32 version + <extension data> + + The version number of the protocol specified in this document is 3. + The version number should be incremented for each incompatible + revision of this protocol. + + The extension data in the above packets may be empty, or may be a + sequence of + + string extension_name + string extension_data + + pairs (both strings MUST always be present if one is, but the + `extension_data' string may be of zero length). If present, these + strings indicate extensions to the baseline protocol. The + `extension_name' field(s) identify the name of the extension. The + name should be of the form "name@domain", where the domain is the DNS + domain name of the organization defining the extension. Additional + names that are not of this format may be defined later by the IETF. + Implementations MUST silently ignore any extensions whose name they + do not recognize. + + + + + + + + + + + + +Ylonen & Lehtinen Expires April 1, 2002 [Page 7] + +Internet-Draft SSH File Transfer Protocol October 2001 + + +5. File Attributes + + A new compound data type is defined for encoding file attributes. It + is basically just a combination of elementary types, but is defined + once because of the non-trivial description of the fields and to + ensure maintainability. + + The same encoding is used both when returning file attributes from + the server and when sending file attributes to the server. When + sending it to the server, the flags field specifies which attributes + are included, and the server will use default values for the + remaining attributes (or will not modify the values of remaining + attributes). When receiving attributes from the server, the flags + specify which attributes are included in the returned data. The + server normally returns all attributes it knows about. + + uint32 flags + uint64 size present only if flag SSH_FILEXFER_ATTR_SIZE + uint32 uid present only if flag SSH_FILEXFER_ATTR_UIDGID + uint32 gid present only if flag SSH_FILEXFER_ATTR_UIDGID + uint32 permissions present only if flag SSH_FILEXFER_ATTR_PERMISSIONS + uint32 atime present only if flag SSH_FILEXFER_ACMODTIME + uint32 mtime present only if flag SSH_FILEXFER_ACMODTIME + uint32 extended_count present only if flag SSH_FILEXFER_ATTR_EXTENDED + string extended_type + string extended_data + ... more extended data (extended_type - extended_data pairs), + so that number of pairs equals extended_count + + The `flags' specify which of the fields are present. Those fields + for which the corresponding flag is not set are not present (not + included in the packet). New flags can only be added by incrementing + the protocol version number (or by using the extension mechanism + described below). + + The `size' field specifies the size of the file in bytes. + + The `uid' and `gid' fields contain numeric Unix-like user and group + identifiers, respectively. + + The `permissions' field contains a bit mask of file permissions as + defined by posix [1]. + + The `atime' and `mtime' contain the access and modification times of + the files, respectively. They are represented as seconds from Jan 1, + 1970 in UTC. + + The SSH_FILEXFER_ATTR_EXTENDED flag provides a general extension + + + +Ylonen & Lehtinen Expires April 1, 2002 [Page 8] + +Internet-Draft SSH File Transfer Protocol October 2001 + + + mechanism for vendor-specific extensions. If the flag is specified, + then the `extended_count' field is present. It specifies the number + of extended_type-extended_data pairs that follow. Each of these + pairs specifies an extended attribute. For each of the attributes, + the extended_type field should be a string of the format + "name@domain", where "domain" is a valid, registered domain name and + "name" identifies the method. The IETF may later standardize certain + names that deviate from this format (e.g., that do not contain the + "@" sign). The interpretation of `extended_data' depends on the + type. Implementations SHOULD ignore extended data fields that they + do not understand. + + Additional fields can be added to the attributes by either defining + additional bits to the flags field to indicate their presence, or by + defining extended attributes for them. The extended attributes + mechanism is recommended for most purposes; additional flags bits + should only be defined by an IETF standards action that also + increments the protocol version number. The use of such new fields + MUST be negotiated by the version number in the protocol exchange. + It is a protocol error if a packet with unsupported protocol bits is + received. + + The flags bits are defined to have the following values: + + #define SSH_FILEXFER_ATTR_SIZE 0x00000001 + #define SSH_FILEXFER_ATTR_UIDGID 0x00000002 + #define SSH_FILEXFER_ATTR_PERMISSIONS 0x00000004 + #define SSH_FILEXFER_ATTR_ACMODTIME 0x00000008 + #define SSH_FILEXFER_ATTR_EXTENDED 0x80000000 + + + + + + + + + + + + + + + + + + + + + + +Ylonen & Lehtinen Expires April 1, 2002 [Page 9] + +Internet-Draft SSH File Transfer Protocol October 2001 + + +6. Requests From the Client to the Server + + Requests from the client to the server represent the various file + system operations. Each request begins with an `id' field, which is + a 32-bit identifier identifying the request (selected by the client). + The same identifier will be returned in the response to the request. + One possible implementation of it is a monotonically increasing + request sequence number (modulo 2^32). + + Many operations in the protocol operate on open files. The + SSH_FXP_OPEN request can return a file handle (which is an opaque + variable-length string) which may be used to access the file later + (e.g. in a read operation). The client MUST NOT send requests the + server with bogus or closed handles. However, the server MUST + perform adequate checks on the handle in order to avoid security + risks due to fabricated handles. + + This design allows either stateful and stateless server + implementation, as well as an implementation which caches state + between requests but may also flush it. The contents of the file + handle string are entirely up to the server and its design. The + client should not modify or attempt to interpret the file handle + strings. + + The file handle strings MUST NOT be longer than 256 bytes. + +6.1 Request Synchronization and Reordering + + The protocol and implementations MUST process requests relating to + the same file in the order in which they are received. In other + words, if an application submits multiple requests to the server, the + results in the responses will be the same as if it had sent the + requests one at a time and waited for the response in each case. For + example, the server may process non-overlapping read/write requests + to the same file in parallel, but overlapping reads and writes cannot + be reordered or parallelized. However, there are no ordering + restrictions on the server for processing requests from two different + file transfer connections. The server may interleave and parallelize + them at will. + + There are no restrictions on the order in which responses to + outstanding requests are delivered to the client, except that the + server must ensure fairness in the sense that processing of no + request will be indefinitely delayed even if the client is sending + other requests so that there are multiple outstanding requests all + the time. + + + + + +Ylonen & Lehtinen Expires April 1, 2002 [Page 10] + +Internet-Draft SSH File Transfer Protocol October 2001 + + +6.2 File Names + + This protocol represents file names as strings. File names are + assumed to use the slash ('/') character as a directory separator. + + File names starting with a slash are "absolute", and are relative to + the root of the file system. Names starting with any other character + are relative to the user's default directory (home directory). Note + that identifying the user is assumed to take place outside of this + protocol. + + Servers SHOULD interpret a path name component ".." as referring to + the parent directory, and "." as referring to the current directory. + If the server implementation limits access to certain parts of the + file system, it must be extra careful in parsing file names when + enforcing such restrictions. There have been numerous reported + security bugs where a ".." in a path name has allowed access outside + the intended area. + + An empty path name is valid, and it refers to the user's default + directory (usually the user's home directory). + + Otherwise, no syntax is defined for file names by this specification. + Clients should not make any other assumptions; however, they can + splice path name components returned by SSH_FXP_READDIR together + using a slash ('/') as the separator, and that will work as expected. + + It is understood that the lack of well-defined semantics for file + names may cause interoperability problems between clients and servers + using radically different operating systems. However, this approach + is known to work acceptably with most systems, and alternative + approaches that e.g. treat file names as sequences of structured + components are quite complicated. + +6.3 Opening, Creating, and Closing Files + + Files are opened and created using the SSH_FXP_OPEN message, whose + data part is as follows: + + uint32 id + string filename + uint32 pflags + ATTRS attrs + + The `id' field is the request identifier as for all requests. + + The `filename' field specifies the file name. See Section ``File + Names'' for more information. + + + +Ylonen & Lehtinen Expires April 1, 2002 [Page 11] + +Internet-Draft SSH File Transfer Protocol October 2001 + + + The `pflags' field is a bitmask. The following bits have been + defined. + + #define SSH_FXF_READ 0x00000001 + #define SSH_FXF_WRITE 0x00000002 + #define SSH_FXF_APPEND 0x00000004 + #define SSH_FXF_CREAT 0x00000008 + #define SSH_FXF_TRUNC 0x00000010 + #define SSH_FXF_EXCL 0x00000020 + + These have the following meanings: + + SSH_FXF_READ + Open the file for reading. + + SSH_FXF_WRITE + Open the file for writing. If both this and SSH_FXF_READ are + specified, the file is opened for both reading and writing. + + SSH_FXF_APPEND + Force all writes to append data at the end of the file. + + SSH_FXF_CREAT + If this flag is specified, then a new file will be created if one + does not already exist (if O_TRUNC is specified, the new file will + be truncated to zero length if it previously exists). + + SSH_FXF_TRUNC + Forces an existing file with the same name to be truncated to zero + length when creating a file by specifying SSH_FXF_CREAT. + SSH_FXF_CREAT MUST also be specified if this flag is used. + + SSH_FXF_EXCL + Causes the request to fail if the named file already exists. + SSH_FXF_CREAT MUST also be specified if this flag is used. + + The `attrs' field specifies the initial attributes for the file. + Default values will be used for those attributes that are not + specified. See Section ``File Attributes'' for more information. + + Regardless the server operating system, the file will always be + opened in "binary" mode (i.e., no translations between different + character sets and newline encodings). + + The response to this message will be either SSH_FXP_HANDLE (if the + operation is successful) or SSH_FXP_STATUS (if the operation fails). + + + + + +Ylonen & Lehtinen Expires April 1, 2002 [Page 12] + +Internet-Draft SSH File Transfer Protocol October 2001 + + + A file is closed by using the SSH_FXP_CLOSE request. Its data field + has the following format: + + uint32 id + string handle + + where `id' is the request identifier, and `handle' is a handle + previously returned in the response to SSH_FXP_OPEN or + SSH_FXP_OPENDIR. The handle becomes invalid immediately after this + request has been sent. + + The response to this request will be a SSH_FXP_STATUS message. One + should note that on some server platforms even a close can fail. + This can happen e.g. if the server operating system caches writes, + and an error occurs while flushing cached writes during the close. + +6.4 Reading and Writing + + Once a file has been opened, it can be read using the SSH_FXP_READ + message, which has the following format: + + uint32 id + string handle + uint64 offset + uint32 len + + where `id' is the request identifier, `handle' is an open file handle + returned by SSH_FXP_OPEN, `offset' is the offset (in bytes) relative + to the beginning of the file from where to start reading, and `len' + is the maximum number of bytes to read. + + In response to this request, the server will read as many bytes as it + can from the file (up to `len'), and return them in a SSH_FXP_DATA + message. If an error occurs or EOF is encountered before reading any + data, the server will respond with SSH_FXP_STATUS. For normal disk + files, it is guaranteed that this will read the specified number of + bytes, or up to end of file. For e.g. device files this may return + fewer bytes than requested. + + Writing to a file is achieved using the SSH_FXP_WRITE message, which + has the following format: + + uint32 id + string handle + uint64 offset + string data + + where `id' is a request identifier, `handle' is a file handle + + + +Ylonen & Lehtinen Expires April 1, 2002 [Page 13] + +Internet-Draft SSH File Transfer Protocol October 2001 + + + returned by SSH_FXP_OPEN, `offset' is the offset (in bytes) from the + beginning of the file where to start writing, and `data' is the data + to be written. + + The write will extend the file if writing beyond the end of the file. + It is legal to write way beyond the end of the file; the semantics + are to write zeroes from the end of the file to the specified offset + and then the data. On most operating systems, such writes do not + allocate disk space but instead leave "holes" in the file. + + The server responds to a write request with a SSH_FXP_STATUS message. + +6.5 Removing and Renaming Files + + Files can be removed using the SSH_FXP_REMOVE message. It has the + following format: + + uint32 id + string filename + + where `id' is the request identifier and `filename' is the name of + the file to be removed. See Section ``File Names'' for more + information. This request cannot be used to remove directories. + + The server will respond to this request with a SSH_FXP_STATUS + message. + + Files (and directories) can be renamed using the SSH_FXP_RENAME + message. Its data is as follows: + + uint32 id + string oldpath + string newpath + + where `id' is the request identifier, `oldpath' is the name of an + existing file or directory, and `newpath' is the new name for the + file or directory. It is an error if there already exists a file + with the name specified by newpath. The server may also fail rename + requests in other situations, for example if `oldpath' and `newpath' + point to different file systems on the server. + + The server will respond to this request with a SSH_FXP_STATUS + message. + + + + + + + + +Ylonen & Lehtinen Expires April 1, 2002 [Page 14] + +Internet-Draft SSH File Transfer Protocol October 2001 + + +6.6 Creating and Deleting Directories + + New directories can be created using the SSH_FXP_MKDIR request. It + has the following format: + + uint32 id + string path + ATTRS attrs + + where `id' is the request identifier, `path' and `attrs' specifies + the modifications to be made to its attributes. See Section ``File + Names'' for more information on file names. Attributes are discussed + in more detail in Section ``File Attributes''. specifies the + directory to be created. An error will be returned if a file or + directory with the specified path already exists. The server will + respond to this request with a SSH_FXP_STATUS message. + + Directories can be removed using the SSH_FXP_RMDIR request, which + has the following format: + + uint32 id + string path + + where `id' is the request identifier, and `path' specifies the + directory to be removed. See Section ``File Names'' for more + information on file names. An error will be returned if no directory + with the specified path exists, or if the specified directory is not + empty, or if the path specified a file system object other than a + directory. The server responds to this request with a SSH_FXP_STATUS + message. + +6.7 Scanning Directories + + The files in a directory can be listed using the SSH_FXP_OPENDIR and + SSH_FXP_READDIR requests. Each SSH_FXP_READDIR request returns one + or more file names with full file attributes for each file. The + client should call SSH_FXP_READDIR repeatedly until it has found the + file it is looking for or until the server responds with a + SSH_FXP_STATUS message indicating an error (normally SSH_FX_EOF if + there are no more files in the directory). The client should then + close the handle using the SSH_FXP_CLOSE request. + + + + + + + + + + +Ylonen & Lehtinen Expires April 1, 2002 [Page 15] + +Internet-Draft SSH File Transfer Protocol October 2001 + + + The SSH_FXP_OPENDIR opens a directory for reading. It has the + following format: + + uint32 id + string path + + where `id' is the request identifier and `path' is the path name of + the directory to be listed (without any trailing slash). See Section + ``File Names'' for more information on file names. This will return + an error if the path does not specify a directory or if the directory + is not readable. The server will respond to this request with either + a SSH_FXP_HANDLE or a SSH_FXP_STATUS message. + + Once the directory has been successfully opened, files (and + directories) contained in it can be listed using SSH_FXP_READDIR + requests. These are of the format + + uint32 id + string handle + + where `id' is the request identifier, and `handle' is a handle + returned by SSH_FXP_OPENDIR. (It is a protocol error to attempt to + use an ordinary file handle returned by SSH_FXP_OPEN.) + + The server responds to this request with either a SSH_FXP_NAME or a + SSH_FXP_STATUS message. One or more names may be returned at a time. + Full status information is returned for each name in order to speed + up typical directory listings. + + When the client no longer wishes to read more names from the + directory, it SHOULD call SSH_FXP_CLOSE for the handle. The handle + should be closed regardless of whether an error has occurred or not. + +6.8 Retrieving File Attributes + + Very often, file attributes are automatically returned by + SSH_FXP_READDIR. However, sometimes there is need to specifically + retrieve the attributes for a named file. This can be done using the + SSH_FXP_STAT, SSH_FXP_LSTAT and SSH_FXP_FSTAT requests. + + SSH_FXP_STAT and SSH_FXP_LSTAT only differ in that SSH_FXP_STAT + follows symbolic links on the server, whereas SSH_FXP_LSTAT does not + follow symbolic links. Both have the same format: + + uint32 id + string path + + where `id' is the request identifier, and `path' specifies the file + + + +Ylonen & Lehtinen Expires April 1, 2002 [Page 16] + +Internet-Draft SSH File Transfer Protocol October 2001 + + + system object for which status is to be returned. The server + responds to this request with either SSH_FXP_ATTRS or SSH_FXP_STATUS. + + SSH_FXP_FSTAT differs from the others in that it returns status + information for an open file (identified by the file handle). Its + format is as follows: + + uint32 id + string handle + + where `id' is the request identifier and `handle' is a file handle + returned by SSH_FXP_OPEN. The server responds to this request with + SSH_FXP_ATTRS or SSH_FXP_STATUS. + +6.9 Setting File Attributes + + File attributes may be modified using the SSH_FXP_SETSTAT and + SSH_FXP_FSETSTAT requests. These requests are used for operations + such as changing the ownership, permissions or access times, as well + as for truncating a file. + + The SSH_FXP_SETSTAT request is of the following format: + + uint32 id + string path + ATTRS attrs + + where `id' is the request identifier, `path' specifies the file + system object (e.g. file or directory) whose attributes are to be + modified, and `attrs' specifies the modifications to be made to its + attributes. Attributes are discussed in more detail in Section + ``File Attributes''. + + An error will be returned if the specified file system object does + not exist or the user does not have sufficient rights to modify the + specified attributes. The server responds to this request with a + SSH_FXP_STATUS message. + + The SSH_FXP_FSETSTAT request modifies the attributes of a file which + is already open. It has the following format: + + uint32 id + string handle + ATTRS attrs + + where `id' is the request identifier, `handle' (MUST be returned by + SSH_FXP_OPEN) identifies the file whose attributes are to be + modified, and `attrs' specifies the modifications to be made to its + + + +Ylonen & Lehtinen Expires April 1, 2002 [Page 17] + +Internet-Draft SSH File Transfer Protocol October 2001 + + + attributes. Attributes are discussed in more detail in Section + ``File Attributes''. The server will respond to this request with + SSH_FXP_STATUS. + +6.10 Dealing with Symbolic links + + The SSH_FXP_READLINK request may be used to read the target of a + symbolic link. It would have a data part as follows: + + uint32 id + string path + + where `id' is the request identifier and `path' specifies the path + name of the symlink to be read. + + The server will respond with a SSH_FXP_NAME packet containing only + one name and a dummy attributes value. The name in the returned + packet contains the target of the link. If an error occurs, the + server may respond with SSH_FXP_STATUS. + + The SSH_FXP_SYMLINK request will create a symbolic link on the + server. It is of the following format + + uint32 id + string linkpath + string targetpath + + where `id' is the request identifier, `linkpath' specifies the path + name of the symlink to be created and `targetpath' specifies the + target of the symlink. The server shall respond with a + SSH_FXP_STATUS indicating either success (SSH_FX_OK) or an error + condition. + +6.11 Canonicalizing the Server-Side Path Name + + The SSH_FXP_REALPATH request can be used to have the server + canonicalize any given path name to an absolute path. This is useful + for converting path names containing ".." components or relative + pathnames without a leading slash into absolute paths. The format of + the request is as follows: + + uint32 id + string path + + where `id' is the request identifier and `path' specifies the path + name to be canonicalized. The server will respond with a + SSH_FXP_NAME packet containing only one name and a dummy attributes + value. The name is the returned packet will be in canonical form. + + + +Ylonen & Lehtinen Expires April 1, 2002 [Page 18] + +Internet-Draft SSH File Transfer Protocol October 2001 + + + If an error occurs, the server may also respond with SSH_FXP_STATUS. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Ylonen & Lehtinen Expires April 1, 2002 [Page 19] + +Internet-Draft SSH File Transfer Protocol October 2001 + + +7. Responses from the Server to the Client + + The server responds to the client using one of a few response + packets. All requests can return a SSH_FXP_STATUS response upon + failure. When the operation is successful, any of the responses may + be returned (depending on the operation). If no data needs to be + returned to the client, the SSH_FXP_STATUS response with SSH_FX_OK + status is appropriate. Otherwise, the SSH_FXP_HANDLE message is used + to return a file handle (for SSH_FXP_OPEN and SSH_FXP_OPENDIR + requests), SSH_FXP_DATA is used to return data from SSH_FXP_READ, + SSH_FXP_NAME is used to return one or more file names from a + SSH_FXP_READDIR or SSH_FXP_REALPATH request, and SSH_FXP_ATTRS is + used to return file attributes from SSH_FXP_STAT, SSH_FXP_LSTAT, and + SSH_FXP_FSTAT requests. + + Exactly one response will be returned for each request. Each + response packet contains a request identifier which can be used to + match each response with the corresponding request. Note that it is + legal to have several requests outstanding simultaneously, and the + server is allowed to send responses to them in a different order from + the order in which the requests were sent (the result of their + execution, however, is guaranteed to be as if they had been processed + one at a time in the order in which the requests were sent). + + Response packets are of the same general format as request packets. + Each response packet begins with the request identifier. + + The format of the data portion of the SSH_FXP_STATUS response is as + follows: + + uint32 id + uint32 error/status code + string error message (ISO-10646 UTF-8 [RFC-2279]) + string language tag (as defined in [RFC-1766]) + + where `id' is the request identifier, and `error/status code' + indicates the result of the requested operation. The value SSH_FX_OK + indicates success, and all other values indicate failure. + + + + + + + + + + + + + +Ylonen & Lehtinen Expires April 1, 2002 [Page 20] + +Internet-Draft SSH File Transfer Protocol October 2001 + + + Currently, the following values are defined (other values may be + defined by future versions of this protocol): + + #define SSH_FX_OK 0 + #define SSH_FX_EOF 1 + #define SSH_FX_NO_SUCH_FILE 2 + #define SSH_FX_PERMISSION_DENIED 3 + #define SSH_FX_FAILURE 4 + #define SSH_FX_BAD_MESSAGE 5 + #define SSH_FX_NO_CONNECTION 6 + #define SSH_FX_CONNECTION_LOST 7 + #define SSH_FX_OP_UNSUPPORTED 8 + + SSH_FX_OK + Indicates successful completion of the operation. + + SSH_FX_EOF + indicates end-of-file condition; for SSH_FX_READ it means that no + more data is available in the file, and for SSH_FX_READDIR it + indicates that no more files are contained in the directory. + + SSH_FX_NO_SUCH_FILE + is returned when a reference is made to a file which should exist + but doesn't. + + SSH_FX_PERMISSION_DENIED + is returned when the authenticated user does not have sufficient + permissions to perform the operation. + + SSH_FX_FAILURE + is a generic catch-all error message; it should be returned if an + error occurs for which there is no more specific error code + defined. + + SSH_FX_BAD_MESSAGE + may be returned if a badly formatted packet or protocol + incompatibility is detected. + + SSH_FX_NO_CONNECTION + is a pseudo-error which indicates that the client has no + connection to the server (it can only be generated locally by the + client, and MUST NOT be returned by servers). + + SSH_FX_CONNECTION_LOST + is a pseudo-error which indicates that the connection to the + server has been lost (it can only be generated locally by the + client, and MUST NOT be returned by servers). + + + + +Ylonen & Lehtinen Expires April 1, 2002 [Page 21] + +Internet-Draft SSH File Transfer Protocol October 2001 + + + SSH_FX_OP_UNSUPPORTED + indicates that an attempt was made to perform an operation which + is not supported for the server (it may be generated locally by + the client if e.g. the version number exchange indicates that a + required feature is not supported by the server, or it may be + returned by the server if the server does not implement an + operation). + + The SSH_FXP_HANDLE response has the following format: + + uint32 id + string handle + + where `id' is the request identifier, and `handle' is an arbitrary + string that identifies an open file or directory on the server. The + handle is opaque to the client; the client MUST NOT attempt to + interpret or modify it in any way. The length of the handle string + MUST NOT exceed 256 data bytes. + + The SSH_FXP_DATA response has the following format: + + uint32 id + string data + + where `id' is the request identifier, and `data' is an arbitrary byte + string containing the requested data. The data string may be at most + the number of bytes requested in a SSH_FXP_READ request, but may also + be shorter if end of file is reached or if the read is from something + other than a regular file. + + The SSH_FXP_NAME response has the following format: + + uint32 id + uint32 count + repeats count times: + string filename + string longname + ATTRS attrs + + where `id' is the request identifier, `count' is the number of names + returned in this response, and the remaining fields repeat `count' + times (so that all three fields are first included for the first + file, then for the second file, etc). In the repeated part, + `filename' is a file name being returned (for SSH_FXP_READDIR, it + will be a relative name within the directory, without any path + components; for SSH_FXP_REALPATH it will be an absolute path name), + `longname' is an expanded format for the file name, similar to what + is returned by "ls -l" on Unix systems, and `attrs' is the attributes + + + +Ylonen & Lehtinen Expires April 1, 2002 [Page 22] + +Internet-Draft SSH File Transfer Protocol October 2001 + + + of the file as described in Section ``File Attributes''. + + The format of the `longname' field is unspecified by this protocol. + It MUST be suitable for use in the output of a directory listing + command (in fact, the recommended operation for a directory listing + command is to simply display this data). However, clients SHOULD NOT + attempt to parse the longname field for file attributes; they SHOULD + use the attrs field instead. + + The recommended format for the longname field is as follows: + + -rwxr-xr-x 1 mjos staff 348911 Mar 25 14:29 t-filexfer + 1234567890 123 12345678 12345678 12345678 123456789012 + + Here, the first line is sample output, and the second field indicates + widths of the various fields. Fields are separated by spaces. The + first field lists file permissions for user, group, and others; the + second field is link count; the third field is the name of the user + who owns the file; the fourth field is the name of the group that + owns the file; the fifth field is the size of the file in bytes; the + sixth field (which actually may contain spaces, but is fixed to 12 + characters) is the file modification time, and the seventh field is + the file name. Each field is specified to be a minimum of certain + number of character positions (indicated by the second line above), + but may also be longer if the data does not fit in the specified + length. + + The SSH_FXP_ATTRS response has the following format: + + uint32 id + ATTRS attrs + + where `id' is the request identifier, and `attrs' is the returned + file attributes as described in Section ``File Attributes''. + + + + + + + + + + + + + + + + + +Ylonen & Lehtinen Expires April 1, 2002 [Page 23] + +Internet-Draft SSH File Transfer Protocol October 2001 + + +8. Vendor-Specific Extensions + + The SSH_FXP_EXTENDED request provides a generic extension mechanism + for adding vendor-specific commands. The request has the following + format: + + uint32 id + string extended-request + ... any request-specific data ... + + where `id' is the request identifier, and `extended-request' is a + string of the format "name@domain", where domain is an internet + domain name of the vendor defining the request. The rest of the + request is completely vendor-specific, and servers should only + attempt to interpret it if they recognize the `extended-request' + name. + + The server may respond to such requests using any of the response + packets defined in Section ``Responses from the Server to the + Client''. Additionally, the server may also respond with a + SSH_FXP_EXTENDED_REPLY packet, as defined below. If the server does + not recognize the `extended-request' name, then the server MUST + respond with SSH_FXP_STATUS with error/status set to + SSH_FX_OP_UNSUPPORTED. + + The SSH_FXP_EXTENDED_REPLY packet can be used to carry arbitrary + extension-specific data from the server to the client. It is of the + following format: + + uint32 id + ... any request-specific data ... + + + + + + + + + + + + + + + + + + + + +Ylonen & Lehtinen Expires April 1, 2002 [Page 24] + +Internet-Draft SSH File Transfer Protocol October 2001 + + +9. Security Considerations + + This protocol assumes that it is run over a secure channel and that + the endpoints of the channel have been authenticated. Thus, this + protocol assumes that it is externally protected from network-level + attacks. + + This protocol provides file system access to arbitrary files on the + server (only constrained by the server implementation). It is the + responsibility of the server implementation to enforce any access + controls that may be required to limit the access allowed for any + particular user (the user being authenticated externally to this + protocol, typically using the SSH User Authentication Protocol [6]. + + Care must be taken in the server implementation to check the validity + of received file handle strings. The server should not rely on them + directly; it MUST check the validity of each handle before relying on + it. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Ylonen & Lehtinen Expires April 1, 2002 [Page 25] + +Internet-Draft SSH File Transfer Protocol October 2001 + + +10. Changes from previous protocol versions + + The SSH File Transfer Protocol has changed over time, before it's + standardization. The following is a description of the incompatible + changes between different versions. + +10.1 Changes between versions 3 and 2 + + o The SSH_FXP_READLINK and SSH_FXP_SYMLINK messages were added. + + o The SSH_FXP_EXTENDED and SSH_FXP_EXTENDED_REPLY messages were + added. + + o The SSH_FXP_STATUS message was changed to include fields `error + message' and `language tag'. + + +10.2 Changes between versions 2 and 1 + + o The SSH_FXP_RENAME message was added. + + +10.3 Changes between versions 1 and 0 + + o Implementation changes, no actual protocol changes. + + + + + + + + + + + + + + + + + + + + + + + + + + +Ylonen & Lehtinen Expires April 1, 2002 [Page 26] + +Internet-Draft SSH File Transfer Protocol October 2001 + + +11. Trademark Issues + + "ssh" is a registered trademark of SSH Communications Security Corp + in the United States and/or other countries. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Ylonen & Lehtinen Expires April 1, 2002 [Page 27] + +Internet-Draft SSH File Transfer Protocol October 2001 + + +References + + [1] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and + P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January + 1999. + + [2] Institute of Electrical and Electronics Engineers, "Information + Technology - Portable Operating System Interface (POSIX) - Part + 1: System Application Program Interface (API) [C Language]", + IEEE Standard 1003.2, 1996. + + [3] Rinne, T., Ylonen, T., Kivinen, T., Saarinen, M. and S. + Lehtinen, "SSH Protocol Architecture", draft-ietf-secsh- + architecture-09 (work in progress), July 2001. + + [4] Rinne, T., Ylonen, T., Kivinen, T., Saarinen, M. and S. + Lehtinen, "SSH Protocol Transport Protocol", draft-ietf-secsh- + architecture-09 (work in progress), July 2001. + + [5] Rinne, T., Ylonen, T., Kivinen, T., Saarinen, M. and S. + Lehtinen, "SSH Connection Protocol", draft-ietf-secsh-connect-11 + (work in progress), July 2001. + + [6] Rinne, T., Ylonen, T., Kivinen, T., Saarinen, M. and S. + Lehtinen, "SSH Authentication Protocol", draft-ietf-secsh- + userauth-11 (work in progress), July 2001. + + +Authors' Addresses + + Tatu Ylonen + SSH Communications Security Corp + Fredrikinkatu 42 + HELSINKI FIN-00100 + Finland + + EMail: [email protected] + + + Sami Lehtinen + SSH Communications Security Corp + Fredrikinkatu 42 + HELSINKI FIN-00100 + Finland + + EMail: [email protected] + + + + + +Ylonen & Lehtinen Expires April 1, 2002 [Page 28] + +Internet-Draft SSH File Transfer Protocol October 2001 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2001). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Ylonen & Lehtinen Expires April 1, 2002 [Page 29] + + + diff --git a/lib/ssh/doc/standard/draft-ietf-secsh-filexfer-03.2.ps b/lib/ssh/doc/standard/draft-ietf-secsh-filexfer-03.2.ps new file mode 100644 index 0000000000..6a40cd6067 --- /dev/null +++ b/lib/ssh/doc/standard/draft-ietf-secsh-filexfer-03.2.ps @@ -0,0 +1,3511 @@ +%!PS-Adobe-3.0 +%%BoundingBox: 75 0 595 747 +%%Title: Enscript Output +%%For: Magnus Thoang +%%Creator: GNU enscript 1.6.1 +%%CreationDate: Wed Nov 12 12:18:50 2003 +%%Orientation: Portrait +%%Pages: 18 0 +%%DocumentMedia: A4 595 842 0 () () +%%DocumentNeededResources: (atend) +%%EndComments +%%BeginProlog +%%BeginProcSet: PStoPS 1 15 +userdict begin +[/showpage/erasepage/copypage]{dup where{pop dup load + type/operatortype eq{1 array cvx dup 0 3 index cvx put + bind def}{pop}ifelse}{pop}ifelse}forall +[/letter/legal/executivepage/a4/a4small/b5/com10envelope + /monarchenvelope/c5envelope/dlenvelope/lettersmall/note + /folio/quarto/a5]{dup where{dup wcheck{exch{}put} + {pop{}def}ifelse}{pop}ifelse}forall +/setpagedevice {pop}bind 1 index where{dup wcheck{3 1 roll put} + {pop def}ifelse}{def}ifelse +/PStoPSmatrix matrix currentmatrix def +/PStoPSxform matrix def/PStoPSclip{clippath}def +/defaultmatrix{PStoPSmatrix exch PStoPSxform exch concatmatrix}bind def +/initmatrix{matrix defaultmatrix setmatrix}bind def +/initclip[{matrix currentmatrix PStoPSmatrix setmatrix + [{currentpoint}stopped{$error/newerror false put{newpath}} + {/newpath cvx 3 1 roll/moveto cvx 4 array astore cvx}ifelse] + {[/newpath cvx{/moveto cvx}{/lineto cvx} + {/curveto cvx}{/closepath cvx}pathforall]cvx exch pop} + stopped{$error/errorname get/invalidaccess eq{cleartomark + $error/newerror false put cvx exec}{stop}ifelse}if}bind aload pop + /initclip dup load dup type dup/operatortype eq{pop exch pop} + {dup/arraytype eq exch/packedarraytype eq or + {dup xcheck{exch pop aload pop}{pop cvx}ifelse} + {pop cvx}ifelse}ifelse + {newpath PStoPSclip clip newpath exec setmatrix} bind aload pop]cvx def +/initgraphics{initmatrix newpath initclip 1 setlinewidth + 0 setlinecap 0 setlinejoin []0 setdash 0 setgray + 10 setmiterlimit}bind def +end +%%EndProcSet +%%BeginResource: procset Enscript-Prolog 1.6 1 +% +% Procedures. +% + +/_S { % save current state + /_s save def +} def +/_R { % restore from saved state + _s restore +} def + +/S { % showpage protecting gstate + gsave + showpage + grestore +} bind def + +/MF { % fontname newfontname -> - make a new encoded font + /newfontname exch def + /fontname exch def + + /fontdict fontname findfont def + /newfont fontdict maxlength dict def + + fontdict { + exch + dup /FID eq { + % skip FID pair + pop pop + } { + % copy to the new font dictionary + exch newfont 3 1 roll put + } ifelse + } forall + + newfont /FontName newfontname put + + % insert only valid encoding vectors + encoding_vector length 256 eq { + newfont /Encoding encoding_vector put + } if + + newfontname newfont definefont pop +} def + +/SF { % fontname width height -> - set a new font + /height exch def + /width exch def + + findfont + [width 0 0 height 0 0] makefont setfont +} def + +/SUF { % fontname width height -> - set a new user font + /height exch def + /width exch def + + /F-gs-user-font MF + /F-gs-user-font width height SF +} def + +/M {moveto} bind def +/s {show} bind def + +/Box { % x y w h -> - define box path + /d_h exch def /d_w exch def /d_y exch def /d_x exch def + d_x d_y moveto + d_w 0 rlineto + 0 d_h rlineto + d_w neg 0 rlineto + closepath +} def + +/bgs { % x y height blskip gray str -> - show string with bg color + /str exch def + /gray exch def + /blskip exch def + /height exch def + /y exch def + /x exch def + + gsave + x y blskip sub str stringwidth pop height Box + gray setgray + fill + grestore + x y M str s +} def + +% Highlight bars. +/highlight_bars { % nlines lineheight output_y_margin gray -> - + gsave + setgray + /ymarg exch def + /lineheight exch def + /nlines exch def + + % This 2 is just a magic number to sync highlight lines to text. + 0 d_header_y ymarg sub 2 sub translate + + /cw d_output_w cols div def + /nrows d_output_h ymarg 2 mul sub lineheight div cvi def + + % for each column + 0 1 cols 1 sub { + cw mul /xp exch def + + % for each rows + 0 1 nrows 1 sub { + /rn exch def + rn lineheight mul neg /yp exch def + rn nlines idiv 2 mod 0 eq { + % Draw highlight bar. 4 is just a magic indentation. + xp 4 add yp cw 8 sub lineheight neg Box fill + } if + } for + } for + + grestore +} def + +% Line highlight bar. +/line_highlight { % x y width height gray -> - + gsave + /gray exch def + Box gray setgray fill + grestore +} def + +% Column separator lines. +/column_lines { + gsave + .1 setlinewidth + 0 d_footer_h translate + /cw d_output_w cols div def + 1 1 cols 1 sub { + cw mul 0 moveto + 0 d_output_h rlineto stroke + } for + grestore +} def + +% Column borders. +/column_borders { + gsave + .1 setlinewidth + 0 d_footer_h moveto + 0 d_output_h rlineto + d_output_w 0 rlineto + 0 d_output_h neg rlineto + closepath stroke + grestore +} def + +% Do the actual underlay drawing +/draw_underlay { + ul_style 0 eq { + ul_str true charpath stroke + } { + ul_str show + } ifelse +} def + +% Underlay +/underlay { % - -> - + gsave + 0 d_page_h translate + d_page_h neg d_page_w atan rotate + + ul_gray setgray + ul_font setfont + /dw d_page_h dup mul d_page_w dup mul add sqrt def + ul_str stringwidth pop dw exch sub 2 div ul_h_ptsize -2 div moveto + draw_underlay + grestore +} def + +/user_underlay { % - -> - + gsave + ul_x ul_y translate + ul_angle rotate + ul_gray setgray + ul_font setfont + 0 0 ul_h_ptsize 2 div sub moveto + draw_underlay + grestore +} def + +% Page prefeed +/page_prefeed { % bool -> - + statusdict /prefeed known { + statusdict exch /prefeed exch put + } { + pop + } ifelse +} def + +% Wrapped line markers +/wrapped_line_mark { % x y charwith charheight type -> - + /type exch def + /h exch def + /w exch def + /y exch def + /x exch def + + type 2 eq { + % Black boxes (like TeX does) + gsave + 0 setlinewidth + x w 4 div add y M + 0 h rlineto w 2 div 0 rlineto 0 h neg rlineto + closepath fill + grestore + } { + type 3 eq { + % Small arrows + gsave + .2 setlinewidth + x w 2 div add y h 2 div add M + w 4 div 0 rlineto + x w 4 div add y lineto stroke + + x w 4 div add w 8 div add y h 4 div add M + x w 4 div add y lineto + w 4 div h 8 div rlineto stroke + grestore + } { + % do nothing + } ifelse + } ifelse +} def + +% EPSF import. + +/BeginEPSF { + /b4_Inc_state save def % Save state for cleanup + /dict_count countdictstack def % Count objects on dict stack + /op_count count 1 sub def % Count objects on operand stack + userdict begin + /showpage { } def + 0 setgray 0 setlinecap + 1 setlinewidth 0 setlinejoin + 10 setmiterlimit [ ] 0 setdash newpath + /languagelevel where { + pop languagelevel + 1 ne { + false setstrokeadjust false setoverprint + } if + } if +} bind def + +/EndEPSF { + count op_count sub { pos } repeat % Clean up stacks + countdictstack dict_count sub { end } repeat + b4_Inc_state restore +} bind def + +% Check PostScript language level. +/languagelevel where { + pop /gs_languagelevel languagelevel def +} { + /gs_languagelevel 1 def +} ifelse +%%EndResource +%%BeginResource: procset Enscript-Encoding-88591 1.6 1 +/encoding_vector [ +/.notdef /.notdef /.notdef /.notdef +/.notdef /.notdef /.notdef /.notdef +/.notdef /.notdef /.notdef /.notdef +/.notdef /.notdef /.notdef /.notdef +/.notdef /.notdef /.notdef /.notdef +/.notdef /.notdef /.notdef /.notdef +/.notdef /.notdef /.notdef /.notdef +/.notdef /.notdef /.notdef /.notdef +/space /exclam /quotedbl /numbersign +/dollar /percent /ampersand /quoteright +/parenleft /parenright /asterisk /plus +/comma /hyphen /period /slash +/zero /one /two /three +/four /five /six /seven +/eight /nine /colon /semicolon +/less /equal /greater /question +/at /A /B /C +/D /E /F /G +/H /I /J /K +/L /M /N /O +/P /Q /R /S +/T /U /V /W +/X /Y /Z /bracketleft +/backslash /bracketright /asciicircum /underscore +/quoteleft /a /b /c +/d /e /f /g +/h /i /j /k +/l /m /n /o +/p /q /r /s +/t /u /v /w +/x /y /z /braceleft +/bar /braceright /tilde /.notdef +/.notdef /.notdef /.notdef /.notdef +/.notdef /.notdef /.notdef /.notdef +/.notdef /.notdef /.notdef /.notdef +/.notdef /.notdef /.notdef /.notdef +/.notdef /.notdef /.notdef /.notdef +/.notdef /.notdef /.notdef /.notdef +/.notdef /.notdef /.notdef /.notdef +/.notdef /.notdef /.notdef /.notdef +/space /exclamdown /cent /sterling +/currency /yen /brokenbar /section +/dieresis /copyright /ordfeminine /guillemotleft +/logicalnot /hyphen /registered /macron +/degree /plusminus /twosuperior /threesuperior +/acute /mu /paragraph /bullet +/cedilla /onesuperior /ordmasculine /guillemotright +/onequarter /onehalf /threequarters /questiondown +/Agrave /Aacute /Acircumflex /Atilde +/Adieresis /Aring /AE /Ccedilla +/Egrave /Eacute /Ecircumflex /Edieresis +/Igrave /Iacute /Icircumflex /Idieresis +/Eth /Ntilde /Ograve /Oacute +/Ocircumflex /Otilde /Odieresis /multiply +/Oslash /Ugrave /Uacute /Ucircumflex +/Udieresis /Yacute /Thorn /germandbls +/agrave /aacute /acircumflex /atilde +/adieresis /aring /ae /ccedilla +/egrave /eacute /ecircumflex /edieresis +/igrave /iacute /icircumflex /idieresis +/eth /ntilde /ograve /oacute +/ocircumflex /otilde /odieresis /divide +/oslash /ugrave /uacute /ucircumflex +/udieresis /yacute /thorn /ydieresis +] def +%%EndResource +%%EndProlog +%%BeginSetup +%%IncludeResource: font Courier-Bold +%%IncludeResource: font Courier +/HFpt_w 10 def +/HFpt_h 10 def +/Courier-Bold /HF-gs-font MF +/HF /HF-gs-font findfont [HFpt_w 0 0 HFpt_h 0 0] makefont def +/Courier /F-gs-font MF +/F-gs-font 10 10 SF +/#copies 1 def +/d_page_w 520 def +/d_page_h 747 def +/d_header_x 0 def +/d_header_y 747 def +/d_header_w 520 def +/d_header_h 0 def +/d_footer_x 0 def +/d_footer_y 0 def +/d_footer_w 520 def +/d_footer_h 0 def +/d_output_w 520 def +/d_output_h 747 def +/cols 1 def +userdict/PStoPSxform PStoPSmatrix matrix currentmatrix + matrix invertmatrix matrix concatmatrix + matrix invertmatrix put +%%EndSetup +%%Page: (0,1) 1 +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 0.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +/showpage{}def/copypage{}def/erasepage{}def +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 1 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 701 M +(Secure Shell Working Group J. Galbraith) s +5 690 M +(Internet-Draft VanDyke Software) s +5 679 M +(Expires: April 16, 2003 T. Ylonen) s +5 668 M +( S. Lehtinen) s +5 657 M +( SSH Communications Security Corp) s +5 646 M +( October 16, 2002) s +5 613 M +( SSH File Transfer Protocol) s +5 602 M +( draft-ietf-secsh-filexfer-03.txt) s +5 580 M +(Status of this Memo) s +5 558 M +( This document is an Internet-Draft and is in full conformance with) s +5 547 M +( all provisions of Section 10 of RFC2026.) s +5 525 M +( Internet-Drafts are working documents of the Internet Engineering) s +5 514 M +( Task Force \(IETF\), its areas, and its working groups. Note that) s +5 503 M +( other groups may also distribute working documents as Internet-) s +5 492 M +( Drafts.) s +5 470 M +( Internet-Drafts are draft documents valid for a maximum of six months) s +5 459 M +( and may be updated, replaced, or obsoleted by other documents at any) s +5 448 M +( time. It is inappropriate to use Internet-Drafts as reference) s +5 437 M +( material or to cite them other than as "work in progress.") s +5 415 M +( The list of current Internet-Drafts can be accessed at http://) s +5 404 M +( www.ietf.org/ietf/1id-abstracts.txt.) s +5 382 M +( The list of Internet-Draft Shadow Directories can be accessed at) s +5 371 M +( http://www.ietf.org/shadow.html.) s +5 349 M +( This Internet-Draft will expire on April 16, 2003.) s +5 327 M +(Copyright Notice) s +5 305 M +( Copyright \(C\) The Internet Society \(2002\). All Rights Reserved.) s +5 283 M +(Abstract) s +5 261 M +( The SSH File Transfer Protocol provides secure file transfer) s +5 250 M +( functionality over any reliable data stream. It is the standard file) s +5 239 M +( transfer protocol for use with the SSH2 protocol. This document) s +5 228 M +( describes the file transfer protocol and its interface to the SSH2) s +5 217 M +( protocol suite.) s +5 129 M +(Galbraith, et al. Expires April 16, 2003 [Page 1]) s +_R +S +PStoPSsaved restore +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 421.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 2 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH File Transfer Protocol October 2002) s +5 690 M +(Table of Contents) s +5 668 M +( 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3) s +5 657 M +( 2. Use with the SSH Connection Protocol . . . . . . . . . . . 4) s +5 646 M +( 3. General Packet Format . . . . . . . . . . . . . . . . . . 5) s +5 635 M +( 4. Protocol Initialization . . . . . . . . . . . . . . . . . 7) s +5 624 M +( 4.1 Client Initialization . . . . . . . . . . . . . . . . . . 7) s +5 613 M +( 4.2 Server Initialization . . . . . . . . . . . . . . . . . . 7) s +5 602 M +( 4.3 Determining Server Newline Convention . . . . . . . . . . 8) s +5 591 M +( 5. File Attributes . . . . . . . . . . . . . . . . . . . . . 9) s +5 580 M +( 5.1 Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 9) s +5 569 M +( 5.2 Type . . . . . . . . . . . . . . . . . . . . . . . . . . . 10) s +5 558 M +( 5.3 Size . . . . . . . . . . . . . . . . . . . . . . . . . . . 10) s +5 547 M +( 5.4 Owner and Group . . . . . . . . . . . . . . . . . . . . . 10) s +5 536 M +( 5.5 Permissions . . . . . . . . . . . . . . . . . . . . . . . 11) s +5 525 M +( 5.6 Times . . . . . . . . . . . . . . . . . . . . . . . . . . 11) s +5 514 M +( 5.7 ACL . . . . . . . . . . . . . . . . . . . . . . . . . . . 11) s +5 503 M +( 5.8 Extended attributes . . . . . . . . . . . . . . . . . . . 12) s +5 492 M +( 6. Requests From the Client to the Server . . . . . . . . . . 13) s +5 481 M +( 6.1 Request Synchronization and Reordering . . . . . . . . . . 13) s +5 470 M +( 6.2 File Names . . . . . . . . . . . . . . . . . . . . . . . . 14) s +5 459 M +( 6.3 Opening, Creating, and Closing Files . . . . . . . . . . . 14) s +5 448 M +( 6.4 Reading and Writing . . . . . . . . . . . . . . . . . . . 17) s +5 437 M +( 6.5 Removing and Renaming Files . . . . . . . . . . . . . . . 18) s +5 426 M +( 6.6 Creating and Deleting Directories . . . . . . . . . . . . 19) s +5 415 M +( 6.7 Scanning Directories . . . . . . . . . . . . . . . . . . . 19) s +5 404 M +( 6.8 Retrieving File Attributes . . . . . . . . . . . . . . . . 20) s +5 393 M +( 6.9 Setting File Attributes . . . . . . . . . . . . . . . . . 21) s +5 382 M +( 6.10 Dealing with Symbolic links . . . . . . . . . . . . . . . 22) s +5 371 M +( 6.11 Canonicalizing the Server-Side Path Name . . . . . . . . . 23) s +5 360 M +( 6.11.1 Best practice for dealing with paths . . . . . . . . . . . 23) s +5 349 M +( 7. Responses from the Server to the Client . . . . . . . . . 24) s +5 338 M +( 8. Vendor-Specific Extensions . . . . . . . . . . . . . . . . 28) s +5 327 M +( 9. Security Considerations . . . . . . . . . . . . . . . . . 29) s +5 316 M +( 10. Changes from previous protocol versions . . . . . . . . . 30) s +5 305 M +( 10.1 Changes between versions 4 and 3 . . . . . . . . . . . . . 30) s +5 294 M +( 10.2 Changes between versions 3 and 2 . . . . . . . . . . . . . 31) s +5 283 M +( 10.3 Changes between versions 2 and 1 . . . . . . . . . . . . . 31) s +5 272 M +( 10.4 Changes between versions 1 and 0 . . . . . . . . . . . . . 31) s +5 261 M +( 11. Trademark Issues . . . . . . . . . . . . . . . . . . . . . 32) s +5 250 M +( References . . . . . . . . . . . . . . . . . . . . . . . . 33) s +5 239 M +( Authors' Addresses . . . . . . . . . . . . . . . . . . . . 33) s +5 228 M +( Full Copyright Statement . . . . . . . . . . . . . . . . . 35) s +5 129 M +(Galbraith, et al. Expires April 16, 2003 [Page 2]) s +_R +S +PStoPSsaved restore +%%Page: (2,3) 2 +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 0.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +/showpage{}def/copypage{}def/erasepage{}def +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 3 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH File Transfer Protocol October 2002) s +5 690 M +(1. Introduction) s +5 668 M +( This protocol provides secure file transfer \(and more generally file) s +5 657 M +( system access\) functionality over a reliable data stream, such as a) s +5 646 M +( channel in the SSH2 protocol [5].) s +5 624 M +( This protocol is designed so that it could be used to implement a) s +5 613 M +( secure remote file system service, as well as a secure file transfer) s +5 602 M +( service.) s +5 580 M +( This protocol assumes that it runs over a secure channel, and that) s +5 569 M +( the server has already authenticated the user at the client end, and) s +5 558 M +( that the identity of the client user is externally available to the) s +5 547 M +( server implementation.) s +5 525 M +( In general, this protocol follows a simple request-response model.) s +5 514 M +( Each request and response contains a sequence number and multiple) s +5 503 M +( requests may be pending simultaneously. There are a relatively large) s +5 492 M +( number of different request messages, but a small number of possible) s +5 481 M +( response messages. Each request has one or more response messages) s +5 470 M +( that may be returned in result \(e.g., a read either returns data or) s +5 459 M +( reports error status\).) s +5 437 M +( The packet format descriptions in this specification follow the) s +5 426 M +( notation presented in the secsh architecture draft. [5]) s +5 404 M +( Even though this protocol is described in the context of the SSH2) s +5 393 M +( protocol, this protocol is general and independent of the rest of the) s +5 382 M +( SSH2 protocol suite. It could be used in a number of different) s +5 371 M +( applications, such as secure file transfer over TLS RFC 2246 [1] and) s +5 360 M +( transfer of management information in VPN applications.) s +5 129 M +(Galbraith, et al. Expires April 16, 2003 [Page 3]) s +_R +S +PStoPSsaved restore +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 421.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 4 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH File Transfer Protocol October 2002) s +5 690 M +(2. Use with the SSH Connection Protocol) s +5 668 M +( When used with the SSH2 Protocol suite, this protocol is intended to) s +5 657 M +( be used from the SSH Connection Protocol [7] as a subsystem, as) s +5 646 M +( described in section ``Starting a Shell or a Command''. The) s +5 635 M +( subsystem name used with this protocol is "sftp".) s +5 129 M +(Galbraith, et al. Expires April 16, 2003 [Page 4]) s +_R +S +PStoPSsaved restore +%%Page: (4,5) 3 +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 0.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +/showpage{}def/copypage{}def/erasepage{}def +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 5 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH File Transfer Protocol October 2002) s +5 690 M +(3. General Packet Format) s +5 668 M +( All packets transmitted over the secure connection are of the) s +5 657 M +( following format:) s +5 635 M +( uint32 length) s +5 624 M +( byte type) s +5 613 M +( byte[length - 1] data payload) s +5 591 M +( That is, they are just data preceded by 32-bit length and 8-bit type) s +5 580 M +( fields. The `length' is the length of the data area, and does not) s +5 569 M +( include the `length' field itself. The format and interpretation of) s +5 558 M +( the data area depends on the packet type.) s +5 536 M +( All packet descriptions below only specify the packet type and the) s +5 525 M +( data that goes into the data field. Thus, they should be prefixed by) s +5 514 M +( the `length' and `type' fields.) s +5 492 M +( The maximum size of a packet is in practice determined by the client) s +5 481 M +( \(the maximum size of read or write requests that it sends, plus a few) s +5 470 M +( bytes of packet overhead\). All servers SHOULD support packets of at) s +5 459 M +( least 34000 bytes \(where the packet size refers to the full length,) s +5 448 M +( including the header above\). This should allow for reads and writes) s +5 437 M +( of at most 32768 bytes.) s +5 415 M +( There is no limit on the number of outstanding \(non-acknowledged\)) s +5 404 M +( requests that the client may send to the server. In practice this is) s +5 393 M +( limited by the buffering available on the data stream and the queuing) s +5 382 M +( performed by the server. If the server's queues are full, it should) s +5 371 M +( not read any more data from the stream, and flow control will prevent) s +5 360 M +( the client from sending more requests. Note, however, that while) s +5 349 M +( there is no restriction on the protocol level, the client's API may) s +5 338 M +( provide a limit in order to prevent infinite queuing of outgoing) s +5 327 M +( requests at the client.) s +5 305 M +( The following values are defined for packet types.) s +5 129 M +(Galbraith, et al. Expires April 16, 2003 [Page 5]) s +_R +S +PStoPSsaved restore +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 421.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 6 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH File Transfer Protocol October 2002) s +5 690 M +( #define SSH_FXP_INIT 1) s +5 679 M +( #define SSH_FXP_VERSION 2) s +5 668 M +( #define SSH_FXP_OPEN 3) s +5 657 M +( #define SSH_FXP_CLOSE 4) s +5 646 M +( #define SSH_FXP_READ 5) s +5 635 M +( #define SSH_FXP_WRITE 6) s +5 624 M +( #define SSH_FXP_LSTAT 7) s +5 613 M +( #define SSH_FXP_FSTAT 8) s +5 602 M +( #define SSH_FXP_SETSTAT 9) s +5 591 M +( #define SSH_FXP_FSETSTAT 10) s +5 580 M +( #define SSH_FXP_OPENDIR 11) s +5 569 M +( #define SSH_FXP_READDIR 12) s +5 558 M +( #define SSH_FXP_REMOVE 13) s +5 547 M +( #define SSH_FXP_MKDIR 14) s +5 536 M +( #define SSH_FXP_RMDIR 15) s +5 525 M +( #define SSH_FXP_REALPATH 16) s +5 514 M +( #define SSH_FXP_STAT 17) s +5 503 M +( #define SSH_FXP_RENAME 18) s +5 492 M +( #define SSH_FXP_READLINK 19) s +5 481 M +( #define SSH_FXP_SYMLINK 20) s +5 459 M +( #define SSH_FXP_STATUS 101) s +5 448 M +( #define SSH_FXP_HANDLE 102) s +5 437 M +( #define SSH_FXP_DATA 103) s +5 426 M +( #define SSH_FXP_NAME 104) s +5 415 M +( #define SSH_FXP_ATTRS 105) s +5 393 M +( #define SSH_FXP_EXTENDED 200) s +5 382 M +( #define SSH_FXP_EXTENDED_REPLY 201) s +5 360 M +( RESERVED_FOR_EXTENSIONS 210-255) s +5 338 M +( Additional packet types should only be defined if the protocol) s +5 327 M +( version number \(see Section ``Protocol Initialization''\) is) s +5 316 M +( incremented, and their use MUST be negotiated using the version) s +5 305 M +( number. However, the SSH_FXP_EXTENDED and SSH_FXP_EXTENDED_REPLY) s +5 294 M +( packets can be used to implement vendor-specific extensions. See) s +5 283 M +( Section ``Vendor-Specific-Extensions'' for more details.) s +5 129 M +(Galbraith, et al. Expires April 16, 2003 [Page 6]) s +_R +S +PStoPSsaved restore +%%Page: (6,7) 4 +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 0.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +/showpage{}def/copypage{}def/erasepage{}def +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 7 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH File Transfer Protocol October 2002) s +5 690 M +(4. Protocol Initialization) s +5 668 M +( When the file transfer protocol starts, the client first sends a) s +5 657 M +( SSH_FXP_INIT \(including its version number\) packet to the server.) s +5 646 M +( The server responds with a SSH_FXP_VERSION packet, supplying the) s +5 635 M +( lowest of its own and the client's version number. Both parties) s +5 624 M +( should from then on adhere to particular version of the protocol.) s +5 602 M +( The version number of the protocol specified in this document is 4.) s +5 591 M +( The version number should be incremented for each incompatible) s +5 580 M +( revision of this protocol.) s +5 558 M +(4.1 Client Initialization) s +5 536 M +( The SSH_FXP_INIT packet \(from client to server\) has the following) s +5 525 M +( data:) s +5 503 M +( uint32 version) s +5 481 M +( Version 3 of this protocol allowed clients to include extensions in) s +5 470 M +( the SSH_FXP_INIT packet; however, this can cause interoperability) s +5 459 M +( problems with version 1 and version 2 servers because the client must) s +5 448 M +( send this packet before knowing the servers version.) s +5 426 M +( In this version of the protocol, clients MUST use the) s +5 415 M +( SSH_FXP_EXTENDED packet to send extensions to the server after) s +5 404 M +( version exchange has completed. Clients MUST NOT include extensions) s +5 393 M +( in the version packet. This will prevent interoperability problems) s +5 382 M +( with older servers) s +5 360 M +(4.2 Server Initialization) s +5 338 M +( The SSH_FXP_VERSION packet \(from server to client\) has the following) s +5 327 M +( data:) s +5 305 M +( uint32 version) s +5 294 M +( <extension data>) s +5 272 M +( 'version' is the lower of the protocol version supported by the) s +5 261 M +( server and the version number received from the client.) s +5 239 M +( The extension data may be empty, or may be a sequence of) s +5 217 M +( string extension_name) s +5 206 M +( string extension_data) s +5 184 M +( pairs \(both strings MUST always be present if one is, but the) s +5 173 M +( `extension_data' string may be of zero length\). If present, these) s +5 129 M +(Galbraith, et al. Expires April 16, 2003 [Page 7]) s +_R +S +PStoPSsaved restore +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 421.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 8 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH File Transfer Protocol October 2002) s +5 690 M +( strings indicate extensions to the baseline protocol. The) s +5 679 M +( `extension_name' field\(s\) identify the name of the extension. The) s +5 668 M +( name should be of the form "name@domain", where the domain is the DNS) s +5 657 M +( domain name of the organization defining the extension. Additional) s +5 646 M +( names that are not of this format may be defined later by the IETF.) s +5 635 M +( Implementations MUST silently ignore any extensions whose name they) s +5 624 M +( do not recognize.) s +5 602 M +(4.3 Determining Server Newline Convention) s +5 580 M +( In order to correctly process text files in a cross platform) s +5 569 M +( compatible way, the newline convention must be converted from that of) s +5 558 M +( the server to that of the client, or, during an upload, from that of) s +5 547 M +( the client to that of the server.) s +5 525 M +( Versions 3 and prior of this protocol made no provisions for) s +5 514 M +( processing text files. Many clients implemented some sort of) s +5 503 M +( conversion algorithm, but without either a 'canonical' on the wire) s +5 492 M +( format or knowledge of the servers newline convention, correct) s +5 481 M +( conversion was not always possible.) s +5 459 M +( Starting with Version 4, the SSH_FXF_TEXT file open flag \(Section) s +5 448 M +( 6.3\) makes it possible to request that the server translate a file to) s +5 437 M +( a 'canonical' on the wire format. This format uses \\r\\n as the line) s +5 426 M +( separator.) s +5 404 M +( Servers for systems using multiple newline characters \(for example,) s +5 393 M +( Mac OS X or VMS\) or systems using counted records, MUST translate to) s +5 382 M +( the canonical form.) s +5 360 M +( However, to ease the burden of implementation on servers that use a) s +5 349 M +( single, simple separator sequence, the following extension allows the) s +5 338 M +( canonical format to be changed.) s +5 316 M +( string "newline") s +5 305 M +( string new-canonical-separator \(usually "\\r" or "\\n" or "\\r\\n"\)) s +5 283 M +( All clients MUST support this extension.) s +5 261 M +( When processing text files, clients SHOULD NOT translate any) s +5 250 M +( character or sequence that is not an exact match of the servers) s +5 239 M +( newline separator.) s +5 217 M +( In particular, if the newline sequence being used is the canonical) s +5 206 M +( "\\r\\n" sequence, a lone \\r or a lone \\n SHOULD be written through) s +5 195 M +( without change.) s +5 129 M +(Galbraith, et al. Expires April 16, 2003 [Page 8]) s +_R +S +PStoPSsaved restore +%%Page: (8,9) 5 +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 0.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +/showpage{}def/copypage{}def/erasepage{}def +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 9 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH File Transfer Protocol October 2002) s +5 690 M +(5. File Attributes) s +5 668 M +( A new compound data type is defined for encoding file attributes.) s +5 657 M +( The same encoding is used both when returning file attributes from) s +5 646 M +( the server and when sending file attributes to the server. When) s +5 635 M +( sending it to the server, the flags field specifies which attributes) s +5 624 M +( are included, and the server will use default values for the) s +5 613 M +( remaining attributes \(or will not modify the values of remaining) s +5 602 M +( attributes\). When receiving attributes from the server, the flags) s +5 591 M +( specify which attributes are included in the returned data. The) s +5 580 M +( server normally returns all attributes it knows about.) s +5 558 M +( uint32 flags) s +5 547 M +( byte type always present) s +5 536 M +( uint64 size present only if flag SSH_FILEXFER_ATTR_SIZE) s +5 525 M +( string owner present only if flag SSH_FILEXFER_ATTR_OWNERGROUP) s +5 514 M +( string group present only if flag SSH_FILEXFER_ATTR_OWNERGROUP) s +5 503 M +( uint32 permissions present only if flag SSH_FILEXFER_ATTR_PERMISSIONS) s +5 492 M +( uint32 atime present only if flag SSH_FILEXFER_ATTR_ACCESSTIME) s +5 481 M +( uint32 createtime present only if flag SSH_FILEXFER_ATTR_CREATETIME) s +5 470 M +( uint32 mtime present only if flag SSH_FILEXFER_ATTR_MODIFYTIME) s +5 459 M +( string acl present only if flag SSH_FILEXFER_ATTR_ACL) s +5 448 M +( uint32 extended_count present only if flag SSH_FILEXFER_ATTR_EXTENDED) s +5 437 M +( string extended_type) s +5 426 M +( string extended_data) s +5 415 M +( ... more extended data \(extended_type - extended_data pairs\),) s +5 404 M +( so that number of pairs equals extended_count) s +5 371 M +(5.1 Flags) s +5 349 M +( The `flags' specify which of the fields are present. Those fields) s +5 338 M +( for which the corresponding flag is not set are not present \(not) s +5 327 M +( included in the packet\). New flags can only be added by incrementing) s +5 316 M +( the protocol version number \(or by using the extension mechanism) s +5 305 M +( described below\).) s +5 283 M +( The flags bits are defined to have the following values:) s +5 261 M +( #define SSH_FILEXFER_ATTR_SIZE 0x00000001) s +5 250 M +( #define SSH_FILEXFER_ATTR_PERMISSIONS 0x00000004) s +5 239 M +( #define SSH_FILEXFER_ATTR_ACCESSTIME 0x00000008) s +5 228 M +( #define SSH_FILEXFER_ATTR_CREATETIME 0x00000010) s +5 217 M +( #define SSH_FILEXFER_ATTR_MODIFYTIME 0x00000020) s +5 206 M +( #define SSH_FILEXFER_ATTR_ACL 0x00000040) s +5 195 M +( #define SSH_FILEXFER_ATTR_OWNERGROUP 0x00000080) s +5 184 M +( #define SSH_FILEXFER_ATTR_EXTENDED 0x80000000) s +5 129 M +(Galbraith, et al. Expires April 16, 2003 [Page 9]) s +_R +S +PStoPSsaved restore +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 421.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 10 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH File Transfer Protocol October 2002) s +5 690 M +( In previous versions of this protocol flags value 0x00000002 was) s +5 679 M +( SSH_FILEXFER_ATTR_UIDGID. This value is now unused, and OWNERGROUP) s +5 668 M +( was given a new value in order to ease implementation burden.) s +5 657 M +( 0x00000002 MUST NOT appear in the mask. Some future version of this) s +5 646 M +( protocol may reuse flag 0x00000002.) s +5 624 M +(5.2 Type) s +5 602 M +( The type field is always present. The following types are defined:) s +5 580 M +( #define SSH_FILEXFER_TYPE_REGULAR 1) s +5 569 M +( #define SSH_FILEXFER_TYPE_DIRECTORY 2) s +5 558 M +( #define SSH_FILEXFER_TYPE_SYMLINK 3) s +5 547 M +( #define SSH_FILEXFER_TYPE_SPECIAL 4) s +5 536 M +( #define SSH_FILEXFER_TYPE_UNKNOWN 5) s +5 514 M +( On a POSIX system, these values would be derived from the permission) s +5 503 M +( field.) s +5 481 M +(5.3 Size) s +5 459 M +( The `size' field specifies the size of the file on disk, in bytes.) s +5 448 M +( If it is present during file creation, it should be considered a hint) s +5 437 M +( as to the files eventual size.) s +5 415 M +( Files opened with the SSH_FXF_TEXT flag may have a size that is) s +5 404 M +( greater or less than the value of the size field.) s +5 382 M +(5.4 Owner and Group) s +5 360 M +( The `owner' and `group' fields are represented as UTF-8 strings; this) s +5 349 M +( is the form used by NFS v4. See NFS version 4 Protocol. [3] The) s +5 338 M +( following text is selected quotations from section 5.6.) s +5 316 M +( To avoid a representation that is tied to a particular underlying) s +5 305 M +( implementation at the client or server, the use of UTF-8 strings has) s +5 294 M +( been chosen. The string should be of the form user@dns_domain".) s +5 283 M +( This will allow for a client and server that do not use the same) s +5 272 M +( local representation the ability to translate to a common syntax that) s +5 261 M +( can be interpreted by both. In the case where there is no) s +5 250 M +( translation available to the client or server, the attribute value) s +5 239 M +( must be constructed without the "@". Therefore, the absence of the @) s +5 228 M +( from the owner or owner_group attribute signifies that no translation) s +5 217 M +( was available and the receiver of the attribute should not place any) s +5 206 M +( special meaning with the attribute value. Even though the attribute) s +5 195 M +( value can not be translated, it may still be useful. In the case of) s +5 184 M +( a client, the attribute string may be used for local display of) s +5 173 M +( ownership.) s +5 129 M +(Galbraith, et al. Expires April 16, 2003 [Page 10]) s +_R +S +PStoPSsaved restore +%%Page: (10,11) 6 +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 0.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +/showpage{}def/copypage{}def/erasepage{}def +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 11 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH File Transfer Protocol October 2002) s +5 690 M +(5.5 Permissions) s +5 668 M +( The `permissions' field contains a bit mask of file permissions as) s +5 657 M +( defined by POSIX [1].) s +5 635 M +(5.6 Times) s +5 613 M +( The 'atime', 'createtime', and 'mtime' contain the access, creation,) s +5 602 M +( and modification times of the files, respectively. They are) s +5 591 M +( represented as seconds from Jan 1, 1970 in UTC.) s +5 569 M +(5.7 ACL) s +5 547 M +( The 'ACL' field contains an ACL similar to that defined in section) s +5 536 M +( 5.9 of NFS version 4 Protocol [3].) s +5 514 M +( uint32 ace-count) s +5 492 M +( repeated ace-count time:) s +5 481 M +( uint32 ace-type) s +5 470 M +( uint32 ace-flag) s +5 459 M +( uint32 ace-mask) s +5 448 M +( string who [UTF-8]) s +5 426 M +( ace-type is one of the following four values \(taken from NFS Version) s +5 415 M +( 4 Protocol [3]:) s +5 393 M +( const ACE4_ACCESS_ALLOWED_ACE_TYPE = 0x00000000;) s +5 382 M +( const ACE4_ACCESS_DENIED_ACE_TYPE = 0x00000001;) s +5 371 M +( const ACE4_SYSTEM_AUDIT_ACE_TYPE = 0x00000002;) s +5 360 M +( const ACE4_SYSTEM_ALARM_ACE_TYPE = 0x00000003;) s +5 338 M +( ace-flag is a combination of the following flag values. See NFS) s +5 327 M +( Version 4 Protocol [3] section 5.9.2:) s +5 305 M +( const ACE4_FILE_INHERIT_ACE = 0x00000001;) s +5 294 M +( const ACE4_DIRECTORY_INHERIT_ACE = 0x00000002;) s +5 283 M +( const ACE4_NO_PROPAGATE_INHERIT_ACE = 0x00000004;) s +5 272 M +( const ACE4_INHERIT_ONLY_ACE = 0x00000008;) s +5 261 M +( const ACE4_SUCCESSFUL_ACCESS_ACE_FLAG = 0x00000010;) s +5 250 M +( const ACE4_FAILED_ACCESS_ACE_FLAG = 0x00000020;) s +5 239 M +( const ACE4_IDENTIFIER_GROUP = 0x00000040;) s +5 217 M +( ace-mask is any combination of the following flags \(taken from NFS) s +5 206 M +( Version 4 Protocol [3] section 5.9.3:) s +5 129 M +(Galbraith, et al. Expires April 16, 2003 [Page 11]) s +_R +S +PStoPSsaved restore +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 421.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 12 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH File Transfer Protocol October 2002) s +5 690 M +( const ACE4_READ_DATA = 0x00000001;) s +5 679 M +( const ACE4_LIST_DIRECTORY = 0x00000001;) s +5 668 M +( const ACE4_WRITE_DATA = 0x00000002;) s +5 657 M +( const ACE4_ADD_FILE = 0x00000002;) s +5 646 M +( const ACE4_APPEND_DATA = 0x00000004;) s +5 635 M +( const ACE4_ADD_SUBDIRECTORY = 0x00000004;) s +5 624 M +( const ACE4_READ_NAMED_ATTRS = 0x00000008;) s +5 613 M +( const ACE4_WRITE_NAMED_ATTRS = 0x00000010;) s +5 602 M +( const ACE4_EXECUTE = 0x00000020;) s +5 591 M +( const ACE4_DELETE_CHILD = 0x00000040;) s +5 580 M +( const ACE4_READ_ATTRIBUTES = 0x00000080;) s +5 569 M +( const ACE4_WRITE_ATTRIBUTES = 0x00000100;) s +5 558 M +( const ACE4_DELETE = 0x00010000;) s +5 547 M +( const ACE4_READ_ACL = 0x00020000;) s +5 536 M +( const ACE4_WRITE_ACL = 0x00040000;) s +5 525 M +( const ACE4_WRITE_OWNER = 0x00080000;) s +5 514 M +( const ACE4_SYNCHRONIZE = 0x00100000;) s +5 492 M +( who is a UTF-8 string of the form described in 'Owner and Group') s +5 481 M +( \(Section 5.4\)) s +5 459 M +(5.8 Extended attributes) s +5 437 M +( The SSH_FILEXFER_ATTR_EXTENDED flag provides a general extension) s +5 426 M +( mechanism for vendor-specific extensions. If the flag is specified,) s +5 415 M +( then the `extended_count' field is present. It specifies the number) s +5 404 M +( of extended_type-extended_data pairs that follow. Each of these) s +5 393 M +( pairs specifies an extended attribute. For each of the attributes,) s +5 382 M +( the extended_type field should be a string of the format) s +5 371 M +( "name@domain", where "domain" is a valid, registered domain name and) s +5 360 M +( "name" identifies the method. The IETF may later standardize certain) s +5 349 M +( names that deviate from this format \(e.g., that do not contain the) s +5 338 M +( "@" sign\). The interpretation of `extended_data' depends on the) s +5 327 M +( type. Implementations SHOULD ignore extended data fields that they) s +5 316 M +( do not understand.) s +5 294 M +( Additional fields can be added to the attributes by either defining) s +5 283 M +( additional bits to the flags field to indicate their presence, or by) s +5 272 M +( defining extended attributes for them. The extended attributes) s +5 261 M +( mechanism is recommended for most purposes; additional flags bits) s +5 250 M +( should only be defined by an IETF standards action that also) s +5 239 M +( increments the protocol version number. The use of such new fields) s +5 228 M +( MUST be negotiated by the version number in the protocol exchange.) s +5 217 M +( It is a protocol error if a packet with unsupported protocol bits is) s +5 206 M +( received.) s +5 129 M +(Galbraith, et al. Expires April 16, 2003 [Page 12]) s +_R +S +PStoPSsaved restore +%%Page: (12,13) 7 +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 0.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +/showpage{}def/copypage{}def/erasepage{}def +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 13 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH File Transfer Protocol October 2002) s +5 690 M +(6. Requests From the Client to the Server) s +5 668 M +( Requests from the client to the server represent the various file) s +5 657 M +( system operations. Each request begins with an `id' field, which is) s +5 646 M +( a 32-bit identifier identifying the request \(selected by the client\).) s +5 635 M +( The same identifier will be returned in the response to the request.) s +5 624 M +( One possible implementation is a monotonically increasing request) s +5 613 M +( sequence number \(modulo 2^32\).) s +5 591 M +( Many operations in the protocol operate on open files. The) s +5 580 M +( SSH_FXP_OPEN request can return a file handle \(which is an opaque) s +5 569 M +( variable-length string\) which may be used to access the file later) s +5 558 M +( \(e.g. in a read operation\). The client MUST NOT send requests the) s +5 547 M +( server with bogus or closed handles. However, the server MUST) s +5 536 M +( perform adequate checks on the handle in order to avoid security) s +5 525 M +( risks due to fabricated handles.) s +5 503 M +( This design allows either stateful and stateless server) s +5 492 M +( implementation, as well as an implementation which caches state) s +5 481 M +( between requests but may also flush it. The contents of the file) s +5 470 M +( handle string are entirely up to the server and its design. The) s +5 459 M +( client should not modify or attempt to interpret the file handle) s +5 448 M +( strings.) s +5 426 M +( The file handle strings MUST NOT be longer than 256 bytes.) s +5 404 M +(6.1 Request Synchronization and Reordering) s +5 382 M +( The protocol and implementations MUST process requests relating to) s +5 371 M +( the same file in the order in which they are received. In other) s +5 360 M +( words, if an application submits multiple requests to the server, the) s +5 349 M +( results in the responses will be the same as if it had sent the) s +5 338 M +( requests one at a time and waited for the response in each case. For) s +5 327 M +( example, the server may process non-overlapping read/write requests) s +5 316 M +( to the same file in parallel, but overlapping reads and writes cannot) s +5 305 M +( be reordered or parallelized. However, there are no ordering) s +5 294 M +( restrictions on the server for processing requests from two different) s +5 283 M +( file transfer connections. The server may interleave and parallelize) s +5 272 M +( them at will.) s +5 250 M +( There are no restrictions on the order in which responses to) s +5 239 M +( outstanding requests are delivered to the client, except that the) s +5 228 M +( server must ensure fairness in the sense that processing of no) s +5 217 M +( request will be indefinitely delayed even if the client is sending) s +5 206 M +( other requests so that there are multiple outstanding requests all) s +5 195 M +( the time.) s +5 129 M +(Galbraith, et al. Expires April 16, 2003 [Page 13]) s +_R +S +PStoPSsaved restore +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 421.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 14 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH File Transfer Protocol October 2002) s +5 690 M +(6.2 File Names) s +5 668 M +( This protocol represents file names as strings. File names are) s +5 657 M +( assumed to use the slash \('/'\) character as a directory separator.) s +5 635 M +( File names starting with a slash are "absolute", and are relative to) s +5 624 M +( the root of the file system. Names starting with any other character) s +5 613 M +( are relative to the user's default directory \(home directory\). Note) s +5 602 M +( that identifying the user is assumed to take place outside of this) s +5 591 M +( protocol.) s +5 569 M +( Servers SHOULD interpret a path name component ".." as referring to) s +5 558 M +( the parent directory, and "." as referring to the current directory.) s +5 547 M +( If the server implementation limits access to certain parts of the) s +5 536 M +( file system, it must be extra careful in parsing file names when) s +5 525 M +( enforcing such restrictions. There have been numerous reported) s +5 514 M +( security bugs where a ".." in a path name has allowed access outside) s +5 503 M +( the intended area.) s +5 481 M +( An empty path name is valid, and it refers to the user's default) s +5 470 M +( directory \(usually the user's home directory\).) s +5 448 M +( Otherwise, no syntax is defined for file names by this specification.) s +5 437 M +( Clients should not make any other assumptions; however, they can) s +5 426 M +( splice path name components returned by SSH_FXP_READDIR together) s +5 415 M +( using a slash \('/'\) as the separator, and that will work as expected.) s +5 393 M +( In order to comply with IETF Policy on Character Sets and Languages) s +5 382 M +( [2], all filenames are to be encoded in UTF-8. The shortest valid) s +5 371 M +( UTF-8 encoding of the UNICODE data MUST be used. The server is) s +5 360 M +( responsible for converting the UNICODE data to whatever canonical) s +5 349 M +( form it requires.) s +5 327 M +( For example, if the server requires that precomposed characters) s +5 316 M +( always be used, the server MUST NOT assume the filename as sent by) s +5 305 M +( the client has this attribute, but must do this normalization itself.) s +5 283 M +( It is understood that the lack of well-defined semantics for file) s +5 272 M +( names may cause interoperability problems between clients and servers) s +5 261 M +( using radically different operating systems. However, this approach) s +5 250 M +( is known to work acceptably with most systems, and alternative) s +5 239 M +( approaches that e.g. treat file names as sequences of structured) s +5 228 M +( components are quite complicated.) s +5 206 M +(6.3 Opening, Creating, and Closing Files) s +5 184 M +( Files are opened and created using the SSH_FXP_OPEN message, whose) s +5 173 M +( data part is as follows:) s +5 129 M +(Galbraith, et al. Expires April 16, 2003 [Page 14]) s +_R +S +PStoPSsaved restore +%%Page: (14,15) 8 +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 0.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +/showpage{}def/copypage{}def/erasepage{}def +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 15 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH File Transfer Protocol October 2002) s +5 690 M +( uint32 id) s +5 679 M +( string filename [UTF-8]) s +5 668 M +( uint32 pflags) s +5 657 M +( ATTRS attrs) s +5 635 M +( The `id' field is the request identifier as for all requests.) s +5 613 M +( The `filename' field specifies the file name. See Section ``File) s +5 602 M +( Names'' for more information.) s +5 580 M +( The `pflags' field is a bitmask. The following bits have been) s +5 569 M +( defined.) s +5 547 M +( #define SSH_FXF_READ 0x00000001) s +5 536 M +( #define SSH_FXF_WRITE 0x00000002) s +5 525 M +( #define SSH_FXF_APPEND 0x00000004) s +5 514 M +( #define SSH_FXF_CREAT 0x00000008) s +5 503 M +( #define SSH_FXF_TRUNC 0x00000010) s +5 492 M +( #define SSH_FXF_EXCL 0x00000020) s +5 481 M +( #define SSH_FXF_TEXT 0x00000040) s +5 459 M +( These have the following meanings:) s +5 437 M +( SSH_FXF_READ) s +5 426 M +( Open the file for reading.) s +5 404 M +( SSH_FXF_WRITE) s +5 393 M +( Open the file for writing. If both this and SSH_FXF_READ are) s +5 382 M +( specified, the file is opened for both reading and writing.) s +5 360 M +( SSH_FXF_APPEND) s +5 349 M +( Force all writes to append data at the end of the file. The) s +5 338 M +( offset parameter to write will be ignored.) s +5 316 M +( SSH_FXF_CREAT) s +5 305 M +( If this flag is specified, then a new file will be created if one) s +5 294 M +( does not already exist \(if O_TRUNC is specified, the new file will) s +5 283 M +( be truncated to zero length if it previously exists\).) s +5 261 M +( SSH_FXF_TRUNC) s +5 250 M +( Forces an existing file with the same name to be truncated to zero) s +5 239 M +( length when creating a file by specifying SSH_FXF_CREAT.) s +5 228 M +( SSH_FXF_CREAT MUST also be specified if this flag is used.) s +5 206 M +( SSH_FXF_EXCL) s +5 195 M +( Causes the request to fail if the named file already exists.) s +5 184 M +( SSH_FXF_CREAT MUST also be specified if this flag is used.) s +5 129 M +(Galbraith, et al. Expires April 16, 2003 [Page 15]) s +_R +S +PStoPSsaved restore +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 421.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 16 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH File Transfer Protocol October 2002) s +5 690 M +( SSH_FXF_TEXT) s +5 679 M +( Indicates that the server should treat the file as text and) s +5 668 M +( convert it to the canonical newline convention in use. \(See) s +5 657 M +( Determining Server Newline Convention. \(Section 4.3\)) s +5 635 M +( When a file is opened with the FXF_TEXT flag, the offset field in) s +5 624 M +( both the read and write function are ignored.) s +5 602 M +( Servers MUST correctly process multiple parallel reads and writes) s +5 591 M +( correctly in this mode. Naturally, it is permissible for them to) s +5 580 M +( do this by serializing the requests. It would not be possible for) s +5 569 M +( a client to reliably detect a server that does not implement) s +5 558 M +( parallel writes in time to prevent damage.) s +5 536 M +( Clients SHOULD use the SSH_FXF_APPEND flag to append data to a) s +5 525 M +( text file rather then using write with a calculated offset.) s +5 503 M +( To support seeks on text file the following SSH_FXP_EXTENDED) s +5 492 M +( packet is defined.) s +5 448 M +( string "text-seek") s +5 437 M +( string file-handle) s +5 426 M +( uint64 line-number) s +5 404 M +( line-number is the index of the line number to seek to, where byte) s +5 393 M +( 0 in the file is line number 0, and the byte directly following) s +5 382 M +( the first newline sequence in the file is line number 1 and so on.) s +5 360 M +( The response to a "text-seek" request is an SSH_FXP_STATUS) s +5 349 M +( message.) s +5 327 M +( An attempt to seek past the end-of-file should result in a) s +5 316 M +( SSH_FX_EOF status.) s +5 294 M +( Servers SHOULD support at least one "text-seek" in order to) s +5 283 M +( support resume. However, a client MUST be prepared to receive) s +5 272 M +( SSH_FX_OP_UNSUPPORTED when attempting a "text-seek" operation.) s +5 261 M +( The client can then try a fall-back strategy, if it has one.) s +5 239 M +( Clients MUST be prepared to handle SSH_FX_OP_UNSUPPORTED returned) s +5 228 M +( for read or write operations that are not sequential.) s +5 206 M +( The `attrs' field specifies the initial attributes for the file.) s +5 195 M +( Default values will be used for those attributes that are not) s +5 184 M +( specified. See Section ``File Attributes'' for more information.) s +5 129 M +(Galbraith, et al. Expires April 16, 2003 [Page 16]) s +_R +S +PStoPSsaved restore +%%Page: (16,17) 9 +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 0.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +/showpage{}def/copypage{}def/erasepage{}def +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 17 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH File Transfer Protocol October 2002) s +5 690 M +( The response to this message will be either SSH_FXP_HANDLE \(if the) s +5 679 M +( operation is successful\) or SSH_FXP_STATUS \(if the operation fails\).) s +5 657 M +( A file is closed by using the SSH_FXP_CLOSE request. Its data field) s +5 646 M +( has the following format:) s +5 624 M +( uint32 id) s +5 613 M +( string handle) s +5 591 M +( where `id' is the request identifier, and `handle' is a handle) s +5 580 M +( previously returned in the response to SSH_FXP_OPEN or) s +5 569 M +( SSH_FXP_OPENDIR. The handle becomes invalid immediately after this) s +5 558 M +( request has been sent.) s +5 536 M +( The response to this request will be a SSH_FXP_STATUS message. One) s +5 525 M +( should note that on some server platforms even a close can fail.) s +5 514 M +( This can happen e.g. if the server operating system caches writes,) s +5 503 M +( and an error occurs while flushing cached writes during the close.) s +5 481 M +(6.4 Reading and Writing) s +5 459 M +( Once a file has been opened, it can be read using the SSH_FXP_READ) s +5 448 M +( message, which has the following format:) s +5 426 M +( uint32 id) s +5 415 M +( string handle) s +5 404 M +( uint64 offset) s +5 393 M +( uint32 len) s +5 371 M +( where `id' is the request identifier, `handle' is an open file handle) s +5 360 M +( returned by SSH_FXP_OPEN, `offset' is the offset \(in bytes\) relative) s +5 349 M +( to the beginning of the file from where to start reading, and `len') s +5 338 M +( is the maximum number of bytes to read.) s +5 316 M +( In response to this request, the server will read as many bytes as it) s +5 305 M +( can from the file \(up to `len'\), and return them in a SSH_FXP_DATA) s +5 294 M +( message. If an error occurs or EOF is encountered before reading any) s +5 283 M +( data, the server will respond with SSH_FXP_STATUS. For normal disk) s +5 272 M +( files, it is guaranteed that this will read the specified number of) s +5 261 M +( bytes, or up to end of file. For e.g. device files this may return) s +5 250 M +( fewer bytes than requested.) s +5 228 M +( Writing to a file is achieved using the SSH_FXP_WRITE message, which) s +5 217 M +( has the following format:) s +5 129 M +(Galbraith, et al. Expires April 16, 2003 [Page 17]) s +_R +S +PStoPSsaved restore +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 421.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 18 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH File Transfer Protocol October 2002) s +5 690 M +( uint32 id) s +5 679 M +( string handle) s +5 668 M +( uint64 offset) s +5 657 M +( string data) s +5 635 M +( where `id' is a request identifier, `handle' is a file handle) s +5 624 M +( returned by SSH_FXP_OPEN, `offset' is the offset \(in bytes\) from the) s +5 613 M +( beginning of the file where to start writing, and `data' is the data) s +5 602 M +( to be written.) s +5 580 M +( The write will extend the file if writing beyond the end of the file.) s +5 569 M +( It is legal to write way beyond the end of the file; the semantics) s +5 558 M +( are to write zeroes from the end of the file to the specified offset) s +5 547 M +( and then the data. On most operating systems, such writes do not) s +5 536 M +( allocate disk space but instead leave "holes" in the file.) s +5 514 M +( The server responds to a write request with a SSH_FXP_STATUS message.) s +5 492 M +(6.5 Removing and Renaming Files) s +5 470 M +( Files can be removed using the SSH_FXP_REMOVE message. It has the) s +5 459 M +( following format:) s +5 437 M +( uint32 id) s +5 426 M +( string filename [UTF-8]) s +5 404 M +( where `id' is the request identifier and `filename' is the name of) s +5 393 M +( the file to be removed. See Section ``File Names'' for more) s +5 382 M +( information. This request cannot be used to remove directories.) s +5 360 M +( The server will respond to this request with a SSH_FXP_STATUS) s +5 349 M +( message.) s +5 327 M +( Files \(and directories\) can be renamed using the SSH_FXP_RENAME) s +5 316 M +( message. Its data is as follows:) s +5 294 M +( uint32 id) s +5 283 M +( string oldpath [UTF-8]) s +5 272 M +( string newpath [UTF-8]) s +5 250 M +( where `id' is the request identifier, `oldpath' is the name of an) s +5 239 M +( existing file or directory, and `newpath' is the new name for the) s +5 228 M +( file or directory. It is an error if there already exists a file) s +5 217 M +( with the name specified by newpath. The server may also fail rename) s +5 206 M +( requests in other situations, for example if `oldpath' and `newpath') s +5 195 M +( point to different file systems on the server.) s +5 173 M +( The server will respond to this request with a SSH_FXP_STATUS) s +5 129 M +(Galbraith, et al. Expires April 16, 2003 [Page 18]) s +_R +S +PStoPSsaved restore +%%Page: (18,19) 10 +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 0.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +/showpage{}def/copypage{}def/erasepage{}def +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 19 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH File Transfer Protocol October 2002) s +5 690 M +( message.) s +5 668 M +(6.6 Creating and Deleting Directories) s +5 646 M +( New directories can be created using the SSH_FXP_MKDIR request. It) s +5 635 M +( has the following format:) s +5 613 M +( uint32 id) s +5 602 M +( string path [UTF-8]) s +5 591 M +( ATTRS attrs) s +5 569 M +( where `id' is the request identifier.) s +5 547 M +( `path' specifies the directory to be created. See Section ``File) s +5 536 M +( Names'' for more information on file names.) s +5 514 M +( `attrs' specifies the attributes that should be applied to it upon) s +5 503 M +( creation. Attributes are discussed in more detail in Section ``File) s +5 492 M +( Attributes''.) s +5 470 M +( The server will respond to this request with a SSH_FXP_STATUS) s +5 459 M +( message. If a file or directory with the specified path already) s +5 448 M +( exists, an error will be returned.) s +5 426 M +( Directories can be removed using the SSH_FXP_RMDIR request, which has) s +5 415 M +( the following format:) s +5 393 M +( uint32 id) s +5 382 M +( string path [UTF-8]) s +5 360 M +( where `id' is the request identifier, and `path' specifies the) s +5 349 M +( directory to be removed. See Section ``File Names'' for more) s +5 338 M +( information on file names.) s +5 316 M +( The server responds to this request with a SSH_FXP_STATUS message.) s +5 305 M +( Errors may be returned from this operation for various reasons,) s +5 294 M +( including, but not limited to, the path does not exist, the path does) s +5 283 M +( not refer to a directory object, the directory is not empty, or the) s +5 272 M +( user has insufficient access or permission to perform the requested) s +5 261 M +( operation.) s +5 239 M +(6.7 Scanning Directories) s +5 217 M +( The files in a directory can be listed using the SSH_FXP_OPENDIR and) s +5 206 M +( SSH_FXP_READDIR requests. Each SSH_FXP_READDIR request returns one) s +5 195 M +( or more file names with full file attributes for each file. The) s +5 184 M +( client should call SSH_FXP_READDIR repeatedly until it has found the) s +5 173 M +( file it is looking for or until the server responds with a) s +5 129 M +(Galbraith, et al. Expires April 16, 2003 [Page 19]) s +_R +S +PStoPSsaved restore +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 421.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 20 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH File Transfer Protocol October 2002) s +5 690 M +( SSH_FXP_STATUS message indicating an error \(normally SSH_FX_EOF if) s +5 679 M +( there are no more files in the directory\). The client should then) s +5 668 M +( close the handle using the SSH_FXP_CLOSE request.) s +5 646 M +( The SSH_FXP_OPENDIR opens a directory for reading. It has the) s +5 635 M +( following format:) s +5 613 M +( uint32 id) s +5 602 M +( string path [UTF-8]) s +5 580 M +( where `id' is the request identifier and `path' is the path name of) s +5 569 M +( the directory to be listed \(without any trailing slash\). See Section) s +5 558 M +( ``File Names'' for more information on file names. This will return) s +5 547 M +( an error if the path does not specify a directory or if the directory) s +5 536 M +( is not readable. The server will respond to this request with either) s +5 525 M +( a SSH_FXP_HANDLE or a SSH_FXP_STATUS message.) s +5 503 M +( Once the directory has been successfully opened, files \(and) s +5 492 M +( directories\) contained in it can be listed using SSH_FXP_READDIR) s +5 481 M +( requests. These are of the format) s +5 459 M +( uint32 id) s +5 448 M +( string handle) s +5 426 M +( where `id' is the request identifier, and `handle' is a handle) s +5 415 M +( returned by SSH_FXP_OPENDIR. \(It is a protocol error to attempt to) s +5 404 M +( use an ordinary file handle returned by SSH_FXP_OPEN.\)) s +5 382 M +( The server responds to this request with either a SSH_FXP_NAME or a) s +5 371 M +( SSH_FXP_STATUS message. One or more names may be returned at a time.) s +5 360 M +( Full status information is returned for each name in order to speed) s +5 349 M +( up typical directory listings.) s +5 327 M +( If there are no more names available to be read, the server MUST) s +5 316 M +( respond with a SSH_FXP_STATUS message with error code of SSH_FX_EOF.) s +5 294 M +( When the client no longer wishes to read more names from the) s +5 283 M +( directory, it SHOULD call SSH_FXP_CLOSE for the handle. The handle) s +5 272 M +( should be closed regardless of whether an error has occurred or not.) s +5 250 M +(6.8 Retrieving File Attributes) s +5 228 M +( Very often, file attributes are automatically returned by) s +5 217 M +( SSH_FXP_READDIR. However, sometimes there is need to specifically) s +5 206 M +( retrieve the attributes for a named file. This can be done using the) s +5 195 M +( SSH_FXP_STAT, SSH_FXP_LSTAT and SSH_FXP_FSTAT requests.) s +5 173 M +( SSH_FXP_STAT and SSH_FXP_LSTAT only differ in that SSH_FXP_STAT) s +5 129 M +(Galbraith, et al. Expires April 16, 2003 [Page 20]) s +_R +S +PStoPSsaved restore +%%Page: (20,21) 11 +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 0.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +/showpage{}def/copypage{}def/erasepage{}def +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 21 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH File Transfer Protocol October 2002) s +5 690 M +( follows symbolic links on the server, whereas SSH_FXP_LSTAT does not) s +5 679 M +( follow symbolic links. Both have the same format:) s +5 657 M +( uint32 id) s +5 646 M +( string path [UTF-8]) s +5 635 M +( uint32 flags) s +5 613 M +( where `id' is the request identifier, and `path' specifies the file) s +5 602 M +( system object for which status is to be returned. The server) s +5 591 M +( responds to this request with either SSH_FXP_ATTRS or SSH_FXP_STATUS.) s +5 569 M +( The flags field specify the attribute flags in which the client has) s +5 558 M +( particular interest. This is a hint to the server. For example,) s +5 547 M +( because retrieving owner / group and acl information can be an) s +5 536 M +( expensive operation under some operating systems, the server may) s +5 525 M +( choose not to retrieve this information unless the client expresses a) s +5 514 M +( specific interest in it.) s +5 492 M +( The client has no guarantee the server will provide all the fields) s +5 481 M +( that it has expressed an interest in.) s +5 459 M +( SSH_FXP_FSTAT differs from the others in that it returns status) s +5 448 M +( information for an open file \(identified by the file handle\). Its) s +5 437 M +( format is as follows:) s +5 415 M +( uint32 id) s +5 404 M +( string handle) s +5 393 M +( uint32 flags) s +5 371 M +( where `id' is the request identifier and `handle' is a file handle) s +5 360 M +( returned by SSH_FXP_OPEN. The server responds to this request with) s +5 349 M +( SSH_FXP_ATTRS or SSH_FXP_STATUS.) s +5 327 M +(6.9 Setting File Attributes) s +5 305 M +( File attributes may be modified using the SSH_FXP_SETSTAT and) s +5 294 M +( SSH_FXP_FSETSTAT requests. These requests are used for operations) s +5 283 M +( such as changing the ownership, permissions or access times, as well) s +5 272 M +( as for truncating a file.) s +5 250 M +( The SSH_FXP_SETSTAT request is of the following format:) s +5 228 M +( uint32 id) s +5 217 M +( string path [UTF-8]) s +5 206 M +( ATTRS attrs) s +5 184 M +( where `id' is the request identifier, `path' specifies the file) s +5 173 M +( system object \(e.g. file or directory\) whose attributes are to be) s +5 129 M +(Galbraith, et al. Expires April 16, 2003 [Page 21]) s +_R +S +PStoPSsaved restore +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 421.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 22 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH File Transfer Protocol October 2002) s +5 690 M +( modified, and `attrs' specifies the modifications to be made to its) s +5 679 M +( attributes. Attributes are discussed in more detail in Section) s +5 668 M +( ``File Attributes''.) s +5 646 M +( An error will be returned if the specified file system object does) s +5 635 M +( not exist or the user does not have sufficient rights to modify the) s +5 624 M +( specified attributes. The server responds to this request with a) s +5 613 M +( SSH_FXP_STATUS message.) s +5 591 M +( The SSH_FXP_FSETSTAT request modifies the attributes of a file which) s +5 580 M +( is already open. It has the following format:) s +5 558 M +( uint32 id) s +5 547 M +( string handle) s +5 536 M +( ATTRS attrs) s +5 514 M +( where `id' is the request identifier, `handle' \(MUST be returned by) s +5 503 M +( SSH_FXP_OPEN\) identifies the file whose attributes are to be) s +5 492 M +( modified, and `attrs' specifies the modifications to be made to its) s +5 481 M +( attributes. Attributes are discussed in more detail in Section) s +5 470 M +( ``File Attributes''. The server will respond to this request with) s +5 459 M +( SSH_FXP_STATUS.) s +5 437 M +(6.10 Dealing with Symbolic links) s +5 415 M +( The SSH_FXP_READLINK request may be used to read the target of a) s +5 404 M +( symbolic link. It would have a data part as follows:) s +5 382 M +( uint32 id) s +5 371 M +( string path [UTF-8]) s +5 349 M +( where `id' is the request identifier and `path' specifies the path) s +5 338 M +( name of the symlink to be read.) s +5 316 M +( The server will respond with a SSH_FXP_NAME packet containing only) s +5 305 M +( one name and a dummy attributes value. The name in the returned) s +5 294 M +( packet contains the target of the link. If an error occurs, the) s +5 283 M +( server may respond with SSH_FXP_STATUS.) s +5 261 M +( The SSH_FXP_SYMLINK request will create a symbolic link on the) s +5 250 M +( server. It is of the following format) s +5 228 M +( uint32 id) s +5 217 M +( string linkpath [UTF-8]) s +5 206 M +( string targetpath [UTF-8]) s +5 184 M +( where `id' is the request identifier, `linkpath' specifies the path) s +5 173 M +( name of the symlink to be created and `targetpath' specifies the) s +5 129 M +(Galbraith, et al. Expires April 16, 2003 [Page 22]) s +_R +S +PStoPSsaved restore +%%Page: (22,23) 12 +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 0.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +/showpage{}def/copypage{}def/erasepage{}def +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 23 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH File Transfer Protocol October 2002) s +5 690 M +( target of the symlink. The server shall respond with a) s +5 679 M +( SSH_FXP_STATUS indicating either success \(SSH_FX_OK\) or an error) s +5 668 M +( condition.) s +5 646 M +(6.11 Canonicalizing the Server-Side Path Name) s +5 624 M +( The SSH_FXP_REALPATH request can be used to have the server) s +5 613 M +( canonicalize any given path name to an absolute path. This is useful) s +5 602 M +( for converting path names containing ".." components or relative) s +5 591 M +( pathnames without a leading slash into absolute paths. The format of) s +5 580 M +( the request is as follows:) s +5 558 M +( uint32 id) s +5 547 M +( string path [UTF-8]) s +5 525 M +( where `id' is the request identifier and `path' specifies the path) s +5 514 M +( name to be canonicalized. The server will respond with a) s +5 503 M +( SSH_FXP_NAME packet containing the name in canonical form and a dummy) s +5 492 M +( attributes value. If an error occurs, the server may also respond) s +5 481 M +( with SSH_FXP_STATUS.) s +5 459 M +(6.11.1 Best practice for dealing with paths) s +5 437 M +( The client SHOULD treat the results of SSH_FXP_REALPATH as a) s +5 426 M +( canonical absolute path, even if the path does not appear to be) s +5 415 M +( absolute. A client that use REALPATH\("."\) and treats the result as) s +5 404 M +( absolute, even if there is no leading slash, will continue to) s +5 393 M +( function correctly, even when talking to a Windows NT or VMS style) s +5 382 M +( system, where absolute paths may not begin with a slash.) s +5 360 M +( For example, if the client wishes to change directory up, and the) s +5 349 M +( server has returned "c:/x/y/z" from REALPATH, the client SHOULD use) s +5 338 M +( "c:/x/y/z/..".) s +5 316 M +( As a second example, if the client wishes to open the file "x.txt" in) s +5 305 M +( the current directory, and server has returned "dka100:/x/y/z" as the) s +5 294 M +( canonical path of the directory, the client SHOULD open "dka100:/x/y/) s +5 283 M +( z/x.txt") s +5 129 M +(Galbraith, et al. Expires April 16, 2003 [Page 23]) s +_R +S +PStoPSsaved restore +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 421.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 24 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH File Transfer Protocol October 2002) s +5 690 M +(7. Responses from the Server to the Client) s +5 668 M +( The server responds to the client using one of a few response) s +5 657 M +( packets. All requests can return a SSH_FXP_STATUS response upon) s +5 646 M +( failure. When the operation is successful, any of the responses may) s +5 635 M +( be returned \(depending on the operation\). If no data needs to be) s +5 624 M +( returned to the client, the SSH_FXP_STATUS response with SSH_FX_OK) s +5 613 M +( status is appropriate. Otherwise, the SSH_FXP_HANDLE message is used) s +5 602 M +( to return a file handle \(for SSH_FXP_OPEN and SSH_FXP_OPENDIR) s +5 591 M +( requests\), SSH_FXP_DATA is used to return data from SSH_FXP_READ,) s +5 580 M +( SSH_FXP_NAME is used to return one or more file names from a) s +5 569 M +( SSH_FXP_READDIR or SSH_FXP_REALPATH request, and SSH_FXP_ATTRS is) s +5 558 M +( used to return file attributes from SSH_FXP_STAT, SSH_FXP_LSTAT, and) s +5 547 M +( SSH_FXP_FSTAT requests.) s +5 525 M +( Exactly one response will be returned for each request. Each) s +5 514 M +( response packet contains a request identifier which can be used to) s +5 503 M +( match each response with the corresponding request. Note that it is) s +5 492 M +( legal to have several requests outstanding simultaneously, and the) s +5 481 M +( server is allowed to send responses to them in a different order from) s +5 470 M +( the order in which the requests were sent \(the result of their) s +5 459 M +( execution, however, is guaranteed to be as if they had been processed) s +5 448 M +( one at a time in the order in which the requests were sent\).) s +5 426 M +( Response packets are of the same general format as request packets.) s +5 415 M +( Each response packet begins with the request identifier.) s +5 393 M +( The format of the data portion of the SSH_FXP_STATUS response is as) s +5 382 M +( follows:) s +5 360 M +( uint32 id) s +5 349 M +( uint32 error/status code) s +5 338 M +( string error message \(ISO-10646 UTF-8 [RFC-2279]\)) s +5 327 M +( string language tag \(as defined in [RFC-1766]\)) s +5 305 M +( where `id' is the request identifier, and `error/status code') s +5 294 M +( indicates the result of the requested operation. The value SSH_FX_OK) s +5 283 M +( indicates success, and all other values indicate failure.) s +5 261 M +( Currently, the following values are defined \(other values may be) s +5 250 M +( defined by future versions of this protocol\):) s +5 129 M +(Galbraith, et al. Expires April 16, 2003 [Page 24]) s +_R +S +PStoPSsaved restore +%%Page: (24,25) 13 +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 0.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +/showpage{}def/copypage{}def/erasepage{}def +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 25 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH File Transfer Protocol October 2002) s +5 690 M +( #define SSH_FX_OK 0) s +5 679 M +( #define SSH_FX_EOF 1) s +5 668 M +( #define SSH_FX_NO_SUCH_FILE 2) s +5 657 M +( #define SSH_FX_PERMISSION_DENIED 3) s +5 646 M +( #define SSH_FX_FAILURE 4) s +5 635 M +( #define SSH_FX_BAD_MESSAGE 5) s +5 624 M +( #define SSH_FX_NO_CONNECTION 6) s +5 613 M +( #define SSH_FX_CONNECTION_LOST 7) s +5 602 M +( #define SSH_FX_OP_UNSUPPORTED 8) s +5 591 M +( #define SSH_FX_INVALID_HANDLE 9) s +5 580 M +( #define SSH_FX_NO_SUCH_PATH 10) s +5 569 M +( #define SSH_FX_FILE_ALREADY_EXISTS 11) s +5 558 M +( #define SSH_FX_WRITE_PROTECT 12) s +5 536 M +( SSH_FX_OK) s +5 525 M +( Indicates successful completion of the operation.) s +5 503 M +( SSH_FX_EOF) s +5 492 M +( indicates end-of-file condition; for SSH_FX_READ it means that no) s +5 481 M +( more data is available in the file, and for SSH_FX_READDIR it) s +5 470 M +( indicates that no more files are contained in the directory.) s +5 448 M +( SSH_FX_NO_SUCH_FILE) s +5 437 M +( is returned when a reference is made to a file which does not) s +5 426 M +( exist.) s +5 404 M +( SSH_FX_PERMISSION_DENIED) s +5 393 M +( is returned when the authenticated user does not have sufficient) s +5 382 M +( permissions to perform the operation.) s +5 360 M +( SSH_FX_FAILURE) s +5 349 M +( is a generic catch-all error message; it should be returned if an) s +5 338 M +( error occurs for which there is no more specific error code) s +5 327 M +( defined.) s +5 305 M +( SSH_FX_BAD_MESSAGE) s +5 294 M +( may be returned if a badly formatted packet or protocol) s +5 283 M +( incompatibility is detected.) s +5 261 M +( SSH_FX_NO_CONNECTION) s +5 250 M +( is a pseudo-error which indicates that the client has no) s +5 239 M +( connection to the server \(it can only be generated locally by the) s +5 228 M +( client, and MUST NOT be returned by servers\).) s +5 206 M +( SSH_FX_CONNECTION_LOST) s +5 195 M +( is a pseudo-error which indicates that the connection to the) s +5 184 M +( server has been lost \(it can only be generated locally by the) s +5 173 M +( client, and MUST NOT be returned by servers\).) s +5 129 M +(Galbraith, et al. Expires April 16, 2003 [Page 25]) s +_R +S +PStoPSsaved restore +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 421.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 26 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH File Transfer Protocol October 2002) s +5 690 M +( SSH_FX_OP_UNSUPPORTED) s +5 679 M +( indicates that an attempt was made to perform an operation which) s +5 668 M +( is not supported for the server \(it may be generated locally by) s +5 657 M +( the client if e.g. the version number exchange indicates that a) s +5 646 M +( required feature is not supported by the server, or it may be) s +5 635 M +( returned by the server if the server does not implement an) s +5 624 M +( operation\).) s +5 602 M +( SSH_FX_INVALID_HANDLE) s +5 591 M +( The handle value was invalid.) s +5 569 M +( SSH_FX_NO_SUCH_PATH) s +5 558 M +( The file path does not exist or is invalid.) s +5 536 M +( SSH_FX_FILE_ALREADY_EXISTS) s +5 525 M +( The file already exists.) s +5 503 M +( SSH_FX_WRITE_PROTECT) s +5 492 M +( The file is on read only media, or the media is write protected.) s +5 470 M +( The SSH_FXP_HANDLE response has the following format:) s +5 448 M +( uint32 id) s +5 437 M +( string handle) s +5 415 M +( where `id' is the request identifier, and `handle' is an arbitrary) s +5 404 M +( string that identifies an open file or directory on the server. The) s +5 393 M +( handle is opaque to the client; the client MUST NOT attempt to) s +5 382 M +( interpret or modify it in any way. The length of the handle string) s +5 371 M +( MUST NOT exceed 256 data bytes.) s +5 349 M +( The SSH_FXP_DATA response has the following format:) s +5 327 M +( uint32 id) s +5 316 M +( string data) s +5 294 M +( where `id' is the request identifier, and `data' is an arbitrary byte) s +5 283 M +( string containing the requested data. The data string may be at most) s +5 272 M +( the number of bytes requested in a SSH_FXP_READ request, but may also) s +5 261 M +( be shorter if end of file is reached or if the read is from something) s +5 250 M +( other than a regular file.) s +5 228 M +( The SSH_FXP_NAME response has the following format:) s +5 129 M +(Galbraith, et al. Expires April 16, 2003 [Page 26]) s +_R +S +PStoPSsaved restore +%%Page: (26,27) 14 +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 0.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +/showpage{}def/copypage{}def/erasepage{}def +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 27 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH File Transfer Protocol October 2002) s +5 690 M +( uint32 id) s +5 679 M +( uint32 count) s +5 668 M +( repeats count times:) s +5 657 M +( string filename [UTF-8]) s +5 646 M +( ATTRS attrs) s +5 624 M +( where `id' is the request identifier, `count' is the number of names) s +5 613 M +( returned in this response, and the remaining fields repeat `count') s +5 602 M +( times \(so that all three fields are first included for the first) s +5 591 M +( file, then for the second file, etc\). In the repeated part,) s +5 580 M +( `filename' is a file name being returned \(for SSH_FXP_READDIR, it) s +5 569 M +( will be a relative name within the directory, without any path) s +5 558 M +( components; for SSH_FXP_REALPATH it will be an absolute path name\),) s +5 547 M +( and `attrs' is the attributes of the file as described in Section) s +5 536 M +( ``File Attributes''.) s +5 514 M +( The SSH_FXP_ATTRS response has the following format:) s +5 492 M +( uint32 id) s +5 481 M +( ATTRS attrs) s +5 459 M +( where `id' is the request identifier, and `attrs' is the returned) s +5 448 M +( file attributes as described in Section ``File Attributes''.) s +5 129 M +(Galbraith, et al. Expires April 16, 2003 [Page 27]) s +_R +S +PStoPSsaved restore +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 421.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 28 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH File Transfer Protocol October 2002) s +5 690 M +(8. Vendor-Specific Extensions) s +5 668 M +( The SSH_FXP_EXTENDED request provides a generic extension mechanism) s +5 657 M +( for adding vendor-specific commands. The request has the following) s +5 646 M +( format:) s +5 624 M +( uint32 id) s +5 613 M +( string extended-request) s +5 602 M +( ... any request-specific data ...) s +5 580 M +( where `id' is the request identifier, and `extended-request' is a) s +5 569 M +( string of the format "name@domain", where domain is an internet) s +5 558 M +( domain name of the vendor defining the request. The rest of the) s +5 547 M +( request is completely vendor-specific, and servers should only) s +5 536 M +( attempt to interpret it if they recognize the `extended-request') s +5 525 M +( name.) s +5 503 M +( The server may respond to such requests using any of the response) s +5 492 M +( packets defined in Section ``Responses from the Server to the) s +5 481 M +( Client''. Additionally, the server may also respond with a) s +5 470 M +( SSH_FXP_EXTENDED_REPLY packet, as defined below. If the server does) s +5 459 M +( not recognize the `extended-request' name, then the server MUST) s +5 448 M +( respond with SSH_FXP_STATUS with error/status set to) s +5 437 M +( SSH_FX_OP_UNSUPPORTED.) s +5 415 M +( The SSH_FXP_EXTENDED_REPLY packet can be used to carry arbitrary) s +5 404 M +( extension-specific data from the server to the client. It is of the) s +5 393 M +( following format:) s +5 371 M +( uint32 id) s +5 360 M +( ... any request-specific data ...) s +5 338 M +( There is a range of packet types reserved for use by extensions. In) s +5 327 M +( order to avoid collision, extensions that turn on the use of) s +5 316 M +( additional packet types should determine those numbers dynamically.) s +5 294 M +( The suggested way of doing this is have an extension request from the) s +5 283 M +( client to the server that enables the extension; the extension) s +5 272 M +( response from the server to the client would specify the actual type) s +5 261 M +( values to use, in additional to any other data.) s +5 239 M +( Extension authors should be mindful of the limited range of packet) s +5 228 M +( types available \(there are only 45 values available\) and avoid) s +5 217 M +( requiring a new packet type where possible.) s +5 129 M +(Galbraith, et al. Expires April 16, 2003 [Page 28]) s +_R +S +PStoPSsaved restore +%%Page: (28,29) 15 +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 0.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +/showpage{}def/copypage{}def/erasepage{}def +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 29 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH File Transfer Protocol October 2002) s +5 690 M +(9. Security Considerations) s +5 668 M +( This protocol assumes that it is run over a secure channel and that) s +5 657 M +( the endpoints of the channel have been authenticated. Thus, this) s +5 646 M +( protocol assumes that it is externally protected from network-level) s +5 635 M +( attacks.) s +5 613 M +( This protocol provides file system access to arbitrary files on the) s +5 602 M +( server \(only constrained by the server implementation\). It is the) s +5 591 M +( responsibility of the server implementation to enforce any access) s +5 580 M +( controls that may be required to limit the access allowed for any) s +5 569 M +( particular user \(the user being authenticated externally to this) s +5 558 M +( protocol, typically using the SSH User Authentication Protocol [8].) s +5 536 M +( Care must be taken in the server implementation to check the validity) s +5 525 M +( of received file handle strings. The server should not rely on them) s +5 514 M +( directly; it MUST check the validity of each handle before relying on) s +5 503 M +( it.) s +5 129 M +(Galbraith, et al. Expires April 16, 2003 [Page 29]) s +_R +S +PStoPSsaved restore +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 421.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 30 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH File Transfer Protocol October 2002) s +5 690 M +(10. Changes from previous protocol versions) s +5 668 M +( The SSH File Transfer Protocol has changed over time, before it's) s +5 657 M +( standardization. The following is a description of the incompatible) s +5 646 M +( changes between different versions.) s +5 624 M +(10.1 Changes between versions 4 and 3) s +5 602 M +( Many of the changes between version 4 and version 3 are to the) s +5 591 M +( attribute structure to make it more flexible for non-unix platforms.) s +5 569 M +( o Make all filenames UTF-8.) s +5 547 M +( o Added 'newline' extension.) s +5 525 M +( o Made file attribute owner and group strings so they can actually) s +5 514 M +( be used on disparate systems.) s +5 492 M +( o Added createtime field, and added separate flags for atime,) s +5 481 M +( createtime, and mtime so they can be set separately.) s +5 459 M +( o Split the file type out of the permissions field and into it's own) s +5 448 M +( field \(which is always present.\)) s +5 426 M +( o Added acl attribute.) s +5 404 M +( o Added SSH_FXF_TEXT file open flag.) s +5 382 M +( o Added flags field to the get stat commands so that the client can) s +5 371 M +( specifically request information the server might not normally) s +5 360 M +( included for performance reasons.) s +5 338 M +( o Removed the long filename from the names structure-- it can now be) s +5 327 M +( built from information available in the attrs structure.) s +5 305 M +( o Added reserved range of packet numbers for extensions.) s +5 283 M +( o Added several additional error codes.) s +5 261 M +( o Change the way version negotiate works slightly. Previously, if) s +5 250 M +( the client version were higher than the server version, the server) s +5 239 M +( was supposed to 'echo back' the clients version. The server now) s +5 228 M +( sends it's own version and the lower of the two is considered to) s +5 217 M +( be the one in use.) s +5 129 M +(Galbraith, et al. Expires April 16, 2003 [Page 30]) s +_R +S +PStoPSsaved restore +%%Page: (30,31) 16 +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 0.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +/showpage{}def/copypage{}def/erasepage{}def +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 31 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH File Transfer Protocol October 2002) s +5 690 M +(10.2 Changes between versions 3 and 2) s +5 668 M +( o The SSH_FXP_READLINK and SSH_FXP_SYMLINK messages were added.) s +5 646 M +( o The SSH_FXP_EXTENDED and SSH_FXP_EXTENDED_REPLY messages were) s +5 635 M +( added.) s +5 613 M +( o The SSH_FXP_STATUS message was changed to include fields `error) s +5 602 M +( message' and `language tag'.) s +5 569 M +(10.3 Changes between versions 2 and 1) s +5 547 M +( o The SSH_FXP_RENAME message was added.) s +5 514 M +(10.4 Changes between versions 1 and 0) s +5 492 M +( o Implementation changes, no actual protocol changes.) s +5 129 M +(Galbraith, et al. Expires April 16, 2003 [Page 31]) s +_R +S +PStoPSsaved restore +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 421.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 32 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH File Transfer Protocol October 2002) s +5 690 M +(11. Trademark Issues) s +5 668 M +( "ssh" is a registered trademark of SSH Communications Security Corp) s +5 657 M +( in the United States and/or other countries.) s +5 129 M +(Galbraith, et al. Expires April 16, 2003 [Page 32]) s +_R +S +PStoPSsaved restore +%%Page: (32,33) 17 +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 0.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +/showpage{}def/copypage{}def/erasepage{}def +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 33 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH File Transfer Protocol October 2002) s +5 690 M +(References) s +5 668 M +( [1] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and) s +5 657 M +( P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January) s +5 646 M +( 1999.) s +5 624 M +( [2] Alvestrand, H., "IETF Policy on Character Sets and Languages",) s +5 613 M +( BCP 18, RFC 2277, January 1998.) s +5 591 M +( [3] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame,) s +5 580 M +( C., Eisler, M. and D. Noveck, "NFS version 4 Protocol", RFC) s +5 569 M +( 3010, December 2000.) s +5 547 M +( [4] Institute of Electrical and Electronics Engineers, "Information) s +5 536 M +( Technology - Portable Operating System Interface \(POSIX\) - Part) s +5 525 M +( 1: System Application Program Interface \(API\) [C Language]",) s +5 514 M +( IEEE Standard 1003.2, 1996.) s +5 492 M +( [5] Rinne, T., Ylonen, T., Kivinen, T., Saarinen, M. and S.) s +5 481 M +( Lehtinen, "SSH Protocol Architecture", draft-ietf-secsh-) s +5 470 M +( architecture-13 \(work in progress\), September 2002.) s +5 448 M +( [6] Rinne, T., Ylonen, T., Kivinen, T., Saarinen, M. and S.) s +5 437 M +( Lehtinen, "SSH Protocol Transport Protocol", draft-ietf-secsh-) s +5 426 M +( transport-15 \(work in progress\), September 2002.) s +5 404 M +( [7] Rinne, T., Ylonen, T., Kivinen, T., Saarinen, M. and S.) s +5 393 M +( Lehtinen, "SSH Connection Protocol", draft-ietf-secsh-connect-16) s +5 382 M +( \(work in progress\), September 2002.) s +5 360 M +( [8] Rinne, T., Ylonen, T., Kivinen, T., Saarinen, M. and S.) s +5 349 M +( Lehtinen, "SSH Authentication Protocol", draft-ietf-secsh-) s +5 338 M +( userauth-16 \(work in progress\), September 2002.) s +5 305 M +(Authors' Addresses) s +5 283 M +( Joseph Galbraith) s +5 272 M +( VanDyke Software) s +5 261 M +( 4848 Tramway Ridge Blvd) s +5 250 M +( Suite 101) s +5 239 M +( Albuquerque, NM 87111) s +5 228 M +( US) s +5 206 M +( Phone: +1 505 332 5700) s +5 195 M +( EMail: [email protected]) s +5 129 M +(Galbraith, et al. Expires April 16, 2003 [Page 33]) s +_R +S +PStoPSsaved restore +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 421.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 34 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH File Transfer Protocol October 2002) s +5 690 M +( Tatu Ylonen) s +5 679 M +( SSH Communications Security Corp) s +5 668 M +( Fredrikinkatu 42) s +5 657 M +( HELSINKI FIN-00100) s +5 646 M +( Finland) s +5 624 M +( EMail: [email protected]) s +5 591 M +( Sami Lehtinen) s +5 580 M +( SSH Communications Security Corp) s +5 569 M +( Fredrikinkatu 42) s +5 558 M +( HELSINKI FIN-00100) s +5 547 M +( Finland) s +5 525 M +( EMail: [email protected]) s +5 129 M +(Galbraith, et al. Expires April 16, 2003 [Page 34]) s +_R +S +PStoPSsaved restore +%%Page: (34,35) 18 +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 0.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +/showpage{}def/copypage{}def/erasepage{}def +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 35 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH File Transfer Protocol October 2002) s +5 690 M +(Full Copyright Statement) s +5 668 M +( Copyright \(C\) The Internet Society \(2002\). All Rights Reserved.) s +5 646 M +( This document and translations of it may be copied and furnished to) s +5 635 M +( others, and derivative works that comment on or otherwise explain it) s +5 624 M +( or assist in its implementation may be prepared, copied, published) s +5 613 M +( and distributed, in whole or in part, without restriction of any) s +5 602 M +( kind, provided that the above copyright notice and this paragraph are) s +5 591 M +( included on all such copies and derivative works. However, this) s +5 580 M +( document itself may not be modified in any way, such as by removing) s +5 569 M +( the copyright notice or references to the Internet Society or other) s +5 558 M +( Internet organizations, except as needed for the purpose of) s +5 547 M +( developing Internet standards in which case the procedures for) s +5 536 M +( copyrights defined in the Internet Standards process must be) s +5 525 M +( followed, or as required to translate it into languages other than) s +5 514 M +( English.) s +5 492 M +( The limited permissions granted above are perpetual and will not be) s +5 481 M +( revoked by the Internet Society or its successors or assigns.) s +5 459 M +( This document and the information contained herein is provided on an) s +5 448 M +( "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING) s +5 437 M +( TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING) s +5 426 M +( BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION) s +5 415 M +( HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF) s +5 404 M +( MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.) s +5 382 M +(Acknowledgement) s +5 360 M +( Funding for the RFC Editor function is currently provided by the) s +5 349 M +( Internet Society.) s +5 129 M +(Galbraith, et al. Expires April 16, 2003 [Page 35]) s +_R +S +PStoPSsaved restore +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 421.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 36 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +_R +S +PStoPSsaved restore +%%Trailer +%%Pages: 36 +%%DocumentNeededResources: font Courier-Bold Courier +%%EOF diff --git a/lib/ssh/doc/standard/draft-ietf-secsh-filexfer-03.txt b/lib/ssh/doc/standard/draft-ietf-secsh-filexfer-03.txt new file mode 100644 index 0000000000..83960ae976 --- /dev/null +++ b/lib/ssh/doc/standard/draft-ietf-secsh-filexfer-03.txt @@ -0,0 +1,1962 @@ + + + +Secure Shell Working Group J. Galbraith +Internet-Draft VanDyke Software +Expires: April 16, 2003 T. Ylonen + S. Lehtinen + SSH Communications Security Corp + October 16, 2002 + + + SSH File Transfer Protocol + draft-ietf-secsh-filexfer-03.txt + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at http:// + www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on April 16, 2003. + +Copyright Notice + + Copyright (C) The Internet Society (2002). All Rights Reserved. + +Abstract + + The SSH File Transfer Protocol provides secure file transfer + functionality over any reliable data stream. It is the standard file + transfer protocol for use with the SSH2 protocol. This document + describes the file transfer protocol and its interface to the SSH2 + protocol suite. + + + + + + + +Galbraith, et al. Expires April 16, 2003 [Page 1] + +Internet-Draft SSH File Transfer Protocol October 2002 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Use with the SSH Connection Protocol . . . . . . . . . . . 4 + 3. General Packet Format . . . . . . . . . . . . . . . . . . 5 + 4. Protocol Initialization . . . . . . . . . . . . . . . . . 7 + 4.1 Client Initialization . . . . . . . . . . . . . . . . . . 7 + 4.2 Server Initialization . . . . . . . . . . . . . . . . . . 7 + 4.3 Determining Server Newline Convention . . . . . . . . . . 8 + 5. File Attributes . . . . . . . . . . . . . . . . . . . . . 9 + 5.1 Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 9 + 5.2 Type . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 5.3 Size . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 5.4 Owner and Group . . . . . . . . . . . . . . . . . . . . . 10 + 5.5 Permissions . . . . . . . . . . . . . . . . . . . . . . . 11 + 5.6 Times . . . . . . . . . . . . . . . . . . . . . . . . . . 11 + 5.7 ACL . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 + 5.8 Extended attributes . . . . . . . . . . . . . . . . . . . 12 + 6. Requests From the Client to the Server . . . . . . . . . . 13 + 6.1 Request Synchronization and Reordering . . . . . . . . . . 13 + 6.2 File Names . . . . . . . . . . . . . . . . . . . . . . . . 14 + 6.3 Opening, Creating, and Closing Files . . . . . . . . . . . 14 + 6.4 Reading and Writing . . . . . . . . . . . . . . . . . . . 17 + 6.5 Removing and Renaming Files . . . . . . . . . . . . . . . 18 + 6.6 Creating and Deleting Directories . . . . . . . . . . . . 19 + 6.7 Scanning Directories . . . . . . . . . . . . . . . . . . . 19 + 6.8 Retrieving File Attributes . . . . . . . . . . . . . . . . 20 + 6.9 Setting File Attributes . . . . . . . . . . . . . . . . . 21 + 6.10 Dealing with Symbolic links . . . . . . . . . . . . . . . 22 + 6.11 Canonicalizing the Server-Side Path Name . . . . . . . . . 23 + 6.11.1 Best practice for dealing with paths . . . . . . . . . . . 23 + 7. Responses from the Server to the Client . . . . . . . . . 24 + 8. Vendor-Specific Extensions . . . . . . . . . . . . . . . . 28 + 9. Security Considerations . . . . . . . . . . . . . . . . . 29 + 10. Changes from previous protocol versions . . . . . . . . . 30 + 10.1 Changes between versions 4 and 3 . . . . . . . . . . . . . 30 + 10.2 Changes between versions 3 and 2 . . . . . . . . . . . . . 31 + 10.3 Changes between versions 2 and 1 . . . . . . . . . . . . . 31 + 10.4 Changes between versions 1 and 0 . . . . . . . . . . . . . 31 + 11. Trademark Issues . . . . . . . . . . . . . . . . . . . . . 32 + References . . . . . . . . . . . . . . . . . . . . . . . . 33 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . 33 + Full Copyright Statement . . . . . . . . . . . . . . . . . 35 + + + + + + + + +Galbraith, et al. Expires April 16, 2003 [Page 2] + +Internet-Draft SSH File Transfer Protocol October 2002 + + +1. Introduction + + This protocol provides secure file transfer (and more generally file + system access) functionality over a reliable data stream, such as a + channel in the SSH2 protocol [5]. + + This protocol is designed so that it could be used to implement a + secure remote file system service, as well as a secure file transfer + service. + + This protocol assumes that it runs over a secure channel, and that + the server has already authenticated the user at the client end, and + that the identity of the client user is externally available to the + server implementation. + + In general, this protocol follows a simple request-response model. + Each request and response contains a sequence number and multiple + requests may be pending simultaneously. There are a relatively large + number of different request messages, but a small number of possible + response messages. Each request has one or more response messages + that may be returned in result (e.g., a read either returns data or + reports error status). + + The packet format descriptions in this specification follow the + notation presented in the secsh architecture draft. [5] + + Even though this protocol is described in the context of the SSH2 + protocol, this protocol is general and independent of the rest of the + SSH2 protocol suite. It could be used in a number of different + applications, such as secure file transfer over TLS RFC 2246 [1] and + transfer of management information in VPN applications. + + + + + + + + + + + + + + + + + + + + +Galbraith, et al. Expires April 16, 2003 [Page 3] + +Internet-Draft SSH File Transfer Protocol October 2002 + + +2. Use with the SSH Connection Protocol + + When used with the SSH2 Protocol suite, this protocol is intended to + be used from the SSH Connection Protocol [7] as a subsystem, as + described in section ``Starting a Shell or a Command''. The + subsystem name used with this protocol is "sftp". + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Galbraith, et al. Expires April 16, 2003 [Page 4] + +Internet-Draft SSH File Transfer Protocol October 2002 + + +3. General Packet Format + + All packets transmitted over the secure connection are of the + following format: + + uint32 length + byte type + byte[length - 1] data payload + + That is, they are just data preceded by 32-bit length and 8-bit type + fields. The `length' is the length of the data area, and does not + include the `length' field itself. The format and interpretation of + the data area depends on the packet type. + + All packet descriptions below only specify the packet type and the + data that goes into the data field. Thus, they should be prefixed by + the `length' and `type' fields. + + The maximum size of a packet is in practice determined by the client + (the maximum size of read or write requests that it sends, plus a few + bytes of packet overhead). All servers SHOULD support packets of at + least 34000 bytes (where the packet size refers to the full length, + including the header above). This should allow for reads and writes + of at most 32768 bytes. + + There is no limit on the number of outstanding (non-acknowledged) + requests that the client may send to the server. In practice this is + limited by the buffering available on the data stream and the queuing + performed by the server. If the server's queues are full, it should + not read any more data from the stream, and flow control will prevent + the client from sending more requests. Note, however, that while + there is no restriction on the protocol level, the client's API may + provide a limit in order to prevent infinite queuing of outgoing + requests at the client. + + The following values are defined for packet types. + + + + + + + + + + + + + + + +Galbraith, et al. Expires April 16, 2003 [Page 5] + +Internet-Draft SSH File Transfer Protocol October 2002 + + + #define SSH_FXP_INIT 1 + #define SSH_FXP_VERSION 2 + #define SSH_FXP_OPEN 3 + #define SSH_FXP_CLOSE 4 + #define SSH_FXP_READ 5 + #define SSH_FXP_WRITE 6 + #define SSH_FXP_LSTAT 7 + #define SSH_FXP_FSTAT 8 + #define SSH_FXP_SETSTAT 9 + #define SSH_FXP_FSETSTAT 10 + #define SSH_FXP_OPENDIR 11 + #define SSH_FXP_READDIR 12 + #define SSH_FXP_REMOVE 13 + #define SSH_FXP_MKDIR 14 + #define SSH_FXP_RMDIR 15 + #define SSH_FXP_REALPATH 16 + #define SSH_FXP_STAT 17 + #define SSH_FXP_RENAME 18 + #define SSH_FXP_READLINK 19 + #define SSH_FXP_SYMLINK 20 + + #define SSH_FXP_STATUS 101 + #define SSH_FXP_HANDLE 102 + #define SSH_FXP_DATA 103 + #define SSH_FXP_NAME 104 + #define SSH_FXP_ATTRS 105 + + #define SSH_FXP_EXTENDED 200 + #define SSH_FXP_EXTENDED_REPLY 201 + + RESERVED_FOR_EXTENSIONS 210-255 + + Additional packet types should only be defined if the protocol + version number (see Section ``Protocol Initialization'') is + incremented, and their use MUST be negotiated using the version + number. However, the SSH_FXP_EXTENDED and SSH_FXP_EXTENDED_REPLY + packets can be used to implement vendor-specific extensions. See + Section ``Vendor-Specific-Extensions'' for more details. + + + + + + + + + + + + + +Galbraith, et al. Expires April 16, 2003 [Page 6] + +Internet-Draft SSH File Transfer Protocol October 2002 + + +4. Protocol Initialization + + When the file transfer protocol starts, the client first sends a + SSH_FXP_INIT (including its version number) packet to the server. + The server responds with a SSH_FXP_VERSION packet, supplying the + lowest of its own and the client's version number. Both parties + should from then on adhere to particular version of the protocol. + + The version number of the protocol specified in this document is 4. + The version number should be incremented for each incompatible + revision of this protocol. + +4.1 Client Initialization + + The SSH_FXP_INIT packet (from client to server) has the following + data: + + uint32 version + + Version 3 of this protocol allowed clients to include extensions in + the SSH_FXP_INIT packet; however, this can cause interoperability + problems with version 1 and version 2 servers because the client must + send this packet before knowing the servers version. + + In this version of the protocol, clients MUST use the + SSH_FXP_EXTENDED packet to send extensions to the server after + version exchange has completed. Clients MUST NOT include extensions + in the version packet. This will prevent interoperability problems + with older servers + +4.2 Server Initialization + + The SSH_FXP_VERSION packet (from server to client) has the following + data: + + uint32 version + <extension data> + + 'version' is the lower of the protocol version supported by the + server and the version number received from the client. + + The extension data may be empty, or may be a sequence of + + string extension_name + string extension_data + + pairs (both strings MUST always be present if one is, but the + `extension_data' string may be of zero length). If present, these + + + +Galbraith, et al. Expires April 16, 2003 [Page 7] + +Internet-Draft SSH File Transfer Protocol October 2002 + + + strings indicate extensions to the baseline protocol. The + `extension_name' field(s) identify the name of the extension. The + name should be of the form "name@domain", where the domain is the DNS + domain name of the organization defining the extension. Additional + names that are not of this format may be defined later by the IETF. + Implementations MUST silently ignore any extensions whose name they + do not recognize. + +4.3 Determining Server Newline Convention + + In order to correctly process text files in a cross platform + compatible way, the newline convention must be converted from that of + the server to that of the client, or, during an upload, from that of + the client to that of the server. + + Versions 3 and prior of this protocol made no provisions for + processing text files. Many clients implemented some sort of + conversion algorithm, but without either a 'canonical' on the wire + format or knowledge of the servers newline convention, correct + conversion was not always possible. + + Starting with Version 4, the SSH_FXF_TEXT file open flag (Section + 6.3) makes it possible to request that the server translate a file to + a 'canonical' on the wire format. This format uses \r\n as the line + separator. + + Servers for systems using multiple newline characters (for example, + Mac OS X or VMS) or systems using counted records, MUST translate to + the canonical form. + + However, to ease the burden of implementation on servers that use a + single, simple separator sequence, the following extension allows the + canonical format to be changed. + + string "newline" + string new-canonical-separator (usually "\r" or "\n" or "\r\n") + + All clients MUST support this extension. + + When processing text files, clients SHOULD NOT translate any + character or sequence that is not an exact match of the servers + newline separator. + + In particular, if the newline sequence being used is the canonical + "\r\n" sequence, a lone \r or a lone \n SHOULD be written through + without change. + + + + + +Galbraith, et al. Expires April 16, 2003 [Page 8] + +Internet-Draft SSH File Transfer Protocol October 2002 + + +5. File Attributes + + A new compound data type is defined for encoding file attributes. + The same encoding is used both when returning file attributes from + the server and when sending file attributes to the server. When + sending it to the server, the flags field specifies which attributes + are included, and the server will use default values for the + remaining attributes (or will not modify the values of remaining + attributes). When receiving attributes from the server, the flags + specify which attributes are included in the returned data. The + server normally returns all attributes it knows about. + + uint32 flags + byte type always present + uint64 size present only if flag SSH_FILEXFER_ATTR_SIZE + string owner present only if flag SSH_FILEXFER_ATTR_OWNERGROUP + string group present only if flag SSH_FILEXFER_ATTR_OWNERGROUP + uint32 permissions present only if flag SSH_FILEXFER_ATTR_PERMISSIONS + uint32 atime present only if flag SSH_FILEXFER_ATTR_ACCESSTIME + uint32 createtime present only if flag SSH_FILEXFER_ATTR_CREATETIME + uint32 mtime present only if flag SSH_FILEXFER_ATTR_MODIFYTIME + string acl present only if flag SSH_FILEXFER_ATTR_ACL + uint32 extended_count present only if flag SSH_FILEXFER_ATTR_EXTENDED + string extended_type + string extended_data + ... more extended data (extended_type - extended_data pairs), + so that number of pairs equals extended_count + + +5.1 Flags + + The `flags' specify which of the fields are present. Those fields + for which the corresponding flag is not set are not present (not + included in the packet). New flags can only be added by incrementing + the protocol version number (or by using the extension mechanism + described below). + + The flags bits are defined to have the following values: + + #define SSH_FILEXFER_ATTR_SIZE 0x00000001 + #define SSH_FILEXFER_ATTR_PERMISSIONS 0x00000004 + #define SSH_FILEXFER_ATTR_ACCESSTIME 0x00000008 + #define SSH_FILEXFER_ATTR_CREATETIME 0x00000010 + #define SSH_FILEXFER_ATTR_MODIFYTIME 0x00000020 + #define SSH_FILEXFER_ATTR_ACL 0x00000040 + #define SSH_FILEXFER_ATTR_OWNERGROUP 0x00000080 + #define SSH_FILEXFER_ATTR_EXTENDED 0x80000000 + + + + +Galbraith, et al. Expires April 16, 2003 [Page 9] + +Internet-Draft SSH File Transfer Protocol October 2002 + + + In previous versions of this protocol flags value 0x00000002 was + SSH_FILEXFER_ATTR_UIDGID. This value is now unused, and OWNERGROUP + was given a new value in order to ease implementation burden. + 0x00000002 MUST NOT appear in the mask. Some future version of this + protocol may reuse flag 0x00000002. + +5.2 Type + + The type field is always present. The following types are defined: + + #define SSH_FILEXFER_TYPE_REGULAR 1 + #define SSH_FILEXFER_TYPE_DIRECTORY 2 + #define SSH_FILEXFER_TYPE_SYMLINK 3 + #define SSH_FILEXFER_TYPE_SPECIAL 4 + #define SSH_FILEXFER_TYPE_UNKNOWN 5 + + On a POSIX system, these values would be derived from the permission + field. + +5.3 Size + + The `size' field specifies the size of the file on disk, in bytes. + If it is present during file creation, it should be considered a hint + as to the files eventual size. + + Files opened with the SSH_FXF_TEXT flag may have a size that is + greater or less than the value of the size field. + +5.4 Owner and Group + + The `owner' and `group' fields are represented as UTF-8 strings; this + is the form used by NFS v4. See NFS version 4 Protocol. [3] The + following text is selected quotations from section 5.6. + + To avoid a representation that is tied to a particular underlying + implementation at the client or server, the use of UTF-8 strings has + been chosen. The string should be of the form user@dns_domain". + This will allow for a client and server that do not use the same + local representation the ability to translate to a common syntax that + can be interpreted by both. In the case where there is no + translation available to the client or server, the attribute value + must be constructed without the "@". Therefore, the absence of the @ + from the owner or owner_group attribute signifies that no translation + was available and the receiver of the attribute should not place any + special meaning with the attribute value. Even though the attribute + value can not be translated, it may still be useful. In the case of + a client, the attribute string may be used for local display of + ownership. + + + +Galbraith, et al. Expires April 16, 2003 [Page 10] + +Internet-Draft SSH File Transfer Protocol October 2002 + + +5.5 Permissions + + The `permissions' field contains a bit mask of file permissions as + defined by POSIX [1]. + +5.6 Times + + The 'atime', 'createtime', and 'mtime' contain the access, creation, + and modification times of the files, respectively. They are + represented as seconds from Jan 1, 1970 in UTC. + +5.7 ACL + + The 'ACL' field contains an ACL similar to that defined in section + 5.9 of NFS version 4 Protocol [3]. + + uint32 ace-count + + repeated ace-count time: + uint32 ace-type + uint32 ace-flag + uint32 ace-mask + string who [UTF-8] + + ace-type is one of the following four values (taken from NFS Version + 4 Protocol [3]: + + const ACE4_ACCESS_ALLOWED_ACE_TYPE = 0x00000000; + const ACE4_ACCESS_DENIED_ACE_TYPE = 0x00000001; + const ACE4_SYSTEM_AUDIT_ACE_TYPE = 0x00000002; + const ACE4_SYSTEM_ALARM_ACE_TYPE = 0x00000003; + + ace-flag is a combination of the following flag values. See NFS + Version 4 Protocol [3] section 5.9.2: + + const ACE4_FILE_INHERIT_ACE = 0x00000001; + const ACE4_DIRECTORY_INHERIT_ACE = 0x00000002; + const ACE4_NO_PROPAGATE_INHERIT_ACE = 0x00000004; + const ACE4_INHERIT_ONLY_ACE = 0x00000008; + const ACE4_SUCCESSFUL_ACCESS_ACE_FLAG = 0x00000010; + const ACE4_FAILED_ACCESS_ACE_FLAG = 0x00000020; + const ACE4_IDENTIFIER_GROUP = 0x00000040; + + ace-mask is any combination of the following flags (taken from NFS + Version 4 Protocol [3] section 5.9.3: + + + + + + +Galbraith, et al. Expires April 16, 2003 [Page 11] + +Internet-Draft SSH File Transfer Protocol October 2002 + + + const ACE4_READ_DATA = 0x00000001; + const ACE4_LIST_DIRECTORY = 0x00000001; + const ACE4_WRITE_DATA = 0x00000002; + const ACE4_ADD_FILE = 0x00000002; + const ACE4_APPEND_DATA = 0x00000004; + const ACE4_ADD_SUBDIRECTORY = 0x00000004; + const ACE4_READ_NAMED_ATTRS = 0x00000008; + const ACE4_WRITE_NAMED_ATTRS = 0x00000010; + const ACE4_EXECUTE = 0x00000020; + const ACE4_DELETE_CHILD = 0x00000040; + const ACE4_READ_ATTRIBUTES = 0x00000080; + const ACE4_WRITE_ATTRIBUTES = 0x00000100; + const ACE4_DELETE = 0x00010000; + const ACE4_READ_ACL = 0x00020000; + const ACE4_WRITE_ACL = 0x00040000; + const ACE4_WRITE_OWNER = 0x00080000; + const ACE4_SYNCHRONIZE = 0x00100000; + + who is a UTF-8 string of the form described in 'Owner and Group' + (Section 5.4) + +5.8 Extended attributes + + The SSH_FILEXFER_ATTR_EXTENDED flag provides a general extension + mechanism for vendor-specific extensions. If the flag is specified, + then the `extended_count' field is present. It specifies the number + of extended_type-extended_data pairs that follow. Each of these + pairs specifies an extended attribute. For each of the attributes, + the extended_type field should be a string of the format + "name@domain", where "domain" is a valid, registered domain name and + "name" identifies the method. The IETF may later standardize certain + names that deviate from this format (e.g., that do not contain the + "@" sign). The interpretation of `extended_data' depends on the + type. Implementations SHOULD ignore extended data fields that they + do not understand. + + Additional fields can be added to the attributes by either defining + additional bits to the flags field to indicate their presence, or by + defining extended attributes for them. The extended attributes + mechanism is recommended for most purposes; additional flags bits + should only be defined by an IETF standards action that also + increments the protocol version number. The use of such new fields + MUST be negotiated by the version number in the protocol exchange. + It is a protocol error if a packet with unsupported protocol bits is + received. + + + + + + +Galbraith, et al. Expires April 16, 2003 [Page 12] + +Internet-Draft SSH File Transfer Protocol October 2002 + + +6. Requests From the Client to the Server + + Requests from the client to the server represent the various file + system operations. Each request begins with an `id' field, which is + a 32-bit identifier identifying the request (selected by the client). + The same identifier will be returned in the response to the request. + One possible implementation is a monotonically increasing request + sequence number (modulo 2^32). + + Many operations in the protocol operate on open files. The + SSH_FXP_OPEN request can return a file handle (which is an opaque + variable-length string) which may be used to access the file later + (e.g. in a read operation). The client MUST NOT send requests the + server with bogus or closed handles. However, the server MUST + perform adequate checks on the handle in order to avoid security + risks due to fabricated handles. + + This design allows either stateful and stateless server + implementation, as well as an implementation which caches state + between requests but may also flush it. The contents of the file + handle string are entirely up to the server and its design. The + client should not modify or attempt to interpret the file handle + strings. + + The file handle strings MUST NOT be longer than 256 bytes. + +6.1 Request Synchronization and Reordering + + The protocol and implementations MUST process requests relating to + the same file in the order in which they are received. In other + words, if an application submits multiple requests to the server, the + results in the responses will be the same as if it had sent the + requests one at a time and waited for the response in each case. For + example, the server may process non-overlapping read/write requests + to the same file in parallel, but overlapping reads and writes cannot + be reordered or parallelized. However, there are no ordering + restrictions on the server for processing requests from two different + file transfer connections. The server may interleave and parallelize + them at will. + + There are no restrictions on the order in which responses to + outstanding requests are delivered to the client, except that the + server must ensure fairness in the sense that processing of no + request will be indefinitely delayed even if the client is sending + other requests so that there are multiple outstanding requests all + the time. + + + + + +Galbraith, et al. Expires April 16, 2003 [Page 13] + +Internet-Draft SSH File Transfer Protocol October 2002 + + +6.2 File Names + + This protocol represents file names as strings. File names are + assumed to use the slash ('/') character as a directory separator. + + File names starting with a slash are "absolute", and are relative to + the root of the file system. Names starting with any other character + are relative to the user's default directory (home directory). Note + that identifying the user is assumed to take place outside of this + protocol. + + Servers SHOULD interpret a path name component ".." as referring to + the parent directory, and "." as referring to the current directory. + If the server implementation limits access to certain parts of the + file system, it must be extra careful in parsing file names when + enforcing such restrictions. There have been numerous reported + security bugs where a ".." in a path name has allowed access outside + the intended area. + + An empty path name is valid, and it refers to the user's default + directory (usually the user's home directory). + + Otherwise, no syntax is defined for file names by this specification. + Clients should not make any other assumptions; however, they can + splice path name components returned by SSH_FXP_READDIR together + using a slash ('/') as the separator, and that will work as expected. + + In order to comply with IETF Policy on Character Sets and Languages + [2], all filenames are to be encoded in UTF-8. The shortest valid + UTF-8 encoding of the UNICODE data MUST be used. The server is + responsible for converting the UNICODE data to whatever canonical + form it requires. + + For example, if the server requires that precomposed characters + always be used, the server MUST NOT assume the filename as sent by + the client has this attribute, but must do this normalization itself. + + It is understood that the lack of well-defined semantics for file + names may cause interoperability problems between clients and servers + using radically different operating systems. However, this approach + is known to work acceptably with most systems, and alternative + approaches that e.g. treat file names as sequences of structured + components are quite complicated. + +6.3 Opening, Creating, and Closing Files + + Files are opened and created using the SSH_FXP_OPEN message, whose + data part is as follows: + + + +Galbraith, et al. Expires April 16, 2003 [Page 14] + +Internet-Draft SSH File Transfer Protocol October 2002 + + + uint32 id + string filename [UTF-8] + uint32 pflags + ATTRS attrs + + The `id' field is the request identifier as for all requests. + + The `filename' field specifies the file name. See Section ``File + Names'' for more information. + + The `pflags' field is a bitmask. The following bits have been + defined. + + #define SSH_FXF_READ 0x00000001 + #define SSH_FXF_WRITE 0x00000002 + #define SSH_FXF_APPEND 0x00000004 + #define SSH_FXF_CREAT 0x00000008 + #define SSH_FXF_TRUNC 0x00000010 + #define SSH_FXF_EXCL 0x00000020 + #define SSH_FXF_TEXT 0x00000040 + + These have the following meanings: + + SSH_FXF_READ + Open the file for reading. + + SSH_FXF_WRITE + Open the file for writing. If both this and SSH_FXF_READ are + specified, the file is opened for both reading and writing. + + SSH_FXF_APPEND + Force all writes to append data at the end of the file. The + offset parameter to write will be ignored. + + SSH_FXF_CREAT + If this flag is specified, then a new file will be created if one + does not already exist (if O_TRUNC is specified, the new file will + be truncated to zero length if it previously exists). + + SSH_FXF_TRUNC + Forces an existing file with the same name to be truncated to zero + length when creating a file by specifying SSH_FXF_CREAT. + SSH_FXF_CREAT MUST also be specified if this flag is used. + + SSH_FXF_EXCL + Causes the request to fail if the named file already exists. + SSH_FXF_CREAT MUST also be specified if this flag is used. + + + + +Galbraith, et al. Expires April 16, 2003 [Page 15] + +Internet-Draft SSH File Transfer Protocol October 2002 + + + SSH_FXF_TEXT + Indicates that the server should treat the file as text and + convert it to the canonical newline convention in use. (See + Determining Server Newline Convention. (Section 4.3) + + When a file is opened with the FXF_TEXT flag, the offset field in + both the read and write function are ignored. + + Servers MUST correctly process multiple parallel reads and writes + correctly in this mode. Naturally, it is permissible for them to + do this by serializing the requests. It would not be possible for + a client to reliably detect a server that does not implement + parallel writes in time to prevent damage. + + Clients SHOULD use the SSH_FXF_APPEND flag to append data to a + text file rather then using write with a calculated offset. + + To support seeks on text file the following SSH_FXP_EXTENDED + packet is defined. + + + + string "text-seek" + string file-handle + uint64 line-number + + line-number is the index of the line number to seek to, where byte + 0 in the file is line number 0, and the byte directly following + the first newline sequence in the file is line number 1 and so on. + + The response to a "text-seek" request is an SSH_FXP_STATUS + message. + + An attempt to seek past the end-of-file should result in a + SSH_FX_EOF status. + + Servers SHOULD support at least one "text-seek" in order to + support resume. However, a client MUST be prepared to receive + SSH_FX_OP_UNSUPPORTED when attempting a "text-seek" operation. + The client can then try a fall-back strategy, if it has one. + + Clients MUST be prepared to handle SSH_FX_OP_UNSUPPORTED returned + for read or write operations that are not sequential. + + The `attrs' field specifies the initial attributes for the file. + Default values will be used for those attributes that are not + specified. See Section ``File Attributes'' for more information. + + + + +Galbraith, et al. Expires April 16, 2003 [Page 16] + +Internet-Draft SSH File Transfer Protocol October 2002 + + + The response to this message will be either SSH_FXP_HANDLE (if the + operation is successful) or SSH_FXP_STATUS (if the operation fails). + + A file is closed by using the SSH_FXP_CLOSE request. Its data field + has the following format: + + uint32 id + string handle + + where `id' is the request identifier, and `handle' is a handle + previously returned in the response to SSH_FXP_OPEN or + SSH_FXP_OPENDIR. The handle becomes invalid immediately after this + request has been sent. + + The response to this request will be a SSH_FXP_STATUS message. One + should note that on some server platforms even a close can fail. + This can happen e.g. if the server operating system caches writes, + and an error occurs while flushing cached writes during the close. + +6.4 Reading and Writing + + Once a file has been opened, it can be read using the SSH_FXP_READ + message, which has the following format: + + uint32 id + string handle + uint64 offset + uint32 len + + where `id' is the request identifier, `handle' is an open file handle + returned by SSH_FXP_OPEN, `offset' is the offset (in bytes) relative + to the beginning of the file from where to start reading, and `len' + is the maximum number of bytes to read. + + In response to this request, the server will read as many bytes as it + can from the file (up to `len'), and return them in a SSH_FXP_DATA + message. If an error occurs or EOF is encountered before reading any + data, the server will respond with SSH_FXP_STATUS. For normal disk + files, it is guaranteed that this will read the specified number of + bytes, or up to end of file. For e.g. device files this may return + fewer bytes than requested. + + Writing to a file is achieved using the SSH_FXP_WRITE message, which + has the following format: + + + + + + + +Galbraith, et al. Expires April 16, 2003 [Page 17] + +Internet-Draft SSH File Transfer Protocol October 2002 + + + uint32 id + string handle + uint64 offset + string data + + where `id' is a request identifier, `handle' is a file handle + returned by SSH_FXP_OPEN, `offset' is the offset (in bytes) from the + beginning of the file where to start writing, and `data' is the data + to be written. + + The write will extend the file if writing beyond the end of the file. + It is legal to write way beyond the end of the file; the semantics + are to write zeroes from the end of the file to the specified offset + and then the data. On most operating systems, such writes do not + allocate disk space but instead leave "holes" in the file. + + The server responds to a write request with a SSH_FXP_STATUS message. + +6.5 Removing and Renaming Files + + Files can be removed using the SSH_FXP_REMOVE message. It has the + following format: + + uint32 id + string filename [UTF-8] + + where `id' is the request identifier and `filename' is the name of + the file to be removed. See Section ``File Names'' for more + information. This request cannot be used to remove directories. + + The server will respond to this request with a SSH_FXP_STATUS + message. + + Files (and directories) can be renamed using the SSH_FXP_RENAME + message. Its data is as follows: + + uint32 id + string oldpath [UTF-8] + string newpath [UTF-8] + + where `id' is the request identifier, `oldpath' is the name of an + existing file or directory, and `newpath' is the new name for the + file or directory. It is an error if there already exists a file + with the name specified by newpath. The server may also fail rename + requests in other situations, for example if `oldpath' and `newpath' + point to different file systems on the server. + + The server will respond to this request with a SSH_FXP_STATUS + + + +Galbraith, et al. Expires April 16, 2003 [Page 18] + +Internet-Draft SSH File Transfer Protocol October 2002 + + + message. + +6.6 Creating and Deleting Directories + + New directories can be created using the SSH_FXP_MKDIR request. It + has the following format: + + uint32 id + string path [UTF-8] + ATTRS attrs + + where `id' is the request identifier. + + `path' specifies the directory to be created. See Section ``File + Names'' for more information on file names. + + `attrs' specifies the attributes that should be applied to it upon + creation. Attributes are discussed in more detail in Section ``File + Attributes''. + + The server will respond to this request with a SSH_FXP_STATUS + message. If a file or directory with the specified path already + exists, an error will be returned. + + Directories can be removed using the SSH_FXP_RMDIR request, which has + the following format: + + uint32 id + string path [UTF-8] + + where `id' is the request identifier, and `path' specifies the + directory to be removed. See Section ``File Names'' for more + information on file names. + + The server responds to this request with a SSH_FXP_STATUS message. + Errors may be returned from this operation for various reasons, + including, but not limited to, the path does not exist, the path does + not refer to a directory object, the directory is not empty, or the + user has insufficient access or permission to perform the requested + operation. + +6.7 Scanning Directories + + The files in a directory can be listed using the SSH_FXP_OPENDIR and + SSH_FXP_READDIR requests. Each SSH_FXP_READDIR request returns one + or more file names with full file attributes for each file. The + client should call SSH_FXP_READDIR repeatedly until it has found the + file it is looking for or until the server responds with a + + + +Galbraith, et al. Expires April 16, 2003 [Page 19] + +Internet-Draft SSH File Transfer Protocol October 2002 + + + SSH_FXP_STATUS message indicating an error (normally SSH_FX_EOF if + there are no more files in the directory). The client should then + close the handle using the SSH_FXP_CLOSE request. + + The SSH_FXP_OPENDIR opens a directory for reading. It has the + following format: + + uint32 id + string path [UTF-8] + + where `id' is the request identifier and `path' is the path name of + the directory to be listed (without any trailing slash). See Section + ``File Names'' for more information on file names. This will return + an error if the path does not specify a directory or if the directory + is not readable. The server will respond to this request with either + a SSH_FXP_HANDLE or a SSH_FXP_STATUS message. + + Once the directory has been successfully opened, files (and + directories) contained in it can be listed using SSH_FXP_READDIR + requests. These are of the format + + uint32 id + string handle + + where `id' is the request identifier, and `handle' is a handle + returned by SSH_FXP_OPENDIR. (It is a protocol error to attempt to + use an ordinary file handle returned by SSH_FXP_OPEN.) + + The server responds to this request with either a SSH_FXP_NAME or a + SSH_FXP_STATUS message. One or more names may be returned at a time. + Full status information is returned for each name in order to speed + up typical directory listings. + + If there are no more names available to be read, the server MUST + respond with a SSH_FXP_STATUS message with error code of SSH_FX_EOF. + + When the client no longer wishes to read more names from the + directory, it SHOULD call SSH_FXP_CLOSE for the handle. The handle + should be closed regardless of whether an error has occurred or not. + +6.8 Retrieving File Attributes + + Very often, file attributes are automatically returned by + SSH_FXP_READDIR. However, sometimes there is need to specifically + retrieve the attributes for a named file. This can be done using the + SSH_FXP_STAT, SSH_FXP_LSTAT and SSH_FXP_FSTAT requests. + + SSH_FXP_STAT and SSH_FXP_LSTAT only differ in that SSH_FXP_STAT + + + +Galbraith, et al. Expires April 16, 2003 [Page 20] + +Internet-Draft SSH File Transfer Protocol October 2002 + + + follows symbolic links on the server, whereas SSH_FXP_LSTAT does not + follow symbolic links. Both have the same format: + + uint32 id + string path [UTF-8] + uint32 flags + + where `id' is the request identifier, and `path' specifies the file + system object for which status is to be returned. The server + responds to this request with either SSH_FXP_ATTRS or SSH_FXP_STATUS. + + The flags field specify the attribute flags in which the client has + particular interest. This is a hint to the server. For example, + because retrieving owner / group and acl information can be an + expensive operation under some operating systems, the server may + choose not to retrieve this information unless the client expresses a + specific interest in it. + + The client has no guarantee the server will provide all the fields + that it has expressed an interest in. + + SSH_FXP_FSTAT differs from the others in that it returns status + information for an open file (identified by the file handle). Its + format is as follows: + + uint32 id + string handle + uint32 flags + + where `id' is the request identifier and `handle' is a file handle + returned by SSH_FXP_OPEN. The server responds to this request with + SSH_FXP_ATTRS or SSH_FXP_STATUS. + +6.9 Setting File Attributes + + File attributes may be modified using the SSH_FXP_SETSTAT and + SSH_FXP_FSETSTAT requests. These requests are used for operations + such as changing the ownership, permissions or access times, as well + as for truncating a file. + + The SSH_FXP_SETSTAT request is of the following format: + + uint32 id + string path [UTF-8] + ATTRS attrs + + where `id' is the request identifier, `path' specifies the file + system object (e.g. file or directory) whose attributes are to be + + + +Galbraith, et al. Expires April 16, 2003 [Page 21] + +Internet-Draft SSH File Transfer Protocol October 2002 + + + modified, and `attrs' specifies the modifications to be made to its + attributes. Attributes are discussed in more detail in Section + ``File Attributes''. + + An error will be returned if the specified file system object does + not exist or the user does not have sufficient rights to modify the + specified attributes. The server responds to this request with a + SSH_FXP_STATUS message. + + The SSH_FXP_FSETSTAT request modifies the attributes of a file which + is already open. It has the following format: + + uint32 id + string handle + ATTRS attrs + + where `id' is the request identifier, `handle' (MUST be returned by + SSH_FXP_OPEN) identifies the file whose attributes are to be + modified, and `attrs' specifies the modifications to be made to its + attributes. Attributes are discussed in more detail in Section + ``File Attributes''. The server will respond to this request with + SSH_FXP_STATUS. + +6.10 Dealing with Symbolic links + + The SSH_FXP_READLINK request may be used to read the target of a + symbolic link. It would have a data part as follows: + + uint32 id + string path [UTF-8] + + where `id' is the request identifier and `path' specifies the path + name of the symlink to be read. + + The server will respond with a SSH_FXP_NAME packet containing only + one name and a dummy attributes value. The name in the returned + packet contains the target of the link. If an error occurs, the + server may respond with SSH_FXP_STATUS. + + The SSH_FXP_SYMLINK request will create a symbolic link on the + server. It is of the following format + + uint32 id + string linkpath [UTF-8] + string targetpath [UTF-8] + + where `id' is the request identifier, `linkpath' specifies the path + name of the symlink to be created and `targetpath' specifies the + + + +Galbraith, et al. Expires April 16, 2003 [Page 22] + +Internet-Draft SSH File Transfer Protocol October 2002 + + + target of the symlink. The server shall respond with a + SSH_FXP_STATUS indicating either success (SSH_FX_OK) or an error + condition. + +6.11 Canonicalizing the Server-Side Path Name + + The SSH_FXP_REALPATH request can be used to have the server + canonicalize any given path name to an absolute path. This is useful + for converting path names containing ".." components or relative + pathnames without a leading slash into absolute paths. The format of + the request is as follows: + + uint32 id + string path [UTF-8] + + where `id' is the request identifier and `path' specifies the path + name to be canonicalized. The server will respond with a + SSH_FXP_NAME packet containing the name in canonical form and a dummy + attributes value. If an error occurs, the server may also respond + with SSH_FXP_STATUS. + +6.11.1 Best practice for dealing with paths + + The client SHOULD treat the results of SSH_FXP_REALPATH as a + canonical absolute path, even if the path does not appear to be + absolute. A client that use REALPATH(".") and treats the result as + absolute, even if there is no leading slash, will continue to + function correctly, even when talking to a Windows NT or VMS style + system, where absolute paths may not begin with a slash. + + For example, if the client wishes to change directory up, and the + server has returned "c:/x/y/z" from REALPATH, the client SHOULD use + "c:/x/y/z/..". + + As a second example, if the client wishes to open the file "x.txt" in + the current directory, and server has returned "dka100:/x/y/z" as the + canonical path of the directory, the client SHOULD open "dka100:/x/y/ + z/x.txt" + + + + + + + + + + + + + +Galbraith, et al. Expires April 16, 2003 [Page 23] + +Internet-Draft SSH File Transfer Protocol October 2002 + + +7. Responses from the Server to the Client + + The server responds to the client using one of a few response + packets. All requests can return a SSH_FXP_STATUS response upon + failure. When the operation is successful, any of the responses may + be returned (depending on the operation). If no data needs to be + returned to the client, the SSH_FXP_STATUS response with SSH_FX_OK + status is appropriate. Otherwise, the SSH_FXP_HANDLE message is used + to return a file handle (for SSH_FXP_OPEN and SSH_FXP_OPENDIR + requests), SSH_FXP_DATA is used to return data from SSH_FXP_READ, + SSH_FXP_NAME is used to return one or more file names from a + SSH_FXP_READDIR or SSH_FXP_REALPATH request, and SSH_FXP_ATTRS is + used to return file attributes from SSH_FXP_STAT, SSH_FXP_LSTAT, and + SSH_FXP_FSTAT requests. + + Exactly one response will be returned for each request. Each + response packet contains a request identifier which can be used to + match each response with the corresponding request. Note that it is + legal to have several requests outstanding simultaneously, and the + server is allowed to send responses to them in a different order from + the order in which the requests were sent (the result of their + execution, however, is guaranteed to be as if they had been processed + one at a time in the order in which the requests were sent). + + Response packets are of the same general format as request packets. + Each response packet begins with the request identifier. + + The format of the data portion of the SSH_FXP_STATUS response is as + follows: + + uint32 id + uint32 error/status code + string error message (ISO-10646 UTF-8 [RFC-2279]) + string language tag (as defined in [RFC-1766]) + + where `id' is the request identifier, and `error/status code' + indicates the result of the requested operation. The value SSH_FX_OK + indicates success, and all other values indicate failure. + + Currently, the following values are defined (other values may be + defined by future versions of this protocol): + + + + + + + + + + +Galbraith, et al. Expires April 16, 2003 [Page 24] + +Internet-Draft SSH File Transfer Protocol October 2002 + + + #define SSH_FX_OK 0 + #define SSH_FX_EOF 1 + #define SSH_FX_NO_SUCH_FILE 2 + #define SSH_FX_PERMISSION_DENIED 3 + #define SSH_FX_FAILURE 4 + #define SSH_FX_BAD_MESSAGE 5 + #define SSH_FX_NO_CONNECTION 6 + #define SSH_FX_CONNECTION_LOST 7 + #define SSH_FX_OP_UNSUPPORTED 8 + #define SSH_FX_INVALID_HANDLE 9 + #define SSH_FX_NO_SUCH_PATH 10 + #define SSH_FX_FILE_ALREADY_EXISTS 11 + #define SSH_FX_WRITE_PROTECT 12 + + SSH_FX_OK + Indicates successful completion of the operation. + + SSH_FX_EOF + indicates end-of-file condition; for SSH_FX_READ it means that no + more data is available in the file, and for SSH_FX_READDIR it + indicates that no more files are contained in the directory. + + SSH_FX_NO_SUCH_FILE + is returned when a reference is made to a file which does not + exist. + + SSH_FX_PERMISSION_DENIED + is returned when the authenticated user does not have sufficient + permissions to perform the operation. + + SSH_FX_FAILURE + is a generic catch-all error message; it should be returned if an + error occurs for which there is no more specific error code + defined. + + SSH_FX_BAD_MESSAGE + may be returned if a badly formatted packet or protocol + incompatibility is detected. + + SSH_FX_NO_CONNECTION + is a pseudo-error which indicates that the client has no + connection to the server (it can only be generated locally by the + client, and MUST NOT be returned by servers). + + SSH_FX_CONNECTION_LOST + is a pseudo-error which indicates that the connection to the + server has been lost (it can only be generated locally by the + client, and MUST NOT be returned by servers). + + + +Galbraith, et al. Expires April 16, 2003 [Page 25] + +Internet-Draft SSH File Transfer Protocol October 2002 + + + SSH_FX_OP_UNSUPPORTED + indicates that an attempt was made to perform an operation which + is not supported for the server (it may be generated locally by + the client if e.g. the version number exchange indicates that a + required feature is not supported by the server, or it may be + returned by the server if the server does not implement an + operation). + + SSH_FX_INVALID_HANDLE + The handle value was invalid. + + SSH_FX_NO_SUCH_PATH + The file path does not exist or is invalid. + + SSH_FX_FILE_ALREADY_EXISTS + The file already exists. + + SSH_FX_WRITE_PROTECT + The file is on read only media, or the media is write protected. + + The SSH_FXP_HANDLE response has the following format: + + uint32 id + string handle + + where `id' is the request identifier, and `handle' is an arbitrary + string that identifies an open file or directory on the server. The + handle is opaque to the client; the client MUST NOT attempt to + interpret or modify it in any way. The length of the handle string + MUST NOT exceed 256 data bytes. + + The SSH_FXP_DATA response has the following format: + + uint32 id + string data + + where `id' is the request identifier, and `data' is an arbitrary byte + string containing the requested data. The data string may be at most + the number of bytes requested in a SSH_FXP_READ request, but may also + be shorter if end of file is reached or if the read is from something + other than a regular file. + + The SSH_FXP_NAME response has the following format: + + + + + + + + +Galbraith, et al. Expires April 16, 2003 [Page 26] + +Internet-Draft SSH File Transfer Protocol October 2002 + + + uint32 id + uint32 count + repeats count times: + string filename [UTF-8] + ATTRS attrs + + where `id' is the request identifier, `count' is the number of names + returned in this response, and the remaining fields repeat `count' + times (so that all three fields are first included for the first + file, then for the second file, etc). In the repeated part, + `filename' is a file name being returned (for SSH_FXP_READDIR, it + will be a relative name within the directory, without any path + components; for SSH_FXP_REALPATH it will be an absolute path name), + and `attrs' is the attributes of the file as described in Section + ``File Attributes''. + + The SSH_FXP_ATTRS response has the following format: + + uint32 id + ATTRS attrs + + where `id' is the request identifier, and `attrs' is the returned + file attributes as described in Section ``File Attributes''. + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Galbraith, et al. Expires April 16, 2003 [Page 27] + +Internet-Draft SSH File Transfer Protocol October 2002 + + +8. Vendor-Specific Extensions + + The SSH_FXP_EXTENDED request provides a generic extension mechanism + for adding vendor-specific commands. The request has the following + format: + + uint32 id + string extended-request + ... any request-specific data ... + + where `id' is the request identifier, and `extended-request' is a + string of the format "name@domain", where domain is an internet + domain name of the vendor defining the request. The rest of the + request is completely vendor-specific, and servers should only + attempt to interpret it if they recognize the `extended-request' + name. + + The server may respond to such requests using any of the response + packets defined in Section ``Responses from the Server to the + Client''. Additionally, the server may also respond with a + SSH_FXP_EXTENDED_REPLY packet, as defined below. If the server does + not recognize the `extended-request' name, then the server MUST + respond with SSH_FXP_STATUS with error/status set to + SSH_FX_OP_UNSUPPORTED. + + The SSH_FXP_EXTENDED_REPLY packet can be used to carry arbitrary + extension-specific data from the server to the client. It is of the + following format: + + uint32 id + ... any request-specific data ... + + There is a range of packet types reserved for use by extensions. In + order to avoid collision, extensions that turn on the use of + additional packet types should determine those numbers dynamically. + + The suggested way of doing this is have an extension request from the + client to the server that enables the extension; the extension + response from the server to the client would specify the actual type + values to use, in additional to any other data. + + Extension authors should be mindful of the limited range of packet + types available (there are only 45 values available) and avoid + requiring a new packet type where possible. + + + + + + + +Galbraith, et al. Expires April 16, 2003 [Page 28] + +Internet-Draft SSH File Transfer Protocol October 2002 + + +9. Security Considerations + + This protocol assumes that it is run over a secure channel and that + the endpoints of the channel have been authenticated. Thus, this + protocol assumes that it is externally protected from network-level + attacks. + + This protocol provides file system access to arbitrary files on the + server (only constrained by the server implementation). It is the + responsibility of the server implementation to enforce any access + controls that may be required to limit the access allowed for any + particular user (the user being authenticated externally to this + protocol, typically using the SSH User Authentication Protocol [8]. + + Care must be taken in the server implementation to check the validity + of received file handle strings. The server should not rely on them + directly; it MUST check the validity of each handle before relying on + it. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Galbraith, et al. Expires April 16, 2003 [Page 29] + +Internet-Draft SSH File Transfer Protocol October 2002 + + +10. Changes from previous protocol versions + + The SSH File Transfer Protocol has changed over time, before it's + standardization. The following is a description of the incompatible + changes between different versions. + +10.1 Changes between versions 4 and 3 + + Many of the changes between version 4 and version 3 are to the + attribute structure to make it more flexible for non-unix platforms. + + o Make all filenames UTF-8. + + o Added 'newline' extension. + + o Made file attribute owner and group strings so they can actually + be used on disparate systems. + + o Added createtime field, and added separate flags for atime, + createtime, and mtime so they can be set separately. + + o Split the file type out of the permissions field and into it's own + field (which is always present.) + + o Added acl attribute. + + o Added SSH_FXF_TEXT file open flag. + + o Added flags field to the get stat commands so that the client can + specifically request information the server might not normally + included for performance reasons. + + o Removed the long filename from the names structure-- it can now be + built from information available in the attrs structure. + + o Added reserved range of packet numbers for extensions. + + o Added several additional error codes. + + o Change the way version negotiate works slightly. Previously, if + the client version were higher than the server version, the server + was supposed to 'echo back' the clients version. The server now + sends it's own version and the lower of the two is considered to + be the one in use. + + + + + + + +Galbraith, et al. Expires April 16, 2003 [Page 30] + +Internet-Draft SSH File Transfer Protocol October 2002 + + +10.2 Changes between versions 3 and 2 + + o The SSH_FXP_READLINK and SSH_FXP_SYMLINK messages were added. + + o The SSH_FXP_EXTENDED and SSH_FXP_EXTENDED_REPLY messages were + added. + + o The SSH_FXP_STATUS message was changed to include fields `error + message' and `language tag'. + + +10.3 Changes between versions 2 and 1 + + o The SSH_FXP_RENAME message was added. + + +10.4 Changes between versions 1 and 0 + + o Implementation changes, no actual protocol changes. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Galbraith, et al. Expires April 16, 2003 [Page 31] + +Internet-Draft SSH File Transfer Protocol October 2002 + + +11. Trademark Issues + + "ssh" is a registered trademark of SSH Communications Security Corp + in the United States and/or other countries. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Galbraith, et al. Expires April 16, 2003 [Page 32] + +Internet-Draft SSH File Transfer Protocol October 2002 + + +References + + [1] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and + P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January + 1999. + + [2] Alvestrand, H., "IETF Policy on Character Sets and Languages", + BCP 18, RFC 2277, January 1998. + + [3] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, + C., Eisler, M. and D. Noveck, "NFS version 4 Protocol", RFC + 3010, December 2000. + + [4] Institute of Electrical and Electronics Engineers, "Information + Technology - Portable Operating System Interface (POSIX) - Part + 1: System Application Program Interface (API) [C Language]", + IEEE Standard 1003.2, 1996. + + [5] Rinne, T., Ylonen, T., Kivinen, T., Saarinen, M. and S. + Lehtinen, "SSH Protocol Architecture", draft-ietf-secsh- + architecture-13 (work in progress), September 2002. + + [6] Rinne, T., Ylonen, T., Kivinen, T., Saarinen, M. and S. + Lehtinen, "SSH Protocol Transport Protocol", draft-ietf-secsh- + transport-15 (work in progress), September 2002. + + [7] Rinne, T., Ylonen, T., Kivinen, T., Saarinen, M. and S. + Lehtinen, "SSH Connection Protocol", draft-ietf-secsh-connect-16 + (work in progress), September 2002. + + [8] Rinne, T., Ylonen, T., Kivinen, T., Saarinen, M. and S. + Lehtinen, "SSH Authentication Protocol", draft-ietf-secsh- + userauth-16 (work in progress), September 2002. + + +Authors' Addresses + + Joseph Galbraith + VanDyke Software + 4848 Tramway Ridge Blvd + Suite 101 + Albuquerque, NM 87111 + US + + Phone: +1 505 332 5700 + EMail: [email protected] + + + + + +Galbraith, et al. Expires April 16, 2003 [Page 33] + +Internet-Draft SSH File Transfer Protocol October 2002 + + + Tatu Ylonen + SSH Communications Security Corp + Fredrikinkatu 42 + HELSINKI FIN-00100 + Finland + + EMail: [email protected] + + + Sami Lehtinen + SSH Communications Security Corp + Fredrikinkatu 42 + HELSINKI FIN-00100 + Finland + + EMail: [email protected] + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Galbraith, et al. Expires April 16, 2003 [Page 34] + +Internet-Draft SSH File Transfer Protocol October 2002 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2002). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Galbraith, et al. Expires April 16, 2003 [Page 35] + + diff --git a/lib/ssh/doc/standard/draft-ietf-secsh-filexfer-04.txt b/lib/ssh/doc/standard/draft-ietf-secsh-filexfer-04.txt new file mode 100644 index 0000000000..9f51883cd2 --- /dev/null +++ b/lib/ssh/doc/standard/draft-ietf-secsh-filexfer-04.txt @@ -0,0 +1,2130 @@ + + + +Secure Shell Working Group J. Galbraith +Internet-Draft VanDyke Software +Expires: June 18, 2003 T. Ylonen + S. Lehtinen + SSH Communications Security Corp + December 18, 2002 + + + SSH File Transfer Protocol + draft-ietf-secsh-filexfer-04.txt + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as + Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at http:// + www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on June 18, 2003. + +Copyright Notice + + Copyright (C) The Internet Society (2002). All Rights Reserved. + +Abstract + + The SSH File Transfer Protocol provides secure file transfer + functionality over any reliable data stream. It is the standard file + transfer protocol for use with the SSH2 protocol. This document + describes the file transfer protocol and its interface to the SSH2 + protocol suite. + + + + + + + +Galbraith, et al. Expires June 18, 2003 [Page 1] + +Internet-Draft SSH File Transfer Protocol December 2002 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Use with the SSH Connection Protocol . . . . . . . . . . . 4 + 3. General Packet Format . . . . . . . . . . . . . . . . . . 5 + 3.1 The use of stderr in the server . . . . . . . . . . . . . 6 + 4. Protocol Initialization . . . . . . . . . . . . . . . . . 8 + 4.1 Client Initialization . . . . . . . . . . . . . . . . . . 8 + 4.2 Server Initialization . . . . . . . . . . . . . . . . . . 8 + 4.3 Determining Server Newline Convention . . . . . . . . . . 9 + 5. File Attributes . . . . . . . . . . . . . . . . . . . . . 10 + 5.1 Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 5.2 Type . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 + 5.3 Size . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 + 5.4 Owner and Group . . . . . . . . . . . . . . . . . . . . . 11 + 5.5 Permissions . . . . . . . . . . . . . . . . . . . . . . . 12 + 5.6 Times . . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 5.7 ACL . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 5.8 Extended attributes . . . . . . . . . . . . . . . . . . . 14 + 6. Requests From the Client to the Server . . . . . . . . . . 15 + 6.1 Request Synchronization and Reordering . . . . . . . . . . 15 + 6.2 File Names . . . . . . . . . . . . . . . . . . . . . . . . 16 + 6.3 Opening, Creating, and Closing Files . . . . . . . . . . . 16 + 6.4 Reading and Writing . . . . . . . . . . . . . . . . . . . 19 + 6.5 Removing and Renaming Files . . . . . . . . . . . . . . . 20 + 6.6 Creating and Deleting Directories . . . . . . . . . . . . 21 + 6.7 Scanning Directories . . . . . . . . . . . . . . . . . . . 21 + 6.8 Retrieving File Attributes . . . . . . . . . . . . . . . . 22 + 6.9 Setting File Attributes . . . . . . . . . . . . . . . . . 23 + 6.10 Dealing with Symbolic links . . . . . . . . . . . . . . . 24 + 6.11 Canonicalizing the Server-Side Path Name . . . . . . . . . 25 + 6.11.1 Best practice for dealing with paths . . . . . . . . . . . 25 + 7. Responses from the Server to the Client . . . . . . . . . 26 + 8. Vendor-Specific Extensions . . . . . . . . . . . . . . . . 30 + 9. Security Considerations . . . . . . . . . . . . . . . . . 31 + 10. Changes from previous protocol versions . . . . . . . . . 32 + 10.1 Changes between versions 4 and 3 . . . . . . . . . . . . . 32 + 10.2 Changes between versions 3 and 2 . . . . . . . . . . . . . 33 + 10.3 Changes between versions 2 and 1 . . . . . . . . . . . . . 33 + 10.4 Changes between versions 1 and 0 . . . . . . . . . . . . . 33 + 11. Trademark Issues . . . . . . . . . . . . . . . . . . . . . 34 + References . . . . . . . . . . . . . . . . . . . . . . . . 35 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . 35 + Intellectual Property and Copyright Statements . . . . . . 37 + + + + + + + +Galbraith, et al. Expires June 18, 2003 [Page 2] + +Internet-Draft SSH File Transfer Protocol December 2002 + + +1. Introduction + + This protocol provides secure file transfer (and more generally file + system access) functionality over a reliable data stream, such as a + channel in the SSH2 protocol [5]. + + This protocol is designed so that it could be used to implement a + secure remote file system service, as well as a secure file transfer + service. + + This protocol assumes that it runs over a secure channel, and that + the server has already authenticated the user at the client end, and + that the identity of the client user is externally available to the + server implementation. + + In general, this protocol follows a simple request-response model. + Each request and response contains a sequence number and multiple + requests may be pending simultaneously. There are a relatively large + number of different request messages, but a small number of possible + response messages. Each request has one or more response messages + that may be returned in result (e.g., a read either returns data or + reports error status). + + The packet format descriptions in this specification follow the + notation presented in the secsh architecture draft. [5] + + Even though this protocol is described in the context of the SSH2 + protocol, this protocol is general and independent of the rest of the + SSH2 protocol suite. It could be used in a number of different + applications, such as secure file transfer over TLS RFC 2246 [1] and + transfer of management information in VPN applications. + + + + + + + + + + + + + + + + + + + + +Galbraith, et al. Expires June 18, 2003 [Page 3] + +Internet-Draft SSH File Transfer Protocol December 2002 + + +2. Use with the SSH Connection Protocol + + When used with the SSH2 Protocol suite, this protocol is intended to + be used from the SSH Connection Protocol [7] as a subsystem, as + described in section ``Starting a Shell or a Command''. The + subsystem name used with this protocol is "sftp". + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Galbraith, et al. Expires June 18, 2003 [Page 4] + +Internet-Draft SSH File Transfer Protocol December 2002 + + +3. General Packet Format + + All packets transmitted over the secure connection are of the + following format: + + uint32 length + byte type + byte[length - 1] data payload + + That is, they are just data preceded by 32-bit length and 8-bit type + fields. The `length' is the length of the data area, and does not + include the `length' field itself. The format and interpretation of + the data area depends on the packet type. + + All packet descriptions below only specify the packet type and the + data that goes into the data field. Thus, they should be prefixed by + the `length' and `type' fields. + + The maximum size of a packet is in practice determined by the client + (the maximum size of read or write requests that it sends, plus a few + bytes of packet overhead). All servers SHOULD support packets of at + least 34000 bytes (where the packet size refers to the full length, + including the header above). This should allow for reads and writes + of at most 32768 bytes. + + There is no limit on the number of outstanding (non-acknowledged) + requests that the client may send to the server. In practice this is + limited by the buffering available on the data stream and the queuing + performed by the server. If the server's queues are full, it should + not read any more data from the stream, and flow control will prevent + the client from sending more requests. Note, however, that while + there is no restriction on the protocol level, the client's API may + provide a limit in order to prevent infinite queuing of outgoing + requests at the client. + + The following values are defined for packet types. + + + + + + + + + + + + + + + +Galbraith, et al. Expires June 18, 2003 [Page 5] + +Internet-Draft SSH File Transfer Protocol December 2002 + + + #define SSH_FXP_INIT 1 + #define SSH_FXP_VERSION 2 + #define SSH_FXP_OPEN 3 + #define SSH_FXP_CLOSE 4 + #define SSH_FXP_READ 5 + #define SSH_FXP_WRITE 6 + #define SSH_FXP_LSTAT 7 + #define SSH_FXP_FSTAT 8 + #define SSH_FXP_SETSTAT 9 + #define SSH_FXP_FSETSTAT 10 + #define SSH_FXP_OPENDIR 11 + #define SSH_FXP_READDIR 12 + #define SSH_FXP_REMOVE 13 + #define SSH_FXP_MKDIR 14 + #define SSH_FXP_RMDIR 15 + #define SSH_FXP_REALPATH 16 + #define SSH_FXP_STAT 17 + #define SSH_FXP_RENAME 18 + #define SSH_FXP_READLINK 19 + #define SSH_FXP_SYMLINK 20 + + #define SSH_FXP_STATUS 101 + #define SSH_FXP_HANDLE 102 + #define SSH_FXP_DATA 103 + #define SSH_FXP_NAME 104 + #define SSH_FXP_ATTRS 105 + + #define SSH_FXP_EXTENDED 200 + #define SSH_FXP_EXTENDED_REPLY 201 + + RESERVED_FOR_EXTENSIONS 210-255 + + Additional packet types should only be defined if the protocol + version number (see Section ``Protocol Initialization'') is + incremented, and their use MUST be negotiated using the version + number. However, the SSH_FXP_EXTENDED and SSH_FXP_EXTENDED_REPLY + packets can be used to implement vendor-specific extensions. See + Section ``Vendor-Specific-Extensions'' for more details. + +3.1 The use of stderr in the server + + Packets are sent and received on stdout and stdin. Data sent on + stderr by the server SHOULD be considered debug or supplemental error + information, and MAY be displayed to the user. + + For example, during initialization, there is no client request + active, so errors or warning information cannot be sent to the client + as part of the SFTP protocol at this early stage. However, the + + + +Galbraith, et al. Expires June 18, 2003 [Page 6] + +Internet-Draft SSH File Transfer Protocol December 2002 + + + errors or warnings MAY be sent as stderr text. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Galbraith, et al. Expires June 18, 2003 [Page 7] + +Internet-Draft SSH File Transfer Protocol December 2002 + + +4. Protocol Initialization + + When the file transfer protocol starts, the client first sends a + SSH_FXP_INIT (including its version number) packet to the server. + The server responds with a SSH_FXP_VERSION packet, supplying the + lowest of its own and the client's version number. Both parties + should from then on adhere to particular version of the protocol. + + The version number of the protocol specified in this document is 4. + The version number should be incremented for each incompatible + revision of this protocol. + +4.1 Client Initialization + + The SSH_FXP_INIT packet (from client to server) has the following + data: + + uint32 version + + Version 3 of this protocol allowed clients to include extensions in + the SSH_FXP_INIT packet; however, this can cause interoperability + problems with version 1 and version 2 servers because the client must + send this packet before knowing the servers version. + + In this version of the protocol, clients MUST use the + SSH_FXP_EXTENDED packet to send extensions to the server after + version exchange has completed. Clients MUST NOT include extensions + in the version packet. This will prevent interoperability problems + with older servers + +4.2 Server Initialization + + The SSH_FXP_VERSION packet (from server to client) has the following + data: + + uint32 version + <extension data> + + 'version' is the lower of the protocol version supported by the + server and the version number received from the client. + + The extension data may be empty, or may be a sequence of + + string extension_name + string extension_data + + pairs (both strings MUST always be present if one is, but the + `extension_data' string may be of zero length). If present, these + + + +Galbraith, et al. Expires June 18, 2003 [Page 8] + +Internet-Draft SSH File Transfer Protocol December 2002 + + + strings indicate extensions to the baseline protocol. The + `extension_name' field(s) identify the name of the extension. The + name should be of the form "name@domain", where the domain is the DNS + domain name of the organization defining the extension. Additional + names that are not of this format may be defined later by the IETF. + Implementations MUST silently ignore any extensions whose name they + do not recognize. + +4.3 Determining Server Newline Convention + + In order to correctly process text files in a cross platform + compatible way, the newline convention must be converted from that of + the server to that of the client, or, during an upload, from that of + the client to that of the server. + + Versions 3 and prior of this protocol made no provisions for + processing text files. Many clients implemented some sort of + conversion algorithm, but without either a 'canonical' on the wire + format or knowledge of the servers newline convention, correct + conversion was not always possible. + + Starting with Version 4, the SSH_FXF_TEXT file open flag (Section + 6.3) makes it possible to request that the server translate a file to + a 'canonical' on the wire format. This format uses \r\n as the line + separator. + + Servers for systems using multiple newline characters (for example, + Mac OS X or VMS) or systems using counted records, MUST translate to + the canonical form. + + However, to ease the burden of implementation on servers that use a + single, simple separator sequence, the following extension allows the + canonical format to be changed. + + string "newline" + string new-canonical-separator (usually "\r" or "\n" or "\r\n") + + All clients MUST support this extension. + + When processing text files, clients SHOULD NOT translate any + character or sequence that is not an exact match of the servers + newline separator. + + In particular, if the newline sequence being used is the canonical + "\r\n" sequence, a lone \r or a lone \n SHOULD be written through + without change. + + + + + +Galbraith, et al. Expires June 18, 2003 [Page 9] + +Internet-Draft SSH File Transfer Protocol December 2002 + + +5. File Attributes + + A new compound data type is defined for encoding file attributes. + The same encoding is used both when returning file attributes from + the server and when sending file attributes to the server. When + sending it to the server, the flags field specifies which attributes + are included, and the server will use default values for the + remaining attributes (or will not modify the values of remaining + attributes). When receiving attributes from the server, the flags + specify which attributes are included in the returned data. The + server normally returns all attributes it knows about. + + uint32 flags + byte type always present + uint64 size present only if flag SIZE + string owner present only if flag OWNERGROUP + string group present only if flag OWNERGROUP + uint32 permissions present only if flag PERMISSIONS + uint64 atime present only if flag ACCESSTIME + uint32 atime_nseconds present only if flag SUBSECOND_TIMES + uint64 createtime present only if flag CREATETIME + uint32 createtime_nseconds present only if flag SUBSECOND_TIMES + uint64 mtime present only if flag MODIFYTIME + uint32 mtime_nseconds present only if flag SUBSECOND_TIMES + string acl present only if flag ACL + uint32 extended_count present only if flag EXTENDED + string extended_type + string extended_data + ... more extended data (extended_type - extended_data pairs), + so that number of pairs equals extended_count + + +5.1 Flags + + The `flags' specify which of the fields are present. Those fields + for which the corresponding flag is not set are not present (not + included in the packet). New flags can only be added by incrementing + the protocol version number (or by using the extension mechanism + described below). + + The flags bits are defined to have the following values: + + + + + + + + + + +Galbraith, et al. Expires June 18, 2003 [Page 10] + +Internet-Draft SSH File Transfer Protocol December 2002 + + + #define SSH_FILEXFER_ATTR_SIZE 0x00000001 + #define SSH_FILEXFER_ATTR_PERMISSIONS 0x00000040 + #define SSH_FILEXFER_ATTR_ACCESSTIME 0x00000008 + #define SSH_FILEXFER_ATTR_CREATETIME 0x00000010 + #define SSH_FILEXFER_ATTR_MODIFYTIME 0x00000020 + #define SSH_FILEXFER_ATTR_ACL 0x00000040 + #define SSH_FILEXFER_ATTR_OWNERGROUP 0x00000080 + #define SSH_FILEXFER_ATTR_SUBSECOND_TIMES 0x00000100 + #define SSH_FILEXFER_ATTR_EXTENDED 0x80000000 + + In previous versions of this protocol flags value 0x00000002 was + SSH_FILEXFER_ATTR_UIDGID. This value is now unused, and OWNERGROUP + was given a new value in order to ease implementation burden. + 0x00000002 MUST NOT appear in the mask. Some future version of this + protocol may reuse flag 0x00000002. + +5.2 Type + + The type field is always present. The following types are defined: + + #define SSH_FILEXFER_TYPE_REGULAR 1 + #define SSH_FILEXFER_TYPE_DIRECTORY 2 + #define SSH_FILEXFER_TYPE_SYMLINK 3 + #define SSH_FILEXFER_TYPE_SPECIAL 4 + #define SSH_FILEXFER_TYPE_UNKNOWN 5 + + On a POSIX system, these values would be derived from the permission + field. + +5.3 Size + + The `size' field specifies the size of the file on disk, in bytes. + If it is present during file creation, it should be considered a hint + as to the files eventual size. + + Files opened with the SSH_FXF_TEXT flag may have a size that is + greater or less than the value of the size field. + +5.4 Owner and Group + + The `owner' and `group' fields are represented as UTF-8 strings; this + is the form used by NFS v4. See NFS version 4 Protocol. [3] The + following text is selected quotations from section 5.6. + + To avoid a representation that is tied to a particular underlying + implementation at the client or server, the use of UTF-8 strings has + been chosen. The string should be of the form user@dns_domain". + This will allow for a client and server that do not use the same + + + +Galbraith, et al. Expires June 18, 2003 [Page 11] + +Internet-Draft SSH File Transfer Protocol December 2002 + + + local representation the ability to translate to a common syntax that + can be interpreted by both. In the case where there is no + translation available to the client or server, the attribute value + must be constructed without the "@". Therefore, the absence of the @ + from the owner or owner_group attribute signifies that no translation + was available and the receiver of the attribute should not place any + special meaning with the attribute value. Even though the attribute + value can not be translated, it may still be useful. In the case of + a client, the attribute string may be used for local display of + ownership. + +5.5 Permissions + + The `permissions' field contains a bit mask of file permissions as + defined by POSIX [1]. + +5.6 Times + + The 'atime', 'createtime', and 'mtime' contain the access, creation, + and modification times of the files, respectively. They are + represented as seconds from Jan 1, 1970 in UTC. + + A negative value indicates number of seconds before Jan 1, 1970. In + both cases, if the SSH_FILEXFER_ATTR_SUBSECOND_TIMES flag is set, the + nseconds field is to be added to the seconds field for the final time + representation. For example, if the time to be represented is + one-half second before 0 hour January 1, 1970, the seconds field + would have a value of negative one (-1) and the nseconds fields would + have a value of one-half second (500000000). Values greater than + 999,999,999 for nseconds are considered invalid. + +5.7 ACL + + The 'ACL' field contains an ACL similar to that defined in section + 5.9 of NFS version 4 Protocol [3]. + + uint32 ace-count + + repeated ace-count time: + uint32 ace-type + uint32 ace-flag + uint32 ace-mask + string who [UTF-8] + + ace-type is one of the following four values (taken from NFS Version + 4 Protocol [3]: + + + + + +Galbraith, et al. Expires June 18, 2003 [Page 12] + +Internet-Draft SSH File Transfer Protocol December 2002 + + + const ACE4_ACCESS_ALLOWED_ACE_TYPE = 0x00000000; + const ACE4_ACCESS_DENIED_ACE_TYPE = 0x00000001; + const ACE4_SYSTEM_AUDIT_ACE_TYPE = 0x00000002; + const ACE4_SYSTEM_ALARM_ACE_TYPE = 0x00000003; + + ace-flag is a combination of the following flag values. See NFS + Version 4 Protocol [3] section 5.9.2: + + const ACE4_FILE_INHERIT_ACE = 0x00000001; + const ACE4_DIRECTORY_INHERIT_ACE = 0x00000002; + const ACE4_NO_PROPAGATE_INHERIT_ACE = 0x00000004; + const ACE4_INHERIT_ONLY_ACE = 0x00000008; + const ACE4_SUCCESSFUL_ACCESS_ACE_FLAG = 0x00000010; + const ACE4_FAILED_ACCESS_ACE_FLAG = 0x00000020; + const ACE4_IDENTIFIER_GROUP = 0x00000040; + + ace-mask is any combination of the following flags (taken from NFS + Version 4 Protocol [3] section 5.9.3: + + const ACE4_READ_DATA = 0x00000001; + const ACE4_LIST_DIRECTORY = 0x00000001; + const ACE4_WRITE_DATA = 0x00000002; + const ACE4_ADD_FILE = 0x00000002; + const ACE4_APPEND_DATA = 0x00000004; + const ACE4_ADD_SUBDIRECTORY = 0x00000004; + const ACE4_READ_NAMED_ATTRS = 0x00000008; + const ACE4_WRITE_NAMED_ATTRS = 0x00000010; + const ACE4_EXECUTE = 0x00000020; + const ACE4_DELETE_CHILD = 0x00000040; + const ACE4_READ_ATTRIBUTES = 0x00000080; + const ACE4_WRITE_ATTRIBUTES = 0x00000100; + const ACE4_DELETE = 0x00010000; + const ACE4_READ_ACL = 0x00020000; + const ACE4_WRITE_ACL = 0x00040000; + const ACE4_WRITE_OWNER = 0x00080000; + const ACE4_SYNCHRONIZE = 0x00100000; + + who is a UTF-8 string of the form described in 'Owner and Group' + (Section 5.4) + + Also, as per '5.9.4 ACE who' [3] there are several identifiers that + need to be understood universally. Some of these identifiers cannot + be understood when an client access the server, but have meaning when + a local process accesses the file. The ability to display and modify + these permissions is permitted over SFTP. + + OWNER The owner of the file. + + + + +Galbraith, et al. Expires June 18, 2003 [Page 13] + +Internet-Draft SSH File Transfer Protocol December 2002 + + + GROUP The group associated with the file. + + EVERYONE The world. + + INTERACTIVE Accessed from an interactive terminal. + + NETWORK Accessed via the network. + + DIALUP Accessed as a dialup user to the server. + + BATCH Accessed from a batch job. + + ANONYMOUS Accessed without any authentication. + + AUTHENTICATED Any authenticated user (opposite of ANONYMOUS). + + SERVICE Access from a system service. + + To avoid conflict, these special identifiers are distinguish by an + appended "@" and should appear in the form "xxxx@" (note: no domain + name after the "@"). For example: ANONYMOUS@. + +5.8 Extended attributes + + The SSH_FILEXFER_ATTR_EXTENDED flag provides a general extension + mechanism for vendor-specific extensions. If the flag is specified, + then the `extended_count' field is present. It specifies the number + of extended_type-extended_data pairs that follow. Each of these + pairs specifies an extended attribute. For each of the attributes, + the extended_type field should be a string of the format + "name@domain", where "domain" is a valid, registered domain name and + "name" identifies the method. The IETF may later standardize certain + names that deviate from this format (e.g., that do not contain the + "@" sign). The interpretation of `extended_data' depends on the + type. Implementations SHOULD ignore extended data fields that they + do not understand. + + Additional fields can be added to the attributes by either defining + additional bits to the flags field to indicate their presence, or by + defining extended attributes for them. The extended attributes + mechanism is recommended for most purposes; additional flags bits + should only be defined by an IETF standards action that also + increments the protocol version number. The use of such new fields + MUST be negotiated by the version number in the protocol exchange. + It is a protocol error if a packet with unsupported protocol bits is + received. + + + + + +Galbraith, et al. Expires June 18, 2003 [Page 14] + +Internet-Draft SSH File Transfer Protocol December 2002 + + +6. Requests From the Client to the Server + + Requests from the client to the server represent the various file + system operations. Each request begins with an `id' field, which is + a 32-bit identifier identifying the request (selected by the client). + The same identifier will be returned in the response to the request. + One possible implementation is a monotonically increasing request + sequence number (modulo 2^32). + + Many operations in the protocol operate on open files. The + SSH_FXP_OPEN request can return a file handle (which is an opaque + variable-length string) which may be used to access the file later + (e.g. in a read operation). The client MUST NOT send requests the + server with bogus or closed handles. However, the server MUST + perform adequate checks on the handle in order to avoid security + risks due to fabricated handles. + + This design allows either stateful and stateless server + implementation, as well as an implementation which caches state + between requests but may also flush it. The contents of the file + handle string are entirely up to the server and its design. The + client should not modify or attempt to interpret the file handle + strings. + + The file handle strings MUST NOT be longer than 256 bytes. + +6.1 Request Synchronization and Reordering + + The protocol and implementations MUST process requests relating to + the same file in the order in which they are received. In other + words, if an application submits multiple requests to the server, the + results in the responses will be the same as if it had sent the + requests one at a time and waited for the response in each case. For + example, the server may process non-overlapping read/write requests + to the same file in parallel, but overlapping reads and writes cannot + be reordered or parallelized. However, there are no ordering + restrictions on the server for processing requests from two different + file transfer connections. The server may interleave and parallelize + them at will. + + There are no restrictions on the order in which responses to + outstanding requests are delivered to the client, except that the + server must ensure fairness in the sense that processing of no + request will be indefinitely delayed even if the client is sending + other requests so that there are multiple outstanding requests all + the time. + + + + + +Galbraith, et al. Expires June 18, 2003 [Page 15] + +Internet-Draft SSH File Transfer Protocol December 2002 + + +6.2 File Names + + This protocol represents file names as strings. File names are + assumed to use the slash ('/') character as a directory separator. + + File names starting with a slash are "absolute", and are relative to + the root of the file system. Names starting with any other character + are relative to the user's default directory (home directory). Note + that identifying the user is assumed to take place outside of this + protocol. + + Servers SHOULD interpret a path name component ".." as referring to + the parent directory, and "." as referring to the current directory. + If the server implementation limits access to certain parts of the + file system, it must be extra careful in parsing file names when + enforcing such restrictions. There have been numerous reported + security bugs where a ".." in a path name has allowed access outside + the intended area. + + An empty path name is valid, and it refers to the user's default + directory (usually the user's home directory). + + Otherwise, no syntax is defined for file names by this specification. + Clients should not make any other assumptions; however, they can + splice path name components returned by SSH_FXP_READDIR together + using a slash ('/') as the separator, and that will work as expected. + + In order to comply with IETF Policy on Character Sets and Languages + [2], all filenames are to be encoded in UTF-8. The shortest valid + UTF-8 encoding of the UNICODE data MUST be used. The server is + responsible for converting the UNICODE data to whatever canonical + form it requires. + + For example, if the server requires that precomposed characters + always be used, the server MUST NOT assume the filename as sent by + the client has this attribute, but must do this normalization itself. + + It is understood that the lack of well-defined semantics for file + names may cause interoperability problems between clients and servers + using radically different operating systems. However, this approach + is known to work acceptably with most systems, and alternative + approaches that e.g. treat file names as sequences of structured + components are quite complicated. + +6.3 Opening, Creating, and Closing Files + + Files are opened and created using the SSH_FXP_OPEN message, whose + data part is as follows: + + + +Galbraith, et al. Expires June 18, 2003 [Page 16] + +Internet-Draft SSH File Transfer Protocol December 2002 + + + uint32 id + string filename [UTF-8] + uint32 pflags + ATTRS attrs + + The `id' field is the request identifier as for all requests. + + The `filename' field specifies the file name. See Section ``File + Names'' for more information. + + The `pflags' field is a bitmask. The following bits have been + defined. + + #define SSH_FXF_READ 0x00000001 + #define SSH_FXF_WRITE 0x00000002 + #define SSH_FXF_APPEND 0x00000004 + #define SSH_FXF_CREAT 0x00000008 + #define SSH_FXF_TRUNC 0x00000010 + #define SSH_FXF_EXCL 0x00000020 + #define SSH_FXF_TEXT 0x00000040 + + These have the following meanings: + + SSH_FXF_READ + Open the file for reading. + + SSH_FXF_WRITE + Open the file for writing. If both this and SSH_FXF_READ are + specified, the file is opened for both reading and writing. + + SSH_FXF_APPEND + Force all writes to append data at the end of the file. The + offset parameter to write will be ignored. + + SSH_FXF_CREAT + If this flag is specified, then a new file will be created if one + does not already exist (if O_TRUNC is specified, the new file will + be truncated to zero length if it previously exists). + + SSH_FXF_TRUNC + Forces an existing file with the same name to be truncated to zero + length when creating a file by specifying SSH_FXF_CREAT. + SSH_FXF_CREAT MUST also be specified if this flag is used. + + SSH_FXF_EXCL + Causes the request to fail if the named file already exists. + SSH_FXF_CREAT MUST also be specified if this flag is used. + + + + +Galbraith, et al. Expires June 18, 2003 [Page 17] + +Internet-Draft SSH File Transfer Protocol December 2002 + + + SSH_FXF_TEXT + Indicates that the server should treat the file as text and + convert it to the canonical newline convention in use. (See + Determining Server Newline Convention. (Section 4.3) + + When a file is opened with the FXF_TEXT flag, the offset field in + both the read and write function are ignored. + + Servers MUST correctly process multiple parallel reads and writes + correctly in this mode. Naturally, it is permissible for them to + do this by serializing the requests. It would not be possible for + a client to reliably detect a server that does not implement + parallel writes in time to prevent damage. + + Clients SHOULD use the SSH_FXF_APPEND flag to append data to a + text file rather then using write with a calculated offset. + + To support seeks on text file the following SSH_FXP_EXTENDED + packet is defined. + + + + string "text-seek" + string file-handle + uint64 line-number + + line-number is the index of the line number to seek to, where byte + 0 in the file is line number 0, and the byte directly following + the first newline sequence in the file is line number 1 and so on. + + The response to a "text-seek" request is an SSH_FXP_STATUS + message. + + An attempt to seek past the end-of-file should result in a + SSH_FX_EOF status. + + Servers SHOULD support at least one "text-seek" in order to + support resume. However, a client MUST be prepared to receive + SSH_FX_OP_UNSUPPORTED when attempting a "text-seek" operation. + The client can then try a fall-back strategy, if it has one. + + Clients MUST be prepared to handle SSH_FX_OP_UNSUPPORTED returned + for read or write operations that are not sequential. + + The `attrs' field specifies the initial attributes for the file. + Default values will be used for those attributes that are not + specified. See Section ``File Attributes'' for more information. + + + + +Galbraith, et al. Expires June 18, 2003 [Page 18] + +Internet-Draft SSH File Transfer Protocol December 2002 + + + The response to this message will be either SSH_FXP_HANDLE (if the + operation is successful) or SSH_FXP_STATUS (if the operation fails). + + A file is closed by using the SSH_FXP_CLOSE request. Its data field + has the following format: + + uint32 id + string handle + + where `id' is the request identifier, and `handle' is a handle + previously returned in the response to SSH_FXP_OPEN or + SSH_FXP_OPENDIR. The handle becomes invalid immediately after this + request has been sent. + + The response to this request will be a SSH_FXP_STATUS message. One + should note that on some server platforms even a close can fail. + This can happen e.g. if the server operating system caches writes, + and an error occurs while flushing cached writes during the close. + +6.4 Reading and Writing + + Once a file has been opened, it can be read using the following + message: + + byte SSH_FXP_READ + uint32 id + string handle + uint64 offset + uint32 len + + where `id' is the request identifier, `handle' is an open file handle + returned by SSH_FXP_OPEN, `offset' is the offset (in bytes) relative + to the beginning of the file from where to start reading, and `len' + is the maximum number of bytes to read. + + In response to this request, the server will read as many bytes as it + can from the file (up to `len'), and return them in a SSH_FXP_DATA + message. If an error occurs or EOF is encountered before reading any + data, the server will respond with SSH_FXP_STATUS. + + For normal disk files, it is normally guaranteed that this will read + the specified number of bytes, or up to end of file. However, if the + read length is very long, the server may truncate it if it doesn't + support packets of that length. See General Packet Format (Section + 3). + + For e.g. device files this may return fewer bytes than requested. + + + + +Galbraith, et al. Expires June 18, 2003 [Page 19] + +Internet-Draft SSH File Transfer Protocol December 2002 + + + Writing to a file is achieved using the following message: + + byte SSH_FXP_WRITE + uint32 id + string handle + uint64 offset + string data + + where `id' is a request identifier, `handle' is a file handle + returned by SSH_FXP_OPEN, `offset' is the offset (in bytes) from the + beginning of the file where to start writing, and `data' is the data + to be written. + + The write will extend the file if writing beyond the end of the file. + It is legal to write way beyond the end of the file; the semantics + are to write zeroes from the end of the file to the specified offset + and then the data. On most operating systems, such writes do not + allocate disk space but instead leave "holes" in the file. + + The server responds to a write request with a SSH_FXP_STATUS message. + +6.5 Removing and Renaming Files + + Files can be removed using the SSH_FXP_REMOVE message. It has the + following format: + + uint32 id + string filename [UTF-8] + + where `id' is the request identifier and `filename' is the name of + the file to be removed. See Section ``File Names'' for more + information. This request cannot be used to remove directories. + + The server will respond to this request with a SSH_FXP_STATUS + message. + + Files (and directories) can be renamed using the SSH_FXP_RENAME + message. Its data is as follows: + + uint32 id + string oldpath [UTF-8] + string newpath [UTF-8] + + where `id' is the request identifier, `oldpath' is the name of an + existing file or directory, and `newpath' is the new name for the + file or directory. It is an error if there already exists a file + with the name specified by newpath. The server may also fail rename + requests in other situations, for example if `oldpath' and `newpath' + + + +Galbraith, et al. Expires June 18, 2003 [Page 20] + +Internet-Draft SSH File Transfer Protocol December 2002 + + + point to different file systems on the server. + + The server will respond to this request with a SSH_FXP_STATUS + message. + +6.6 Creating and Deleting Directories + + New directories can be created using the SSH_FXP_MKDIR request. It + has the following format: + + uint32 id + string path [UTF-8] + ATTRS attrs + + where `id' is the request identifier. + + `path' specifies the directory to be created. See Section ``File + Names'' for more information on file names. + + `attrs' specifies the attributes that should be applied to it upon + creation. Attributes are discussed in more detail in Section ``File + Attributes''. + + The server will respond to this request with a SSH_FXP_STATUS + message. If a file or directory with the specified path already + exists, an error will be returned. + + Directories can be removed using the SSH_FXP_RMDIR request, which has + the following format: + + uint32 id + string path [UTF-8] + + where `id' is the request identifier, and `path' specifies the + directory to be removed. See Section ``File Names'' for more + information on file names. + + The server responds to this request with a SSH_FXP_STATUS message. + Errors may be returned from this operation for various reasons, + including, but not limited to, the path does not exist, the path does + not refer to a directory object, the directory is not empty, or the + user has insufficient access or permission to perform the requested + operation. + +6.7 Scanning Directories + + The files in a directory can be listed using the SSH_FXP_OPENDIR and + SSH_FXP_READDIR requests. Each SSH_FXP_READDIR request returns one + + + +Galbraith, et al. Expires June 18, 2003 [Page 21] + +Internet-Draft SSH File Transfer Protocol December 2002 + + + or more file names with full file attributes for each file. The + client should call SSH_FXP_READDIR repeatedly until it has found the + file it is looking for or until the server responds with a + SSH_FXP_STATUS message indicating an error (normally SSH_FX_EOF if + there are no more files in the directory). The client should then + close the handle using the SSH_FXP_CLOSE request. + + The SSH_FXP_OPENDIR opens a directory for reading. It has the + following format: + + uint32 id + string path [UTF-8] + + where `id' is the request identifier and `path' is the path name of + the directory to be listed (without any trailing slash). See Section + ``File Names'' for more information on file names. This will return + an error if the path does not specify a directory or if the directory + is not readable. The server will respond to this request with either + a SSH_FXP_HANDLE or a SSH_FXP_STATUS message. + + Once the directory has been successfully opened, files (and + directories) contained in it can be listed using SSH_FXP_READDIR + requests. These are of the format + + uint32 id + string handle + + where `id' is the request identifier, and `handle' is a handle + returned by SSH_FXP_OPENDIR. (It is a protocol error to attempt to + use an ordinary file handle returned by SSH_FXP_OPEN.) + + The server responds to this request with either a SSH_FXP_NAME or a + SSH_FXP_STATUS message. One or more names may be returned at a time. + Full status information is returned for each name in order to speed + up typical directory listings. + + If there are no more names available to be read, the server MUST + respond with a SSH_FXP_STATUS message with error code of SSH_FX_EOF. + + When the client no longer wishes to read more names from the + directory, it SHOULD call SSH_FXP_CLOSE for the handle. The handle + should be closed regardless of whether an error has occurred or not. + +6.8 Retrieving File Attributes + + Very often, file attributes are automatically returned by + SSH_FXP_READDIR. However, sometimes there is need to specifically + retrieve the attributes for a named file. This can be done using the + + + +Galbraith, et al. Expires June 18, 2003 [Page 22] + +Internet-Draft SSH File Transfer Protocol December 2002 + + + SSH_FXP_STAT, SSH_FXP_LSTAT and SSH_FXP_FSTAT requests. + + SSH_FXP_STAT and SSH_FXP_LSTAT only differ in that SSH_FXP_STAT + follows symbolic links on the server, whereas SSH_FXP_LSTAT does not + follow symbolic links. Both have the same format: + + uint32 id + string path [UTF-8] + uint32 flags + + where `id' is the request identifier, and `path' specifies the file + system object for which status is to be returned. The server + responds to this request with either SSH_FXP_ATTRS or SSH_FXP_STATUS. + + The flags field specify the attribute flags in which the client has + particular interest. This is a hint to the server. For example, + because retrieving owner / group and acl information can be an + expensive operation under some operating systems, the server may + choose not to retrieve this information unless the client expresses a + specific interest in it. + + The client has no guarantee the server will provide all the fields + that it has expressed an interest in. + + SSH_FXP_FSTAT differs from the others in that it returns status + information for an open file (identified by the file handle). Its + format is as follows: + + uint32 id + string handle + uint32 flags + + where `id' is the request identifier and `handle' is a file handle + returned by SSH_FXP_OPEN. The server responds to this request with + SSH_FXP_ATTRS or SSH_FXP_STATUS. + +6.9 Setting File Attributes + + File attributes may be modified using the SSH_FXP_SETSTAT and + SSH_FXP_FSETSTAT requests. These requests are used for operations + such as changing the ownership, permissions or access times, as well + as for truncating a file. + + The SSH_FXP_SETSTAT request is of the following format: + + + + + + + +Galbraith, et al. Expires June 18, 2003 [Page 23] + +Internet-Draft SSH File Transfer Protocol December 2002 + + + uint32 id + string path [UTF-8] + ATTRS attrs + + where `id' is the request identifier, `path' specifies the file + system object (e.g. file or directory) whose attributes are to be + modified, and `attrs' specifies the modifications to be made to its + attributes. Attributes are discussed in more detail in Section + ``File Attributes''. + + An error will be returned if the specified file system object does + not exist or the user does not have sufficient rights to modify the + specified attributes. The server responds to this request with a + SSH_FXP_STATUS message. + + The SSH_FXP_FSETSTAT request modifies the attributes of a file which + is already open. It has the following format: + + uint32 id + string handle + ATTRS attrs + + where `id' is the request identifier, `handle' (MUST be returned by + SSH_FXP_OPEN) identifies the file whose attributes are to be + modified, and `attrs' specifies the modifications to be made to its + attributes. Attributes are discussed in more detail in Section + ``File Attributes''. The server will respond to this request with + SSH_FXP_STATUS. + +6.10 Dealing with Symbolic links + + The SSH_FXP_READLINK request may be used to read the target of a + symbolic link. It would have a data part as follows: + + uint32 id + string path [UTF-8] + + where `id' is the request identifier and `path' specifies the path + name of the symlink to be read. + + The server will respond with a SSH_FXP_NAME packet containing only + one name and a dummy attributes value. The name in the returned + packet contains the target of the link. If an error occurs, the + server may respond with SSH_FXP_STATUS. + + The SSH_FXP_SYMLINK request will create a symbolic link on the + server. It is of the following format + + + + +Galbraith, et al. Expires June 18, 2003 [Page 24] + +Internet-Draft SSH File Transfer Protocol December 2002 + + + uint32 id + string linkpath [UTF-8] + string targetpath [UTF-8] + + where `id' is the request identifier, `linkpath' specifies the path + name of the symlink to be created and `targetpath' specifies the + target of the symlink. The server shall respond with a + SSH_FXP_STATUS indicating either success (SSH_FX_OK) or an error + condition. + +6.11 Canonicalizing the Server-Side Path Name + + The SSH_FXP_REALPATH request can be used to have the server + canonicalize any given path name to an absolute path. This is useful + for converting path names containing ".." components or relative + pathnames without a leading slash into absolute paths. The format of + the request is as follows: + + uint32 id + string path [UTF-8] + + where `id' is the request identifier and `path' specifies the path + name to be canonicalized. The server will respond with a + SSH_FXP_NAME packet containing the name in canonical form and a dummy + attributes value. If an error occurs, the server may also respond + with SSH_FXP_STATUS. + +6.11.1 Best practice for dealing with paths + + The client SHOULD treat the results of SSH_FXP_REALPATH as a + canonical absolute path, even if the path does not appear to be + absolute. A client that use REALPATH(".") and treats the result as + absolute, even if there is no leading slash, will continue to + function correctly, even when talking to a Windows NT or VMS style + system, where absolute paths may not begin with a slash. + + For example, if the client wishes to change directory up, and the + server has returned "c:/x/y/z" from REALPATH, the client SHOULD use + "c:/x/y/z/..". + + As a second example, if the client wishes to open the file "x.txt" in + the current directory, and server has returned "dka100:/x/y/z" as the + canonical path of the directory, the client SHOULD open "dka100:/x/y/ + z/x.txt" + + + + + + + +Galbraith, et al. Expires June 18, 2003 [Page 25] + +Internet-Draft SSH File Transfer Protocol December 2002 + + +7. Responses from the Server to the Client + + The server responds to the client using one of a few response + packets. All requests can return a SSH_FXP_STATUS response upon + failure. When the operation is successful, any of the responses may + be returned (depending on the operation). If no data needs to be + returned to the client, the SSH_FXP_STATUS response with SSH_FX_OK + status is appropriate. Otherwise, the SSH_FXP_HANDLE message is used + to return a file handle (for SSH_FXP_OPEN and SSH_FXP_OPENDIR + requests), SSH_FXP_DATA is used to return data from SSH_FXP_READ, + SSH_FXP_NAME is used to return one or more file names from a + SSH_FXP_READDIR or SSH_FXP_REALPATH request, and SSH_FXP_ATTRS is + used to return file attributes from SSH_FXP_STAT, SSH_FXP_LSTAT, and + SSH_FXP_FSTAT requests. + + Exactly one response will be returned for each request. Each + response packet contains a request identifier which can be used to + match each response with the corresponding request. Note that it is + legal to have several requests outstanding simultaneously, and the + server is allowed to send responses to them in a different order from + the order in which the requests were sent (the result of their + execution, however, is guaranteed to be as if they had been processed + one at a time in the order in which the requests were sent). + + Response packets are of the same general format as request packets. + Each response packet begins with the request identifier. + + The format of the data portion of the SSH_FXP_STATUS response is as + follows: + + uint32 id + uint32 error/status code + string error message (ISO-10646 UTF-8 [RFC-2279]) + string language tag (as defined in [RFC-1766]) + + where `id' is the request identifier, and `error/status code' + indicates the result of the requested operation. The value SSH_FX_OK + indicates success, and all other values indicate failure. + + Currently, the following values are defined (other values may be + defined by future versions of this protocol): + + + + + + + + + + +Galbraith, et al. Expires June 18, 2003 [Page 26] + +Internet-Draft SSH File Transfer Protocol December 2002 + + + #define SSH_FX_OK 0 + #define SSH_FX_EOF 1 + #define SSH_FX_NO_SUCH_FILE 2 + #define SSH_FX_PERMISSION_DENIED 3 + #define SSH_FX_FAILURE 4 + #define SSH_FX_BAD_MESSAGE 5 + #define SSH_FX_NO_CONNECTION 6 + #define SSH_FX_CONNECTION_LOST 7 + #define SSH_FX_OP_UNSUPPORTED 8 + #define SSH_FX_INVALID_HANDLE 9 + #define SSH_FX_NO_SUCH_PATH 10 + #define SSH_FX_FILE_ALREADY_EXISTS 11 + #define SSH_FX_WRITE_PROTECT 12 + #define SSH_FX_NO_MEDIA 13 + + SSH_FX_OK + Indicates successful completion of the operation. + + SSH_FX_EOF + indicates end-of-file condition; for SSH_FX_READ it means that no + more data is available in the file, and for SSH_FX_READDIR it + indicates that no more files are contained in the directory. + + SSH_FX_NO_SUCH_FILE + is returned when a reference is made to a file which does not + exist. + + SSH_FX_PERMISSION_DENIED + is returned when the authenticated user does not have sufficient + permissions to perform the operation. + + SSH_FX_FAILURE + is a generic catch-all error message; it should be returned if an + error occurs for which there is no more specific error code + defined. + + SSH_FX_BAD_MESSAGE + may be returned if a badly formatted packet or protocol + incompatibility is detected. + + SSH_FX_NO_CONNECTION + is a pseudo-error which indicates that the client has no + connection to the server (it can only be generated locally by the + client, and MUST NOT be returned by servers). + + SSH_FX_CONNECTION_LOST + is a pseudo-error which indicates that the connection to the + server has been lost (it can only be generated locally by the + + + +Galbraith, et al. Expires June 18, 2003 [Page 27] + +Internet-Draft SSH File Transfer Protocol December 2002 + + + client, and MUST NOT be returned by servers). + + SSH_FX_OP_UNSUPPORTED + indicates that an attempt was made to perform an operation which + is not supported for the server (it may be generated locally by + the client if e.g. the version number exchange indicates that a + required feature is not supported by the server, or it may be + returned by the server if the server does not implement an + operation). + + SSH_FX_INVALID_HANDLE + The handle value was invalid. + + SSH_FX_NO_SUCH_PATH + The file path does not exist or is invalid. + + SSH_FX_FILE_ALREADY_EXISTS + The file already exists. + + SSH_FX_WRITE_PROTECT + The file is on read only media, or the media is write protected. + + SSH_FX_NO_MEDIA + The requested operation can not be completed because there is no + media available in the drive. + + The SSH_FXP_HANDLE response has the following format: + + uint32 id + string handle + + where `id' is the request identifier, and `handle' is an arbitrary + string that identifies an open file or directory on the server. The + handle is opaque to the client; the client MUST NOT attempt to + interpret or modify it in any way. The length of the handle string + MUST NOT exceed 256 data bytes. + + The SSH_FXP_DATA response has the following format: + + uint32 id + string data + + where `id' is the request identifier, and `data' is an arbitrary byte + string containing the requested data. The data string may be at most + the number of bytes requested in a SSH_FXP_READ request, but may also + be shorter if end of file is reached or if the read is from something + other than a regular file. + + + + +Galbraith, et al. Expires June 18, 2003 [Page 28] + +Internet-Draft SSH File Transfer Protocol December 2002 + + + The SSH_FXP_NAME response has the following format: + + uint32 id + uint32 count + repeats count times: + string filename [UTF-8] + ATTRS attrs + + where `id' is the request identifier, `count' is the number of names + returned in this response, and the remaining fields repeat `count' + times (so that all three fields are first included for the first + file, then for the second file, etc). In the repeated part, + `filename' is a file name being returned (for SSH_FXP_READDIR, it + will be a relative name within the directory, without any path + components; for SSH_FXP_REALPATH it will be an absolute path name), + and `attrs' is the attributes of the file as described in Section + ``File Attributes''. + + The SSH_FXP_ATTRS response has the following format: + + uint32 id + ATTRS attrs + + where `id' is the request identifier, and `attrs' is the returned + file attributes as described in Section ``File Attributes''. + + + + + + + + + + + + + + + + + + + + + + + + + + +Galbraith, et al. Expires June 18, 2003 [Page 29] + +Internet-Draft SSH File Transfer Protocol December 2002 + + +8. Vendor-Specific Extensions + + The SSH_FXP_EXTENDED request provides a generic extension mechanism + for adding vendor-specific commands. The request has the following + format: + + uint32 id + string extended-request + ... any request-specific data ... + + where `id' is the request identifier, and `extended-request' is a + string of the format "name@domain", where domain is an internet + domain name of the vendor defining the request. The rest of the + request is completely vendor-specific, and servers should only + attempt to interpret it if they recognize the `extended-request' + name. + + The server may respond to such requests using any of the response + packets defined in Section ``Responses from the Server to the + Client''. Additionally, the server may also respond with a + SSH_FXP_EXTENDED_REPLY packet, as defined below. If the server does + not recognize the `extended-request' name, then the server MUST + respond with SSH_FXP_STATUS with error/status set to + SSH_FX_OP_UNSUPPORTED. + + The SSH_FXP_EXTENDED_REPLY packet can be used to carry arbitrary + extension-specific data from the server to the client. It is of the + following format: + + uint32 id + ... any request-specific data ... + + There is a range of packet types reserved for use by extensions. In + order to avoid collision, extensions that turn on the use of + additional packet types should determine those numbers dynamically. + + The suggested way of doing this is have an extension request from the + client to the server that enables the extension; the extension + response from the server to the client would specify the actual type + values to use, in additional to any other data. + + Extension authors should be mindful of the limited range of packet + types available (there are only 45 values available) and avoid + requiring a new packet type where possible. + + + + + + + +Galbraith, et al. Expires June 18, 2003 [Page 30] + +Internet-Draft SSH File Transfer Protocol December 2002 + + +9. Security Considerations + + This protocol assumes that it is run over a secure channel and that + the endpoints of the channel have been authenticated. Thus, this + protocol assumes that it is externally protected from network-level + attacks. + + This protocol provides file system access to arbitrary files on the + server (only constrained by the server implementation). It is the + responsibility of the server implementation to enforce any access + controls that may be required to limit the access allowed for any + particular user (the user being authenticated externally to this + protocol, typically using the SSH User Authentication Protocol [8]. + + Care must be taken in the server implementation to check the validity + of received file handle strings. The server should not rely on them + directly; it MUST check the validity of each handle before relying on + it. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Galbraith, et al. Expires June 18, 2003 [Page 31] + +Internet-Draft SSH File Transfer Protocol December 2002 + + +10. Changes from previous protocol versions + + The SSH File Transfer Protocol has changed over time, before it's + standardization. The following is a description of the incompatible + changes between different versions. + +10.1 Changes between versions 4 and 3 + + Many of the changes between version 4 and version 3 are to the + attribute structure to make it more flexible for non-unix platforms. + + o Clarify the use of stderr by the server. + + o Clarify handling of very large read requests by the server. + + o Make all filenames UTF-8. + + o Added 'newline' extension. + + o Made time fields 64 bit, and optionally have nanosecond resultion. + + o Made file attribute owner and group strings so they can actually + be used on disparate systems. + + o Added createtime field, and added separate flags for atime, + createtime, and mtime so they can be set separately. + + o Split the file type out of the permissions field and into it's own + field (which is always present.) + + o Added acl attribute. + + o Added SSH_FXF_TEXT file open flag. + + o Added flags field to the get stat commands so that the client can + specifically request information the server might not normally + included for performance reasons. + + o Removed the long filename from the names structure-- it can now be + built from information available in the attrs structure. + + o Added reserved range of packet numbers for extensions. + + o Added several additional error codes. + + + + + + + +Galbraith, et al. Expires June 18, 2003 [Page 32] + +Internet-Draft SSH File Transfer Protocol December 2002 + + +10.2 Changes between versions 3 and 2 + + o The SSH_FXP_READLINK and SSH_FXP_SYMLINK messages were added. + + o The SSH_FXP_EXTENDED and SSH_FXP_EXTENDED_REPLY messages were + added. + + o The SSH_FXP_STATUS message was changed to include fields `error + message' and `language tag'. + + +10.3 Changes between versions 2 and 1 + + o The SSH_FXP_RENAME message was added. + + +10.4 Changes between versions 1 and 0 + + o Implementation changes, no actual protocol changes. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Galbraith, et al. Expires June 18, 2003 [Page 33] + +Internet-Draft SSH File Transfer Protocol December 2002 + + +11. Trademark Issues + + "ssh" is a registered trademark of SSH Communications Security Corp + in the United States and/or other countries. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Galbraith, et al. Expires June 18, 2003 [Page 34] + +Internet-Draft SSH File Transfer Protocol December 2002 + + +References + + [1] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and + P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January + 1999. + + [2] Alvestrand, H., "IETF Policy on Character Sets and Languages", + BCP 18, RFC 2277, January 1998. + + [3] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, + C., Eisler, M. and D. Noveck, "NFS version 4 Protocol", RFC + 3010, December 2000. + + [4] Institute of Electrical and Electronics Engineers, "Information + Technology - Portable Operating System Interface (POSIX) - Part + 1: System Application Program Interface (API) [C Language]", + IEEE Standard 1003.2, 1996. + + [5] Rinne, T., Ylonen, T., Kivinen, T., Saarinen, M. and S. + Lehtinen, "SSH Protocol Architecture", + draft-ietf-secsh-architecture-13 (work in progress), September + 2002. + + [6] Rinne, T., Ylonen, T., Kivinen, T., Saarinen, M. and S. + Lehtinen, "SSH Protocol Transport Protocol", + draft-ietf-secsh-transport-15 (work in progress), September + 2002. + + [7] Rinne, T., Ylonen, T., Kivinen, T., Saarinen, M. and S. + Lehtinen, "SSH Connection Protocol", draft-ietf-secsh-connect-16 + (work in progress), September 2002. + + [8] Rinne, T., Ylonen, T., Kivinen, T., Saarinen, M. and S. + Lehtinen, "SSH Authentication Protocol", + draft-ietf-secsh-userauth-16 (work in progress), September 2002. + + +Authors' Addresses + + Joseph Galbraith + VanDyke Software + 4848 Tramway Ridge Blvd + Suite 101 + Albuquerque, NM 87111 + US + + Phone: +1 505 332 5700 + EMail: [email protected] + + + +Galbraith, et al. Expires June 18, 2003 [Page 35] + +Internet-Draft SSH File Transfer Protocol December 2002 + + + Tatu Ylonen + SSH Communications Security Corp + Fredrikinkatu 42 + HELSINKI FIN-00100 + Finland + + EMail: [email protected] + + + Sami Lehtinen + SSH Communications Security Corp + Fredrikinkatu 42 + HELSINKI FIN-00100 + Finland + + EMail: [email protected] + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Galbraith, et al. Expires June 18, 2003 [Page 36] + +Internet-Draft SSH File Transfer Protocol December 2002 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + intellectual property or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; neither does it represent that it + has made any effort to identify any such rights. Information on the + IETF's procedures with respect to rights in standards-track and + standards-related documentation can be found in BCP-11. Copies of + claims of rights made available for publication and any assurances of + licenses to be made available, or the result of an attempt made to + obtain a general license or permission for the use of such + proprietary rights by implementors or users of this specification can + be obtained from the IETF Secretariat. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights which may cover technology that may be required to practice + this standard. Please address the information to the IETF Executive + Director. + + +Full Copyright Statement + + Copyright (C) The Internet Society (2002). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assignees. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + + + +Galbraith, et al. Expires June 18, 2003 [Page 37] + +Internet-Draft SSH File Transfer Protocol December 2002 + + + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Galbraith, et al. Expires June 18, 2003 [Page 38] + + diff --git a/lib/ssh/doc/standard/draft-ietf-secsh-transport-17.2.ps b/lib/ssh/doc/standard/draft-ietf-secsh-transport-17.2.ps new file mode 100644 index 0000000000..d692285b4e --- /dev/null +++ b/lib/ssh/doc/standard/draft-ietf-secsh-transport-17.2.ps @@ -0,0 +1,3205 @@ +%!PS-Adobe-3.0 +%%BoundingBox: 75 0 595 747 +%%Title: Enscript Output +%%For: Magnus Thoang +%%Creator: GNU enscript 1.6.1 +%%CreationDate: Fri Oct 31 13:35:14 2003 +%%Orientation: Portrait +%%Pages: 15 0 +%%DocumentMedia: A4 595 842 0 () () +%%DocumentNeededResources: (atend) +%%EndComments +%%BeginProlog +%%BeginProcSet: PStoPS 1 15 +userdict begin +[/showpage/erasepage/copypage]{dup where{pop dup load + type/operatortype eq{1 array cvx dup 0 3 index cvx put + bind def}{pop}ifelse}{pop}ifelse}forall +[/letter/legal/executivepage/a4/a4small/b5/com10envelope + /monarchenvelope/c5envelope/dlenvelope/lettersmall/note + /folio/quarto/a5]{dup where{dup wcheck{exch{}put} + {pop{}def}ifelse}{pop}ifelse}forall +/setpagedevice {pop}bind 1 index where{dup wcheck{3 1 roll put} + {pop def}ifelse}{def}ifelse +/PStoPSmatrix matrix currentmatrix def +/PStoPSxform matrix def/PStoPSclip{clippath}def +/defaultmatrix{PStoPSmatrix exch PStoPSxform exch concatmatrix}bind def +/initmatrix{matrix defaultmatrix setmatrix}bind def +/initclip[{matrix currentmatrix PStoPSmatrix setmatrix + [{currentpoint}stopped{$error/newerror false put{newpath}} + {/newpath cvx 3 1 roll/moveto cvx 4 array astore cvx}ifelse] + {[/newpath cvx{/moveto cvx}{/lineto cvx} + {/curveto cvx}{/closepath cvx}pathforall]cvx exch pop} + stopped{$error/errorname get/invalidaccess eq{cleartomark + $error/newerror false put cvx exec}{stop}ifelse}if}bind aload pop + /initclip dup load dup type dup/operatortype eq{pop exch pop} + {dup/arraytype eq exch/packedarraytype eq or + {dup xcheck{exch pop aload pop}{pop cvx}ifelse} + {pop cvx}ifelse}ifelse + {newpath PStoPSclip clip newpath exec setmatrix} bind aload pop]cvx def +/initgraphics{initmatrix newpath initclip 1 setlinewidth + 0 setlinecap 0 setlinejoin []0 setdash 0 setgray + 10 setmiterlimit}bind def +end +%%EndProcSet +%%BeginResource: procset Enscript-Prolog 1.6 1 +% +% Procedures. +% + +/_S { % save current state + /_s save def +} def +/_R { % restore from saved state + _s restore +} def + +/S { % showpage protecting gstate + gsave + showpage + grestore +} bind def + +/MF { % fontname newfontname -> - make a new encoded font + /newfontname exch def + /fontname exch def + + /fontdict fontname findfont def + /newfont fontdict maxlength dict def + + fontdict { + exch + dup /FID eq { + % skip FID pair + pop pop + } { + % copy to the new font dictionary + exch newfont 3 1 roll put + } ifelse + } forall + + newfont /FontName newfontname put + + % insert only valid encoding vectors + encoding_vector length 256 eq { + newfont /Encoding encoding_vector put + } if + + newfontname newfont definefont pop +} def + +/SF { % fontname width height -> - set a new font + /height exch def + /width exch def + + findfont + [width 0 0 height 0 0] makefont setfont +} def + +/SUF { % fontname width height -> - set a new user font + /height exch def + /width exch def + + /F-gs-user-font MF + /F-gs-user-font width height SF +} def + +/M {moveto} bind def +/s {show} bind def + +/Box { % x y w h -> - define box path + /d_h exch def /d_w exch def /d_y exch def /d_x exch def + d_x d_y moveto + d_w 0 rlineto + 0 d_h rlineto + d_w neg 0 rlineto + closepath +} def + +/bgs { % x y height blskip gray str -> - show string with bg color + /str exch def + /gray exch def + /blskip exch def + /height exch def + /y exch def + /x exch def + + gsave + x y blskip sub str stringwidth pop height Box + gray setgray + fill + grestore + x y M str s +} def + +% Highlight bars. +/highlight_bars { % nlines lineheight output_y_margin gray -> - + gsave + setgray + /ymarg exch def + /lineheight exch def + /nlines exch def + + % This 2 is just a magic number to sync highlight lines to text. + 0 d_header_y ymarg sub 2 sub translate + + /cw d_output_w cols div def + /nrows d_output_h ymarg 2 mul sub lineheight div cvi def + + % for each column + 0 1 cols 1 sub { + cw mul /xp exch def + + % for each rows + 0 1 nrows 1 sub { + /rn exch def + rn lineheight mul neg /yp exch def + rn nlines idiv 2 mod 0 eq { + % Draw highlight bar. 4 is just a magic indentation. + xp 4 add yp cw 8 sub lineheight neg Box fill + } if + } for + } for + + grestore +} def + +% Line highlight bar. +/line_highlight { % x y width height gray -> - + gsave + /gray exch def + Box gray setgray fill + grestore +} def + +% Column separator lines. +/column_lines { + gsave + .1 setlinewidth + 0 d_footer_h translate + /cw d_output_w cols div def + 1 1 cols 1 sub { + cw mul 0 moveto + 0 d_output_h rlineto stroke + } for + grestore +} def + +% Column borders. +/column_borders { + gsave + .1 setlinewidth + 0 d_footer_h moveto + 0 d_output_h rlineto + d_output_w 0 rlineto + 0 d_output_h neg rlineto + closepath stroke + grestore +} def + +% Do the actual underlay drawing +/draw_underlay { + ul_style 0 eq { + ul_str true charpath stroke + } { + ul_str show + } ifelse +} def + +% Underlay +/underlay { % - -> - + gsave + 0 d_page_h translate + d_page_h neg d_page_w atan rotate + + ul_gray setgray + ul_font setfont + /dw d_page_h dup mul d_page_w dup mul add sqrt def + ul_str stringwidth pop dw exch sub 2 div ul_h_ptsize -2 div moveto + draw_underlay + grestore +} def + +/user_underlay { % - -> - + gsave + ul_x ul_y translate + ul_angle rotate + ul_gray setgray + ul_font setfont + 0 0 ul_h_ptsize 2 div sub moveto + draw_underlay + grestore +} def + +% Page prefeed +/page_prefeed { % bool -> - + statusdict /prefeed known { + statusdict exch /prefeed exch put + } { + pop + } ifelse +} def + +% Wrapped line markers +/wrapped_line_mark { % x y charwith charheight type -> - + /type exch def + /h exch def + /w exch def + /y exch def + /x exch def + + type 2 eq { + % Black boxes (like TeX does) + gsave + 0 setlinewidth + x w 4 div add y M + 0 h rlineto w 2 div 0 rlineto 0 h neg rlineto + closepath fill + grestore + } { + type 3 eq { + % Small arrows + gsave + .2 setlinewidth + x w 2 div add y h 2 div add M + w 4 div 0 rlineto + x w 4 div add y lineto stroke + + x w 4 div add w 8 div add y h 4 div add M + x w 4 div add y lineto + w 4 div h 8 div rlineto stroke + grestore + } { + % do nothing + } ifelse + } ifelse +} def + +% EPSF import. + +/BeginEPSF { + /b4_Inc_state save def % Save state for cleanup + /dict_count countdictstack def % Count objects on dict stack + /op_count count 1 sub def % Count objects on operand stack + userdict begin + /showpage { } def + 0 setgray 0 setlinecap + 1 setlinewidth 0 setlinejoin + 10 setmiterlimit [ ] 0 setdash newpath + /languagelevel where { + pop languagelevel + 1 ne { + false setstrokeadjust false setoverprint + } if + } if +} bind def + +/EndEPSF { + count op_count sub { pos } repeat % Clean up stacks + countdictstack dict_count sub { end } repeat + b4_Inc_state restore +} bind def + +% Check PostScript language level. +/languagelevel where { + pop /gs_languagelevel languagelevel def +} { + /gs_languagelevel 1 def +} ifelse +%%EndResource +%%BeginResource: procset Enscript-Encoding-88591 1.6 1 +/encoding_vector [ +/.notdef /.notdef /.notdef /.notdef +/.notdef /.notdef /.notdef /.notdef +/.notdef /.notdef /.notdef /.notdef +/.notdef /.notdef /.notdef /.notdef +/.notdef /.notdef /.notdef /.notdef +/.notdef /.notdef /.notdef /.notdef +/.notdef /.notdef /.notdef /.notdef +/.notdef /.notdef /.notdef /.notdef +/space /exclam /quotedbl /numbersign +/dollar /percent /ampersand /quoteright +/parenleft /parenright /asterisk /plus +/comma /hyphen /period /slash +/zero /one /two /three +/four /five /six /seven +/eight /nine /colon /semicolon +/less /equal /greater /question +/at /A /B /C +/D /E /F /G +/H /I /J /K +/L /M /N /O +/P /Q /R /S +/T /U /V /W +/X /Y /Z /bracketleft +/backslash /bracketright /asciicircum /underscore +/quoteleft /a /b /c +/d /e /f /g +/h /i /j /k +/l /m /n /o +/p /q /r /s +/t /u /v /w +/x /y /z /braceleft +/bar /braceright /tilde /.notdef +/.notdef /.notdef /.notdef /.notdef +/.notdef /.notdef /.notdef /.notdef +/.notdef /.notdef /.notdef /.notdef +/.notdef /.notdef /.notdef /.notdef +/.notdef /.notdef /.notdef /.notdef +/.notdef /.notdef /.notdef /.notdef +/.notdef /.notdef /.notdef /.notdef +/.notdef /.notdef /.notdef /.notdef +/space /exclamdown /cent /sterling +/currency /yen /brokenbar /section +/dieresis /copyright /ordfeminine /guillemotleft +/logicalnot /hyphen /registered /macron +/degree /plusminus /twosuperior /threesuperior +/acute /mu /paragraph /bullet +/cedilla /onesuperior /ordmasculine /guillemotright +/onequarter /onehalf /threequarters /questiondown +/Agrave /Aacute /Acircumflex /Atilde +/Adieresis /Aring /AE /Ccedilla +/Egrave /Eacute /Ecircumflex /Edieresis +/Igrave /Iacute /Icircumflex /Idieresis +/Eth /Ntilde /Ograve /Oacute +/Ocircumflex /Otilde /Odieresis /multiply +/Oslash /Ugrave /Uacute /Ucircumflex +/Udieresis /Yacute /Thorn /germandbls +/agrave /aacute /acircumflex /atilde +/adieresis /aring /ae /ccedilla +/egrave /eacute /ecircumflex /edieresis +/igrave /iacute /icircumflex /idieresis +/eth /ntilde /ograve /oacute +/ocircumflex /otilde /odieresis /divide +/oslash /ugrave /uacute /ucircumflex +/udieresis /yacute /thorn /ydieresis +] def +%%EndResource +%%EndProlog +%%BeginSetup +%%IncludeResource: font Courier-Bold +%%IncludeResource: font Courier +/HFpt_w 10 def +/HFpt_h 10 def +/Courier-Bold /HF-gs-font MF +/HF /HF-gs-font findfont [HFpt_w 0 0 HFpt_h 0 0] makefont def +/Courier /F-gs-font MF +/F-gs-font 10 10 SF +/#copies 1 def +/d_page_w 520 def +/d_page_h 747 def +/d_header_x 0 def +/d_header_y 747 def +/d_header_w 520 def +/d_header_h 0 def +/d_footer_x 0 def +/d_footer_y 0 def +/d_footer_w 520 def +/d_footer_h 0 def +/d_output_w 520 def +/d_output_h 747 def +/cols 1 def +userdict/PStoPSxform PStoPSmatrix matrix currentmatrix + matrix invertmatrix matrix concatmatrix + matrix invertmatrix put +%%EndSetup +%%Page: (0,1) 1 +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 0.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +/showpage{}def/copypage{}def/erasepage{}def +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 1 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 701 M +(Network Working Group T. Ylonen) s +5 690 M +(Internet-Draft SSH Communications Security Corp) s +5 679 M +(Expires: March 31, 2004 D. Moffat, Editor, Ed.) s +5 668 M +( Sun Microsystems, Inc) s +5 657 M +( Oct 2003) s +5 624 M +( SSH Transport Layer Protocol) s +5 613 M +( draft-ietf-secsh-transport-17.txt) s +5 591 M +(Status of this Memo) s +5 569 M +( This document is an Internet-Draft and is in full conformance with) s +5 558 M +( all provisions of Section 10 of RFC2026.) s +5 536 M +( Internet-Drafts are working documents of the Internet Engineering) s +5 525 M +( Task Force \(IETF\), its areas, and its working groups. Note that other) s +5 514 M +( groups may also distribute working documents as Internet-Drafts.) s +5 492 M +( Internet-Drafts are draft documents valid for a maximum of six months) s +5 481 M +( and may be updated, replaced, or obsoleted by other documents at any) s +5 470 M +( time. It is inappropriate to use Internet-Drafts as reference) s +5 459 M +( material or to cite them other than as "work in progress.") s +5 437 M +( The list of current Internet-Drafts can be accessed at http://) s +5 426 M +( www.ietf.org/ietf/1id-abstracts.txt.) s +5 404 M +( The list of Internet-Draft Shadow Directories can be accessed at) s +5 393 M +( http://www.ietf.org/shadow.html.) s +5 371 M +( This Internet-Draft will expire on March 31, 2004.) s +5 349 M +(Copyright Notice) s +5 327 M +( Copyright \(C\) The Internet Society \(2003\). All Rights Reserved.) s +5 305 M +(Abstract) s +5 283 M +( SSH is a protocol for secure remote login and other secure network) s +5 272 M +( services over an insecure network.) s +5 250 M +( This document describes the SSH transport layer protocol which) s +5 239 M +( typically runs on top of TCP/IP. The protocol can be used as a basis) s +5 228 M +( for a number of secure network services. It provides strong) s +5 217 M +( encryption, server authentication, and integrity protection. It may) s +5 206 M +( also provide compression.) s +5 184 M +( Key exchange method, public key algorithm, symmetric encryption) s +5 173 M +( algorithm, message authentication algorithm, and hash algorithm are) s +5 129 M +(Ylonen & Moffat, Editor Expires March 31, 2004 [Page 1]) s +_R +S +PStoPSsaved restore +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 421.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 2 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH Transport Layer Protocol Oct 2003) s +5 690 M +( all negotiated.) s +5 668 M +( This document also describes the Diffie-Hellman key exchange method) s +5 657 M +( and the minimal set of algorithms that are needed to implement the) s +5 646 M +( SSH transport layer protocol.) s +5 624 M +(Table of Contents) s +5 602 M +( 1. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 3) s +5 591 M +( 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3) s +5 580 M +( 3. Conventions Used in This Document . . . . . . . . . . . . . 3) s +5 569 M +( 4. Connection Setup . . . . . . . . . . . . . . . . . . . . . . 3) s +5 558 M +( 4.1 Use over TCP/IP . . . . . . . . . . . . . . . . . . . . . . 4) s +5 547 M +( 4.2 Protocol Version Exchange . . . . . . . . . . . . . . . . . 4) s +5 536 M +( 4.3 Compatibility With Old SSH Versions . . . . . . . . . . . . 4) s +5 525 M +( 4.3.1 Old Client, New Server . . . . . . . . . . . . . . . . . . . 5) s +5 514 M +( 4.3.2 New Client, Old Server . . . . . . . . . . . . . . . . . . . 5) s +5 503 M +( 5. Binary Packet Protocol . . . . . . . . . . . . . . . . . . . 5) s +5 492 M +( 5.1 Maximum Packet Length . . . . . . . . . . . . . . . . . . . 6) s +5 481 M +( 5.2 Compression . . . . . . . . . . . . . . . . . . . . . . . . 7) s +5 470 M +( 5.3 Encryption . . . . . . . . . . . . . . . . . . . . . . . . . 7) s +5 459 M +( 5.4 Data Integrity . . . . . . . . . . . . . . . . . . . . . . . 9) s +5 448 M +( 5.5 Key Exchange Methods . . . . . . . . . . . . . . . . . . . . 10) s +5 437 M +( 5.6 Public Key Algorithms . . . . . . . . . . . . . . . . . . . 11) s +5 426 M +( 6. Key Exchange . . . . . . . . . . . . . . . . . . . . . . . . 13) s +5 415 M +( 6.1 Algorithm Negotiation . . . . . . . . . . . . . . . . . . . 13) s +5 404 M +( 6.2 Output from Key Exchange . . . . . . . . . . . . . . . . . . 16) s +5 393 M +( 6.3 Taking Keys Into Use . . . . . . . . . . . . . . . . . . . . 17) s +5 382 M +( 7. Diffie-Hellman Key Exchange . . . . . . . . . . . . . . . . 18) s +5 371 M +( 7.1 diffie-hellman-group1-sha1 . . . . . . . . . . . . . . . . . 19) s +5 360 M +( 8. Key Re-Exchange . . . . . . . . . . . . . . . . . . . . . . 20) s +5 349 M +( 9. Service Request . . . . . . . . . . . . . . . . . . . . . . 21) s +5 338 M +( 10. Additional Messages . . . . . . . . . . . . . . . . . . . . 21) s +5 327 M +( 10.1 Disconnection Message . . . . . . . . . . . . . . . . . . . 22) s +5 316 M +( 10.2 Ignored Data Message . . . . . . . . . . . . . . . . . . . . 22) s +5 305 M +( 10.3 Debug Message . . . . . . . . . . . . . . . . . . . . . . . 23) s +5 294 M +( 10.4 Reserved Messages . . . . . . . . . . . . . . . . . . . . . 23) s +5 283 M +( 11. Summary of Message Numbers . . . . . . . . . . . . . . . . . 23) s +5 272 M +( 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 24) s +5 261 M +( 13. Security Considerations . . . . . . . . . . . . . . . . . . 24) s +5 250 M +( 14. Intellectual Property . . . . . . . . . . . . . . . . . . . 24) s +5 239 M +( 15. Additional Information . . . . . . . . . . . . . . . . . . . 24) s +5 228 M +( Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 26) s +5 217 M +( Normative . . . . . . . . . . . . . . . . . . . . . . . . . 25) s +5 206 M +( Informative . . . . . . . . . . . . . . . . . . . . . . . . 25) s +5 195 M +( A. Contibutors . . . . . . . . . . . . . . . . . . . . . . . . 27) s +5 184 M +( Intellectual Property and Copyright Statements . . . . . . . 28) s +5 129 M +(Ylonen & Moffat, Editor Expires March 31, 2004 [Page 2]) s +_R +S +PStoPSsaved restore +%%Page: (2,3) 2 +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 0.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +/showpage{}def/copypage{}def/erasepage{}def +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 3 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH Transport Layer Protocol Oct 2003) s +5 690 M +(1. Contributors) s +5 668 M +( The major original contributors of this document were: Tatu Ylonen,) s +5 657 M +( Tero Kivinen, Timo J. Rinne, Sami Lehtinen \(all of SSH Communications) s +5 646 M +( Security Corp\), and Markku-Juhani O. Saarinen \(University of) s +5 635 M +( Jyvaskyla\)) s +5 613 M +( The document editor is: [email protected]. Comments on this) s +5 602 M +( internet draft should be sent to the IETF SECSH working group,) s +5 591 M +( details at: http://ietf.org/html.charters/secsh-charter.html) s +5 569 M +(2. Introduction) s +5 547 M +( The SSH transport layer is a secure low level transport protocol. It) s +5 536 M +( provides strong encryption, cryptographic host authentication, and) s +5 525 M +( integrity protection.) s +5 503 M +( Authentication in this protocol level is host-based; this protocol) s +5 492 M +( does not perform user authentication. A higher level protocol for) s +5 481 M +( user authentication can be designed on top of this protocol.) s +5 459 M +( The protocol has been designed to be simple, flexible, to allow) s +5 448 M +( parameter negotiation, and to minimize the number of round-trips.) s +5 437 M +( Key exchange method, public key algorithm, symmetric encryption) s +5 426 M +( algorithm, message authentication algorithm, and hash algorithm are) s +5 415 M +( all negotiated. It is expected that in most environments, only 2) s +5 404 M +( round-trips will be needed for full key exchange, server) s +5 393 M +( authentication, service request, and acceptance notification of) s +5 382 M +( service request. The worst case is 3 round-trips.) s +5 360 M +(3. Conventions Used in This Document) s +5 338 M +( The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",) s +5 327 M +( and "MAY" that appear in this document are to be interpreted as) s +5 316 M +( described in [RFC2119].) s +5 294 M +( The used data types and terminology are specified in the architecture) s +5 283 M +( document [SSH-ARCH].) s +5 261 M +( The architecture document also discusses the algorithm naming) s +5 250 M +( conventions that MUST be used with the SSH protocols.) s +5 228 M +(4. Connection Setup) s +5 206 M +( SSH works over any 8-bit clean, binary-transparent transport. The) s +5 195 M +( underlying transport SHOULD protect against transmission errors as) s +5 184 M +( such errors cause the SSH connection to terminate.) s +5 129 M +(Ylonen & Moffat, Editor Expires March 31, 2004 [Page 3]) s +_R +S +PStoPSsaved restore +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 421.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 4 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH Transport Layer Protocol Oct 2003) s +5 690 M +( The client initiates the connection.) s +5 668 M +(4.1 Use over TCP/IP) s +5 646 M +( When used over TCP/IP, the server normally listens for connections on) s +5 635 M +( port 22. This port number has been registered with the IANA, and has) s +5 624 M +( been officially assigned for SSH.) s +5 602 M +(4.2 Protocol Version Exchange) s +5 580 M +( When the connection has been established, both sides MUST send an) s +5 569 M +( identification string of the form "SSH-protoversion-softwareversion) s +5 558 M +( comments", followed by carriage return and newline characters \(ASCII) s +5 547 M +( 13 and 10, respectively\). Both sides MUST be able to process) s +5 536 M +( identification strings without carriage return character. No null) s +5 525 M +( character is sent. The maximum length of the string is 255) s +5 514 M +( characters, including the carriage return and newline.) s +5 492 M +( The part of the identification string preceding carriage return and) s +5 481 M +( newline is used in the Diffie-Hellman key exchange \(see Section) s +5 470 M +( Section 7\).) s +5 448 M +( The server MAY send other lines of data before sending the version) s +5 437 M +( string. Each line SHOULD be terminated by a carriage return and) s +5 426 M +( newline. Such lines MUST NOT begin with "SSH-", and SHOULD be) s +5 415 M +( encoded in ISO-10646 UTF-8 [RFC2279] \(language is not specified\).) s +5 404 M +( Clients MUST be able to process such lines; they MAY be silently) s +5 393 M +( ignored, or MAY be displayed to the client user; if they are) s +5 382 M +( displayed, control character filtering discussed in [SSH-ARCH] SHOULD) s +5 371 M +( be used. The primary use of this feature is to allow TCP-wrappers to) s +5 360 M +( display an error message before disconnecting.) s +5 338 M +( Version strings MUST consist of printable US-ASCII characters, not) s +5 327 M +( including whitespaces or a minus sign \(-\). The version string is) s +5 316 M +( primarily used to trigger compatibility extensions and to indicate) s +5 305 M +( the capabilities of an implementation. The comment string should) s +5 294 M +( contain additional information that might be useful in solving user) s +5 283 M +( problems.) s +5 261 M +( The protocol version described in this document is 2.0.) s +5 239 M +( Key exchange will begin immediately after sending this identifier.) s +5 228 M +( All packets following the identification string SHALL use the binary) s +5 217 M +( packet protocol, to be described below.) s +5 195 M +(4.3 Compatibility With Old SSH Versions) s +5 173 M +( During the transition period, it is important to be able to work in a) s +5 129 M +(Ylonen & Moffat, Editor Expires March 31, 2004 [Page 4]) s +_R +S +PStoPSsaved restore +%%Page: (4,5) 3 +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 0.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +/showpage{}def/copypage{}def/erasepage{}def +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 5 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH Transport Layer Protocol Oct 2003) s +5 690 M +( way that is compatible with the installed SSH clients and servers) s +5 679 M +( that use an older version of the protocol. Information in this) s +5 668 M +( section is only relevant for implementations supporting compatibility) s +5 657 M +( with SSH versions 1.x. There is no standards track or informational) s +5 646 M +( draft available that defines the SSH 1.x protocol. The only known) s +5 635 M +( documentation of the 1.x protocol is contained in README files that) s +5 624 M +( are shipped along with the source code.) s +5 602 M +(4.3.1 Old Client, New Server) s +5 580 M +( Server implementations MAY support a configurable "compatibility") s +5 569 M +( flag that enables compatibility with old versions. When this flag is) s +5 558 M +( on, the server SHOULD identify its protocol version as "1.99".) s +5 547 M +( Clients using protocol 2.0 MUST be able to identify this as identical) s +5 536 M +( to "2.0". In this mode the server SHOULD NOT send the carriage) s +5 525 M +( return character \(ASCII 13\) after the version identification string.) s +5 503 M +( In the compatibility mode the server SHOULD NOT send any further data) s +5 492 M +( after its initialization string until it has received an) s +5 481 M +( identification string from the client. The server can then determine) s +5 470 M +( whether the client is using an old protocol, and can revert to the) s +5 459 M +( old protocol if required. In the compatibility mode, the server MUST) s +5 448 M +( NOT send additional data before the version string.) s +5 426 M +( When compatibility with old clients is not needed, the server MAY) s +5 415 M +( send its initial key exchange data immediately after the) s +5 404 M +( identification string.) s +5 382 M +(4.3.2 New Client, Old Server) s +5 360 M +( Since the new client MAY immediately send additional data after its) s +5 349 M +( identification string \(before receiving server's identification\), the) s +5 338 M +( old protocol may already have been corrupted when the client learns) s +5 327 M +( that the server is old. When this happens, the client SHOULD close) s +5 316 M +( the connection to the server, and reconnect using the old protocol.) s +5 294 M +(5. Binary Packet Protocol) s +5 272 M +( Each packet is in the following format:) s +5 250 M +( uint32 packet_length) s +5 239 M +( byte padding_length) s +5 228 M +( byte[n1] payload; n1 = packet_length - padding_length - 1) s +5 217 M +( byte[n2] random padding; n2 = padding_length) s +5 206 M +( byte[m] mac \(message authentication code\); m = mac_length) s +5 184 M +( packet_length) s +5 129 M +(Ylonen & Moffat, Editor Expires March 31, 2004 [Page 5]) s +_R +S +PStoPSsaved restore +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 421.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 6 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH Transport Layer Protocol Oct 2003) s +5 690 M +( The length of the packet \(bytes\), not including MAC or the) s +5 679 M +( packet_length field itself.) s +5 657 M +( padding_length) s +5 646 M +( Length of padding \(bytes\).) s +5 624 M +( payload) s +5 613 M +( The useful contents of the packet. If compression has been) s +5 602 M +( negotiated, this field is compressed. Initially, compression) s +5 591 M +( MUST be "none".) s +5 569 M +( random padding) s +5 558 M +( Arbitrary-length padding, such that the total length of) s +5 547 M +( \(packet_length || padding_length || payload || padding\) is a) s +5 536 M +( multiple of the cipher block size or 8, whichever is larger.) s +5 525 M +( There MUST be at least four bytes of padding. The padding) s +5 514 M +( SHOULD consist of random bytes. The maximum amount of padding) s +5 503 M +( is 255 bytes.) s +5 481 M +( mac) s +5 470 M +( Message authentication code. If message authentication has) s +5 459 M +( been negotiated, this field contains the MAC bytes. Initially,) s +5 448 M +( the MAC algorithm MUST be "none".) s +5 415 M +( Note that length of the concatenation of packet length, padding) s +5 404 M +( length, payload, and padding MUST be a multiple of the cipher block) s +5 393 M +( size or 8, whichever is larger. This constraint MUST be enforced) s +5 382 M +( even when using stream ciphers. Note that the packet length field is) s +5 371 M +( also encrypted, and processing it requires special care when sending) s +5 360 M +( or receiving packets.) s +5 338 M +( The minimum size of a packet is 16 \(or the cipher block size,) s +5 327 M +( whichever is larger\) bytes \(plus MAC\); implementations SHOULD decrypt) s +5 316 M +( the length after receiving the first 8 \(or cipher block size,) s +5 305 M +( whichever is larger\) bytes of a packet.) s +5 283 M +(5.1 Maximum Packet Length) s +5 261 M +( All implementations MUST be able to process packets with uncompressed) s +5 250 M +( payload length of 32768 bytes or less and total packet size of 35000) s +5 239 M +( bytes or less \(including length, padding length, payload, padding,) s +5 228 M +( and MAC.\). The maximum of 35000 bytes is an arbitrary chosen value) s +5 217 M +( larger than uncompressed size. Implementations SHOULD support longer) s +5 206 M +( packets, where they might be needed, e.g. if an implementation wants) s +5 195 M +( to send a very large number of certificates. Such packets MAY be) s +5 184 M +( sent if the version string indicates that the other party is able to) s +5 173 M +( process them. However, implementations SHOULD check that the packet) s +5 129 M +(Ylonen & Moffat, Editor Expires March 31, 2004 [Page 6]) s +_R +S +PStoPSsaved restore +%%Page: (6,7) 4 +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 0.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +/showpage{}def/copypage{}def/erasepage{}def +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 7 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH Transport Layer Protocol Oct 2003) s +5 690 M +( length is reasonable for the implementation to avoid) s +5 679 M +( denial-of-service and/or buffer overflow attacks.) s +5 657 M +(5.2 Compression) s +5 635 M +( If compression has been negotiated, the payload field \(and only it\)) s +5 624 M +( will be compressed using the negotiated algorithm. The length field) s +5 613 M +( and MAC will be computed from the compressed payload. Encryption will) s +5 602 M +( be done after compression.) s +5 580 M +( Compression MAY be stateful, depending on the method. Compression) s +5 569 M +( MUST be independent for each direction, and implementations MUST) s +5 558 M +( allow independently choosing the algorithm for each direction.) s +5 536 M +( The following compression methods are currently defined:) s +5 514 M +( none REQUIRED no compression) s +5 503 M +( zlib OPTIONAL ZLIB \(LZ77\) compression) s +5 481 M +( The "zlib" compression is described in [RFC1950] and in [RFC1951].) s +5 470 M +( The compression context is initialized after each key exchange, and) s +5 459 M +( is passed from one packet to the next with only a partial flush being) s +5 448 M +( performed at the end of each packet. A partial flush means that the) s +5 437 M +( current compressed block is ended and all data will be output. If the) s +5 426 M +( current block is not a stored block, one or more empty blocks are) s +5 415 M +( added after the current block to ensure that there are at least 8) s +5 404 M +( bits counting from the start of the end-of-block code of the current) s +5 393 M +( block to the end of the packet payload.) s +5 371 M +( Additional methods may be defined as specified in [SSH-ARCH].) s +5 349 M +(5.3 Encryption) s +5 327 M +( An encryption algorithm and a key will be negotiated during the key) s +5 316 M +( exchange. When encryption is in effect, the packet length, padding) s +5 305 M +( length, payload and padding fields of each packet MUST be encrypted) s +5 294 M +( with the given algorithm.) s +5 272 M +( The encrypted data in all packets sent in one direction SHOULD be) s +5 261 M +( considered a single data stream. For example, initialization vectors) s +5 250 M +( SHOULD be passed from the end of one packet to the beginning of the) s +5 239 M +( next packet. All ciphers SHOULD use keys with an effective key length) s +5 228 M +( of 128 bits or more.) s +5 206 M +( The ciphers in each direction MUST run independently of each other,) s +5 195 M +( and implementations MUST allow independently choosing the algorithm) s +5 184 M +( for each direction \(if multiple algorithms are allowed by local) s +5 173 M +( policy\).) s +5 129 M +(Ylonen & Moffat, Editor Expires March 31, 2004 [Page 7]) s +_R +S +PStoPSsaved restore +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 421.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 8 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH Transport Layer Protocol Oct 2003) s +5 690 M +( The following ciphers are currently defined:) s +5 668 M +( 3des-cbc REQUIRED three-key 3DES in CBC mode) s +5 657 M +( blowfish-cbc OPTIONALi Blowfish in CBC mode) s +5 646 M +( twofish256-cbc OPTIONAL Twofish in CBC mode,) s +5 635 M +( with 256-bit key) s +5 624 M +( twofish-cbc OPTIONAL alias for "twofish256-cbc" \(this) s +5 613 M +( is being retained for) s +5 602 M +( historical reasons\)) s +5 591 M +( twofish192-cbc OPTIONAL Twofish with 192-bit key) s +5 580 M +( twofish128-cbc OPTIONAL Twofish with 128-bit key) s +5 569 M +( aes256-cbc OPTIONAL AES \(Rijndael\) in CBC mode,) s +5 558 M +( with 256-bit key) s +5 547 M +( aes192-cbc OPTIONAL AES with 192-bit key) s +5 536 M +( aes128-cbc RECOMMENDED AES with 128-bit key) s +5 525 M +( serpent256-cbc OPTIONAL Serpent in CBC mode, with) s +5 514 M +( 256-bit key) s +5 503 M +( serpent192-cbc OPTIONAL Serpent with 192-bit key) s +5 492 M +( serpent128-cbc OPTIONAL Serpent with 128-bit key) s +5 481 M +( arcfour OPTIONAL the ARCFOUR stream cipher) s +5 470 M +( idea-cbc OPTIONAL IDEA in CBC mode) s +5 459 M +( cast128-cbc OPTIONAL CAST-128 in CBC mode) s +5 448 M +( none OPTIONAL no encryption; NOT RECOMMENDED) s +5 426 M +( The "3des-cbc" cipher is three-key triple-DES) s +5 415 M +( \(encrypt-decrypt-encrypt\), where the first 8 bytes of the key are) s +5 404 M +( used for the first encryption, the next 8 bytes for the decryption,) s +5 393 M +( and the following 8 bytes for the final encryption. This requires 24) s +5 382 M +( bytes of key data \(of which 168 bits are actually used\). To) s +5 371 M +( implement CBC mode, outer chaining MUST be used \(i.e., there is only) s +5 360 M +( one initialization vector\). This is a block cipher with 8 byte) s +5 349 M +( blocks. This algorithm is defined in [FIPS-46-3]) s +5 327 M +( The "blowfish-cbc" cipher is Blowfish in CBC mode, with 128 bit keys) s +5 316 M +( [SCHNEIER]. This is a block cipher with 8 byte blocks.) s +5 294 M +( The "twofish-cbc" or "twofish256-cbc" cipher is Twofish in CBC mode,) s +5 283 M +( with 256 bit keys as described [TWOFISH]. This is a block cipher with) s +5 272 M +( 16 byte blocks.) s +5 250 M +( The "twofish192-cbc" cipher. Same as above but with 192-bit key.) s +5 228 M +( The "twofish128-cbc" cipher. Same as above but with 128-bit key.) s +5 206 M +( The "aes256-cbc" cipher is AES \(Advanced Encryption Standard\)) s +5 195 M +( [FIPS-197], formerly Rijndael, in CBC mode. This version uses 256-bit) s +5 184 M +( key.) s +5 129 M +(Ylonen & Moffat, Editor Expires March 31, 2004 [Page 8]) s +_R +S +PStoPSsaved restore +%%Page: (8,9) 5 +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 0.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +/showpage{}def/copypage{}def/erasepage{}def +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 9 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH Transport Layer Protocol Oct 2003) s +5 690 M +( The "aes192-cbc" cipher. Same as above but with 192-bit key.) s +5 668 M +( The "aes128-cbc" cipher. Same as above but with 128-bit key.) s +5 646 M +( The "serpent256-cbc" cipher in CBC mode, with 256-bit key as) s +5 635 M +( described in the Serpent AES submission.) s +5 613 M +( The "serpent192-cbc" cipher. Same as above but with 192-bit key.) s +5 591 M +( The "serpent128-cbc" cipher. Same as above but with 128-bit key.) s +5 569 M +( The "arcfour" is the Arcfour stream cipher with 128 bit keys. The) s +5 558 M +( Arcfour cipher is believed to be compatible with the RC4 cipher) s +5 547 M +( [SCHNEIER]. RC4 is a registered trademark of RSA Data Security Inc.) s +5 536 M +( Arcfour \(and RC4\) has problems with weak keys, and should be used) s +5 525 M +( with caution.) s +5 503 M +( The "idea-cbc" cipher is the IDEA cipher in CBC mode [SCHNEIER].) s +5 481 M +( The "cast128-cbc" cipher is the CAST-128 cipher in CBC mode) s +5 470 M +( [RFC2144].) s +5 448 M +( The "none" algorithm specifies that no encryption is to be done.) s +5 437 M +( Note that this method provides no confidentiality protection, and it) s +5 426 M +( is not recommended. Some functionality \(e.g. password) s +5 415 M +( authentication\) may be disabled for security reasons if this cipher) s +5 404 M +( is chosen.) s +5 382 M +( Additional methods may be defined as specified in [SSH-ARCH].) s +5 360 M +(5.4 Data Integrity) s +5 338 M +( Data integrity is protected by including with each packet a message) s +5 327 M +( authentication code \(MAC\) that is computed from a shared secret,) s +5 316 M +( packet sequence number, and the contents of the packet.) s +5 294 M +( The message authentication algorithm and key are negotiated during) s +5 283 M +( key exchange. Initially, no MAC will be in effect, and its length) s +5 272 M +( MUST be zero. After key exchange, the selected MAC will be computed) s +5 261 M +( before encryption from the concatenation of packet data:) s +5 239 M +( mac = MAC\(key, sequence_number || unencrypted_packet\)) s +5 217 M +( where unencrypted_packet is the entire packet without MAC \(the length) s +5 206 M +( fields, payload and padding\), and sequence_number is an implicit) s +5 195 M +( packet sequence number represented as uint32. The sequence number is) s +5 184 M +( initialized to zero for the first packet, and is incremented after) s +5 173 M +( every packet \(regardless of whether encryption or MAC is in use\). It) s +5 129 M +(Ylonen & Moffat, Editor Expires March 31, 2004 [Page 9]) s +_R +S +PStoPSsaved restore +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 421.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 10 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH Transport Layer Protocol Oct 2003) s +5 690 M +( is never reset, even if keys/algorithms are renegotiated later. It) s +5 679 M +( wraps around to zero after every 2^32 packets. The packet sequence) s +5 668 M +( number itself is not included in the packet sent over the wire.) s +5 646 M +( The MAC algorithms for each direction MUST run independently, and) s +5 635 M +( implementations MUST allow choosing the algorithm independently for) s +5 624 M +( both directions.) s +5 602 M +( The MAC bytes resulting from the MAC algorithm MUST be transmitted) s +5 591 M +( without encryption as the last part of the packet. The number of MAC) s +5 580 M +( bytes depends on the algorithm chosen.) s +5 558 M +( The following MAC algorithms are currently defined:) s +5 536 M +( hmac-sha1 REQUIRED HMAC-SHA1 \(digest length = key) s +5 525 M +( length = 20\)) s +5 514 M +( hmac-sha1-96 RECOMMENDED first 96 bits of HMAC-SHA1 \(digest) s +5 503 M +( length = 12, key length = 20\)) s +5 492 M +( hmac-md5 OPTIONAL HMAC-MD5 \(digest length = key) s +5 481 M +( length = 16\)) s +5 470 M +( hmac-md5-96 OPTIONAL first 96 bits of HMAC-MD5 \(digest) s +5 459 M +( length = 12, key length = 16\)) s +5 448 M +( none OPTIONAL no MAC; NOT RECOMMENDED) s +5 426 M +( Figure 1) s +5 404 M +( The "hmac-*" algorithms are described in [RFC2104] The "*-n" MACs use) s +5 393 M +( only the first n bits of the resulting value.) s +5 371 M +( The hash algorithms are described in [SCHNEIER].) s +5 349 M +( Additional methods may be defined as specified in [SSH-ARCH].) s +5 327 M +(5.5 Key Exchange Methods) s +5 305 M +( The key exchange method specifies how one-time session keys are) s +5 294 M +( generated for encryption and for authentication, and how the server) s +5 283 M +( authentication is done.) s +5 261 M +( Only one REQUIRED key exchange method has been defined:) s +5 239 M +( diffie-hellman-group1-sha1 REQUIRED) s +5 217 M +( This method is described later in this document.) s +5 195 M +( Additional methods may be defined as specified in [SSH-ARCH].) s +5 129 M +(Ylonen & Moffat, Editor Expires March 31, 2004 [Page 10]) s +_R +S +PStoPSsaved restore +%%Page: (10,11) 6 +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 0.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +/showpage{}def/copypage{}def/erasepage{}def +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 11 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH Transport Layer Protocol Oct 2003) s +5 690 M +(5.6 Public Key Algorithms) s +5 668 M +( This protocol has been designed to be able to operate with almost any) s +5 657 M +( public key format, encoding, and algorithm \(signature and/or) s +5 646 M +( encryption\).) s +5 624 M +( There are several aspects that define a public key type:) s +5 613 M +( o Key format: how is the key encoded and how are certificates) s +5 602 M +( represented. The key blobs in this protocol MAY contain) s +5 591 M +( certificates in addition to keys.) s +5 580 M +( o Signature and/or encryption algorithms. Some key types may not) s +5 569 M +( support both signing and encryption. Key usage may also be) s +5 558 M +( restricted by policy statements in e.g. certificates. In this) s +5 547 M +( case, different key types SHOULD be defined for the different) s +5 536 M +( policy alternatives.) s +5 525 M +( o Encoding of signatures and/or encrypted data. This includes but is) s +5 514 M +( not limited to padding, byte order, and data formats.) s +5 492 M +( The following public key and/or certificate formats are currently defined:) s +5 470 M +( ssh-dss REQUIRED sign Raw DSS Key) s +5 459 M +( ssh-rsa RECOMMENDED sign Raw RSA Key) s +5 448 M +( x509v3-sign-rsa OPTIONAL sign X.509 certificates \(RSA key\)) s +5 437 M +( x509v3-sign-dss OPTIONAL sign X.509 certificates \(DSS key\)) s +5 426 M +( spki-sign-rsa OPTIONAL sign SPKI certificates \(RSA key\)) s +5 415 M +( spki-sign-dss OPTIONAL sign SPKI certificates \(DSS key\)) s +5 404 M +( pgp-sign-rsa OPTIONAL sign OpenPGP certificates \(RSA key\)) s +5 393 M +( pgp-sign-dss OPTIONAL sign OpenPGP certificates \(DSS key\)) s +5 371 M +( Additional key types may be defined as specified in [SSH-ARCH].) s +5 349 M +( The key type MUST always be explicitly known \(from algorithm) s +5 338 M +( negotiation or some other source\). It is not normally included in) s +5 327 M +( the key blob.) s +5 305 M +( Certificates and public keys are encoded as follows:) s +5 283 M +( string certificate or public key format identifier) s +5 272 M +( byte[n] key/certificate data) s +5 250 M +( The certificate part may have be a zero length string, but a public) s +5 239 M +( key is required. This is the public key that will be used for) s +5 228 M +( authentication; the certificate sequence contained in the certificate) s +5 217 M +( blob can be used to provide authorization.) s +5 195 M +( Public key / certifcate formats that do not explicitly specify a) s +5 184 M +( signature format identifier MUST use the public key / certificate) s +5 173 M +( format identifier as the signature identifier.) s +5 129 M +(Ylonen & Moffat, Editor Expires March 31, 2004 [Page 11]) s +_R +S +PStoPSsaved restore +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 421.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 12 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH Transport Layer Protocol Oct 2003) s +5 690 M +( Signatures are encoded as follows:) s +5 679 M +( string signature format identifier \(as specified by the) s +5 668 M +( public key / cert format\)) s +5 657 M +( byte[n] signature blob in format specific encoding.) s +5 624 M +( The "ssh-dss" key format has the following specific encoding:) s +5 602 M +( string "ssh-dss") s +5 591 M +( mpint p) s +5 580 M +( mpint q) s +5 569 M +( mpint g) s +5 558 M +( mpint y) s +5 536 M +( Here the p, q, g, and y parameters form the signature key blob.) s +5 514 M +( Signing and verifying using this key format is done according to the) s +5 503 M +( Digital Signature Standard [FIPS-186] using the SHA-1 hash. A) s +5 492 M +( description can also be found in [SCHNEIER].) s +5 470 M +( The resulting signature is encoded as follows:) s +5 448 M +( string "ssh-dss") s +5 437 M +( string dss_signature_blob) s +5 415 M +( dss_signature_blob is encoded as a string containing r followed by s) s +5 404 M +( \(which are 160 bits long integers, without lengths or padding,) s +5 393 M +( unsigned and in network byte order\).) s +5 371 M +( The "ssh-rsa" key format has the following specific encoding:) s +5 349 M +( string "ssh-rsa") s +5 338 M +( mpint e) s +5 327 M +( mpint n) s +5 305 M +( Here the e and n parameters form the signature key blob.) s +5 283 M +( Signing and verifying using this key format is done according to) s +5 272 M +( [SCHNEIER] and [PKCS1] using the SHA-1 hash.) s +5 250 M +( The resulting signature is encoded as follows:) s +5 228 M +( string "ssh-rsa") s +5 217 M +( string rsa_signature_blob) s +5 195 M +( rsa_signature_blob is encoded as a string containing s \(which is an) s +5 184 M +( integer, without lengths or padding, unsigned and in network byte) s +5 173 M +( order\).) s +5 129 M +(Ylonen & Moffat, Editor Expires March 31, 2004 [Page 12]) s +_R +S +PStoPSsaved restore +%%Page: (12,13) 7 +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 0.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +/showpage{}def/copypage{}def/erasepage{}def +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 13 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH Transport Layer Protocol Oct 2003) s +5 690 M +( The "spki-sign-rsa" method indicates that the certificate blob) s +5 679 M +( contains a sequence of SPKI certificates. The format of SPKI) s +5 668 M +( certificates is described in [RFC2693]. This method indicates that) s +5 657 M +( the key \(or one of the keys in the certificate\) is an RSA-key.) s +5 635 M +( The "spki-sign-dss". As above, but indicates that the key \(or one of) s +5 624 M +( the keys in the certificate\) is a DSS-key.) s +5 602 M +( The "pgp-sign-rsa" method indicates the certificates, the public key,) s +5 591 M +( and the signature are in OpenPGP compatible binary format) s +5 580 M +( \([RFC2440]\). This method indicates that the key is an RSA-key.) s +5 558 M +( The "pgp-sign-dss". As above, but indicates that the key is a) s +5 547 M +( DSS-key.) s +5 525 M +(6. Key Exchange) s +5 503 M +( Key exchange begins by each side sending lists of supported) s +5 492 M +( algorithms. Each side has a preferred algorithm in each category, and) s +5 481 M +( it is assumed that most implementations at any given time will use) s +5 470 M +( the same preferred algorithm. Each side MAY guess which algorithm) s +5 459 M +( the other side is using, and MAY send an initial key exchange packet) s +5 448 M +( according to the algorithm if appropriate for the preferred method.) s +5 426 M +( Guess is considered wrong, if:) s +5 415 M +( o the kex algorithm and/or the host key algorithm is guessed wrong) s +5 404 M +( \(server and client have different preferred algorithm\), or) s +5 393 M +( o if any of the other algorithms cannot be agreed upon \(the) s +5 382 M +( procedure is defined below in Section Section 6.1\).) s +5 360 M +( Otherwise, the guess is considered to be right and the optimistically) s +5 349 M +( sent packet MUST be handled as the first key exchange packet.) s +5 327 M +( However, if the guess was wrong, and a packet was optimistically sent) s +5 316 M +( by one or both parties, such packets MUST be ignored \(even if the) s +5 305 M +( error in the guess would not affect the contents of the initial) s +5 294 M +( packet\(s\)\), and the appropriate side MUST send the correct initial) s +5 283 M +( packet.) s +5 261 M +( Server authentication in the key exchange MAY be implicit. After a) s +5 250 M +( key exchange with implicit server authentication, the client MUST) s +5 239 M +( wait for response to its service request message before sending any) s +5 228 M +( further data.) s +5 206 M +(6.1 Algorithm Negotiation) s +5 184 M +( Key exchange begins by each side sending the following packet:) s +5 129 M +(Ylonen & Moffat, Editor Expires March 31, 2004 [Page 13]) s +_R +S +PStoPSsaved restore +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 421.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 14 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH Transport Layer Protocol Oct 2003) s +5 690 M +( byte SSH_MSG_KEXINIT) s +5 679 M +( byte[16] cookie \(random bytes\)) s +5 668 M +( string kex_algorithms) s +5 657 M +( string server_host_key_algorithms) s +5 646 M +( string encryption_algorithms_client_to_server) s +5 635 M +( string encryption_algorithms_server_to_client) s +5 624 M +( string mac_algorithms_client_to_server) s +5 613 M +( string mac_algorithms_server_to_client) s +5 602 M +( string compression_algorithms_client_to_server) s +5 591 M +( string compression_algorithms_server_to_client) s +5 580 M +( string languages_client_to_server) s +5 569 M +( string languages_server_to_client) s +5 558 M +( boolean first_kex_packet_follows) s +5 547 M +( uint32 0 \(reserved for future extension\)) s +5 525 M +( Each of the algorithm strings MUST be a comma-separated list of) s +5 514 M +( algorithm names \(see ''Algorithm Naming'' in [SSH-ARCH]\). Each) s +5 503 M +( supported \(allowed\) algorithm MUST be listed in order of preference.) s +5 481 M +( The first algorithm in each list MUST be the preferred \(guessed\)) s +5 470 M +( algorithm. Each string MUST contain at least one algorithm name.) s +5 437 M +( cookie) s +5 426 M +( The cookie MUST be a random value generated by the sender. Its) s +5 415 M +( purpose is to make it impossible for either side to fully) s +5 404 M +( determine the keys and the session identifier.) s +5 382 M +( kex_algorithms) s +5 371 M +( Key exchange algorithms were defined above. The first) s +5 360 M +( algorithm MUST be the preferred \(and guessed\) algorithm. If) s +5 349 M +( both sides make the same guess, that algorithm MUST be used.) s +5 338 M +( Otherwise, the following algorithm MUST be used to choose a key) s +5 327 M +( exchange method: iterate over client's kex algorithms, one at a) s +5 316 M +( time. Choose the first algorithm that satisfies the following) s +5 305 M +( conditions:) s +5 294 M +( + the server also supports the algorithm,) s +5 283 M +( + if the algorithm requires an encryption-capable host key,) s +5 272 M +( there is an encryption-capable algorithm on the server's) s +5 261 M +( server_host_key_algorithms that is also supported by the) s +5 250 M +( client, and) s +5 239 M +( + if the algorithm requires a signature-capable host key,) s +5 228 M +( there is a signature-capable algorithm on the server's) s +5 217 M +( server_host_key_algorithms that is also supported by the) s +5 206 M +( client.) s +5 195 M +( + If no algorithm satisfying all these conditions can be) s +5 184 M +( found, the connection fails, and both sides MUST disconnect.) s +5 129 M +(Ylonen & Moffat, Editor Expires March 31, 2004 [Page 14]) s +_R +S +PStoPSsaved restore +%%Page: (14,15) 8 +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 0.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +/showpage{}def/copypage{}def/erasepage{}def +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 15 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH Transport Layer Protocol Oct 2003) s +5 690 M +( server_host_key_algorithms) s +5 679 M +( List of the algorithms supported for the server host key. The) s +5 668 M +( server lists the algorithms for which it has host keys; the) s +5 657 M +( client lists the algorithms that it is willing to accept.) s +5 646 M +( \(There MAY be multiple host keys for a host, possibly with) s +5 635 M +( different algorithms.\)) s +5 613 M +( Some host keys may not support both signatures and encryption) s +5 602 M +( \(this can be determined from the algorithm\), and thus not all) s +5 591 M +( host keys are valid for all key exchange methods.) s +5 569 M +( Algorithm selection depends on whether the chosen key exchange) s +5 558 M +( algorithm requires a signature or encryption capable host key.) s +5 547 M +( It MUST be possible to determine this from the public key) s +5 536 M +( algorithm name. The first algorithm on the client's list that) s +5 525 M +( satisfies the requirements and is also supported by the server) s +5 514 M +( MUST be chosen. If there is no such algorithm, both sides MUST) s +5 503 M +( disconnect.) s +5 481 M +( encryption_algorithms) s +5 470 M +( Lists the acceptable symmetric encryption algorithms in order) s +5 459 M +( of preference. The chosen encryption algorithm to each) s +5 448 M +( direction MUST be the first algorithm on the client's list) s +5 437 M +( that is also on the server's list. If there is no such) s +5 426 M +( algorithm, both sides MUST disconnect.) s +5 404 M +( Note that "none" must be explicitly listed if it is to be) s +5 393 M +( acceptable. The defined algorithm names are listed in Section) s +5 382 M +( Section 5.3.) s +5 360 M +( mac_algorithms) s +5 349 M +( Lists the acceptable MAC algorithms in order of preference.) s +5 338 M +( The chosen MAC algorithm MUST be the first algorithm on the) s +5 327 M +( client's list that is also on the server's list. If there is) s +5 316 M +( no such algorithm, both sides MUST disconnect.) s +5 294 M +( Note that "none" must be explicitly listed if it is to be) s +5 283 M +( acceptable. The MAC algorithm names are listed in Section) s +5 272 M +( Figure 1.) s +5 250 M +( compression_algorithms) s +5 239 M +( Lists the acceptable compression algorithms in order of) s +5 228 M +( preference. The chosen compression algorithm MUST be the first) s +5 217 M +( algorithm on the client's list that is also on the server's) s +5 206 M +( list. If there is no such algorithm, both sides MUST) s +5 195 M +( disconnect.) s +5 129 M +(Ylonen & Moffat, Editor Expires March 31, 2004 [Page 15]) s +_R +S +PStoPSsaved restore +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 421.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 16 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH Transport Layer Protocol Oct 2003) s +5 690 M +( Note that "none" must be explicitly listed if it is to be) s +5 679 M +( acceptable. The compression algorithm names are listed in) s +5 668 M +( Section Section 5.2.) s +5 646 M +( languages) s +5 635 M +( This is a comma-separated list of language tags in order of) s +5 624 M +( preference [RFC3066]. Both parties MAY ignore this list. If) s +5 613 M +( there are no language preferences, this list SHOULD be empty.) s +5 602 M +( Language tags SHOULD NOT be present unless they are known to be) s +5 591 M +( needed by the sending party.) s +5 569 M +( first_kex_packet_follows) s +5 558 M +( Indicates whether a guessed key exchange packet follows. If a) s +5 547 M +( guessed packet will be sent, this MUST be TRUE. If no guessed) s +5 536 M +( packet will be sent, this MUST be FALSE.) s +5 514 M +( After receiving the SSH_MSG_KEXINIT packet from the other side,) s +5 503 M +( each party will know whether their guess was right. If the) s +5 492 M +( other party's guess was wrong, and this field was TRUE, the) s +5 481 M +( next packet MUST be silently ignored, and both sides MUST then) s +5 470 M +( act as determined by the negotiated key exchange method. If) s +5 459 M +( the guess was right, key exchange MUST continue using the) s +5 448 M +( guessed packet.) s +5 426 M +( After the KEXINIT packet exchange, the key exchange algorithm is run.) s +5 415 M +( It may involve several packet exchanges, as specified by the key) s +5 404 M +( exchange method.) s +5 382 M +(6.2 Output from Key Exchange) s +5 360 M +( The key exchange produces two values: a shared secret K, and an) s +5 349 M +( exchange hash H. Encryption and authentication keys are derived from) s +5 338 M +( these. The exchange hash H from the first key exchange is) s +5 327 M +( additionally used as the session identifier, which is a unique) s +5 316 M +( identifier for this connection. It is used by authentication methods) s +5 305 M +( as a part of the data that is signed as a proof of possession of a) s +5 294 M +( private key. Once computed, the session identifier is not changed,) s +5 283 M +( even if keys are later re-exchanged.) s +5 250 M +( Each key exchange method specifies a hash function that is used in) s +5 239 M +( the key exchange. The same hash algorithm MUST be used in key) s +5 228 M +( derivation. Here, we'll call it HASH.) s +5 195 M +( Encryption keys MUST be computed as HASH of a known value and K as) s +5 184 M +( follows:) s +5 129 M +(Ylonen & Moffat, Editor Expires March 31, 2004 [Page 16]) s +_R +S +PStoPSsaved restore +%%Page: (16,17) 9 +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 0.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +/showpage{}def/copypage{}def/erasepage{}def +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 17 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH Transport Layer Protocol Oct 2003) s +5 690 M +( o Initial IV client to server: HASH\(K || H || "A" || session_id\)) s +5 679 M +( \(Here K is encoded as mpint and "A" as byte and session_id as raw) s +5 668 M +( data."A" means the single character A, ASCII 65\).) s +5 657 M +( o Initial IV server to client: HASH\(K || H || "B" || session_id\)) s +5 646 M +( o Encryption key client to server: HASH\(K || H || "C" || session_id\)) s +5 635 M +( o Encryption key server to client: HASH\(K || H || "D" || session_id\)) s +5 624 M +( o Integrity key client to server: HASH\(K || H || "E" || session_id\)) s +5 613 M +( o Integrity key server to client: HASH\(K || H || "F" || session_id\)) s +5 591 M +( Key data MUST be taken from the beginning of the hash output. 128) s +5 580 M +( bits \(16 bytes\) MUST be used for algorithms with variable-length) s +5 569 M +( keys. The only variable key length algorithm defined in this document) s +5 558 M +( is arcfour\). For other algorithms, as many bytes as are needed are) s +5 547 M +( taken from the beginning of the hash value. If the key length needed) s +5 536 M +( is longer than the output of the HASH, the key is extended by) s +5 525 M +( computing HASH of the concatenation of K and H and the entire key so) s +5 514 M +( far, and appending the resulting bytes \(as many as HASH generates\) to) s +5 503 M +( the key. This process is repeated until enough key material is) s +5 492 M +( available; the key is taken from the beginning of this value. In) s +5 481 M +( other words:) s +5 459 M +( K1 = HASH\(K || H || X || session_id\) \(X is e.g. "A"\)) s +5 448 M +( K2 = HASH\(K || H || K1\)) s +5 437 M +( K3 = HASH\(K || H || K1 || K2\)) s +5 426 M +( ...) s +5 415 M +( key = K1 || K2 || K3 || ...) s +5 393 M +( This process will lose entropy if the amount of entropy in K is) s +5 382 M +( larger than the internal state size of HASH.) s +5 360 M +(6.3 Taking Keys Into Use) s +5 338 M +( Key exchange ends by each side sending an SSH_MSG_NEWKEYS message.) s +5 327 M +( This message is sent with the old keys and algorithms. All messages) s +5 316 M +( sent after this message MUST use the new keys and algorithms.) s +5 283 M +( When this message is received, the new keys and algorithms MUST be) s +5 272 M +( taken into use for receiving.) s +5 239 M +( This message is the only valid message after key exchange, in) s +5 228 M +( addition to SSH_MSG_DEBUG, SSH_MSG_DISCONNECT and SSH_MSG_IGNORE) s +5 217 M +( messages. The purpose of this message is to ensure that a party is) s +5 206 M +( able to respond with a disconnect message that the other party can) s +5 195 M +( understand if something goes wrong with the key exchange.) s +5 184 M +( Implementations MUST NOT accept any other messages after key exchange) s +5 173 M +( before receiving SSH_MSG_NEWKEYS.) s +5 129 M +(Ylonen & Moffat, Editor Expires March 31, 2004 [Page 17]) s +_R +S +PStoPSsaved restore +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 421.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 18 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH Transport Layer Protocol Oct 2003) s +5 690 M +( byte SSH_MSG_NEWKEYS) s +5 657 M +(7. Diffie-Hellman Key Exchange) s +5 635 M +( The Diffie-Hellman key exchange provides a shared secret that can not) s +5 624 M +( be determined by either party alone. The key exchange is combined) s +5 613 M +( with a signature with the host key to provide host authentication.) s +5 580 M +( In the following description \(C is the client, S is the server; p is) s +5 569 M +( a large safe prime, g is a generator for a subgroup of GF\(p\), and q) s +5 558 M +( is the order of the subgroup; V_S is S's version string; V_C is C's) s +5 547 M +( version string; K_S is S's public host key; I_C is C's KEXINIT) s +5 536 M +( message and I_S S's KEXINIT message which have been exchanged before) s +5 525 M +( this part begins\):) s +5 492 M +( 1. C generates a random number x \(1 < x < q\) and computes e = g^x) s +5 481 M +( mod p. C sends "e" to S.) s +5 459 M +( 2. S generates a random number y \(0 < y < q\) and computes f = g^y) s +5 448 M +( mod p. S receives "e". It computes K = e^y mod p, H = hash\(V_C) s +5 437 M +( || V_S || I_C || I_S || K_S || e || f || K\) \(these elements are) s +5 426 M +( encoded according to their types; see below\), and signature s on) s +5 415 M +( H with its private host key. S sends "K_S || f || s" to C. The) s +5 404 M +( signing operation may involve a second hashing operation.) s +5 382 M +( 3. C verifies that K_S really is the host key for S \(e.g. using) s +5 371 M +( certificates or a local database\). C is also allowed to accept) s +5 360 M +( the key without verification; however, doing so will render the) s +5 349 M +( protocol insecure against active attacks \(but may be desirable) s +5 338 M +( for practical reasons in the short term in many environments\). C) s +5 327 M +( then computes K = f^x mod p, H = hash\(V_C || V_S || I_C || I_S ||) s +5 316 M +( K_S || e || f || K\), and verifies the signature s on H.) s +5 294 M +( Either side MUST NOT send or accept e or f values that are not in the) s +5 283 M +( range [1, p-1]. If this condition is violated, the key exchange) s +5 272 M +( fails.) s +5 239 M +( This is implemented with the following messages. The hash algorithm) s +5 228 M +( for computing the exchange hash is defined by the method name, and is) s +5 217 M +( called HASH. The public key algorithm for signing is negotiated with) s +5 206 M +( the KEXINIT messages.) s +5 184 M +( First, the client sends the following:) s +5 129 M +(Ylonen & Moffat, Editor Expires March 31, 2004 [Page 18]) s +_R +S +PStoPSsaved restore +%%Page: (18,19) 10 +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 0.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +/showpage{}def/copypage{}def/erasepage{}def +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 19 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH Transport Layer Protocol Oct 2003) s +5 690 M +( byte SSH_MSG_KEXDH_INIT) s +5 679 M +( mpint e) s +5 646 M +( The server responds with the following:) s +5 624 M +( byte SSH_MSG_KEXDH_REPLY) s +5 613 M +( string server public host key and certificates \(K_S\)) s +5 602 M +( mpint f) s +5 591 M +( string signature of H) s +5 569 M +( The hash H is computed as the HASH hash of the concatenation of the) s +5 558 M +( following:) s +5 536 M +( string V_C, the client's version string \(CR and NL excluded\)) s +5 525 M +( string V_S, the server's version string \(CR and NL excluded\)) s +5 514 M +( string I_C, the payload of the client's SSH_MSG_KEXINIT) s +5 503 M +( string I_S, the payload of the server's SSH_MSG_KEXINIT) s +5 492 M +( string K_S, the host key) s +5 481 M +( mpint e, exchange value sent by the client) s +5 470 M +( mpint f, exchange value sent by the server) s +5 459 M +( mpint K, the shared secret) s +5 437 M +( This value is called the exchange hash, and it is used to) s +5 426 M +( authenticate the key exchange. The exchange hash SHOULD be kept) s +5 415 M +( secret.) s +5 382 M +( The signature algorithm MUST be applied over H, not the original) s +5 371 M +( data. Most signature algorithms include hashing and additional) s +5 360 M +( padding. For example, "ssh-dss" specifies SHA-1 hashing; in that) s +5 349 M +( case, the data is first hashed with HASH to compute H, and H is then) s +5 338 M +( hashed with SHA-1 as part of the signing operation.) s +5 316 M +(7.1 diffie-hellman-group1-sha1) s +5 294 M +( The "diffie-hellman-group1-sha1" method specifies Diffie-Hellman key) s +5 283 M +( exchange with SHA-1 as HASH, and Oakley group 14 [RFC3526] \(2048-bit) s +5 272 M +( MODP Group\). It is included below in hexadecimal and decimal.) s +5 250 M +( The prime p is equal to 2^1024 - 2^960 - 1 + 2^64 * floor\( 2^894 Pi +) s +5 239 M +( 129093 \). Its hexadecimal value is:) s +5 217 M +( FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1) s +5 206 M +( 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD) s +5 195 M +( EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245) s +5 184 M +( E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED) s +5 173 M +( EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381) s +5 129 M +(Ylonen & Moffat, Editor Expires March 31, 2004 [Page 19]) s +_R +S +PStoPSsaved restore +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 421.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 20 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH Transport Layer Protocol Oct 2003) s +5 690 M +( FFFFFFFF FFFFFFFF.) s +5 668 M +( In decimal, this value is:) s +5 646 M +( 179769313486231590770839156793787453197860296048756011706444) s +5 635 M +( 423684197180216158519368947833795864925541502180565485980503) s +5 624 M +( 646440548199239100050792877003355816639229553136239076508735) s +5 613 M +( 759914822574862575007425302077447712589550957937778424442426) s +5 602 M +( 617334727629299387668709205606050270810842907692932019128194) s +5 591 M +( 467627007.) s +5 569 M +( The generator used with this prime is g = 2. The group order q is \(p) s +5 558 M +( - 1\) / 2.) s +5 536 M +(8. Key Re-Exchange) s +5 514 M +( Key re-exchange is started by sending an SSH_MSG_KEXINIT packet when) s +5 503 M +( not already doing a key exchange \(as described in Section Section) s +5 492 M +( 6.1\). When this message is received, a party MUST respond with its) s +5 481 M +( own SSH_MSG_KEXINIT message except when the received SSH_MSG_KEXINIT) s +5 470 M +( already was a reply. Either party MAY initiate the re-exchange, but) s +5 459 M +( roles MUST NOT be changed \(i.e., the server remains the server, and) s +5 448 M +( the client remains the client\).) s +5 415 M +( Key re-exchange is performed using whatever encryption was in effect) s +5 404 M +( when the exchange was started. Encryption, compression, and MAC) s +5 393 M +( methods are not changed before a new SSH_MSG_NEWKEYS is sent after) s +5 382 M +( the key exchange \(as in the initial key exchange\). Re-exchange is) s +5 371 M +( processed identically to the initial key exchange, except for the) s +5 360 M +( session identifier that will remain unchanged. It is permissible to) s +5 349 M +( change some or all of the algorithms during the re-exchange. Host) s +5 338 M +( keys can also change. All keys and initialization vectors are) s +5 327 M +( recomputed after the exchange. Compression and encryption contexts) s +5 316 M +( are reset.) s +5 283 M +( It is recommended that the keys are changed after each gigabyte of) s +5 272 M +( transmitted data or after each hour of connection time, whichever) s +5 261 M +( comes sooner. However, since the re-exchange is a public key) s +5 250 M +( operation, it requires a fair amount of processing power and should) s +5 239 M +( not be performed too often.) s +5 206 M +( More application data may be sent after the SSH_MSG_NEWKEYS packet) s +5 195 M +( has been sent; key exchange does not affect the protocols that lie) s +5 184 M +( above the SSH transport layer.) s +5 129 M +(Ylonen & Moffat, Editor Expires March 31, 2004 [Page 20]) s +_R +S +PStoPSsaved restore +%%Page: (20,21) 11 +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 0.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +/showpage{}def/copypage{}def/erasepage{}def +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 21 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH Transport Layer Protocol Oct 2003) s +5 690 M +(9. Service Request) s +5 668 M +( After the key exchange, the client requests a service. The service is) s +5 657 M +( identified by a name. The format of names and procedures for defining) s +5 646 M +( new names are defined in [SSH-ARCH].) s +5 613 M +( Currently, the following names have been reserved:) s +5 591 M +( ssh-userauth) s +5 580 M +( ssh-connection) s +5 558 M +( Similar local naming policy is applied to the service names, as is) s +5 547 M +( applied to the algorithm names; a local service should use the) s +5 536 M +( "servicename@domain" syntax.) s +5 514 M +( byte SSH_MSG_SERVICE_REQUEST) s +5 503 M +( string service name) s +5 481 M +( If the server rejects the service request, it SHOULD send an) s +5 470 M +( appropriate SSH_MSG_DISCONNECT message and MUST disconnect.) s +5 437 M +( When the service starts, it may have access to the session identifier) s +5 426 M +( generated during the key exchange.) s +5 393 M +( If the server supports the service \(and permits the client to use) s +5 382 M +( it\), it MUST respond with the following:) s +5 360 M +( byte SSH_MSG_SERVICE_ACCEPT) s +5 349 M +( string service name) s +5 327 M +( Message numbers used by services should be in the area reserved for) s +5 316 M +( them \(see Section 6 in [SSH-ARCH]\). The transport level will) s +5 305 M +( continue to process its own messages.) s +5 272 M +( Note that after a key exchange with implicit server authentication,) s +5 261 M +( the client MUST wait for response to its service request message) s +5 250 M +( before sending any further data.) s +5 228 M +(10. Additional Messages) s +5 206 M +( Either party may send any of the following messages at any time.) s +5 129 M +(Ylonen & Moffat, Editor Expires March 31, 2004 [Page 21]) s +_R +S +PStoPSsaved restore +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 421.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 22 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH Transport Layer Protocol Oct 2003) s +5 690 M +(10.1 Disconnection Message) s +5 668 M +( byte SSH_MSG_DISCONNECT) s +5 657 M +( uint32 reason code) s +5 646 M +( string description [RFC2279]) s +5 635 M +( string language tag [RFC3066]) s +5 613 M +( This message causes immediate termination of the connection. All) s +5 602 M +( implementations MUST be able to process this message; they SHOULD be) s +5 591 M +( able to send this message.) s +5 569 M +( The sender MUST NOT send or receive any data after this message, and) s +5 558 M +( the recipient MUST NOT accept any data after receiving this message.) s +5 547 M +( The description field gives a more specific explanation in a) s +5 536 M +( human-readable form. The error code gives the reason in a more) s +5 525 M +( machine-readable format \(suitable for localization\), and can have the) s +5 514 M +( following values:) s +5 492 M +( #define SSH_DISCONNECT_HOST_NOT_ALLOWED_TO_CONNECT 1) s +5 481 M +( #define SSH_DISCONNECT_PROTOCOL_ERROR 2) s +5 470 M +( #define SSH_DISCONNECT_KEY_EXCHANGE_FAILED 3) s +5 459 M +( #define SSH_DISCONNECT_RESERVED 4) s +5 448 M +( #define SSH_DISCONNECT_MAC_ERROR 5) s +5 437 M +( #define SSH_DISCONNECT_COMPRESSION_ERROR 6) s +5 426 M +( #define SSH_DISCONNECT_SERVICE_NOT_AVAILABLE 7) s +5 415 M +( #define SSH_DISCONNECT_PROTOCOL_VERSION_NOT_SUPPORTED 8) s +5 404 M +( #define SSH_DISCONNECT_HOST_KEY_NOT_VERIFIABLE 9) s +5 393 M +( #define SSH_DISCONNECT_CONNECTION_LOST 10) s +5 382 M +( #define SSH_DISCONNECT_BY_APPLICATION 11) s +5 371 M +( #define SSH_DISCONNECT_TOO_MANY_CONNECTIONS 12) s +5 360 M +( #define SSH_DISCONNECT_AUTH_CANCELLED_BY_USER 13) s +5 349 M +( #define SSH_DISCONNECT_NO_MORE_AUTH_METHODS_AVAILABLE 14) s +5 338 M +( #define SSH_DISCONNECT_ILLEGAL_USER_NAME 15) s +5 316 M +( If the description string is displayed, control character filtering) s +5 305 M +( discussed in [SSH-ARCH] should be used to avoid attacks by sending) s +5 294 M +( terminal control characters.) s +5 272 M +(10.2 Ignored Data Message) s +5 250 M +( byte SSH_MSG_IGNORE) s +5 239 M +( string data) s +5 217 M +( All implementations MUST understand \(and ignore\) this message at any) s +5 206 M +( time \(after receiving the protocol version\). No implementation is) s +5 195 M +( required to send them. This message can be used as an additional) s +5 184 M +( protection measure against advanced traffic analysis techniques.) s +5 129 M +(Ylonen & Moffat, Editor Expires March 31, 2004 [Page 22]) s +_R +S +PStoPSsaved restore +%%Page: (22,23) 12 +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 0.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +/showpage{}def/copypage{}def/erasepage{}def +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 23 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH Transport Layer Protocol Oct 2003) s +5 690 M +(10.3 Debug Message) s +5 668 M +( byte SSH_MSG_DEBUG) s +5 657 M +( boolean always_display) s +5 646 M +( string message [RFC2279]) s +5 635 M +( string language tag [RFC3066]) s +5 613 M +( All implementations MUST understand this message, but they are) s +5 602 M +( allowed to ignore it. This message is used to pass the other side) s +5 591 M +( information that may help debugging. If always_display is TRUE, the) s +5 580 M +( message SHOULD be displayed. Otherwise, it SHOULD NOT be displayed) s +5 569 M +( unless debugging information has been explicitly requested by the) s +5 558 M +( user.) s +5 525 M +( The message doesn't need to contain a newline. It is, however,) s +5 514 M +( allowed to consist of multiple lines separated by CRLF \(Carriage) s +5 503 M +( Return - Line Feed\) pairs.) s +5 470 M +( If the message string is displayed, terminal control character) s +5 459 M +( filtering discussed in [SSH-ARCH] should be used to avoid attacks by) s +5 448 M +( sending terminal control characters.) s +5 426 M +(10.4 Reserved Messages) s +5 404 M +( An implementation MUST respond to all unrecognized messages with an) s +5 393 M +( SSH_MSG_UNIMPLEMENTED message in the order in which the messages were) s +5 382 M +( received. Such messages MUST be otherwise ignored. Later protocol) s +5 371 M +( versions may define other meanings for these message types.) s +5 349 M +( byte SSH_MSG_UNIMPLEMENTED) s +5 338 M +( uint32 packet sequence number of rejected message) s +5 305 M +(11. Summary of Message Numbers) s +5 283 M +( The following message numbers have been defined in this protocol:) s +5 261 M +( #define SSH_MSG_DISCONNECT 1) s +5 250 M +( #define SSH_MSG_IGNORE 2) s +5 239 M +( #define SSH_MSG_UNIMPLEMENTED 3) s +5 228 M +( #define SSH_MSG_DEBUG 4) s +5 217 M +( #define SSH_MSG_SERVICE_REQUEST 5) s +5 206 M +( #define SSH_MSG_SERVICE_ACCEPT 6) s +5 184 M +( #define SSH_MSG_KEXINIT 20) s +5 173 M +( #define SSH_MSG_NEWKEYS 21) s +5 129 M +(Ylonen & Moffat, Editor Expires March 31, 2004 [Page 23]) s +_R +S +PStoPSsaved restore +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 421.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 24 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH Transport Layer Protocol Oct 2003) s +5 690 M +( /* Numbers 30-49 used for kex packets.) s +5 679 M +( Different kex methods may reuse message numbers in) s +5 668 M +( this range. */) s +5 646 M +( #define SSH_MSG_KEXDH_INIT 30) s +5 635 M +( #define SSH_MSG_KEXDH_REPLY 31) s +5 602 M +(12. IANA Considerations) s +5 580 M +( This document is part of a set, the IANA considerations for the SSH) s +5 569 M +( protocol as defined in [SSH-ARCH], [SSH-TRANS], [SSH-USERAUTH],) s +5 558 M +( [SSH-CONNECT] are detailed in [SSH-NUMBERS].) s +5 536 M +(13. Security Considerations) s +5 514 M +( This protocol provides a secure encrypted channel over an insecure) s +5 503 M +( network. It performs server host authentication, key exchange,) s +5 492 M +( encryption, and integrity protection. It also derives a unique) s +5 481 M +( session id that may be used by higher-level protocols.) s +5 459 M +( Full security considerations for this protocol are provided in) s +5 448 M +( Section 8 of [SSH-ARCH]) s +5 426 M +(14. Intellectual Property) s +5 404 M +( The IETF takes no position regarding the validity or scope of any) s +5 393 M +( intellectual property or other rights that might be claimed to) s +5 382 M +( pertain to the implementation or use of the technology described in) s +5 371 M +( this document or the extent to which any license under such rights) s +5 360 M +( might or might not be available; neither does it represent that it) s +5 349 M +( has made any effort to identify any such rights. Information on the) s +5 338 M +( IETF's procedures with respect to rights in standards-track and) s +5 327 M +( standards-related documentation can be found in BCP-11. Copies of) s +5 316 M +( claims of rights made available for publication and any assurances of) s +5 305 M +( licenses to be made available, or the result of an attempt made to) s +5 294 M +( obtain a general license or permission for the use of such) s +5 283 M +( proprietary rights by implementers or users of this specification can) s +5 272 M +( be obtained from the IETF Secretariat.) s +5 250 M +( The IETF has been notified of intellectual property rights claimed in) s +5 239 M +( regard to some or all of the specification contained in this) s +5 228 M +( document. For more information consult the online list of claimed) s +5 217 M +( rights.) s +5 195 M +(15. Additional Information) s +5 173 M +( The current document editor is: [email protected]. Comments on) s +5 129 M +(Ylonen & Moffat, Editor Expires March 31, 2004 [Page 24]) s +_R +S +PStoPSsaved restore +%%Page: (24,25) 13 +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 0.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +/showpage{}def/copypage{}def/erasepage{}def +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 25 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH Transport Layer Protocol Oct 2003) s +5 690 M +( this internet draft should be sent to the IETF SECSH working group,) s +5 679 M +( details at: http://ietf.org/html.charters/secsh-charter.html) s +5 657 M +(Normative) s +5 635 M +( [SSH-ARCH]) s +5 624 M +( Ylonen, T., "SSH Protocol Architecture", I-D) s +5 613 M +( draft-ietf-architecture-15.txt, Oct 2003.) s +5 591 M +( [SSH-TRANS]) s +5 580 M +( Ylonen, T., "SSH Transport Layer Protocol", I-D) s +5 569 M +( draft-ietf-transport-17.txt, Oct 2003.) s +5 547 M +( [SSH-USERAUTH]) s +5 536 M +( Ylonen, T., "SSH Authentication Protocol", I-D) s +5 525 M +( draft-ietf-userauth-18.txt, Oct 2003.) s +5 503 M +( [SSH-CONNECT]) s +5 492 M +( Ylonen, T., "SSH Connection Protocol", I-D) s +5 481 M +( draft-ietf-connect-18.txt, Oct 2003.) s +5 459 M +( [SSH-NUMBERS]) s +5 448 M +( Lehtinen, S. and D. Moffat, "SSH Protocol Assigned) s +5 437 M +( Numbers", I-D draft-ietf-secsh-assignednumbers-05.txt, Oct) s +5 426 M +( 2003.) s +5 404 M +( [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate) s +5 393 M +( Requirement Levels", BCP 14, RFC 2119, March 1997.) s +5 371 M +(Informative) s +5 349 M +( [FIPS-186]) s +5 338 M +( Federal Information Processing Standards Publication,) s +5 327 M +( "FIPS PUB 186, Digital Signature Standard", May 1994.) s +5 305 M +( [FIPS-197]) s +5 294 M +( NIST, "FIPS PUB 197 Advanced Encryption Standard \(AES\)",) s +5 283 M +( November 2001.) s +5 261 M +( [FIPS-46-3]) s +5 250 M +( U.S. Dept. of Commerce, "FIPS PUB 46-3, Data Encryption) s +5 239 M +( Standard \(DES\)", October 1999.) s +5 217 M +( [RFC2459] Housley, R., Ford, W., Polk, T. and D. Solo, "Internet) s +5 206 M +( X.509 Public Key Infrastructure Certificate and CRL) s +5 195 M +( Profile", RFC 2459, January 1999.) s +5 173 M +( [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",) s +5 129 M +(Ylonen & Moffat, Editor Expires March 31, 2004 [Page 25]) s +_R +S +PStoPSsaved restore +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 421.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 26 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH Transport Layer Protocol Oct 2003) s +5 690 M +( STD 13, RFC 1034, November 1987.) s +5 668 M +( [RFC3066] Alvestrand, H., "Tags for the Identification of) s +5 657 M +( Languages", BCP 47, RFC 3066, January 2001.) s +5 635 M +( [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format) s +5 624 M +( Specification version 3.3", RFC 1950, May 1996.) s +5 602 M +( [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification) s +5 591 M +( version 1.3", RFC 1951, May 1996.) s +5 569 M +( [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO) s +5 558 M +( 10646", RFC 2279, January 1998.) s +5 536 M +( [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC:) s +5 525 M +( Keyed-Hashing for Message Authentication", RFC 2104,) s +5 514 M +( February 1997.) s +5 492 M +( [RFC2144] Adams, C., "The CAST-128 Encryption Algorithm", RFC 2144,) s +5 481 M +( May 1997.) s +5 459 M +( [RFC2440] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer,) s +5 448 M +( "OpenPGP Message Format", RFC 2440, November 1998.) s +5 426 M +( [RFC2693] Ellison, C., Frantz, B., Lampson, B., Rivest, R., Thomas,) s +5 415 M +( B. and T. Ylonen, "SPKI Certificate Theory", RFC 2693,) s +5 404 M +( September 1999.) s +5 382 M +( [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential \(MODP\)) s +5 371 M +( Diffie-Hellman groups for Internet Key Exchange \(IKE\)",) s +5 360 M +( RFC 3526, May 2003.) s +5 338 M +( [SCHNEIER]) s +5 327 M +( Schneier, B., "Applied Cryptography Second Edition:) s +5 316 M +( protocols algorithms and source in code in C", 1996.) s +5 294 M +( [TWOFISH] Schneier, B., "The Twofish Encryptions Algorithm: A) s +5 283 M +( 128-Bit Block Cipher, 1st Edition", March 1999.) s +5 129 M +(Ylonen & Moffat, Editor Expires March 31, 2004 [Page 26]) s +_R +S +PStoPSsaved restore +%%Page: (26,27) 14 +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 0.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +/showpage{}def/copypage{}def/erasepage{}def +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 27 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH Transport Layer Protocol Oct 2003) s +5 690 M +(Authors' Addresses) s +5 668 M +( Tatu Ylonen) s +5 657 M +( SSH Communications Security Corp) s +5 646 M +( Fredrikinkatu 42) s +5 635 M +( HELSINKI FIN-00100) s +5 624 M +( Finland) s +5 602 M +( EMail: [email protected]) s +5 569 M +( Darren J. Moffat \(editor\)) s +5 558 M +( Sun Microsystems, Inc) s +5 547 M +( 17 Network Circle) s +5 536 M +( Menlo Park 95025) s +5 525 M +( USA) s +5 503 M +( EMail: [email protected]) s +5 481 M +(Appendix A. Contibutors) s +5 129 M +(Ylonen & Moffat, Editor Expires March 31, 2004 [Page 27]) s +_R +S +PStoPSsaved restore +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 421.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 28 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH Transport Layer Protocol Oct 2003) s +5 690 M +(Intellectual Property Statement) s +5 668 M +( The IETF takes no position regarding the validity or scope of any) s +5 657 M +( intellectual property or other rights that might be claimed to) s +5 646 M +( pertain to the implementation or use of the technology described in) s +5 635 M +( this document or the extent to which any license under such rights) s +5 624 M +( might or might not be available; neither does it represent that it) s +5 613 M +( has made any effort to identify any such rights. Information on the) s +5 602 M +( IETF's procedures with respect to rights in standards-track and) s +5 591 M +( standards-related documentation can be found in BCP-11. Copies of) s +5 580 M +( claims of rights made available for publication and any assurances of) s +5 569 M +( licenses to be made available, or the result of an attempt made to) s +5 558 M +( obtain a general license or permission for the use of such) s +5 547 M +( proprietary rights by implementors or users of this specification can) s +5 536 M +( be obtained from the IETF Secretariat.) s +5 514 M +( The IETF invites any interested party to bring to its attention any) s +5 503 M +( copyrights, patents or patent applications, or other proprietary) s +5 492 M +( rights which may cover technology that may be required to practice) s +5 481 M +( this standard. Please address the information to the IETF Executive) s +5 470 M +( Director.) s +5 448 M +( The IETF has been notified of intellectual property rights claimed in) s +5 437 M +( regard to some or all of the specification contained in this) s +5 426 M +( document. For more information consult the online list of claimed) s +5 415 M +( rights.) s +5 382 M +(Full Copyright Statement) s +5 360 M +( Copyright \(C\) The Internet Society \(2003\). All Rights Reserved.) s +5 338 M +( This document and translations of it may be copied and furnished to) s +5 327 M +( others, and derivative works that comment on or otherwise explain it) s +5 316 M +( or assist in its implementation may be prepared, copied, published) s +5 305 M +( and distributed, in whole or in part, without restriction of any) s +5 294 M +( kind, provided that the above copyright notice and this paragraph are) s +5 283 M +( included on all such copies and derivative works. However, this) s +5 272 M +( document itself may not be modified in any way, such as by removing) s +5 261 M +( the copyright notice or references to the Internet Society or other) s +5 250 M +( Internet organizations, except as needed for the purpose of) s +5 239 M +( developing Internet standards in which case the procedures for) s +5 228 M +( copyrights defined in the Internet Standards process must be) s +5 217 M +( followed, or as required to translate it into languages other than) s +5 206 M +( English.) s +5 184 M +( The limited permissions granted above are perpetual and will not be) s +5 173 M +( revoked by the Internet Society or its successors or assignees.) s +5 129 M +(Ylonen & Moffat, Editor Expires March 31, 2004 [Page 28]) s +_R +S +PStoPSsaved restore +%%Page: (28,29) 15 +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 0.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +/showpage{}def/copypage{}def/erasepage{}def +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 29 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH Transport Layer Protocol Oct 2003) s +5 690 M +( This document and the information contained herein is provided on an) s +5 679 M +( "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING) s +5 668 M +( TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING) s +5 657 M +( BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION) s +5 646 M +( HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF) s +5 635 M +( MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.) s +5 602 M +(Acknowledgment) s +5 580 M +( Funding for the RFC Editor function is currently provided by the) s +5 569 M +( Internet Society.) s +5 129 M +(Ylonen & Moffat, Editor Expires March 31, 2004 [Page 29]) s +_R +S +PStoPSsaved restore +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 421.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +PStoPSxform concat +showpage +PStoPSsaved restore +%%Trailer +%%Pages: 29 +%%DocumentNeededResources: font Courier-Bold Courier +%%EOF diff --git a/lib/ssh/doc/standard/draft-ietf-secsh-transport-17.txt b/lib/ssh/doc/standard/draft-ietf-secsh-transport-17.txt new file mode 100644 index 0000000000..9073ea52b2 --- /dev/null +++ b/lib/ssh/doc/standard/draft-ietf-secsh-transport-17.txt @@ -0,0 +1,1624 @@ + + + +Network Working Group T. Ylonen +Internet-Draft SSH Communications Security Corp +Expires: March 31, 2004 D. Moffat, Editor, Ed. + Sun Microsystems, Inc + Oct 2003 + + + SSH Transport Layer Protocol + draft-ietf-secsh-transport-17.txt + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that other + groups may also distribute working documents as Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at http:// + www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on March 31, 2004. + +Copyright Notice + + Copyright (C) The Internet Society (2003). All Rights Reserved. + +Abstract + + SSH is a protocol for secure remote login and other secure network + services over an insecure network. + + This document describes the SSH transport layer protocol which + typically runs on top of TCP/IP. The protocol can be used as a basis + for a number of secure network services. It provides strong + encryption, server authentication, and integrity protection. It may + also provide compression. + + Key exchange method, public key algorithm, symmetric encryption + algorithm, message authentication algorithm, and hash algorithm are + + + +Ylonen & Moffat, Editor Expires March 31, 2004 [Page 1] + +Internet-Draft SSH Transport Layer Protocol Oct 2003 + + + all negotiated. + + This document also describes the Diffie-Hellman key exchange method + and the minimal set of algorithms that are needed to implement the + SSH transport layer protocol. + +Table of Contents + + 1. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3. Conventions Used in This Document . . . . . . . . . . . . . 3 + 4. Connection Setup . . . . . . . . . . . . . . . . . . . . . . 3 + 4.1 Use over TCP/IP . . . . . . . . . . . . . . . . . . . . . . 4 + 4.2 Protocol Version Exchange . . . . . . . . . . . . . . . . . 4 + 4.3 Compatibility With Old SSH Versions . . . . . . . . . . . . 4 + 4.3.1 Old Client, New Server . . . . . . . . . . . . . . . . . . . 5 + 4.3.2 New Client, Old Server . . . . . . . . . . . . . . . . . . . 5 + 5. Binary Packet Protocol . . . . . . . . . . . . . . . . . . . 5 + 5.1 Maximum Packet Length . . . . . . . . . . . . . . . . . . . 6 + 5.2 Compression . . . . . . . . . . . . . . . . . . . . . . . . 7 + 5.3 Encryption . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 5.4 Data Integrity . . . . . . . . . . . . . . . . . . . . . . . 9 + 5.5 Key Exchange Methods . . . . . . . . . . . . . . . . . . . . 10 + 5.6 Public Key Algorithms . . . . . . . . . . . . . . . . . . . 11 + 6. Key Exchange . . . . . . . . . . . . . . . . . . . . . . . . 13 + 6.1 Algorithm Negotiation . . . . . . . . . . . . . . . . . . . 13 + 6.2 Output from Key Exchange . . . . . . . . . . . . . . . . . . 16 + 6.3 Taking Keys Into Use . . . . . . . . . . . . . . . . . . . . 17 + 7. Diffie-Hellman Key Exchange . . . . . . . . . . . . . . . . 18 + 7.1 diffie-hellman-group1-sha1 . . . . . . . . . . . . . . . . . 19 + 8. Key Re-Exchange . . . . . . . . . . . . . . . . . . . . . . 20 + 9. Service Request . . . . . . . . . . . . . . . . . . . . . . 21 + 10. Additional Messages . . . . . . . . . . . . . . . . . . . . 21 + 10.1 Disconnection Message . . . . . . . . . . . . . . . . . . . 22 + 10.2 Ignored Data Message . . . . . . . . . . . . . . . . . . . . 22 + 10.3 Debug Message . . . . . . . . . . . . . . . . . . . . . . . 23 + 10.4 Reserved Messages . . . . . . . . . . . . . . . . . . . . . 23 + 11. Summary of Message Numbers . . . . . . . . . . . . . . . . . 23 + 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 24 + 13. Security Considerations . . . . . . . . . . . . . . . . . . 24 + 14. Intellectual Property . . . . . . . . . . . . . . . . . . . 24 + 15. Additional Information . . . . . . . . . . . . . . . . . . . 24 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 26 + Normative . . . . . . . . . . . . . . . . . . . . . . . . . 25 + Informative . . . . . . . . . . . . . . . . . . . . . . . . 25 + A. Contibutors . . . . . . . . . . . . . . . . . . . . . . . . 27 + Intellectual Property and Copyright Statements . . . . . . . 28 + + + + +Ylonen & Moffat, Editor Expires March 31, 2004 [Page 2] + +Internet-Draft SSH Transport Layer Protocol Oct 2003 + + +1. Contributors + + The major original contributors of this document were: Tatu Ylonen, + Tero Kivinen, Timo J. Rinne, Sami Lehtinen (all of SSH Communications + Security Corp), and Markku-Juhani O. Saarinen (University of + Jyvaskyla) + + The document editor is: [email protected]. Comments on this + internet draft should be sent to the IETF SECSH working group, + details at: http://ietf.org/html.charters/secsh-charter.html + +2. Introduction + + The SSH transport layer is a secure low level transport protocol. It + provides strong encryption, cryptographic host authentication, and + integrity protection. + + Authentication in this protocol level is host-based; this protocol + does not perform user authentication. A higher level protocol for + user authentication can be designed on top of this protocol. + + The protocol has been designed to be simple, flexible, to allow + parameter negotiation, and to minimize the number of round-trips. + Key exchange method, public key algorithm, symmetric encryption + algorithm, message authentication algorithm, and hash algorithm are + all negotiated. It is expected that in most environments, only 2 + round-trips will be needed for full key exchange, server + authentication, service request, and acceptance notification of + service request. The worst case is 3 round-trips. + +3. Conventions Used in This Document + + The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", + and "MAY" that appear in this document are to be interpreted as + described in [RFC2119]. + + The used data types and terminology are specified in the architecture + document [SSH-ARCH]. + + The architecture document also discusses the algorithm naming + conventions that MUST be used with the SSH protocols. + +4. Connection Setup + + SSH works over any 8-bit clean, binary-transparent transport. The + underlying transport SHOULD protect against transmission errors as + such errors cause the SSH connection to terminate. + + + + +Ylonen & Moffat, Editor Expires March 31, 2004 [Page 3] + +Internet-Draft SSH Transport Layer Protocol Oct 2003 + + + The client initiates the connection. + +4.1 Use over TCP/IP + + When used over TCP/IP, the server normally listens for connections on + port 22. This port number has been registered with the IANA, and has + been officially assigned for SSH. + +4.2 Protocol Version Exchange + + When the connection has been established, both sides MUST send an + identification string of the form "SSH-protoversion-softwareversion + comments", followed by carriage return and newline characters (ASCII + 13 and 10, respectively). Both sides MUST be able to process + identification strings without carriage return character. No null + character is sent. The maximum length of the string is 255 + characters, including the carriage return and newline. + + The part of the identification string preceding carriage return and + newline is used in the Diffie-Hellman key exchange (see Section + Section 7). + + The server MAY send other lines of data before sending the version + string. Each line SHOULD be terminated by a carriage return and + newline. Such lines MUST NOT begin with "SSH-", and SHOULD be + encoded in ISO-10646 UTF-8 [RFC2279] (language is not specified). + Clients MUST be able to process such lines; they MAY be silently + ignored, or MAY be displayed to the client user; if they are + displayed, control character filtering discussed in [SSH-ARCH] SHOULD + be used. The primary use of this feature is to allow TCP-wrappers to + display an error message before disconnecting. + + Version strings MUST consist of printable US-ASCII characters, not + including whitespaces or a minus sign (-). The version string is + primarily used to trigger compatibility extensions and to indicate + the capabilities of an implementation. The comment string should + contain additional information that might be useful in solving user + problems. + + The protocol version described in this document is 2.0. + + Key exchange will begin immediately after sending this identifier. + All packets following the identification string SHALL use the binary + packet protocol, to be described below. + +4.3 Compatibility With Old SSH Versions + + During the transition period, it is important to be able to work in a + + + +Ylonen & Moffat, Editor Expires March 31, 2004 [Page 4] + +Internet-Draft SSH Transport Layer Protocol Oct 2003 + + + way that is compatible with the installed SSH clients and servers + that use an older version of the protocol. Information in this + section is only relevant for implementations supporting compatibility + with SSH versions 1.x. There is no standards track or informational + draft available that defines the SSH 1.x protocol. The only known + documentation of the 1.x protocol is contained in README files that + are shipped along with the source code. + +4.3.1 Old Client, New Server + + Server implementations MAY support a configurable "compatibility" + flag that enables compatibility with old versions. When this flag is + on, the server SHOULD identify its protocol version as "1.99". + Clients using protocol 2.0 MUST be able to identify this as identical + to "2.0". In this mode the server SHOULD NOT send the carriage + return character (ASCII 13) after the version identification string. + + In the compatibility mode the server SHOULD NOT send any further data + after its initialization string until it has received an + identification string from the client. The server can then determine + whether the client is using an old protocol, and can revert to the + old protocol if required. In the compatibility mode, the server MUST + NOT send additional data before the version string. + + When compatibility with old clients is not needed, the server MAY + send its initial key exchange data immediately after the + identification string. + +4.3.2 New Client, Old Server + + Since the new client MAY immediately send additional data after its + identification string (before receiving server's identification), the + old protocol may already have been corrupted when the client learns + that the server is old. When this happens, the client SHOULD close + the connection to the server, and reconnect using the old protocol. + +5. Binary Packet Protocol + + Each packet is in the following format: + + uint32 packet_length + byte padding_length + byte[n1] payload; n1 = packet_length - padding_length - 1 + byte[n2] random padding; n2 = padding_length + byte[m] mac (message authentication code); m = mac_length + + packet_length + + + + +Ylonen & Moffat, Editor Expires March 31, 2004 [Page 5] + +Internet-Draft SSH Transport Layer Protocol Oct 2003 + + + The length of the packet (bytes), not including MAC or the + packet_length field itself. + + padding_length + Length of padding (bytes). + + payload + The useful contents of the packet. If compression has been + negotiated, this field is compressed. Initially, compression + MUST be "none". + + random padding + Arbitrary-length padding, such that the total length of + (packet_length || padding_length || payload || padding) is a + multiple of the cipher block size or 8, whichever is larger. + There MUST be at least four bytes of padding. The padding + SHOULD consist of random bytes. The maximum amount of padding + is 255 bytes. + + mac + Message authentication code. If message authentication has + been negotiated, this field contains the MAC bytes. Initially, + the MAC algorithm MUST be "none". + + + Note that length of the concatenation of packet length, padding + length, payload, and padding MUST be a multiple of the cipher block + size or 8, whichever is larger. This constraint MUST be enforced + even when using stream ciphers. Note that the packet length field is + also encrypted, and processing it requires special care when sending + or receiving packets. + + The minimum size of a packet is 16 (or the cipher block size, + whichever is larger) bytes (plus MAC); implementations SHOULD decrypt + the length after receiving the first 8 (or cipher block size, + whichever is larger) bytes of a packet. + +5.1 Maximum Packet Length + + All implementations MUST be able to process packets with uncompressed + payload length of 32768 bytes or less and total packet size of 35000 + bytes or less (including length, padding length, payload, padding, + and MAC.). The maximum of 35000 bytes is an arbitrary chosen value + larger than uncompressed size. Implementations SHOULD support longer + packets, where they might be needed, e.g. if an implementation wants + to send a very large number of certificates. Such packets MAY be + sent if the version string indicates that the other party is able to + process them. However, implementations SHOULD check that the packet + + + +Ylonen & Moffat, Editor Expires March 31, 2004 [Page 6] + +Internet-Draft SSH Transport Layer Protocol Oct 2003 + + + length is reasonable for the implementation to avoid + denial-of-service and/or buffer overflow attacks. + +5.2 Compression + + If compression has been negotiated, the payload field (and only it) + will be compressed using the negotiated algorithm. The length field + and MAC will be computed from the compressed payload. Encryption will + be done after compression. + + Compression MAY be stateful, depending on the method. Compression + MUST be independent for each direction, and implementations MUST + allow independently choosing the algorithm for each direction. + + The following compression methods are currently defined: + + none REQUIRED no compression + zlib OPTIONAL ZLIB (LZ77) compression + + The "zlib" compression is described in [RFC1950] and in [RFC1951]. + The compression context is initialized after each key exchange, and + is passed from one packet to the next with only a partial flush being + performed at the end of each packet. A partial flush means that the + current compressed block is ended and all data will be output. If the + current block is not a stored block, one or more empty blocks are + added after the current block to ensure that there are at least 8 + bits counting from the start of the end-of-block code of the current + block to the end of the packet payload. + + Additional methods may be defined as specified in [SSH-ARCH]. + +5.3 Encryption + + An encryption algorithm and a key will be negotiated during the key + exchange. When encryption is in effect, the packet length, padding + length, payload and padding fields of each packet MUST be encrypted + with the given algorithm. + + The encrypted data in all packets sent in one direction SHOULD be + considered a single data stream. For example, initialization vectors + SHOULD be passed from the end of one packet to the beginning of the + next packet. All ciphers SHOULD use keys with an effective key length + of 128 bits or more. + + The ciphers in each direction MUST run independently of each other, + and implementations MUST allow independently choosing the algorithm + for each direction (if multiple algorithms are allowed by local + policy). + + + +Ylonen & Moffat, Editor Expires March 31, 2004 [Page 7] + +Internet-Draft SSH Transport Layer Protocol Oct 2003 + + + The following ciphers are currently defined: + + 3des-cbc REQUIRED three-key 3DES in CBC mode + blowfish-cbc OPTIONALi Blowfish in CBC mode + twofish256-cbc OPTIONAL Twofish in CBC mode, + with 256-bit key + twofish-cbc OPTIONAL alias for "twofish256-cbc" (this + is being retained for + historical reasons) + twofish192-cbc OPTIONAL Twofish with 192-bit key + twofish128-cbc OPTIONAL Twofish with 128-bit key + aes256-cbc OPTIONAL AES (Rijndael) in CBC mode, + with 256-bit key + aes192-cbc OPTIONAL AES with 192-bit key + aes128-cbc RECOMMENDED AES with 128-bit key + serpent256-cbc OPTIONAL Serpent in CBC mode, with + 256-bit key + serpent192-cbc OPTIONAL Serpent with 192-bit key + serpent128-cbc OPTIONAL Serpent with 128-bit key + arcfour OPTIONAL the ARCFOUR stream cipher + idea-cbc OPTIONAL IDEA in CBC mode + cast128-cbc OPTIONAL CAST-128 in CBC mode + none OPTIONAL no encryption; NOT RECOMMENDED + + The "3des-cbc" cipher is three-key triple-DES + (encrypt-decrypt-encrypt), where the first 8 bytes of the key are + used for the first encryption, the next 8 bytes for the decryption, + and the following 8 bytes for the final encryption. This requires 24 + bytes of key data (of which 168 bits are actually used). To + implement CBC mode, outer chaining MUST be used (i.e., there is only + one initialization vector). This is a block cipher with 8 byte + blocks. This algorithm is defined in [FIPS-46-3] + + The "blowfish-cbc" cipher is Blowfish in CBC mode, with 128 bit keys + [SCHNEIER]. This is a block cipher with 8 byte blocks. + + The "twofish-cbc" or "twofish256-cbc" cipher is Twofish in CBC mode, + with 256 bit keys as described [TWOFISH]. This is a block cipher with + 16 byte blocks. + + The "twofish192-cbc" cipher. Same as above but with 192-bit key. + + The "twofish128-cbc" cipher. Same as above but with 128-bit key. + + The "aes256-cbc" cipher is AES (Advanced Encryption Standard) + [FIPS-197], formerly Rijndael, in CBC mode. This version uses 256-bit + key. + + + + +Ylonen & Moffat, Editor Expires March 31, 2004 [Page 8] + +Internet-Draft SSH Transport Layer Protocol Oct 2003 + + + The "aes192-cbc" cipher. Same as above but with 192-bit key. + + The "aes128-cbc" cipher. Same as above but with 128-bit key. + + The "serpent256-cbc" cipher in CBC mode, with 256-bit key as + described in the Serpent AES submission. + + The "serpent192-cbc" cipher. Same as above but with 192-bit key. + + The "serpent128-cbc" cipher. Same as above but with 128-bit key. + + The "arcfour" is the Arcfour stream cipher with 128 bit keys. The + Arcfour cipher is believed to be compatible with the RC4 cipher + [SCHNEIER]. RC4 is a registered trademark of RSA Data Security Inc. + Arcfour (and RC4) has problems with weak keys, and should be used + with caution. + + The "idea-cbc" cipher is the IDEA cipher in CBC mode [SCHNEIER]. + + The "cast128-cbc" cipher is the CAST-128 cipher in CBC mode + [RFC2144]. + + The "none" algorithm specifies that no encryption is to be done. + Note that this method provides no confidentiality protection, and it + is not recommended. Some functionality (e.g. password + authentication) may be disabled for security reasons if this cipher + is chosen. + + Additional methods may be defined as specified in [SSH-ARCH]. + +5.4 Data Integrity + + Data integrity is protected by including with each packet a message + authentication code (MAC) that is computed from a shared secret, + packet sequence number, and the contents of the packet. + + The message authentication algorithm and key are negotiated during + key exchange. Initially, no MAC will be in effect, and its length + MUST be zero. After key exchange, the selected MAC will be computed + before encryption from the concatenation of packet data: + + mac = MAC(key, sequence_number || unencrypted_packet) + + where unencrypted_packet is the entire packet without MAC (the length + fields, payload and padding), and sequence_number is an implicit + packet sequence number represented as uint32. The sequence number is + initialized to zero for the first packet, and is incremented after + every packet (regardless of whether encryption or MAC is in use). It + + + +Ylonen & Moffat, Editor Expires March 31, 2004 [Page 9] + +Internet-Draft SSH Transport Layer Protocol Oct 2003 + + + is never reset, even if keys/algorithms are renegotiated later. It + wraps around to zero after every 2^32 packets. The packet sequence + number itself is not included in the packet sent over the wire. + + The MAC algorithms for each direction MUST run independently, and + implementations MUST allow choosing the algorithm independently for + both directions. + + The MAC bytes resulting from the MAC algorithm MUST be transmitted + without encryption as the last part of the packet. The number of MAC + bytes depends on the algorithm chosen. + + The following MAC algorithms are currently defined: + + hmac-sha1 REQUIRED HMAC-SHA1 (digest length = key + length = 20) + hmac-sha1-96 RECOMMENDED first 96 bits of HMAC-SHA1 (digest + length = 12, key length = 20) + hmac-md5 OPTIONAL HMAC-MD5 (digest length = key + length = 16) + hmac-md5-96 OPTIONAL first 96 bits of HMAC-MD5 (digest + length = 12, key length = 16) + none OPTIONAL no MAC; NOT RECOMMENDED + + Figure 1 + + The "hmac-*" algorithms are described in [RFC2104] The "*-n" MACs use + only the first n bits of the resulting value. + + The hash algorithms are described in [SCHNEIER]. + + Additional methods may be defined as specified in [SSH-ARCH]. + +5.5 Key Exchange Methods + + The key exchange method specifies how one-time session keys are + generated for encryption and for authentication, and how the server + authentication is done. + + Only one REQUIRED key exchange method has been defined: + + diffie-hellman-group1-sha1 REQUIRED + + This method is described later in this document. + + Additional methods may be defined as specified in [SSH-ARCH]. + + + + + +Ylonen & Moffat, Editor Expires March 31, 2004 [Page 10] + +Internet-Draft SSH Transport Layer Protocol Oct 2003 + + +5.6 Public Key Algorithms + + This protocol has been designed to be able to operate with almost any + public key format, encoding, and algorithm (signature and/or + encryption). + + There are several aspects that define a public key type: + o Key format: how is the key encoded and how are certificates + represented. The key blobs in this protocol MAY contain + certificates in addition to keys. + o Signature and/or encryption algorithms. Some key types may not + support both signing and encryption. Key usage may also be + restricted by policy statements in e.g. certificates. In this + case, different key types SHOULD be defined for the different + policy alternatives. + o Encoding of signatures and/or encrypted data. This includes but is + not limited to padding, byte order, and data formats. + + The following public key and/or certificate formats are currently defined: + + ssh-dss REQUIRED sign Raw DSS Key + ssh-rsa RECOMMENDED sign Raw RSA Key + x509v3-sign-rsa OPTIONAL sign X.509 certificates (RSA key) + x509v3-sign-dss OPTIONAL sign X.509 certificates (DSS key) + spki-sign-rsa OPTIONAL sign SPKI certificates (RSA key) + spki-sign-dss OPTIONAL sign SPKI certificates (DSS key) + pgp-sign-rsa OPTIONAL sign OpenPGP certificates (RSA key) + pgp-sign-dss OPTIONAL sign OpenPGP certificates (DSS key) + + Additional key types may be defined as specified in [SSH-ARCH]. + + The key type MUST always be explicitly known (from algorithm + negotiation or some other source). It is not normally included in + the key blob. + + Certificates and public keys are encoded as follows: + + string certificate or public key format identifier + byte[n] key/certificate data + + The certificate part may have be a zero length string, but a public + key is required. This is the public key that will be used for + authentication; the certificate sequence contained in the certificate + blob can be used to provide authorization. + + Public key / certifcate formats that do not explicitly specify a + signature format identifier MUST use the public key / certificate + format identifier as the signature identifier. + + + +Ylonen & Moffat, Editor Expires March 31, 2004 [Page 11] + +Internet-Draft SSH Transport Layer Protocol Oct 2003 + + + Signatures are encoded as follows: + string signature format identifier (as specified by the + public key / cert format) + byte[n] signature blob in format specific encoding. + + + The "ssh-dss" key format has the following specific encoding: + + string "ssh-dss" + mpint p + mpint q + mpint g + mpint y + + Here the p, q, g, and y parameters form the signature key blob. + + Signing and verifying using this key format is done according to the + Digital Signature Standard [FIPS-186] using the SHA-1 hash. A + description can also be found in [SCHNEIER]. + + The resulting signature is encoded as follows: + + string "ssh-dss" + string dss_signature_blob + + dss_signature_blob is encoded as a string containing r followed by s + (which are 160 bits long integers, without lengths or padding, + unsigned and in network byte order). + + The "ssh-rsa" key format has the following specific encoding: + + string "ssh-rsa" + mpint e + mpint n + + Here the e and n parameters form the signature key blob. + + Signing and verifying using this key format is done according to + [SCHNEIER] and [PKCS1] using the SHA-1 hash. + + The resulting signature is encoded as follows: + + string "ssh-rsa" + string rsa_signature_blob + + rsa_signature_blob is encoded as a string containing s (which is an + integer, without lengths or padding, unsigned and in network byte + order). + + + +Ylonen & Moffat, Editor Expires March 31, 2004 [Page 12] + +Internet-Draft SSH Transport Layer Protocol Oct 2003 + + + The "spki-sign-rsa" method indicates that the certificate blob + contains a sequence of SPKI certificates. The format of SPKI + certificates is described in [RFC2693]. This method indicates that + the key (or one of the keys in the certificate) is an RSA-key. + + The "spki-sign-dss". As above, but indicates that the key (or one of + the keys in the certificate) is a DSS-key. + + The "pgp-sign-rsa" method indicates the certificates, the public key, + and the signature are in OpenPGP compatible binary format + ([RFC2440]). This method indicates that the key is an RSA-key. + + The "pgp-sign-dss". As above, but indicates that the key is a + DSS-key. + +6. Key Exchange + + Key exchange begins by each side sending lists of supported + algorithms. Each side has a preferred algorithm in each category, and + it is assumed that most implementations at any given time will use + the same preferred algorithm. Each side MAY guess which algorithm + the other side is using, and MAY send an initial key exchange packet + according to the algorithm if appropriate for the preferred method. + + Guess is considered wrong, if: + o the kex algorithm and/or the host key algorithm is guessed wrong + (server and client have different preferred algorithm), or + o if any of the other algorithms cannot be agreed upon (the + procedure is defined below in Section Section 6.1). + + Otherwise, the guess is considered to be right and the optimistically + sent packet MUST be handled as the first key exchange packet. + + However, if the guess was wrong, and a packet was optimistically sent + by one or both parties, such packets MUST be ignored (even if the + error in the guess would not affect the contents of the initial + packet(s)), and the appropriate side MUST send the correct initial + packet. + + Server authentication in the key exchange MAY be implicit. After a + key exchange with implicit server authentication, the client MUST + wait for response to its service request message before sending any + further data. + +6.1 Algorithm Negotiation + + Key exchange begins by each side sending the following packet: + + + + +Ylonen & Moffat, Editor Expires March 31, 2004 [Page 13] + +Internet-Draft SSH Transport Layer Protocol Oct 2003 + + + byte SSH_MSG_KEXINIT + byte[16] cookie (random bytes) + string kex_algorithms + string server_host_key_algorithms + string encryption_algorithms_client_to_server + string encryption_algorithms_server_to_client + string mac_algorithms_client_to_server + string mac_algorithms_server_to_client + string compression_algorithms_client_to_server + string compression_algorithms_server_to_client + string languages_client_to_server + string languages_server_to_client + boolean first_kex_packet_follows + uint32 0 (reserved for future extension) + + Each of the algorithm strings MUST be a comma-separated list of + algorithm names (see ''Algorithm Naming'' in [SSH-ARCH]). Each + supported (allowed) algorithm MUST be listed in order of preference. + + The first algorithm in each list MUST be the preferred (guessed) + algorithm. Each string MUST contain at least one algorithm name. + + + cookie + The cookie MUST be a random value generated by the sender. Its + purpose is to make it impossible for either side to fully + determine the keys and the session identifier. + + kex_algorithms + Key exchange algorithms were defined above. The first + algorithm MUST be the preferred (and guessed) algorithm. If + both sides make the same guess, that algorithm MUST be used. + Otherwise, the following algorithm MUST be used to choose a key + exchange method: iterate over client's kex algorithms, one at a + time. Choose the first algorithm that satisfies the following + conditions: + + the server also supports the algorithm, + + if the algorithm requires an encryption-capable host key, + there is an encryption-capable algorithm on the server's + server_host_key_algorithms that is also supported by the + client, and + + if the algorithm requires a signature-capable host key, + there is a signature-capable algorithm on the server's + server_host_key_algorithms that is also supported by the + client. + + If no algorithm satisfying all these conditions can be + found, the connection fails, and both sides MUST disconnect. + + + + +Ylonen & Moffat, Editor Expires March 31, 2004 [Page 14] + +Internet-Draft SSH Transport Layer Protocol Oct 2003 + + + server_host_key_algorithms + List of the algorithms supported for the server host key. The + server lists the algorithms for which it has host keys; the + client lists the algorithms that it is willing to accept. + (There MAY be multiple host keys for a host, possibly with + different algorithms.) + + Some host keys may not support both signatures and encryption + (this can be determined from the algorithm), and thus not all + host keys are valid for all key exchange methods. + + Algorithm selection depends on whether the chosen key exchange + algorithm requires a signature or encryption capable host key. + It MUST be possible to determine this from the public key + algorithm name. The first algorithm on the client's list that + satisfies the requirements and is also supported by the server + MUST be chosen. If there is no such algorithm, both sides MUST + disconnect. + + encryption_algorithms + Lists the acceptable symmetric encryption algorithms in order + of preference. The chosen encryption algorithm to each + direction MUST be the first algorithm on the client's list + that is also on the server's list. If there is no such + algorithm, both sides MUST disconnect. + + Note that "none" must be explicitly listed if it is to be + acceptable. The defined algorithm names are listed in Section + Section 5.3. + + mac_algorithms + Lists the acceptable MAC algorithms in order of preference. + The chosen MAC algorithm MUST be the first algorithm on the + client's list that is also on the server's list. If there is + no such algorithm, both sides MUST disconnect. + + Note that "none" must be explicitly listed if it is to be + acceptable. The MAC algorithm names are listed in Section + Figure 1. + + compression_algorithms + Lists the acceptable compression algorithms in order of + preference. The chosen compression algorithm MUST be the first + algorithm on the client's list that is also on the server's + list. If there is no such algorithm, both sides MUST + disconnect. + + + + + +Ylonen & Moffat, Editor Expires March 31, 2004 [Page 15] + +Internet-Draft SSH Transport Layer Protocol Oct 2003 + + + Note that "none" must be explicitly listed if it is to be + acceptable. The compression algorithm names are listed in + Section Section 5.2. + + languages + This is a comma-separated list of language tags in order of + preference [RFC3066]. Both parties MAY ignore this list. If + there are no language preferences, this list SHOULD be empty. + Language tags SHOULD NOT be present unless they are known to be + needed by the sending party. + + first_kex_packet_follows + Indicates whether a guessed key exchange packet follows. If a + guessed packet will be sent, this MUST be TRUE. If no guessed + packet will be sent, this MUST be FALSE. + + After receiving the SSH_MSG_KEXINIT packet from the other side, + each party will know whether their guess was right. If the + other party's guess was wrong, and this field was TRUE, the + next packet MUST be silently ignored, and both sides MUST then + act as determined by the negotiated key exchange method. If + the guess was right, key exchange MUST continue using the + guessed packet. + + After the KEXINIT packet exchange, the key exchange algorithm is run. + It may involve several packet exchanges, as specified by the key + exchange method. + +6.2 Output from Key Exchange + + The key exchange produces two values: a shared secret K, and an + exchange hash H. Encryption and authentication keys are derived from + these. The exchange hash H from the first key exchange is + additionally used as the session identifier, which is a unique + identifier for this connection. It is used by authentication methods + as a part of the data that is signed as a proof of possession of a + private key. Once computed, the session identifier is not changed, + even if keys are later re-exchanged. + + + Each key exchange method specifies a hash function that is used in + the key exchange. The same hash algorithm MUST be used in key + derivation. Here, we'll call it HASH. + + + Encryption keys MUST be computed as HASH of a known value and K as + follows: + + + + +Ylonen & Moffat, Editor Expires March 31, 2004 [Page 16] + +Internet-Draft SSH Transport Layer Protocol Oct 2003 + + + o Initial IV client to server: HASH(K || H || "A" || session_id) + (Here K is encoded as mpint and "A" as byte and session_id as raw + data."A" means the single character A, ASCII 65). + o Initial IV server to client: HASH(K || H || "B" || session_id) + o Encryption key client to server: HASH(K || H || "C" || session_id) + o Encryption key server to client: HASH(K || H || "D" || session_id) + o Integrity key client to server: HASH(K || H || "E" || session_id) + o Integrity key server to client: HASH(K || H || "F" || session_id) + + Key data MUST be taken from the beginning of the hash output. 128 + bits (16 bytes) MUST be used for algorithms with variable-length + keys. The only variable key length algorithm defined in this document + is arcfour). For other algorithms, as many bytes as are needed are + taken from the beginning of the hash value. If the key length needed + is longer than the output of the HASH, the key is extended by + computing HASH of the concatenation of K and H and the entire key so + far, and appending the resulting bytes (as many as HASH generates) to + the key. This process is repeated until enough key material is + available; the key is taken from the beginning of this value. In + other words: + + K1 = HASH(K || H || X || session_id) (X is e.g. "A") + K2 = HASH(K || H || K1) + K3 = HASH(K || H || K1 || K2) + ... + key = K1 || K2 || K3 || ... + + This process will lose entropy if the amount of entropy in K is + larger than the internal state size of HASH. + +6.3 Taking Keys Into Use + + Key exchange ends by each side sending an SSH_MSG_NEWKEYS message. + This message is sent with the old keys and algorithms. All messages + sent after this message MUST use the new keys and algorithms. + + + When this message is received, the new keys and algorithms MUST be + taken into use for receiving. + + + This message is the only valid message after key exchange, in + addition to SSH_MSG_DEBUG, SSH_MSG_DISCONNECT and SSH_MSG_IGNORE + messages. The purpose of this message is to ensure that a party is + able to respond with a disconnect message that the other party can + understand if something goes wrong with the key exchange. + Implementations MUST NOT accept any other messages after key exchange + before receiving SSH_MSG_NEWKEYS. + + + +Ylonen & Moffat, Editor Expires March 31, 2004 [Page 17] + +Internet-Draft SSH Transport Layer Protocol Oct 2003 + + + byte SSH_MSG_NEWKEYS + + +7. Diffie-Hellman Key Exchange + + The Diffie-Hellman key exchange provides a shared secret that can not + be determined by either party alone. The key exchange is combined + with a signature with the host key to provide host authentication. + + + In the following description (C is the client, S is the server; p is + a large safe prime, g is a generator for a subgroup of GF(p), and q + is the order of the subgroup; V_S is S's version string; V_C is C's + version string; K_S is S's public host key; I_C is C's KEXINIT + message and I_S S's KEXINIT message which have been exchanged before + this part begins): + + + 1. C generates a random number x (1 < x < q) and computes e = g^x + mod p. C sends "e" to S. + + 2. S generates a random number y (0 < y < q) and computes f = g^y + mod p. S receives "e". It computes K = e^y mod p, H = hash(V_C + || V_S || I_C || I_S || K_S || e || f || K) (these elements are + encoded according to their types; see below), and signature s on + H with its private host key. S sends "K_S || f || s" to C. The + signing operation may involve a second hashing operation. + + 3. C verifies that K_S really is the host key for S (e.g. using + certificates or a local database). C is also allowed to accept + the key without verification; however, doing so will render the + protocol insecure against active attacks (but may be desirable + for practical reasons in the short term in many environments). C + then computes K = f^x mod p, H = hash(V_C || V_S || I_C || I_S || + K_S || e || f || K), and verifies the signature s on H. + + Either side MUST NOT send or accept e or f values that are not in the + range [1, p-1]. If this condition is violated, the key exchange + fails. + + + This is implemented with the following messages. The hash algorithm + for computing the exchange hash is defined by the method name, and is + called HASH. The public key algorithm for signing is negotiated with + the KEXINIT messages. + + First, the client sends the following: + + + + +Ylonen & Moffat, Editor Expires March 31, 2004 [Page 18] + +Internet-Draft SSH Transport Layer Protocol Oct 2003 + + + byte SSH_MSG_KEXDH_INIT + mpint e + + + The server responds with the following: + + byte SSH_MSG_KEXDH_REPLY + string server public host key and certificates (K_S) + mpint f + string signature of H + + The hash H is computed as the HASH hash of the concatenation of the + following: + + string V_C, the client's version string (CR and NL excluded) + string V_S, the server's version string (CR and NL excluded) + string I_C, the payload of the client's SSH_MSG_KEXINIT + string I_S, the payload of the server's SSH_MSG_KEXINIT + string K_S, the host key + mpint e, exchange value sent by the client + mpint f, exchange value sent by the server + mpint K, the shared secret + + This value is called the exchange hash, and it is used to + authenticate the key exchange. The exchange hash SHOULD be kept + secret. + + + The signature algorithm MUST be applied over H, not the original + data. Most signature algorithms include hashing and additional + padding. For example, "ssh-dss" specifies SHA-1 hashing; in that + case, the data is first hashed with HASH to compute H, and H is then + hashed with SHA-1 as part of the signing operation. + +7.1 diffie-hellman-group1-sha1 + + The "diffie-hellman-group1-sha1" method specifies Diffie-Hellman key + exchange with SHA-1 as HASH, and Oakley group 14 [RFC3526] (2048-bit + MODP Group). It is included below in hexadecimal and decimal. + + The prime p is equal to 2^1024 - 2^960 - 1 + 2^64 * floor( 2^894 Pi + + 129093 ). Its hexadecimal value is: + + FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 + 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD + EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 + E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED + EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381 + + + +Ylonen & Moffat, Editor Expires March 31, 2004 [Page 19] + +Internet-Draft SSH Transport Layer Protocol Oct 2003 + + + FFFFFFFF FFFFFFFF. + + In decimal, this value is: + + 179769313486231590770839156793787453197860296048756011706444 + 423684197180216158519368947833795864925541502180565485980503 + 646440548199239100050792877003355816639229553136239076508735 + 759914822574862575007425302077447712589550957937778424442426 + 617334727629299387668709205606050270810842907692932019128194 + 467627007. + + The generator used with this prime is g = 2. The group order q is (p + - 1) / 2. + +8. Key Re-Exchange + + Key re-exchange is started by sending an SSH_MSG_KEXINIT packet when + not already doing a key exchange (as described in Section Section + 6.1). When this message is received, a party MUST respond with its + own SSH_MSG_KEXINIT message except when the received SSH_MSG_KEXINIT + already was a reply. Either party MAY initiate the re-exchange, but + roles MUST NOT be changed (i.e., the server remains the server, and + the client remains the client). + + + Key re-exchange is performed using whatever encryption was in effect + when the exchange was started. Encryption, compression, and MAC + methods are not changed before a new SSH_MSG_NEWKEYS is sent after + the key exchange (as in the initial key exchange). Re-exchange is + processed identically to the initial key exchange, except for the + session identifier that will remain unchanged. It is permissible to + change some or all of the algorithms during the re-exchange. Host + keys can also change. All keys and initialization vectors are + recomputed after the exchange. Compression and encryption contexts + are reset. + + + It is recommended that the keys are changed after each gigabyte of + transmitted data or after each hour of connection time, whichever + comes sooner. However, since the re-exchange is a public key + operation, it requires a fair amount of processing power and should + not be performed too often. + + + More application data may be sent after the SSH_MSG_NEWKEYS packet + has been sent; key exchange does not affect the protocols that lie + above the SSH transport layer. + + + + +Ylonen & Moffat, Editor Expires March 31, 2004 [Page 20] + +Internet-Draft SSH Transport Layer Protocol Oct 2003 + + +9. Service Request + + After the key exchange, the client requests a service. The service is + identified by a name. The format of names and procedures for defining + new names are defined in [SSH-ARCH]. + + + Currently, the following names have been reserved: + + ssh-userauth + ssh-connection + + Similar local naming policy is applied to the service names, as is + applied to the algorithm names; a local service should use the + "servicename@domain" syntax. + + byte SSH_MSG_SERVICE_REQUEST + string service name + + If the server rejects the service request, it SHOULD send an + appropriate SSH_MSG_DISCONNECT message and MUST disconnect. + + + When the service starts, it may have access to the session identifier + generated during the key exchange. + + + If the server supports the service (and permits the client to use + it), it MUST respond with the following: + + byte SSH_MSG_SERVICE_ACCEPT + string service name + + Message numbers used by services should be in the area reserved for + them (see Section 6 in [SSH-ARCH]). The transport level will + continue to process its own messages. + + + Note that after a key exchange with implicit server authentication, + the client MUST wait for response to its service request message + before sending any further data. + +10. Additional Messages + + Either party may send any of the following messages at any time. + + + + + + +Ylonen & Moffat, Editor Expires March 31, 2004 [Page 21] + +Internet-Draft SSH Transport Layer Protocol Oct 2003 + + +10.1 Disconnection Message + + byte SSH_MSG_DISCONNECT + uint32 reason code + string description [RFC2279] + string language tag [RFC3066] + + This message causes immediate termination of the connection. All + implementations MUST be able to process this message; they SHOULD be + able to send this message. + + The sender MUST NOT send or receive any data after this message, and + the recipient MUST NOT accept any data after receiving this message. + The description field gives a more specific explanation in a + human-readable form. The error code gives the reason in a more + machine-readable format (suitable for localization), and can have the + following values: + + #define SSH_DISCONNECT_HOST_NOT_ALLOWED_TO_CONNECT 1 + #define SSH_DISCONNECT_PROTOCOL_ERROR 2 + #define SSH_DISCONNECT_KEY_EXCHANGE_FAILED 3 + #define SSH_DISCONNECT_RESERVED 4 + #define SSH_DISCONNECT_MAC_ERROR 5 + #define SSH_DISCONNECT_COMPRESSION_ERROR 6 + #define SSH_DISCONNECT_SERVICE_NOT_AVAILABLE 7 + #define SSH_DISCONNECT_PROTOCOL_VERSION_NOT_SUPPORTED 8 + #define SSH_DISCONNECT_HOST_KEY_NOT_VERIFIABLE 9 + #define SSH_DISCONNECT_CONNECTION_LOST 10 + #define SSH_DISCONNECT_BY_APPLICATION 11 + #define SSH_DISCONNECT_TOO_MANY_CONNECTIONS 12 + #define SSH_DISCONNECT_AUTH_CANCELLED_BY_USER 13 + #define SSH_DISCONNECT_NO_MORE_AUTH_METHODS_AVAILABLE 14 + #define SSH_DISCONNECT_ILLEGAL_USER_NAME 15 + + If the description string is displayed, control character filtering + discussed in [SSH-ARCH] should be used to avoid attacks by sending + terminal control characters. + +10.2 Ignored Data Message + + byte SSH_MSG_IGNORE + string data + + All implementations MUST understand (and ignore) this message at any + time (after receiving the protocol version). No implementation is + required to send them. This message can be used as an additional + protection measure against advanced traffic analysis techniques. + + + + +Ylonen & Moffat, Editor Expires March 31, 2004 [Page 22] + +Internet-Draft SSH Transport Layer Protocol Oct 2003 + + +10.3 Debug Message + + byte SSH_MSG_DEBUG + boolean always_display + string message [RFC2279] + string language tag [RFC3066] + + All implementations MUST understand this message, but they are + allowed to ignore it. This message is used to pass the other side + information that may help debugging. If always_display is TRUE, the + message SHOULD be displayed. Otherwise, it SHOULD NOT be displayed + unless debugging information has been explicitly requested by the + user. + + + The message doesn't need to contain a newline. It is, however, + allowed to consist of multiple lines separated by CRLF (Carriage + Return - Line Feed) pairs. + + + If the message string is displayed, terminal control character + filtering discussed in [SSH-ARCH] should be used to avoid attacks by + sending terminal control characters. + +10.4 Reserved Messages + + An implementation MUST respond to all unrecognized messages with an + SSH_MSG_UNIMPLEMENTED message in the order in which the messages were + received. Such messages MUST be otherwise ignored. Later protocol + versions may define other meanings for these message types. + + byte SSH_MSG_UNIMPLEMENTED + uint32 packet sequence number of rejected message + + +11. Summary of Message Numbers + + The following message numbers have been defined in this protocol: + + #define SSH_MSG_DISCONNECT 1 + #define SSH_MSG_IGNORE 2 + #define SSH_MSG_UNIMPLEMENTED 3 + #define SSH_MSG_DEBUG 4 + #define SSH_MSG_SERVICE_REQUEST 5 + #define SSH_MSG_SERVICE_ACCEPT 6 + + #define SSH_MSG_KEXINIT 20 + #define SSH_MSG_NEWKEYS 21 + + + +Ylonen & Moffat, Editor Expires March 31, 2004 [Page 23] + +Internet-Draft SSH Transport Layer Protocol Oct 2003 + + + /* Numbers 30-49 used for kex packets. + Different kex methods may reuse message numbers in + this range. */ + + #define SSH_MSG_KEXDH_INIT 30 + #define SSH_MSG_KEXDH_REPLY 31 + + +12. IANA Considerations + + This document is part of a set, the IANA considerations for the SSH + protocol as defined in [SSH-ARCH], [SSH-TRANS], [SSH-USERAUTH], + [SSH-CONNECT] are detailed in [SSH-NUMBERS]. + +13. Security Considerations + + This protocol provides a secure encrypted channel over an insecure + network. It performs server host authentication, key exchange, + encryption, and integrity protection. It also derives a unique + session id that may be used by higher-level protocols. + + Full security considerations for this protocol are provided in + Section 8 of [SSH-ARCH] + +14. Intellectual Property + + The IETF takes no position regarding the validity or scope of any + intellectual property or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; neither does it represent that it + has made any effort to identify any such rights. Information on the + IETF's procedures with respect to rights in standards-track and + standards-related documentation can be found in BCP-11. Copies of + claims of rights made available for publication and any assurances of + licenses to be made available, or the result of an attempt made to + obtain a general license or permission for the use of such + proprietary rights by implementers or users of this specification can + be obtained from the IETF Secretariat. + + The IETF has been notified of intellectual property rights claimed in + regard to some or all of the specification contained in this + document. For more information consult the online list of claimed + rights. + +15. Additional Information + + The current document editor is: [email protected]. Comments on + + + +Ylonen & Moffat, Editor Expires March 31, 2004 [Page 24] + +Internet-Draft SSH Transport Layer Protocol Oct 2003 + + + this internet draft should be sent to the IETF SECSH working group, + details at: http://ietf.org/html.charters/secsh-charter.html + +Normative + + [SSH-ARCH] + Ylonen, T., "SSH Protocol Architecture", I-D + draft-ietf-architecture-15.txt, Oct 2003. + + [SSH-TRANS] + Ylonen, T., "SSH Transport Layer Protocol", I-D + draft-ietf-transport-17.txt, Oct 2003. + + [SSH-USERAUTH] + Ylonen, T., "SSH Authentication Protocol", I-D + draft-ietf-userauth-18.txt, Oct 2003. + + [SSH-CONNECT] + Ylonen, T., "SSH Connection Protocol", I-D + draft-ietf-connect-18.txt, Oct 2003. + + [SSH-NUMBERS] + Lehtinen, S. and D. Moffat, "SSH Protocol Assigned + Numbers", I-D draft-ietf-secsh-assignednumbers-05.txt, Oct + 2003. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + +Informative + + [FIPS-186] + Federal Information Processing Standards Publication, + "FIPS PUB 186, Digital Signature Standard", May 1994. + + [FIPS-197] + NIST, "FIPS PUB 197 Advanced Encryption Standard (AES)", + November 2001. + + [FIPS-46-3] + U.S. Dept. of Commerce, "FIPS PUB 46-3, Data Encryption + Standard (DES)", October 1999. + + [RFC2459] Housley, R., Ford, W., Polk, T. and D. Solo, "Internet + X.509 Public Key Infrastructure Certificate and CRL + Profile", RFC 2459, January 1999. + + [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", + + + +Ylonen & Moffat, Editor Expires March 31, 2004 [Page 25] + +Internet-Draft SSH Transport Layer Protocol Oct 2003 + + + STD 13, RFC 1034, November 1987. + + [RFC3066] Alvestrand, H., "Tags for the Identification of + Languages", BCP 47, RFC 3066, January 2001. + + [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format + Specification version 3.3", RFC 1950, May 1996. + + [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification + version 1.3", RFC 1951, May 1996. + + [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO + 10646", RFC 2279, January 1998. + + [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: + Keyed-Hashing for Message Authentication", RFC 2104, + February 1997. + + [RFC2144] Adams, C., "The CAST-128 Encryption Algorithm", RFC 2144, + May 1997. + + [RFC2440] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, + "OpenPGP Message Format", RFC 2440, November 1998. + + [RFC2693] Ellison, C., Frantz, B., Lampson, B., Rivest, R., Thomas, + B. and T. Ylonen, "SPKI Certificate Theory", RFC 2693, + September 1999. + + [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) + Diffie-Hellman groups for Internet Key Exchange (IKE)", + RFC 3526, May 2003. + + [SCHNEIER] + Schneier, B., "Applied Cryptography Second Edition: + protocols algorithms and source in code in C", 1996. + + [TWOFISH] Schneier, B., "The Twofish Encryptions Algorithm: A + 128-Bit Block Cipher, 1st Edition", March 1999. + + + + + + + + + + + + + +Ylonen & Moffat, Editor Expires March 31, 2004 [Page 26] + +Internet-Draft SSH Transport Layer Protocol Oct 2003 + + +Authors' Addresses + + Tatu Ylonen + SSH Communications Security Corp + Fredrikinkatu 42 + HELSINKI FIN-00100 + Finland + + EMail: [email protected] + + + Darren J. Moffat (editor) + Sun Microsystems, Inc + 17 Network Circle + Menlo Park 95025 + USA + + EMail: [email protected] + +Appendix A. Contibutors + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Ylonen & Moffat, Editor Expires March 31, 2004 [Page 27] + +Internet-Draft SSH Transport Layer Protocol Oct 2003 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + intellectual property or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; neither does it represent that it + has made any effort to identify any such rights. Information on the + IETF's procedures with respect to rights in standards-track and + standards-related documentation can be found in BCP-11. Copies of + claims of rights made available for publication and any assurances of + licenses to be made available, or the result of an attempt made to + obtain a general license or permission for the use of such + proprietary rights by implementors or users of this specification can + be obtained from the IETF Secretariat. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights which may cover technology that may be required to practice + this standard. Please address the information to the IETF Executive + Director. + + The IETF has been notified of intellectual property rights claimed in + regard to some or all of the specification contained in this + document. For more information consult the online list of claimed + rights. + + +Full Copyright Statement + + Copyright (C) The Internet Society (2003). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assignees. + + + +Ylonen & Moffat, Editor Expires March 31, 2004 [Page 28] + +Internet-Draft SSH Transport Layer Protocol Oct 2003 + + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Ylonen & Moffat, Editor Expires March 31, 2004 [Page 29]
\ No newline at end of file diff --git a/lib/ssh/doc/standard/draft-ietf-secsh-userauth-18.2.ps b/lib/ssh/doc/standard/draft-ietf-secsh-userauth-18.2.ps new file mode 100644 index 0000000000..be5799dbce --- /dev/null +++ b/lib/ssh/doc/standard/draft-ietf-secsh-userauth-18.2.ps @@ -0,0 +1,1881 @@ +%!PS-Adobe-3.0 +%%BoundingBox: 75 0 595 747 +%%Title: Enscript Output +%%For: Magnus Thoang +%%Creator: GNU enscript 1.6.1 +%%CreationDate: Fri Oct 31 13:35:32 2003 +%%Orientation: Portrait +%%Pages: 8 0 +%%DocumentMedia: A4 595 842 0 () () +%%DocumentNeededResources: (atend) +%%EndComments +%%BeginProlog +%%BeginProcSet: PStoPS 1 15 +userdict begin +[/showpage/erasepage/copypage]{dup where{pop dup load + type/operatortype eq{1 array cvx dup 0 3 index cvx put + bind def}{pop}ifelse}{pop}ifelse}forall +[/letter/legal/executivepage/a4/a4small/b5/com10envelope + /monarchenvelope/c5envelope/dlenvelope/lettersmall/note + /folio/quarto/a5]{dup where{dup wcheck{exch{}put} + {pop{}def}ifelse}{pop}ifelse}forall +/setpagedevice {pop}bind 1 index where{dup wcheck{3 1 roll put} + {pop def}ifelse}{def}ifelse +/PStoPSmatrix matrix currentmatrix def +/PStoPSxform matrix def/PStoPSclip{clippath}def +/defaultmatrix{PStoPSmatrix exch PStoPSxform exch concatmatrix}bind def +/initmatrix{matrix defaultmatrix setmatrix}bind def +/initclip[{matrix currentmatrix PStoPSmatrix setmatrix + [{currentpoint}stopped{$error/newerror false put{newpath}} + {/newpath cvx 3 1 roll/moveto cvx 4 array astore cvx}ifelse] + {[/newpath cvx{/moveto cvx}{/lineto cvx} + {/curveto cvx}{/closepath cvx}pathforall]cvx exch pop} + stopped{$error/errorname get/invalidaccess eq{cleartomark + $error/newerror false put cvx exec}{stop}ifelse}if}bind aload pop + /initclip dup load dup type dup/operatortype eq{pop exch pop} + {dup/arraytype eq exch/packedarraytype eq or + {dup xcheck{exch pop aload pop}{pop cvx}ifelse} + {pop cvx}ifelse}ifelse + {newpath PStoPSclip clip newpath exec setmatrix} bind aload pop]cvx def +/initgraphics{initmatrix newpath initclip 1 setlinewidth + 0 setlinecap 0 setlinejoin []0 setdash 0 setgray + 10 setmiterlimit}bind def +end +%%EndProcSet +%%BeginResource: procset Enscript-Prolog 1.6 1 +% +% Procedures. +% + +/_S { % save current state + /_s save def +} def +/_R { % restore from saved state + _s restore +} def + +/S { % showpage protecting gstate + gsave + showpage + grestore +} bind def + +/MF { % fontname newfontname -> - make a new encoded font + /newfontname exch def + /fontname exch def + + /fontdict fontname findfont def + /newfont fontdict maxlength dict def + + fontdict { + exch + dup /FID eq { + % skip FID pair + pop pop + } { + % copy to the new font dictionary + exch newfont 3 1 roll put + } ifelse + } forall + + newfont /FontName newfontname put + + % insert only valid encoding vectors + encoding_vector length 256 eq { + newfont /Encoding encoding_vector put + } if + + newfontname newfont definefont pop +} def + +/SF { % fontname width height -> - set a new font + /height exch def + /width exch def + + findfont + [width 0 0 height 0 0] makefont setfont +} def + +/SUF { % fontname width height -> - set a new user font + /height exch def + /width exch def + + /F-gs-user-font MF + /F-gs-user-font width height SF +} def + +/M {moveto} bind def +/s {show} bind def + +/Box { % x y w h -> - define box path + /d_h exch def /d_w exch def /d_y exch def /d_x exch def + d_x d_y moveto + d_w 0 rlineto + 0 d_h rlineto + d_w neg 0 rlineto + closepath +} def + +/bgs { % x y height blskip gray str -> - show string with bg color + /str exch def + /gray exch def + /blskip exch def + /height exch def + /y exch def + /x exch def + + gsave + x y blskip sub str stringwidth pop height Box + gray setgray + fill + grestore + x y M str s +} def + +% Highlight bars. +/highlight_bars { % nlines lineheight output_y_margin gray -> - + gsave + setgray + /ymarg exch def + /lineheight exch def + /nlines exch def + + % This 2 is just a magic number to sync highlight lines to text. + 0 d_header_y ymarg sub 2 sub translate + + /cw d_output_w cols div def + /nrows d_output_h ymarg 2 mul sub lineheight div cvi def + + % for each column + 0 1 cols 1 sub { + cw mul /xp exch def + + % for each rows + 0 1 nrows 1 sub { + /rn exch def + rn lineheight mul neg /yp exch def + rn nlines idiv 2 mod 0 eq { + % Draw highlight bar. 4 is just a magic indentation. + xp 4 add yp cw 8 sub lineheight neg Box fill + } if + } for + } for + + grestore +} def + +% Line highlight bar. +/line_highlight { % x y width height gray -> - + gsave + /gray exch def + Box gray setgray fill + grestore +} def + +% Column separator lines. +/column_lines { + gsave + .1 setlinewidth + 0 d_footer_h translate + /cw d_output_w cols div def + 1 1 cols 1 sub { + cw mul 0 moveto + 0 d_output_h rlineto stroke + } for + grestore +} def + +% Column borders. +/column_borders { + gsave + .1 setlinewidth + 0 d_footer_h moveto + 0 d_output_h rlineto + d_output_w 0 rlineto + 0 d_output_h neg rlineto + closepath stroke + grestore +} def + +% Do the actual underlay drawing +/draw_underlay { + ul_style 0 eq { + ul_str true charpath stroke + } { + ul_str show + } ifelse +} def + +% Underlay +/underlay { % - -> - + gsave + 0 d_page_h translate + d_page_h neg d_page_w atan rotate + + ul_gray setgray + ul_font setfont + /dw d_page_h dup mul d_page_w dup mul add sqrt def + ul_str stringwidth pop dw exch sub 2 div ul_h_ptsize -2 div moveto + draw_underlay + grestore +} def + +/user_underlay { % - -> - + gsave + ul_x ul_y translate + ul_angle rotate + ul_gray setgray + ul_font setfont + 0 0 ul_h_ptsize 2 div sub moveto + draw_underlay + grestore +} def + +% Page prefeed +/page_prefeed { % bool -> - + statusdict /prefeed known { + statusdict exch /prefeed exch put + } { + pop + } ifelse +} def + +% Wrapped line markers +/wrapped_line_mark { % x y charwith charheight type -> - + /type exch def + /h exch def + /w exch def + /y exch def + /x exch def + + type 2 eq { + % Black boxes (like TeX does) + gsave + 0 setlinewidth + x w 4 div add y M + 0 h rlineto w 2 div 0 rlineto 0 h neg rlineto + closepath fill + grestore + } { + type 3 eq { + % Small arrows + gsave + .2 setlinewidth + x w 2 div add y h 2 div add M + w 4 div 0 rlineto + x w 4 div add y lineto stroke + + x w 4 div add w 8 div add y h 4 div add M + x w 4 div add y lineto + w 4 div h 8 div rlineto stroke + grestore + } { + % do nothing + } ifelse + } ifelse +} def + +% EPSF import. + +/BeginEPSF { + /b4_Inc_state save def % Save state for cleanup + /dict_count countdictstack def % Count objects on dict stack + /op_count count 1 sub def % Count objects on operand stack + userdict begin + /showpage { } def + 0 setgray 0 setlinecap + 1 setlinewidth 0 setlinejoin + 10 setmiterlimit [ ] 0 setdash newpath + /languagelevel where { + pop languagelevel + 1 ne { + false setstrokeadjust false setoverprint + } if + } if +} bind def + +/EndEPSF { + count op_count sub { pos } repeat % Clean up stacks + countdictstack dict_count sub { end } repeat + b4_Inc_state restore +} bind def + +% Check PostScript language level. +/languagelevel where { + pop /gs_languagelevel languagelevel def +} { + /gs_languagelevel 1 def +} ifelse +%%EndResource +%%BeginResource: procset Enscript-Encoding-88591 1.6 1 +/encoding_vector [ +/.notdef /.notdef /.notdef /.notdef +/.notdef /.notdef /.notdef /.notdef +/.notdef /.notdef /.notdef /.notdef +/.notdef /.notdef /.notdef /.notdef +/.notdef /.notdef /.notdef /.notdef +/.notdef /.notdef /.notdef /.notdef +/.notdef /.notdef /.notdef /.notdef +/.notdef /.notdef /.notdef /.notdef +/space /exclam /quotedbl /numbersign +/dollar /percent /ampersand /quoteright +/parenleft /parenright /asterisk /plus +/comma /hyphen /period /slash +/zero /one /two /three +/four /five /six /seven +/eight /nine /colon /semicolon +/less /equal /greater /question +/at /A /B /C +/D /E /F /G +/H /I /J /K +/L /M /N /O +/P /Q /R /S +/T /U /V /W +/X /Y /Z /bracketleft +/backslash /bracketright /asciicircum /underscore +/quoteleft /a /b /c +/d /e /f /g +/h /i /j /k +/l /m /n /o +/p /q /r /s +/t /u /v /w +/x /y /z /braceleft +/bar /braceright /tilde /.notdef +/.notdef /.notdef /.notdef /.notdef +/.notdef /.notdef /.notdef /.notdef +/.notdef /.notdef /.notdef /.notdef +/.notdef /.notdef /.notdef /.notdef +/.notdef /.notdef /.notdef /.notdef +/.notdef /.notdef /.notdef /.notdef +/.notdef /.notdef /.notdef /.notdef +/.notdef /.notdef /.notdef /.notdef +/space /exclamdown /cent /sterling +/currency /yen /brokenbar /section +/dieresis /copyright /ordfeminine /guillemotleft +/logicalnot /hyphen /registered /macron +/degree /plusminus /twosuperior /threesuperior +/acute /mu /paragraph /bullet +/cedilla /onesuperior /ordmasculine /guillemotright +/onequarter /onehalf /threequarters /questiondown +/Agrave /Aacute /Acircumflex /Atilde +/Adieresis /Aring /AE /Ccedilla +/Egrave /Eacute /Ecircumflex /Edieresis +/Igrave /Iacute /Icircumflex /Idieresis +/Eth /Ntilde /Ograve /Oacute +/Ocircumflex /Otilde /Odieresis /multiply +/Oslash /Ugrave /Uacute /Ucircumflex +/Udieresis /Yacute /Thorn /germandbls +/agrave /aacute /acircumflex /atilde +/adieresis /aring /ae /ccedilla +/egrave /eacute /ecircumflex /edieresis +/igrave /iacute /icircumflex /idieresis +/eth /ntilde /ograve /oacute +/ocircumflex /otilde /odieresis /divide +/oslash /ugrave /uacute /ucircumflex +/udieresis /yacute /thorn /ydieresis +] def +%%EndResource +%%EndProlog +%%BeginSetup +%%IncludeResource: font Courier-Bold +%%IncludeResource: font Courier +/HFpt_w 10 def +/HFpt_h 10 def +/Courier-Bold /HF-gs-font MF +/HF /HF-gs-font findfont [HFpt_w 0 0 HFpt_h 0 0] makefont def +/Courier /F-gs-font MF +/F-gs-font 10 10 SF +/#copies 1 def +/d_page_w 520 def +/d_page_h 747 def +/d_header_x 0 def +/d_header_y 747 def +/d_header_w 520 def +/d_header_h 0 def +/d_footer_x 0 def +/d_footer_y 0 def +/d_footer_w 520 def +/d_footer_h 0 def +/d_output_w 520 def +/d_output_h 747 def +/cols 1 def +userdict/PStoPSxform PStoPSmatrix matrix currentmatrix + matrix invertmatrix matrix concatmatrix + matrix invertmatrix put +%%EndSetup +%%Page: (0,1) 1 +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 0.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +/showpage{}def/copypage{}def/erasepage{}def +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 1 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 701 M +(Network Working Group T. Ylonen) s +5 690 M +(Internet-Draft SSH Communications Security Corp) s +5 679 M +(Expires: March 2, 2003 D. Moffat, Ed.) s +5 668 M +( Sun Microsystems, Inc) s +5 657 M +( September 2002) s +5 624 M +( SSH Authentication Protocol) s +5 613 M +( draft-ietf-secsh-userauth-18.txt) s +5 591 M +(Status of this Memo) s +5 569 M +( This document is an Internet-Draft and is in full conformance with) s +5 558 M +( all provisions of Section 10 of RFC2026.) s +5 536 M +( Internet-Drafts are working documents of the Internet Engineering) s +5 525 M +( Task Force \(IETF\), its areas, and its working groups. Note that other) s +5 514 M +( groups may also distribute working documents as Internet-Drafts.) s +5 492 M +( Internet-Drafts are draft documents valid for a maximum of six months) s +5 481 M +( and may be updated, replaced, or obsoleted by other documents at any) s +5 470 M +( time. It is inappropriate to use Internet-Drafts as reference) s +5 459 M +( material or to cite them other than as "work in progress.") s +5 437 M +( The list of current Internet-Drafts can be accessed at http://) s +5 426 M +( www.ietf.org/ietf/1id-abstracts.txt.) s +5 404 M +( The list of Internet-Draft Shadow Directories can be accessed at) s +5 393 M +( http://www.ietf.org/shadow.html.) s +5 371 M +( This Internet-Draft will expire on March 2, 2003.) s +5 349 M +(Copyright Notice) s +5 327 M +( Copyright \(C\) The Internet Society \(2002\). All Rights Reserved.) s +5 305 M +(Abstract) s +5 283 M +( SSH is a protocol for secure remote login and other secure network) s +5 272 M +( services over an insecure network. This document describes the SSH) s +5 261 M +( authentication protocol framework and public key, password, and) s +5 250 M +( host-based client authentication methods. Additional authentication) s +5 239 M +( methods are described in separate documents. The SSH authentication) s +5 228 M +( protocol runs on top of the SSH transport layer protocol and provides) s +5 217 M +( a single authenticated tunnel for the SSH connection protocol.) s +5 129 M +(Ylonen & Moffat Expires March 2, 2003 [Page 1]) s +_R +S +PStoPSsaved restore +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 421.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 2 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH Authentication Protocol September 2002) s +5 690 M +(Table of Contents) s +5 668 M +( 1. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 3) s +5 657 M +( 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3) s +5 646 M +( 3. Conventions Used in This Document . . . . . . . . . . . . . 3) s +5 635 M +( 3.1 The Authentication Protocol Framework . . . . . . . . . . . 3) s +5 624 M +( 3.1.1 Authentication Requests . . . . . . . . . . . . . . . . . . 4) s +5 613 M +( 3.1.2 Responses to Authentication Requests . . . . . . . . . . . . 5) s +5 602 M +( 3.1.3 The "none" Authentication Request . . . . . . . . . . . . . 6) s +5 591 M +( 3.1.4 Completion of User Authentication . . . . . . . . . . . . . 6) s +5 580 M +( 3.1.5 Banner Message . . . . . . . . . . . . . . . . . . . . . . . 7) s +5 569 M +( 3.2 Authentication Protocol Message Numbers . . . . . . . . . . 7) s +5 558 M +( 3.3 Public Key Authentication Method: publickey . . . . . . . . 8) s +5 547 M +( 3.4 Password Authentication Method: password . . . . . . . . . . 10) s +5 536 M +( 3.5 Host-Based Authentication: hostbased . . . . . . . . . . . . 11) s +5 525 M +( 4. Security Considerations . . . . . . . . . . . . . . . . . . 12) s +5 514 M +( Normative . . . . . . . . . . . . . . . . . . . . . . . . . 13) s +5 503 M +( Informative . . . . . . . . . . . . . . . . . . . . . . . . 13) s +5 492 M +( Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 14) s +5 481 M +( Intellectual Property and Copyright Statements . . . . . . . 15) s +5 129 M +(Ylonen & Moffat Expires March 2, 2003 [Page 2]) s +_R +S +PStoPSsaved restore +%%Page: (2,3) 2 +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 0.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +/showpage{}def/copypage{}def/erasepage{}def +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 3 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH Authentication Protocol September 2002) s +5 690 M +(1. Contributors) s +5 668 M +( The major original contributors of this document were: Tatu Ylonen,) s +5 657 M +( Tero Kivinen, Timo J. Rinne, Sami Lehtinen \(all of SSH Communications) s +5 646 M +( Security Corp\), and Markku-Juhani O. Saarinen \(University of) s +5 635 M +( Jyvaskyla\)) s +5 613 M +( The document editor is: [email protected]. Comments on this) s +5 602 M +( internet draft should be sent to the IETF SECSH working group,) s +5 591 M +( details at: http://ietf.org/html.charters/secsh-charter.html) s +5 569 M +(2. Introduction) s +5 547 M +( The SSH authentication protocol is a general-purpose user) s +5 536 M +( authentication protocol. It is intended to be run over the SSH) s +5 525 M +( transport layer protocol [SSH-TRANS]. This protocol assumes that the) s +5 514 M +( underlying protocols provide integrity and confidentiality) s +5 503 M +( protection.) s +5 481 M +( This document should be read only after reading the SSH architecture) s +5 470 M +( document [SSH-ARCH]. This document freely uses terminology and) s +5 459 M +( notation from the architecture document without reference or further) s +5 448 M +( explanation.) s +5 426 M +( The service name for this protocol is "ssh-userauth".) s +5 404 M +( When this protocol starts, it receives the session identifier from) s +5 393 M +( the lower-level protocol \(this is the exchange hash H from the first) s +5 382 M +( key exchange\). The session identifier uniquely identifies this) s +5 371 M +( session and is suitable for signing in order to prove ownership of a) s +5 360 M +( private key. This protocol also needs to know whether the lower-level) s +5 349 M +( protocol provides confidentiality protection.) s +5 327 M +(3. Conventions Used in This Document) s +5 305 M +( The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",) s +5 294 M +( and "MAY" that appear in this document are to be interpreted as) s +5 283 M +( described in [RFC2119]) s +5 261 M +( The used data types and terminology are specified in the architecture) s +5 250 M +( document [SSH-ARCH]) s +5 228 M +( The architecture document also discusses the algorithm naming) s +5 217 M +( conventions that MUST be used with the SSH protocols.) s +5 195 M +(3.1 The Authentication Protocol Framework) s +5 173 M +( The server drives the authentication by telling the client which) s +5 129 M +(Ylonen & Moffat Expires March 2, 2003 [Page 3]) s +_R +S +PStoPSsaved restore +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 421.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 4 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH Authentication Protocol September 2002) s +5 690 M +( authentication methods can be used to continue the exchange at any) s +5 679 M +( given time. The client has the freedom to try the methods listed by) s +5 668 M +( the server in any order. This gives the server complete control over) s +5 657 M +( the authentication process if desired, but also gives enough) s +5 646 M +( flexibility for the client to use the methods it supports or that are) s +5 635 M +( most convenient for the user, when multiple methods are offered by) s +5 624 M +( the server.) s +5 602 M +( Authentication methods are identified by their name, as defined in) s +5 591 M +( [SSH-ARCH]. The "none" method is reserved, and MUST NOT be listed as) s +5 580 M +( supported. However, it MAY be sent by the client. The server MUST) s +5 569 M +( always reject this request, unless the client is to be allowed in) s +5 558 M +( without any authentication, in which case the server MUST accept this) s +5 547 M +( request. The main purpose of sending this request is to get the list) s +5 536 M +( of supported methods from the server.) s +5 514 M +( The server SHOULD have a timeout for authentication, and disconnect) s +5 503 M +( if the authentication has not been accepted within the timeout) s +5 492 M +( period. The RECOMMENDED timeout period is 10 minutes. Additionally,) s +5 481 M +( the implementation SHOULD limit the number of failed authentication) s +5 470 M +( attempts a client may perform in a single session \(the RECOMMENDED) s +5 459 M +( limit is 20 attempts\). If the threshold is exceeded, the server) s +5 448 M +( SHOULD disconnect.) s +5 426 M +(3.1.1 Authentication Requests) s +5 404 M +( All authentication requests MUST use the following message format.) s +5 393 M +( Only the first few fields are defined; the remaining fields depend on) s +5 382 M +( the authentication method.) s +5 360 M +( byte SSH_MSG_USERAUTH_REQUEST) s +5 349 M +( string user name \(in ISO-10646 UTF-8 encoding [RFC2279]\)) s +5 338 M +( string service name \(in US-ASCII\)) s +5 327 M +( string method name \(US-ASCII\)) s +5 316 M +( The rest of the packet is method-specific.) s +5 294 M +( The user name and service are repeated in every new authentication) s +5 283 M +( attempt, and MAY change. The server implementation MUST carefully) s +5 272 M +( check them in every message, and MUST flush any accumulated) s +5 261 M +( authentication states if they change. If it is unable to flush some) s +5 250 M +( authentication state, it MUST disconnect if the user or service name) s +5 239 M +( changes.) s +5 217 M +( The service name specifies the service to start after authentication.) s +5 206 M +( There may be several different authenticated services provided. If) s +5 195 M +( the requested service is not available, the server MAY disconnect) s +5 184 M +( immediately or at any later time. Sending a proper disconnect) s +5 173 M +( message is RECOMMENDED. In any case, if the service does not exist,) s +5 129 M +(Ylonen & Moffat Expires March 2, 2003 [Page 4]) s +_R +S +PStoPSsaved restore +%%Page: (4,5) 3 +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 0.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +/showpage{}def/copypage{}def/erasepage{}def +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 5 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH Authentication Protocol September 2002) s +5 690 M +( authentication MUST NOT be accepted.) s +5 668 M +( If the requested user does not exist, the server MAY disconnect, or) s +5 657 M +( MAY send a bogus list of acceptable authentication methods, but never) s +5 646 M +( accept any. This makes it possible for the server to avoid) s +5 635 M +( disclosing information on which accounts exist. In any case, if the) s +5 624 M +( user does not exist, the authentication request MUST NOT be accepted.) s +5 602 M +( While there is usually little point for clients to send requests that) s +5 591 M +( the server does not list as acceptable, sending such requests is not) s +5 580 M +( an error, and the server SHOULD simply reject requests that it does) s +5 569 M +( not recognize.) s +5 547 M +( An authentication request MAY result in a further exchange of) s +5 536 M +( messages. All such messages depend on the authentication method) s +5 525 M +( used, and the client MAY at any time continue with a new) s +5 514 M +( SSH_MSG_USERAUTH_REQUEST message, in which case the server MUST) s +5 503 M +( abandon the previous authentication attempt and continue with the new) s +5 492 M +( one.) s +5 470 M +(3.1.2 Responses to Authentication Requests) s +5 448 M +( If the server rejects the authentication request, it MUST respond) s +5 437 M +( with the following:) s +5 415 M +( byte SSH_MSG_USERAUTH_FAILURE) s +5 404 M +( string authentications that can continue) s +5 393 M +( boolean partial success) s +5 371 M +( "Authentications that can continue" is a comma-separated list of) s +5 360 M +( authentication method names that may productively continue the) s +5 349 M +( authentication dialog.) s +5 327 M +( It is RECOMMENDED that servers only include those methods in the list) s +5 316 M +( that are actually useful. However, it is not illegal to include) s +5 305 M +( methods that cannot be used to authenticate the user.) s +5 283 M +( Already successfully completed authentications SHOULD NOT be included) s +5 272 M +( in the list, unless they really should be performed again for some) s +5 261 M +( reason.) s +5 239 M +( "Partial success" MUST be TRUE if the authentication request to which) s +5 228 M +( this is a response was successful. It MUST be FALSE if the request) s +5 217 M +( was not successfully processed.) s +5 195 M +( When the server accepts authentication, it MUST respond with the) s +5 184 M +( following:) s +5 129 M +(Ylonen & Moffat Expires March 2, 2003 [Page 5]) s +_R +S +PStoPSsaved restore +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 421.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 6 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH Authentication Protocol September 2002) s +5 690 M +( byte SSH_MSG_USERAUTH_SUCCESS) s +5 668 M +( Note that this is not sent after each step in a multi-method) s +5 657 M +( authentication sequence, but only when the authentication is) s +5 646 M +( complete.) s +5 624 M +( The client MAY send several authentication requests without waiting) s +5 613 M +( for responses from previous requests. The server MUST process each) s +5 602 M +( request completely and acknowledge any failed requests with a) s +5 591 M +( SSH_MSG_USERAUTH_FAILURE message before processing the next request.) s +5 569 M +( A request that results in further exchange of messages will be) s +5 558 M +( aborted by a second request. It is not possible to send a second) s +5 547 M +( request without waiting for a response from the server, if the first) s +5 536 M +( request will result in further exchange of messages. No) s +5 525 M +( SSH_MSG_USERAUTH_FAILURE message will be sent for the aborted method.) s +5 503 M +( SSH_MSG_USERAUTH_SUCCESS MUST be sent only once. When) s +5 492 M +( SSH_MSG_USERAUTH_SUCCESS has been sent, any further authentication) s +5 481 M +( requests received after that SHOULD be silently ignored.) s +5 459 M +( Any non-authentication messages sent by the client after the request) s +5 448 M +( that resulted in SSH_MSG_USERAUTH_SUCCESS being sent MUST be passed) s +5 437 M +( to the service being run on top of this protocol. Such messages can) s +5 426 M +( be identified by their message numbers \(see Section Message Numbers) s +5 415 M +( \(Section 3.2\)\).) s +5 393 M +(3.1.3 The "none" Authentication Request) s +5 371 M +( A client may request a list of authentication methods that may) s +5 360 M +( continue by using the "none" authentication method.) s +5 338 M +( If no authentication at all is needed for the user, the server MUST) s +5 327 M +( return SSH_MSG_USERAUTH_SUCCESS. Otherwise, the server MUST return) s +5 316 M +( SSH_MSG_USERAUTH_FAILURE and MAY return with it a list of) s +5 305 M +( authentication methods that can continue.) s +5 283 M +( This method MUST NOT be listed as supported by the server.) s +5 261 M +(3.1.4 Completion of User Authentication) s +5 239 M +( Authentication is complete when the server has responded with) s +5 228 M +( SSH_MSG_USERAUTH_SUCCESS; all authentication related messages) s +5 217 M +( received after sending this message SHOULD be silently ignored.) s +5 195 M +( After sending SSH_MSG_USERAUTH_SUCCESS, the server starts the) s +5 184 M +( requested service.) s +5 129 M +(Ylonen & Moffat Expires March 2, 2003 [Page 6]) s +_R +S +PStoPSsaved restore +%%Page: (6,7) 4 +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 0.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +/showpage{}def/copypage{}def/erasepage{}def +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 7 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH Authentication Protocol September 2002) s +5 690 M +(3.1.5 Banner Message) s +5 668 M +( In some jurisdictions, sending a warning message before) s +5 657 M +( authentication may be relevant for getting legal protection. Many) s +5 646 M +( UNIX machines, for example, normally display text from `/etc/issue',) s +5 635 M +( or use "tcp wrappers" or similar software to display a banner before) s +5 624 M +( issuing a login prompt.) s +5 602 M +( The SSH server may send a SSH_MSG_USERAUTH_BANNER message at any time) s +5 591 M +( before authentication is successful. This message contains text to) s +5 580 M +( be displayed to the client user before authentication is attempted.) s +5 569 M +( The format is as follows:) s +5 547 M +( byte SSH_MSG_USERAUTH_BANNER) s +5 536 M +( string message \(ISO-10646 UTF-8\)) s +5 525 M +( string language tag \(as defined in [RFC3066]\)) s +5 503 M +( The client SHOULD by default display the message on the screen.) s +5 492 M +( However, since the message is likely to be sent for every login) s +5 481 M +( attempt, and since some client software will need to open a separate) s +5 470 M +( window for this warning, the client software may allow the user to) s +5 459 M +( explicitly disable the display of banners from the server. The) s +5 448 M +( message may consist of multiple lines.) s +5 426 M +( If the message string is displayed, control character filtering) s +5 415 M +( discussed in [SSH-ARCH] SHOULD be used to avoid attacks by sending) s +5 404 M +( terminal control characters.) s +5 382 M +(3.2 Authentication Protocol Message Numbers) s +5 360 M +( All message numbers used by this authentication protocol are in the) s +5 349 M +( range from 50 to 79, which is part of the range reserved for) s +5 338 M +( protocols running on top of the SSH transport layer protocol.) s +5 316 M +( Message numbers of 80 and higher are reserved for protocols running) s +5 305 M +( after this authentication protocol, so receiving one of them before) s +5 294 M +( authentication is complete is an error, to which the server MUST) s +5 283 M +( respond by disconnecting \(preferably with a proper disconnect message) s +5 272 M +( sent first to ease troubleshooting\).) s +5 250 M +( After successful authentication, such messages are passed to the) s +5 239 M +( higher-level service.) s +5 217 M +( These are the general authentication message codes:) s +5 195 M +( #define SSH_MSG_USERAUTH_REQUEST 50) s +5 184 M +( #define SSH_MSG_USERAUTH_FAILURE 51) s +5 173 M +( #define SSH_MSG_USERAUTH_SUCCESS 52) s +5 129 M +(Ylonen & Moffat Expires March 2, 2003 [Page 7]) s +_R +S +PStoPSsaved restore +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 421.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 8 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH Authentication Protocol September 2002) s +5 690 M +( #define SSH_MSG_USERAUTH_BANNER 53) s +5 668 M +( In addition to the above, there is a range of message numbers) s +5 657 M +( \(60..79\) reserved for method-specific messages. These messages are) s +5 646 M +( only sent by the server \(client sends only SSH_MSG_USERAUTH_REQUEST) s +5 635 M +( messages\). Different authentication methods reuse the same message) s +5 624 M +( numbers.) s +5 602 M +(3.3 Public Key Authentication Method: publickey) s +5 580 M +( The only REQUIRED authentication method is public key authentication.) s +5 569 M +( All implementations MUST support this method; however, not all users) s +5 558 M +( need to have public keys, and most local policies are not likely to) s +5 547 M +( require public key authentication for all users in the near future.) s +5 525 M +( With this method, the possession of a private key serves as) s +5 514 M +( authentication. This method works by sending a signature created) s +5 503 M +( with a private key of the user. The server MUST check that the key) s +5 492 M +( is a valid authenticator for the user, and MUST check that the) s +5 481 M +( signature is valid. If both hold, the authentication request MUST be) s +5 470 M +( accepted; otherwise it MUST be rejected. \(Note that the server MAY) s +5 459 M +( require additional authentications after successful authentication.\)) s +5 437 M +( Private keys are often stored in an encrypted form at the client) s +5 426 M +( host, and the user must supply a passphrase before the signature can) s +5 415 M +( be generated. Even if they are not, the signing operation involves) s +5 404 M +( some expensive computation. To avoid unnecessary processing and user) s +5 393 M +( interaction, the following message is provided for querying whether) s +5 382 M +( authentication using the key would be acceptable.) s +5 360 M +( byte SSH_MSG_USERAUTH_REQUEST) s +5 349 M +( string user name) s +5 338 M +( string service) s +5 327 M +( string "publickey") s +5 316 M +( boolean FALSE) s +5 305 M +( string public key algorithm name) s +5 294 M +( string public key blob) s +5 272 M +( Public key algorithms are defined in the transport layer) s +5 261 M +( specification [SSH-TRANS]. The public key blob may contain) s +5 250 M +( certificates.) s +5 228 M +( Any public key algorithm may be offered for use in authentication.) s +5 217 M +( In particular, the list is not constrained by what was negotiated) s +5 206 M +( during key exchange. If the server does not support some algorithm,) s +5 195 M +( it MUST simply reject the request.) s +5 173 M +( The server MUST respond to this message with either) s +5 129 M +(Ylonen & Moffat Expires March 2, 2003 [Page 8]) s +_R +S +PStoPSsaved restore +%%Page: (8,9) 5 +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 0.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +/showpage{}def/copypage{}def/erasepage{}def +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 9 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH Authentication Protocol September 2002) s +5 690 M +( SSH_MSG_USERAUTH_FAILURE or with the following:) s +5 668 M +( byte SSH_MSG_USERAUTH_PK_OK) s +5 657 M +( string public key algorithm name from the request) s +5 646 M +( string public key blob from the request) s +5 624 M +( To perform actual authentication, the client MAY then send a) s +5 613 M +( signature generated using the private key. The client MAY send the) s +5 602 M +( signature directly without first verifying whether the key is) s +5 591 M +( acceptable. The signature is sent using the following packet:) s +5 569 M +( byte SSH_MSG_USERAUTH_REQUEST) s +5 558 M +( string user name) s +5 547 M +( string service) s +5 536 M +( string "publickey") s +5 525 M +( boolean TRUE) s +5 514 M +( string public key algorithm name) s +5 503 M +( string public key to be used for authentication) s +5 492 M +( string signature) s +5 470 M +( Signature is a signature by the corresponding private key over the) s +5 459 M +( following data, in the following order:) s +5 437 M +( string session identifier) s +5 426 M +( byte SSH_MSG_USERAUTH_REQUEST) s +5 415 M +( string user name) s +5 404 M +( string service) s +5 393 M +( string "publickey") s +5 382 M +( boolean TRUE) s +5 371 M +( string public key algorithm name) s +5 360 M +( string public key to be used for authentication) s +5 338 M +( When the server receives this message, it MUST check whether the) s +5 327 M +( supplied key is acceptable for authentication, and if so, it MUST) s +5 316 M +( check whether the signature is correct.) s +5 294 M +( If both checks succeed, this method is successful. Note that the) s +5 283 M +( server may require additional authentications. The server MUST) s +5 272 M +( respond with SSH_MSG_USERAUTH_SUCCESS \(if no more authentications are) s +5 261 M +( needed\), or SSH_MSG_USERAUTH_FAILURE \(if the request failed, or more) s +5 250 M +( authentications are needed\).) s +5 228 M +( The following method-specific message numbers are used by the) s +5 217 M +( publickey authentication method.) s +5 195 M +( /* Key-based */) s +5 184 M +( #define SSH_MSG_USERAUTH_PK_OK 60) s +5 129 M +(Ylonen & Moffat Expires March 2, 2003 [Page 9]) s +_R +S +PStoPSsaved restore +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 421.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 10 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH Authentication Protocol September 2002) s +5 690 M +(3.4 Password Authentication Method: password) s +5 668 M +( Password authentication uses the following packets. Note that a) s +5 657 M +( server MAY request the user to change the password. All) s +5 646 M +( implementations SHOULD support password authentication.) s +5 624 M +( byte SSH_MSG_USERAUTH_REQUEST) s +5 613 M +( string user name) s +5 602 M +( string service) s +5 591 M +( string "password") s +5 580 M +( boolean FALSE) s +5 569 M +( string plaintext password \(ISO-10646 UTF-8\)) s +5 547 M +( Note that the password is encoded in ISO-10646 UTF-8. It is up to) s +5 536 M +( the server how it interprets the password and validates it against) s +5 525 M +( the password database. However, if the client reads the password in) s +5 514 M +( some other encoding \(e.g., ISO 8859-1 \(ISO Latin1\)\), it MUST convert) s +5 503 M +( the password to ISO-10646 UTF-8 before transmitting, and the server) s +5 492 M +( MUST convert the password to the encoding used on that system for) s +5 481 M +( passwords.) s +5 459 M +( Note that even though the cleartext password is transmitted in the) s +5 448 M +( packet, the entire packet is encrypted by the transport layer. Both) s +5 437 M +( the server and the client should check whether the underlying) s +5 426 M +( transport layer provides confidentiality \(i.e., if encryption is) s +5 415 M +( being used\). If no confidentiality is provided \(none cipher\),) s +5 404 M +( password authentication SHOULD be disabled. If there is no) s +5 393 M +( confidentiality or no MAC, password change SHOULD be disabled.) s +5 371 M +( Normally, the server responds to this message with success or) s +5 360 M +( failure. However, if the password has expired the server SHOULD) s +5 349 M +( indicate this by responding with SSH_MSG_USERAUTH_PASSWD_CHANGEREQ.) s +5 338 M +( In anycase the server MUST NOT allow an expired password to be used) s +5 327 M +( for authentication.) s +5 305 M +( byte SSH_MSG_USERAUTH_PASSWD_CHANGEREQ) s +5 294 M +( string prompt \(ISO-10646 UTF-8\)) s +5 283 M +( string language tag \(as defined in [RFC3066]\)) s +5 261 M +( In this case, the client MAY continue with a different authentication) s +5 250 M +( method, or request a new password from the user and retry password) s +5 239 M +( authentication using the following message. The client MAY also send) s +5 228 M +( this message instead of the normal password authentication request) s +5 217 M +( without the server asking for it.) s +5 195 M +( byte SSH_MSG_USERAUTH_REQUEST) s +5 184 M +( string user name) s +5 173 M +( string service) s +5 129 M +(Ylonen & Moffat Expires March 2, 2003 [Page 10]) s +_R +S +PStoPSsaved restore +%%Page: (10,11) 6 +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 0.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +/showpage{}def/copypage{}def/erasepage{}def +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 11 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH Authentication Protocol September 2002) s +5 690 M +( string "password") s +5 679 M +( boolean TRUE) s +5 668 M +( string plaintext old password \(ISO-10646 UTF-8\)) s +5 657 M +( string plaintext new password \(ISO-10646 UTF-8\)) s +5 635 M +( The server must reply to request message with) s +5 624 M +( SSH_MSG_USERAUTH_SUCCESS, SSH_MSG_USERAUTH_FAILURE, or another) s +5 613 M +( SSH_MSG_USERAUTH_PASSWD_CHANGEREQ. The meaning of these is as) s +5 602 M +( follows:) s +5 580 M +( SSH_MSG_USERAUTH_SUCCESS The password has been changed, and) s +5 569 M +( authentication has been successfully completed.) s +5 547 M +( SSH_MSG_USERAUTH_FAILURE with partial success The password has) s +5 536 M +( been changed, but more authentications are needed.) s +5 514 M +( SSH_MSG_USERAUTH_FAILURE without partial success The password has) s +5 503 M +( not been changed. Either password changing was not supported, or) s +5 492 M +( the old password was bad. Note that if the server has already) s +5 481 M +( sent SSH_MSG_USERAUTH_PASSWD_CHANGEREQ, we know that it supports) s +5 470 M +( changing the password.) s +5 448 M +( SSH_MSG_USERAUTH_CHANGEREQ The password was not changed because) s +5 437 M +( the new password was not acceptable \(e.g. too easy to guess\).) s +5 415 M +( The following method-specific message numbers are used by the) s +5 404 M +( password authentication method.) s +5 382 M +( #define SSH_MSG_USERAUTH_PASSWD_CHANGEREQ 60) s +5 349 M +(3.5 Host-Based Authentication: hostbased) s +5 327 M +( Some sites wish to allow authentication based on the host where the) s +5 316 M +( user is coming from, and the user name on the remote host. While) s +5 305 M +( this form of authentication is not suitable for high-security sites,) s +5 294 M +( it can be very convenient in many environments. This form of) s +5 283 M +( authentication is OPTIONAL. When used, special care SHOULD be taken) s +5 272 M +( to prevent a regular user from obtaining the private host key.) s +5 250 M +( The client requests this form of authentication by sending the) s +5 239 M +( following message. It is similar to the UNIX "rhosts" and) s +5 228 M +( "hosts.equiv" styles of authentication, except that the identity of) s +5 217 M +( the client host is checked more rigorously.) s +5 195 M +( This method works by having the client send a signature created with) s +5 184 M +( the private key of the client host, which the server checks with that) s +5 173 M +( host's public key. Once the client host's identity is established,) s +5 129 M +(Ylonen & Moffat Expires March 2, 2003 [Page 11]) s +_R +S +PStoPSsaved restore +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 421.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 12 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH Authentication Protocol September 2002) s +5 690 M +( authorization \(but no further authentication\) is performed based on) s +5 679 M +( the user names on the server and the client, and the client host) s +5 668 M +( name.) s +5 646 M +( byte SSH_MSG_USERAUTH_REQUEST) s +5 635 M +( string user name) s +5 624 M +( string service) s +5 613 M +( string "hostbased") s +5 602 M +( string public key algorithm for host key) s +5 591 M +( string public host key and certificates for client host) s +5 580 M +( string client host name \(FQDN; US-ASCII\)) s +5 569 M +( string user name on the client host \(ISO-10646 UTF-8\)) s +5 558 M +( string signature) s +5 536 M +( Public key algorithm names for use in "public key algorithm for host) s +5 525 M +( key" are defined in the transport layer specification. The "public) s +5 514 M +( host key for client host" may include certificates.) s +5 492 M +( Signature is a signature with the private host key of the following) s +5 481 M +( data, in this order:) s +5 459 M +( string session identifier) s +5 448 M +( byte SSH_MSG_USERAUTH_REQUEST) s +5 437 M +( string user name) s +5 426 M +( string service) s +5 415 M +( string "hostbased") s +5 404 M +( string public key algorithm for host key) s +5 393 M +( string public host key and certificates for client host) s +5 382 M +( string client host name \(FQDN; US-ASCII\)) s +5 371 M +( string user name on the client host\(ISO-10646 UTF-8\)) s +5 349 M +( The server MUST verify that the host key actually belongs to the) s +5 338 M +( client host named in the message, that the given user on that host is) s +5 327 M +( allowed to log in, and that the signature is a valid signature on the) s +5 316 M +( appropriate value by the given host key. The server MAY ignore the) s +5 305 M +( client user name, if it wants to authenticate only the client host.) s +5 283 M +( It is RECOMMENDED that whenever possible, the server perform) s +5 272 M +( additional checks to verify that the network address obtained from) s +5 261 M +( the \(untrusted\) network matches the given client host name. This) s +5 250 M +( makes exploiting compromised host keys more difficult. Note that) s +5 239 M +( this may require special handling for connections coming through a) s +5 228 M +( firewall.) s +5 206 M +(4. Security Considerations) s +5 184 M +( The purpose of this protocol is to perform client user) s +5 173 M +( authentication. It assumed that this runs over a secure transport) s +5 129 M +(Ylonen & Moffat Expires March 2, 2003 [Page 12]) s +_R +S +PStoPSsaved restore +%%Page: (12,13) 7 +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 0.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +/showpage{}def/copypage{}def/erasepage{}def +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 13 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH Authentication Protocol September 2002) s +5 690 M +( layer protocol, which has already authenticated the server machine,) s +5 679 M +( established an encrypted communications channel, and computed a) s +5 668 M +( unique session identifier for this session. The transport layer) s +5 657 M +( provides forward secrecy for password authentication and other) s +5 646 M +( methods that rely on secret data.) s +5 624 M +( Full security considerations for this protocol are provided in) s +5 613 M +( Section 8 of [SSH-ARCH]) s +5 591 M +(Normative) s +5 569 M +( [SSH-ARCH]) s +5 558 M +( Ylonen, T., "SSH Protocol Architecture", I-D) s +5 547 M +( draft-ietf-architecture-15.txt, Oct 2003.) s +5 525 M +( [SSH-TRANS]) s +5 514 M +( Ylonen, T., "SSH Transport Layer Protocol", I-D) s +5 503 M +( draft-ietf-transport-17.txt, Oct 2003.) s +5 481 M +( [SSH-USERAUTH]) s +5 470 M +( Ylonen, T., "SSH Authentication Protocol", I-D) s +5 459 M +( draft-ietf-userauth-18.txt, Oct 2003.) s +5 437 M +( [SSH-CONNECT]) s +5 426 M +( Ylonen, T., "SSH Connection Protocol", I-D) s +5 415 M +( draft-ietf-connect-18.txt, Oct 2003.) s +5 393 M +( [SSH-NUMBERS]) s +5 382 M +( Lehtinen, S. and D. Moffat, "SSH Protocol Assigned) s +5 371 M +( Numbers", I-D draft-ietf-secsh-assignednumbers-05.txt, Oct) s +5 360 M +( 2003.) s +5 338 M +( [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate) s +5 327 M +( Requirement Levels", BCP 14, RFC 2119, March 1997.) s +5 305 M +(Informative) s +5 283 M +( [RFC3066] Alvestrand, H., "Tags for the Identification of) s +5 272 M +( Languages", BCP 47, RFC 3066, January 2001.) s +5 250 M +( [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO) s +5 239 M +( 10646", RFC 2279, January 1998.) s +5 129 M +(Ylonen & Moffat Expires March 2, 2003 [Page 13]) s +_R +S +PStoPSsaved restore +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 421.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 14 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH Authentication Protocol September 2002) s +5 690 M +(Authors' Addresses) s +5 668 M +( Tatu Ylonen) s +5 657 M +( SSH Communications Security Corp) s +5 646 M +( Fredrikinkatu 42) s +5 635 M +( HELSINKI FIN-00100) s +5 624 M +( Finland) s +5 602 M +( EMail: [email protected]) s +5 569 M +( Darren J. Moffat \(editor\)) s +5 558 M +( Sun Microsystems, Inc) s +5 547 M +( 17 Network Circle) s +5 536 M +( Menlo Park 95025) s +5 525 M +( USA) s +5 503 M +( EMail: [email protected]) s +5 129 M +(Ylonen & Moffat Expires March 2, 2003 [Page 14]) s +_R +S +PStoPSsaved restore +%%Page: (14,15) 8 +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 0.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +/showpage{}def/copypage{}def/erasepage{}def +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 15 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH Authentication Protocol September 2002) s +5 690 M +(Intellectual Property Statement) s +5 668 M +( The IETF takes no position regarding the validity or scope of any) s +5 657 M +( intellectual property or other rights that might be claimed to) s +5 646 M +( pertain to the implementation or use of the technology described in) s +5 635 M +( this document or the extent to which any license under such rights) s +5 624 M +( might or might not be available; neither does it represent that it) s +5 613 M +( has made any effort to identify any such rights. Information on the) s +5 602 M +( IETF's procedures with respect to rights in standards-track and) s +5 591 M +( standards-related documentation can be found in BCP-11. Copies of) s +5 580 M +( claims of rights made available for publication and any assurances of) s +5 569 M +( licenses to be made available, or the result of an attempt made to) s +5 558 M +( obtain a general license or permission for the use of such) s +5 547 M +( proprietary rights by implementors or users of this specification can) s +5 536 M +( be obtained from the IETF Secretariat.) s +5 514 M +( The IETF invites any interested party to bring to its attention any) s +5 503 M +( copyrights, patents or patent applications, or other proprietary) s +5 492 M +( rights which may cover technology that may be required to practice) s +5 481 M +( this standard. Please address the information to the IETF Executive) s +5 470 M +( Director.) s +5 448 M +( The IETF has been notified of intellectual property rights claimed in) s +5 437 M +( regard to some or all of the specification contained in this) s +5 426 M +( document. For more information consult the online list of claimed) s +5 415 M +( rights.) s +5 382 M +(Full Copyright Statement) s +5 360 M +( Copyright \(C\) The Internet Society \(2002\). All Rights Reserved.) s +5 338 M +( This document and translations of it may be copied and furnished to) s +5 327 M +( others, and derivative works that comment on or otherwise explain it) s +5 316 M +( or assist in its implementation may be prepared, copied, published) s +5 305 M +( and distributed, in whole or in part, without restriction of any) s +5 294 M +( kind, provided that the above copyright notice and this paragraph are) s +5 283 M +( included on all such copies and derivative works. However, this) s +5 272 M +( document itself may not be modified in any way, such as by removing) s +5 261 M +( the copyright notice or references to the Internet Society or other) s +5 250 M +( Internet organizations, except as needed for the purpose of) s +5 239 M +( developing Internet standards in which case the procedures for) s +5 228 M +( copyrights defined in the Internet Standards process must be) s +5 217 M +( followed, or as required to translate it into languages other than) s +5 206 M +( English.) s +5 184 M +( The limited permissions granted above are perpetual and will not be) s +5 173 M +( revoked by the Internet Society or its successors or assignees.) s +5 129 M +(Ylonen & Moffat Expires March 2, 2003 [Page 15]) s +_R +S +PStoPSsaved restore +userdict/PStoPSsaved save put +PStoPSmatrix setmatrix +595.000000 421.271378 translate +90 rotate +0.706651 dup scale +userdict/PStoPSmatrix matrix currentmatrix put +userdict/PStoPSclip{0 0 moveto + 595.000000 0 rlineto 0 842.000000 rlineto -595.000000 0 rlineto + closepath}put initclip +PStoPSxform concat +%%BeginPageSetup +_S +75 0 translate +/pagenum 16 def +/fname () def +/fdir () def +/ftail () def +/user_header_p false def +%%EndPageSetup +5 723 M +(Internet-Draft SSH Authentication Protocol September 2002) s +5 690 M +( This document and the information contained herein is provided on an) s +5 679 M +( "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING) s +5 668 M +( TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING) s +5 657 M +( BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION) s +5 646 M +( HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF) s +5 635 M +( MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.) s +5 602 M +(Acknowledgment) s +5 580 M +( Funding for the RFC Editor function is currently provided by the) s +5 569 M +( Internet Society.) s +5 129 M +(Ylonen & Moffat Expires March 2, 2003 [Page 16]) s +_R +S +PStoPSsaved restore +%%Trailer +%%Pages: 16 +%%DocumentNeededResources: font Courier-Bold Courier +%%EOF diff --git a/lib/ssh/doc/standard/draft-ietf-secsh-userauth-18.txt b/lib/ssh/doc/standard/draft-ietf-secsh-userauth-18.txt new file mode 100644 index 0000000000..9dae578a35 --- /dev/null +++ b/lib/ssh/doc/standard/draft-ietf-secsh-userauth-18.txt @@ -0,0 +1,896 @@ + + + +Network Working Group T. Ylonen +Internet-Draft SSH Communications Security Corp +Expires: March 2, 2003 D. Moffat, Ed. + Sun Microsystems, Inc + September 2002 + + + SSH Authentication Protocol + draft-ietf-secsh-userauth-18.txt + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that other + groups may also distribute working documents as Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at http:// + www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on March 2, 2003. + +Copyright Notice + + Copyright (C) The Internet Society (2002). All Rights Reserved. + +Abstract + + SSH is a protocol for secure remote login and other secure network + services over an insecure network. This document describes the SSH + authentication protocol framework and public key, password, and + host-based client authentication methods. Additional authentication + methods are described in separate documents. The SSH authentication + protocol runs on top of the SSH transport layer protocol and provides + a single authenticated tunnel for the SSH connection protocol. + + + + + + + +Ylonen & Moffat Expires March 2, 2003 [Page 1] + +Internet-Draft SSH Authentication Protocol September 2002 + + +Table of Contents + + 1. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3. Conventions Used in This Document . . . . . . . . . . . . . 3 + 3.1 The Authentication Protocol Framework . . . . . . . . . . . 3 + 3.1.1 Authentication Requests . . . . . . . . . . . . . . . . . . 4 + 3.1.2 Responses to Authentication Requests . . . . . . . . . . . . 5 + 3.1.3 The "none" Authentication Request . . . . . . . . . . . . . 6 + 3.1.4 Completion of User Authentication . . . . . . . . . . . . . 6 + 3.1.5 Banner Message . . . . . . . . . . . . . . . . . . . . . . . 7 + 3.2 Authentication Protocol Message Numbers . . . . . . . . . . 7 + 3.3 Public Key Authentication Method: publickey . . . . . . . . 8 + 3.4 Password Authentication Method: password . . . . . . . . . . 10 + 3.5 Host-Based Authentication: hostbased . . . . . . . . . . . . 11 + 4. Security Considerations . . . . . . . . . . . . . . . . . . 12 + Normative . . . . . . . . . . . . . . . . . . . . . . . . . 13 + Informative . . . . . . . . . . . . . . . . . . . . . . . . 13 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 14 + Intellectual Property and Copyright Statements . . . . . . . 15 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Ylonen & Moffat Expires March 2, 2003 [Page 2] + +Internet-Draft SSH Authentication Protocol September 2002 + + +1. Contributors + + The major original contributors of this document were: Tatu Ylonen, + Tero Kivinen, Timo J. Rinne, Sami Lehtinen (all of SSH Communications + Security Corp), and Markku-Juhani O. Saarinen (University of + Jyvaskyla) + + The document editor is: [email protected]. Comments on this + internet draft should be sent to the IETF SECSH working group, + details at: http://ietf.org/html.charters/secsh-charter.html + +2. Introduction + + The SSH authentication protocol is a general-purpose user + authentication protocol. It is intended to be run over the SSH + transport layer protocol [SSH-TRANS]. This protocol assumes that the + underlying protocols provide integrity and confidentiality + protection. + + This document should be read only after reading the SSH architecture + document [SSH-ARCH]. This document freely uses terminology and + notation from the architecture document without reference or further + explanation. + + The service name for this protocol is "ssh-userauth". + + When this protocol starts, it receives the session identifier from + the lower-level protocol (this is the exchange hash H from the first + key exchange). The session identifier uniquely identifies this + session and is suitable for signing in order to prove ownership of a + private key. This protocol also needs to know whether the lower-level + protocol provides confidentiality protection. + +3. Conventions Used in This Document + + The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", + and "MAY" that appear in this document are to be interpreted as + described in [RFC2119] + + The used data types and terminology are specified in the architecture + document [SSH-ARCH] + + The architecture document also discusses the algorithm naming + conventions that MUST be used with the SSH protocols. + +3.1 The Authentication Protocol Framework + + The server drives the authentication by telling the client which + + + +Ylonen & Moffat Expires March 2, 2003 [Page 3] + +Internet-Draft SSH Authentication Protocol September 2002 + + + authentication methods can be used to continue the exchange at any + given time. The client has the freedom to try the methods listed by + the server in any order. This gives the server complete control over + the authentication process if desired, but also gives enough + flexibility for the client to use the methods it supports or that are + most convenient for the user, when multiple methods are offered by + the server. + + Authentication methods are identified by their name, as defined in + [SSH-ARCH]. The "none" method is reserved, and MUST NOT be listed as + supported. However, it MAY be sent by the client. The server MUST + always reject this request, unless the client is to be allowed in + without any authentication, in which case the server MUST accept this + request. The main purpose of sending this request is to get the list + of supported methods from the server. + + The server SHOULD have a timeout for authentication, and disconnect + if the authentication has not been accepted within the timeout + period. The RECOMMENDED timeout period is 10 minutes. Additionally, + the implementation SHOULD limit the number of failed authentication + attempts a client may perform in a single session (the RECOMMENDED + limit is 20 attempts). If the threshold is exceeded, the server + SHOULD disconnect. + +3.1.1 Authentication Requests + + All authentication requests MUST use the following message format. + Only the first few fields are defined; the remaining fields depend on + the authentication method. + + byte SSH_MSG_USERAUTH_REQUEST + string user name (in ISO-10646 UTF-8 encoding [RFC2279]) + string service name (in US-ASCII) + string method name (US-ASCII) + The rest of the packet is method-specific. + + The user name and service are repeated in every new authentication + attempt, and MAY change. The server implementation MUST carefully + check them in every message, and MUST flush any accumulated + authentication states if they change. If it is unable to flush some + authentication state, it MUST disconnect if the user or service name + changes. + + The service name specifies the service to start after authentication. + There may be several different authenticated services provided. If + the requested service is not available, the server MAY disconnect + immediately or at any later time. Sending a proper disconnect + message is RECOMMENDED. In any case, if the service does not exist, + + + +Ylonen & Moffat Expires March 2, 2003 [Page 4] + +Internet-Draft SSH Authentication Protocol September 2002 + + + authentication MUST NOT be accepted. + + If the requested user does not exist, the server MAY disconnect, or + MAY send a bogus list of acceptable authentication methods, but never + accept any. This makes it possible for the server to avoid + disclosing information on which accounts exist. In any case, if the + user does not exist, the authentication request MUST NOT be accepted. + + While there is usually little point for clients to send requests that + the server does not list as acceptable, sending such requests is not + an error, and the server SHOULD simply reject requests that it does + not recognize. + + An authentication request MAY result in a further exchange of + messages. All such messages depend on the authentication method + used, and the client MAY at any time continue with a new + SSH_MSG_USERAUTH_REQUEST message, in which case the server MUST + abandon the previous authentication attempt and continue with the new + one. + +3.1.2 Responses to Authentication Requests + + If the server rejects the authentication request, it MUST respond + with the following: + + byte SSH_MSG_USERAUTH_FAILURE + string authentications that can continue + boolean partial success + + "Authentications that can continue" is a comma-separated list of + authentication method names that may productively continue the + authentication dialog. + + It is RECOMMENDED that servers only include those methods in the list + that are actually useful. However, it is not illegal to include + methods that cannot be used to authenticate the user. + + Already successfully completed authentications SHOULD NOT be included + in the list, unless they really should be performed again for some + reason. + + "Partial success" MUST be TRUE if the authentication request to which + this is a response was successful. It MUST be FALSE if the request + was not successfully processed. + + When the server accepts authentication, it MUST respond with the + following: + + + + +Ylonen & Moffat Expires March 2, 2003 [Page 5] + +Internet-Draft SSH Authentication Protocol September 2002 + + + byte SSH_MSG_USERAUTH_SUCCESS + + Note that this is not sent after each step in a multi-method + authentication sequence, but only when the authentication is + complete. + + The client MAY send several authentication requests without waiting + for responses from previous requests. The server MUST process each + request completely and acknowledge any failed requests with a + SSH_MSG_USERAUTH_FAILURE message before processing the next request. + + A request that results in further exchange of messages will be + aborted by a second request. It is not possible to send a second + request without waiting for a response from the server, if the first + request will result in further exchange of messages. No + SSH_MSG_USERAUTH_FAILURE message will be sent for the aborted method. + + SSH_MSG_USERAUTH_SUCCESS MUST be sent only once. When + SSH_MSG_USERAUTH_SUCCESS has been sent, any further authentication + requests received after that SHOULD be silently ignored. + + Any non-authentication messages sent by the client after the request + that resulted in SSH_MSG_USERAUTH_SUCCESS being sent MUST be passed + to the service being run on top of this protocol. Such messages can + be identified by their message numbers (see Section Message Numbers + (Section 3.2)). + +3.1.3 The "none" Authentication Request + + A client may request a list of authentication methods that may + continue by using the "none" authentication method. + + If no authentication at all is needed for the user, the server MUST + return SSH_MSG_USERAUTH_SUCCESS. Otherwise, the server MUST return + SSH_MSG_USERAUTH_FAILURE and MAY return with it a list of + authentication methods that can continue. + + This method MUST NOT be listed as supported by the server. + +3.1.4 Completion of User Authentication + + Authentication is complete when the server has responded with + SSH_MSG_USERAUTH_SUCCESS; all authentication related messages + received after sending this message SHOULD be silently ignored. + + After sending SSH_MSG_USERAUTH_SUCCESS, the server starts the + requested service. + + + + +Ylonen & Moffat Expires March 2, 2003 [Page 6] + +Internet-Draft SSH Authentication Protocol September 2002 + + +3.1.5 Banner Message + + In some jurisdictions, sending a warning message before + authentication may be relevant for getting legal protection. Many + UNIX machines, for example, normally display text from `/etc/issue', + or use "tcp wrappers" or similar software to display a banner before + issuing a login prompt. + + The SSH server may send a SSH_MSG_USERAUTH_BANNER message at any time + before authentication is successful. This message contains text to + be displayed to the client user before authentication is attempted. + The format is as follows: + + byte SSH_MSG_USERAUTH_BANNER + string message (ISO-10646 UTF-8) + string language tag (as defined in [RFC3066]) + + The client SHOULD by default display the message on the screen. + However, since the message is likely to be sent for every login + attempt, and since some client software will need to open a separate + window for this warning, the client software may allow the user to + explicitly disable the display of banners from the server. The + message may consist of multiple lines. + + If the message string is displayed, control character filtering + discussed in [SSH-ARCH] SHOULD be used to avoid attacks by sending + terminal control characters. + +3.2 Authentication Protocol Message Numbers + + All message numbers used by this authentication protocol are in the + range from 50 to 79, which is part of the range reserved for + protocols running on top of the SSH transport layer protocol. + + Message numbers of 80 and higher are reserved for protocols running + after this authentication protocol, so receiving one of them before + authentication is complete is an error, to which the server MUST + respond by disconnecting (preferably with a proper disconnect message + sent first to ease troubleshooting). + + After successful authentication, such messages are passed to the + higher-level service. + + These are the general authentication message codes: + + #define SSH_MSG_USERAUTH_REQUEST 50 + #define SSH_MSG_USERAUTH_FAILURE 51 + #define SSH_MSG_USERAUTH_SUCCESS 52 + + + +Ylonen & Moffat Expires March 2, 2003 [Page 7] + +Internet-Draft SSH Authentication Protocol September 2002 + + + #define SSH_MSG_USERAUTH_BANNER 53 + + In addition to the above, there is a range of message numbers + (60..79) reserved for method-specific messages. These messages are + only sent by the server (client sends only SSH_MSG_USERAUTH_REQUEST + messages). Different authentication methods reuse the same message + numbers. + +3.3 Public Key Authentication Method: publickey + + The only REQUIRED authentication method is public key authentication. + All implementations MUST support this method; however, not all users + need to have public keys, and most local policies are not likely to + require public key authentication for all users in the near future. + + With this method, the possession of a private key serves as + authentication. This method works by sending a signature created + with a private key of the user. The server MUST check that the key + is a valid authenticator for the user, and MUST check that the + signature is valid. If both hold, the authentication request MUST be + accepted; otherwise it MUST be rejected. (Note that the server MAY + require additional authentications after successful authentication.) + + Private keys are often stored in an encrypted form at the client + host, and the user must supply a passphrase before the signature can + be generated. Even if they are not, the signing operation involves + some expensive computation. To avoid unnecessary processing and user + interaction, the following message is provided for querying whether + authentication using the key would be acceptable. + + byte SSH_MSG_USERAUTH_REQUEST + string user name + string service + string "publickey" + boolean FALSE + string public key algorithm name + string public key blob + + Public key algorithms are defined in the transport layer + specification [SSH-TRANS]. The public key blob may contain + certificates. + + Any public key algorithm may be offered for use in authentication. + In particular, the list is not constrained by what was negotiated + during key exchange. If the server does not support some algorithm, + it MUST simply reject the request. + + The server MUST respond to this message with either + + + +Ylonen & Moffat Expires March 2, 2003 [Page 8] + +Internet-Draft SSH Authentication Protocol September 2002 + + + SSH_MSG_USERAUTH_FAILURE or with the following: + + byte SSH_MSG_USERAUTH_PK_OK + string public key algorithm name from the request + string public key blob from the request + + To perform actual authentication, the client MAY then send a + signature generated using the private key. The client MAY send the + signature directly without first verifying whether the key is + acceptable. The signature is sent using the following packet: + + byte SSH_MSG_USERAUTH_REQUEST + string user name + string service + string "publickey" + boolean TRUE + string public key algorithm name + string public key to be used for authentication + string signature + + Signature is a signature by the corresponding private key over the + following data, in the following order: + + string session identifier + byte SSH_MSG_USERAUTH_REQUEST + string user name + string service + string "publickey" + boolean TRUE + string public key algorithm name + string public key to be used for authentication + + When the server receives this message, it MUST check whether the + supplied key is acceptable for authentication, and if so, it MUST + check whether the signature is correct. + + If both checks succeed, this method is successful. Note that the + server may require additional authentications. The server MUST + respond with SSH_MSG_USERAUTH_SUCCESS (if no more authentications are + needed), or SSH_MSG_USERAUTH_FAILURE (if the request failed, or more + authentications are needed). + + The following method-specific message numbers are used by the + publickey authentication method. + + /* Key-based */ + #define SSH_MSG_USERAUTH_PK_OK 60 + + + + +Ylonen & Moffat Expires March 2, 2003 [Page 9] + +Internet-Draft SSH Authentication Protocol September 2002 + + +3.4 Password Authentication Method: password + + Password authentication uses the following packets. Note that a + server MAY request the user to change the password. All + implementations SHOULD support password authentication. + + byte SSH_MSG_USERAUTH_REQUEST + string user name + string service + string "password" + boolean FALSE + string plaintext password (ISO-10646 UTF-8) + + Note that the password is encoded in ISO-10646 UTF-8. It is up to + the server how it interprets the password and validates it against + the password database. However, if the client reads the password in + some other encoding (e.g., ISO 8859-1 (ISO Latin1)), it MUST convert + the password to ISO-10646 UTF-8 before transmitting, and the server + MUST convert the password to the encoding used on that system for + passwords. + + Note that even though the cleartext password is transmitted in the + packet, the entire packet is encrypted by the transport layer. Both + the server and the client should check whether the underlying + transport layer provides confidentiality (i.e., if encryption is + being used). If no confidentiality is provided (none cipher), + password authentication SHOULD be disabled. If there is no + confidentiality or no MAC, password change SHOULD be disabled. + + Normally, the server responds to this message with success or + failure. However, if the password has expired the server SHOULD + indicate this by responding with SSH_MSG_USERAUTH_PASSWD_CHANGEREQ. + In anycase the server MUST NOT allow an expired password to be used + for authentication. + + byte SSH_MSG_USERAUTH_PASSWD_CHANGEREQ + string prompt (ISO-10646 UTF-8) + string language tag (as defined in [RFC3066]) + + In this case, the client MAY continue with a different authentication + method, or request a new password from the user and retry password + authentication using the following message. The client MAY also send + this message instead of the normal password authentication request + without the server asking for it. + + byte SSH_MSG_USERAUTH_REQUEST + string user name + string service + + + +Ylonen & Moffat Expires March 2, 2003 [Page 10] + +Internet-Draft SSH Authentication Protocol September 2002 + + + string "password" + boolean TRUE + string plaintext old password (ISO-10646 UTF-8) + string plaintext new password (ISO-10646 UTF-8) + + The server must reply to request message with + SSH_MSG_USERAUTH_SUCCESS, SSH_MSG_USERAUTH_FAILURE, or another + SSH_MSG_USERAUTH_PASSWD_CHANGEREQ. The meaning of these is as + follows: + + SSH_MSG_USERAUTH_SUCCESS The password has been changed, and + authentication has been successfully completed. + + SSH_MSG_USERAUTH_FAILURE with partial success The password has + been changed, but more authentications are needed. + + SSH_MSG_USERAUTH_FAILURE without partial success The password has + not been changed. Either password changing was not supported, or + the old password was bad. Note that if the server has already + sent SSH_MSG_USERAUTH_PASSWD_CHANGEREQ, we know that it supports + changing the password. + + SSH_MSG_USERAUTH_CHANGEREQ The password was not changed because + the new password was not acceptable (e.g. too easy to guess). + + The following method-specific message numbers are used by the + password authentication method. + + #define SSH_MSG_USERAUTH_PASSWD_CHANGEREQ 60 + + +3.5 Host-Based Authentication: hostbased + + Some sites wish to allow authentication based on the host where the + user is coming from, and the user name on the remote host. While + this form of authentication is not suitable for high-security sites, + it can be very convenient in many environments. This form of + authentication is OPTIONAL. When used, special care SHOULD be taken + to prevent a regular user from obtaining the private host key. + + The client requests this form of authentication by sending the + following message. It is similar to the UNIX "rhosts" and + "hosts.equiv" styles of authentication, except that the identity of + the client host is checked more rigorously. + + This method works by having the client send a signature created with + the private key of the client host, which the server checks with that + host's public key. Once the client host's identity is established, + + + +Ylonen & Moffat Expires March 2, 2003 [Page 11] + +Internet-Draft SSH Authentication Protocol September 2002 + + + authorization (but no further authentication) is performed based on + the user names on the server and the client, and the client host + name. + + byte SSH_MSG_USERAUTH_REQUEST + string user name + string service + string "hostbased" + string public key algorithm for host key + string public host key and certificates for client host + string client host name (FQDN; US-ASCII) + string user name on the client host (ISO-10646 UTF-8) + string signature + + Public key algorithm names for use in "public key algorithm for host + key" are defined in the transport layer specification. The "public + host key for client host" may include certificates. + + Signature is a signature with the private host key of the following + data, in this order: + + string session identifier + byte SSH_MSG_USERAUTH_REQUEST + string user name + string service + string "hostbased" + string public key algorithm for host key + string public host key and certificates for client host + string client host name (FQDN; US-ASCII) + string user name on the client host(ISO-10646 UTF-8) + + The server MUST verify that the host key actually belongs to the + client host named in the message, that the given user on that host is + allowed to log in, and that the signature is a valid signature on the + appropriate value by the given host key. The server MAY ignore the + client user name, if it wants to authenticate only the client host. + + It is RECOMMENDED that whenever possible, the server perform + additional checks to verify that the network address obtained from + the (untrusted) network matches the given client host name. This + makes exploiting compromised host keys more difficult. Note that + this may require special handling for connections coming through a + firewall. + +4. Security Considerations + + The purpose of this protocol is to perform client user + authentication. It assumed that this runs over a secure transport + + + +Ylonen & Moffat Expires March 2, 2003 [Page 12] + +Internet-Draft SSH Authentication Protocol September 2002 + + + layer protocol, which has already authenticated the server machine, + established an encrypted communications channel, and computed a + unique session identifier for this session. The transport layer + provides forward secrecy for password authentication and other + methods that rely on secret data. + + Full security considerations for this protocol are provided in + Section 8 of [SSH-ARCH] + +Normative + + [SSH-ARCH] + Ylonen, T., "SSH Protocol Architecture", I-D + draft-ietf-architecture-15.txt, Oct 2003. + + [SSH-TRANS] + Ylonen, T., "SSH Transport Layer Protocol", I-D + draft-ietf-transport-17.txt, Oct 2003. + + [SSH-USERAUTH] + Ylonen, T., "SSH Authentication Protocol", I-D + draft-ietf-userauth-18.txt, Oct 2003. + + [SSH-CONNECT] + Ylonen, T., "SSH Connection Protocol", I-D + draft-ietf-connect-18.txt, Oct 2003. + + [SSH-NUMBERS] + Lehtinen, S. and D. Moffat, "SSH Protocol Assigned + Numbers", I-D draft-ietf-secsh-assignednumbers-05.txt, Oct + 2003. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + +Informative + + [RFC3066] Alvestrand, H., "Tags for the Identification of + Languages", BCP 47, RFC 3066, January 2001. + + [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO + 10646", RFC 2279, January 1998. + + + + + + + + + +Ylonen & Moffat Expires March 2, 2003 [Page 13] + +Internet-Draft SSH Authentication Protocol September 2002 + + +Authors' Addresses + + Tatu Ylonen + SSH Communications Security Corp + Fredrikinkatu 42 + HELSINKI FIN-00100 + Finland + + EMail: [email protected] + + + Darren J. Moffat (editor) + Sun Microsystems, Inc + 17 Network Circle + Menlo Park 95025 + USA + + EMail: [email protected] + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Ylonen & Moffat Expires March 2, 2003 [Page 14] + +Internet-Draft SSH Authentication Protocol September 2002 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + intellectual property or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; neither does it represent that it + has made any effort to identify any such rights. Information on the + IETF's procedures with respect to rights in standards-track and + standards-related documentation can be found in BCP-11. Copies of + claims of rights made available for publication and any assurances of + licenses to be made available, or the result of an attempt made to + obtain a general license or permission for the use of such + proprietary rights by implementors or users of this specification can + be obtained from the IETF Secretariat. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights which may cover technology that may be required to practice + this standard. Please address the information to the IETF Executive + Director. + + The IETF has been notified of intellectual property rights claimed in + regard to some or all of the specification contained in this + document. For more information consult the online list of claimed + rights. + + +Full Copyright Statement + + Copyright (C) The Internet Society (2002). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assignees. + + + +Ylonen & Moffat Expires March 2, 2003 [Page 15] + +Internet-Draft SSH Authentication Protocol September 2002 + + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Ylonen & Moffat Expires March 2, 2003 [Page 16]
\ No newline at end of file |