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,
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.
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.
4.5.3. Future Assignments
Requests for assignments of new opcodes and their associated
arguments MUST be done through the IETF CONSENSUS method, as
described in [RFC2434].
4.6. Names
In the following sections, the values for the name spaces are
textual. The conventions and instructions to the IANA for future
assignments are given in this section. The initial assignments are
given in their respective sections.
4.6.1. Conventions for Names
All names registered by the IANA in the following sections MUST be
printable US-ASCII strings, and MUST NOT contain the characters at-
sign ("@"), comma (","), whitespace, control characters (ASCII codes
32 or less), or the ASCII code 127 (DEL). Names are case-sensitive,
and MUST NOT be longer than 64 characters.
A provision is made here for locally extensible names. The IANA will
not register, and will not control, names with the at-sign in them.
Names with the at-sign in them will have the format of
"name@domainname" (without the double quotes) where the part
preceding the at-sign is the name. The format of the part preceding
the at-sign is not specified; however, these names MUST be printable
US-ASCII strings, and MUST NOT contain the comma character (","),
whitespace, control characters (ASCII codes 32 or less), or the ASCII
code 127 (DEL). They MUST have only a single at-sign in them. The
part following the at-sign MUST be a valid, fully qualified internet
domain name [RFC1034] controlled by the person or organization
defining the name. Names are case-sensitive, and MUST NOT be longer
than 64 characters. It is up to each domain how it manages its local
namespace. It has been noted that these names resemble STD 11
[RFC0822] email addresses. This is purely coincidental and has
nothing to do with STD 11 [RFC0822]. An example of a locally defined
name is "ourcipher-cbc@example.com" (without the double quotes).
4.6.2. Future Assignments of Names
Requests for assignments of new names MUST be done through the IETF
CONSENSUS method, as described in [RFC2434].
4.7. Service Names
The ’service name’ is used to describe a protocol layer. The
following table lists the initial assignments of the ’service name’
values.
Service Name Reference
------------- ---------
ssh-userauth [SSH-USERAUTH]
ssh-connection [SSH-CONNECT]
4.8. Authentication Method Names
The Authentication Method Name is used to describe an authentication
method for the "ssh-userauth" service [SSH-USERAUTH]. The following
table identifies the initial assignments of the Authentication Method
Names.
Method Name Reference
------------ ---------
publickey [SSH-USERAUTH, Section 7]
password [SSH-USERAUTH, Section 8]
hostbased [SSH-USERAUTH, Section 9]
none [SSH-USERAUTH, Section 5.2]
4.9. Connection Protocol Assigned Names
The following table lists the initial assignments to the Connection
Protocol Type and Request names.
4.9.1. Connection Protocol Channel Types
The following table lists the initial assignments of the Connection
Protocol Channel Types.
Channel type Reference
------------ ---------
session [SSH-CONNECT, Section 6.1]
x11 [SSH-CONNECT, Section 6.3.2]
forwarded-tcpip [SSH-CONNECT, Section 7.2]
direct-tcpip [SSH-CONNECT, Section 7.2]
4.9.2. Connection Protocol Global Request Names
The following table lists the initial assignments of the Connection
Protocol Global Request Names.
Request type Reference
------------ ---------
tcpip-forward [SSH-CONNECT, Section 7.1]
cancel-tcpip-forward [SSH-CONNECT, Section 7.1]
4.9.3. Connection Protocol Channel Request Names
The following table lists the initial assignments of the Connection
Protocol Channel Request Names.
Request type Reference
------------ ---------
pty-req [SSH-CONNECT, Section 6.2]
x11-req [SSH-CONNECT, Section 6.3.1]
env [SSH-CONNECT, Section 6.4]
shell [SSH-CONNECT, Section 6.5]
exec [SSH-CONNECT, Section 6.5]
subsystem [SSH-CONNECT, Section 6.5]
window-change [SSH-CONNECT, Section 6.7]
xon-xoff [SSH-CONNECT, Section 6.8]
signal [SSH-CONNECT, Section 6.9]
exit-status [SSH-CONNECT, Section 6.10]
exit-signal [SSH-CONNECT, Section 6.10]
4.9.4. Initial Assignment of Signal Names
The following table lists the initial assignments of the Signal
Names.
Signal Reference
------ ---------
ABRT [SSH-CONNECT]
ALRM [SSH-CONNECT]
FPE [SSH-CONNECT]
HUP [SSH-CONNECT]
ILL [SSH-CONNECT]
INT [SSH-CONNECT]
KILL [SSH-CONNECT]
PIPE [SSH-CONNECT]
QUIT [SSH-CONNECT]
SEGV [SSH-CONNECT]
TERM [SSH-CONNECT]
USR1 [SSH-CONNECT]
USR2 [SSH-CONNECT]
4.9.5. Connection Protocol Subsystem Names
There are no initial assignments of the Connection Protocol Subsystem
Names.
4.10. Key Exchange Method Names
The name "diffie-hellman-group1-sha1" is used for a key exchange
method using an Oakley group, as defined in [RFC2409]. SSH maintains
its own group identifier space, which is logically distinct from
Oakley [RFC2412] and IKE; however, for one additional group, the
Working Group adopted the number assigned by [RFC3526], using
"diffie-hellman-group14-sha1" for the name of the second defined
group. Implementations should treat these names as opaque
identifiers and should not assume any relationship between the groups
used by SSH and the groups defined for IKE.
The following table identifies the initial assignments of the key
exchange methods.
Method name Reference
------------ ---------
diffie-hellman-group1-sha1 [SSH-TRANS, Section 8.1]
diffie-hellman-group14-sha1 [SSH-TRANS, Section 8.2]
4.11. Assigned Algorithm Names
4.11.1. Encryption Algorithm Names
The following table identifies the initial assignment of the
Encryption Algorithm Names.
Encryption Algorithm Name Reference
------------------------- ---------
3des-cbc [SSH-TRANS, Section 6.3]
blowfish-cbc [SSH-TRANS, Section 6.3]
twofish256-cbc [SSH-TRANS, Section 6.3]
twofish-cbc [SSH-TRANS, Section 6.3]
twofish192-cbc [SSH-TRANS, Section 6.3]
twofish128-cbc [SSH-TRANS, Section 6.3]
aes256-cbc [SSH-TRANS, Section 6.3]
aes192-cbc [SSH-TRANS, Section 6.3]
aes128-cbc [SSH-TRANS, Section 6.3]
serpent256-cbc [SSH-TRANS, Section 6.3]
serpent192-cbc [SSH-TRANS, Section 6.3]
serpent128-cbc [SSH-TRANS, Section 6.3]
arcfour [SSH-TRANS, Section 6.3]
idea-cbc [SSH-TRANS, Section 6.3]
cast128-cbc [SSH-TRANS, Section 6.3]
none [SSH-TRANS, Section 6.3]
des-cbc [FIPS-46-3] HISTORIC; See
page 4 of [FIPS-46-3]
4.11.2. MAC Algorithm Names
The following table identifies the initial assignments of the MAC
Algorithm Names.
MAC Algorithm Name Reference
------------------ ---------
hmac-sha1 [SSH-TRANS, Section 6.4]
hmac-sha1-96 [SSH-TRANS, Section 6.4]
hmac-md5 [SSH-TRANS, Section 6.4]
hmac-md5-96 [SSH-TRANS, Section 6.4]
none [SSH-TRANS, Section 6.4]
4.11.3. Public Key Algorithm Names
The following table identifies the initial assignments of the Public
Key Algorithm names.
Public Key Algorithm Name Reference
------------------------- ---------
ssh-dss [SSH-TRANS, Section 6.6]
ssh-rsa [SSH-TRANS, Section 6.6]
pgp-sign-rsa [SSH-TRANS, Section 6.6]
pgp-sign-dss [SSH-TRANS, Section 6.6]
4.11.4. Compression Algorithm Names
The following table identifies the initial assignments of the
Compression Algorithm names.
Compression Algorithm Name Reference
-------------------------- ---------
none [SSH-TRANS, Section 6.2]
zlib [SSH-TRANS, Section 6.2]
5. Security Considerations
This protocol provides a secure encrypted channel over an insecure
network.
Full security considerations for this protocol are provided in
[SSH-ARCH].
6. References
6.1. Normative References
[SSH-ARCH] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell
(SSH) Protocol Architecture", RFC 4251, January 2006.
[SSH-TRANS] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell
(SSH) Transport Layer Protocol", RFC 4253, January
2006.
[SSH-USERAUTH] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell
(SSH) Authentication Protocol", RFC 4252, January
2006.
[SSH-CONNECT] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell
(SSH) Connection Protocol", RFC 4254, January 2006.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing
an IANA Considerations Section in RFCs", BCP 26, RFC
2434, October 1998.
[RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential
(MODP) Diffie-Hellman groups for Internet Key Exchange
(IKE)", RFC 3526, May 2003.
6.2. Informative References
[RFC0822] Crocker, D., "Standard for the format of ARPA Internet
text messages", STD 11, RFC 822, August 1982.
[RFC1034] Mockapetris, P., "Domain names - concepts and
facilities", STD 13, RFC 1034, November 1987.
[RFC2412] Orman, H., "The OAKLEY Key Determination Protocol",
RFC 2412, November 1998.
[FIPS-46-3] US National Institute of Standards and Technology,
"Data Encryption Standard (DES)", Federal Information
Processing Standards Publication 46-3, October 1999.
Authors’ Addresses
Sami Lehtinen
SSH Communications Security Corp
Valimotie 17
00380 Helsinki
Finland
EMail: sjl@ssh.com
Chris Lonvick (editor)
Cisco Systems, Inc.
12515 Research Blvd.
Austin 78759
USA
EMail: clonvick@cisco.com
Trademark Notice
"ssh" is a registered trademark in the United States and/or other
countries.
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights 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; nor does it represent that it has
made any independent effort to identify any such rights. Information