- Vssh 1 11 1 – Ssh Protocol Connectivity Tools Pdf
- Vssh 1 11 1 – Ssh Protocol Connectivity Tools Download
- Vssh 1 11 1 – Ssh Protocol Connectivity Tools Free
The communication is managed according to client – server architecture (SSH Client and SSH server). SSH protocol has developed with two versions named SSH1 and SSH2. SSH1 (Secure Shell Version 1) SSH protocol version 1 was found in 1995 and it consists of three major protocols, called SSH-TRANS, SSH-USERAUTH, and SSH-CONNECT. RFC 4253 SSH Transport Layer Protocol January 2006 way that is compatible with the installed SSH clients and servers that use the older version of the protocol. Information in this section is only relevant for implementations supporting compatibility with SSH versions 1.x. For those interested, the only known documentation of the 1.x protocol is contained in README files that are shipped along.
Get OpenSSH v3.4p1 -- download it or get it in the latest AIX 5L Expansion Pack and Web Download Pack
What is Open Secure Shell?
Open Secure Shell (OpenSSH) is an open source version of the SSH protocol suite of network connectivity tools. The tools provide shell functions that are authenticated and encrypted. A shell is a command language interpreter that reads input from a command line string, stdin or a file. Why use OpenSSH? When you're running over unsecure public networks like the Internet, you can use the SSH command suite instead of the unsecure commands telnet, ftp, and r-commands.
OpenSSH delivers code that communicates using SSH1 and SSH2 protocols. What's the difference? The SSH2 protocol is a rewrite of SSH1. SSH2 contains separate, layered protocols, but SSH1 is one large set of code. SSH2 supports both RSA & DSA keys, but SSH1 supports only RSA, and SSH2 uses a strong crypto integrity check, where SSH1 uses a CRC-32 check. The Internet Engineering Task Force (IETF) maintains the secure shell standards.
What's new?
OpenSSH has been updated to the 3.4p1 version of the open source code from openssh.org. You can download it from OpenSSH on AIX.
The primary new feature is user privilege separation, a security enhancement that prevents super user escalation risks by reducing the amount of code that runs with special privileges. User privilege separation is enabled by default in the OpenSSH server configuration file
/etc/ssh/sshd_config
:The way it works is that a separate server process is created for each connection and when a request comes from a client, the
ssh
monitor process forks an unpriviledged child process that handles all of the requests from the client. If the client's request requires super user privileges the request is sent to the privileged monitor process. When you view the SSH processes started, you will see the sshd
daemon for the monitor process and an unprivileged process owned by the client. For further detailed information about privilege separation, see the August 2002 article by Niels Provos, Preventing Privilege Escalation.Since AIX 5.2 is a new release of the AIX operating system, a separate compilation of the OpenSSH source code was completed on this level of the operating system. The VRMF of the 5.2 level of code is 3.4.0.5200, to distinguish the install images from the 5.1 version. The new VRMF will also help if migrating from AIX 5.1 to AIX 5.2. OpenSSH is compiled using the
C for AIX (cc)
version 5.0 compiler. The VRMF of the installation images will closely match the open source code level, except for the 'F' (Fix level). The fix level will be increased each time a release is made that contains fixes between major open source releases. For example, if we change the 3.4p1 level of code to contain a patch from the 3.5 level of the open source code, the 'F' will be incremented (for example, 3.4.0.5201).The OpenSSH source code has been enhanced with National Language Support (NLS) enablement since the initial 2.9.9 release in April 2002. In the October 2002 release, the message catalog file openssh.cat has been translated into 35 languages. The message catalog files are packaged in installp format with a name like openssh.msg.<LANGUAGE_ABBREVIATION> where LANGUAGE_ABBREVIATION is the 4-character locale code for the country (for example, DE_DE is UTF German). The message catalog filesets are available from the AIX 5L Expansion Pack and Web Download Pack and come bundled in the .tar.Z file. When installing OpenSSH filesets on different locales, the installation software installp determines the correct version of the message catalog fileset to install and the translated message catalog file gets copied into /usr/lib/nls/msg/<LANGUAGE_ABBREVIATION>.
Additional fixes in this release
In the latest OpenSSH version 3.4p1 binaries, we included several patches specific for AIX from the openssh.org site. Xscope 4 3 2 – onscreen graphic measurement tools. The patches are for the following fixes:
- password expiration enforced
- updated files /etc/security/login and failedlogin
- updated the unsuccessful login count
- LOGIN environment variable set
- streaming large amounts of data no longer hangs the session
AIX 5.2 enhancements
Since AIX 5.2 fully supports Pluggable Authentication Modules (PAM), OpenSSH 3.4.0.5200 has been compiled with PAM support. PAM is a framework where a system administrator can add or stack multiple different authentication modules by writing customized modules and configuring the system to use them. On AIX 5.2, the PAM framework consists of a library, pluggable modules and a configuration file. Because OpenSSH is compiled with PAM, the configuration file
/etc/pam.conf
will be created on the server at openssh.base.server
package installation time. (In the future, /etc/pam.conf
will be created at openssh.base.server
installation time).The default PAM module can be
pam_aix
, where pam_aix
is provided by the base AIX operating system (automatically installed on AIX 5.2 in /usr/lib/security
). The pam_aix
module allows access to the AIX security services by providing access to AIX builtin functions such as the AIX pam_aix authentication()
call. The /etc/pam.conf
for OpenSSH will look like this:The permissions on
/etc/pam.conf
will be 644.Cryptographic applications depend on random numbers. If the random numbers are not highly random and are not protected during generation, the security of the encryption may be weakened.
OpenSSH on AIX 5.1 is compiled using the entropy gathering mechanism (random numbers) provided with the OpenSSH source code (
ssh-rand-helper
), as opposed to AIX 4.3.3 (AIX Linux Toolbox) which uses the PRNGD
open source daemon (prngd-0.9.23-3.aix4.3.ppc.rpm package
). The AIX 5.2 base security provides new pseudo random number generator devices,
/dev/random
and /dev/urandomM
, pseudo-device driver and configuration routines that select various hardware device interrupts to provide entropy. OpenSSH in AIX 5.2 is compiled to take advantage of the new device /dev/urandom
. You will also need the latest OpenSSL version, openssl-0.9.6e-2.aix4.3.ppc.rpm
(AIX Linux Toolbox), for OpenSSH to use the /dev/urandom device
.Where to get documentation
- The OpenSSH fileset includes man pages with
openssh.man.en_US
. - On the web, openBSD provides very good man pages.
- For installation instructions on the different levels of AIX (AIX 4.3.3, AIX 5.1 and AIX 5.2), see the IBM redbook Managing AIX Server Farms. Chapter 4.2 provides details about software prerequisites and about how to manage the OpenSSH server and use the client commands.
- The AIX 5.2 Security Guide has information about AIX and PAM.
Packaging
Four installation packages contain the
installp
format of the code:Installation package | Description |
---|---|
openssh.base | Contains the binary executable files for the client and server pieces of secure shell. There are two separate filesets, openssh.base.client and openssh.base.server . You may install the client portion only, but if you install the server portion, the client pieces automatically get installed. |
penssh.license | The IPLA non-warranted with Limited Program Services license text. This is the fileset that ensures that you read and accept the software license before installation. |
openssh.man.en_US | Man pages as shipped with the openssh.org source code. The man pages install into /usr/share/man directory and can be viewed using the man command. There are man pages for each command and the ssh_config and sshd_config configuration files. |
openssh.msg.<LANGUAGE_ABBREVIATION> | Translated message catalog file. The only .msg fileset that gets installed relates to the locale you have installed on the operating system. |
The installation packaging contains the scripts necessary to install the executables into the correct directories.
The following files are in the
openssh.base.client
fileset and are installed in /usr/bin
:The following files are in the
openssh.base.server
fileset and are installed in /usr/sbin
:The following configuration files are installed in
/etc/ssh
:The packaging creates the
sshd
user, group, and /var/empty
directory needed for server execution on 3.4p1 level of code. The packaging also enables the SRC control of the daemon, generates host keys and checks for the prerequisite of OpenSSL before installing.Downloadable resources
Related topics
- Download the opensshi-aix package from OpenSSH on AIX.
- See the openBSD man pages.
- See Preventing Privilege Escalation, article by Niels Provos, August 2002.
Network Working Group | T. Ylonen |
Internet-Draft | T. Kivinen |
Expires: March 21, 2003 | SSH Communications Security Corp |
M. Saarinen | |
University of Jyvaskyla | |
T. Rinne | |
S. Lehtinen | |
SSH Communications Security Corp | |
September 20, 2002 |
draft-ietf-secsh-connect-16.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance withall provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet EngineeringTask Force (IETF), its areas, and its working groups. Note that othergroups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six monthsand may be updated, replaced, or obsoleted by other documents at anytime. It is inappropriate to use Internet-Drafts as reference materialor to cite them other than as 'work in progress.'
The list of current Internet-Drafts can be accessed athttp://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed athttp://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 21, 2003.
Copyright Notice
Copyright © The Internet Society (2002). All RightsReserved.
Abstract
SSH is a protocol for secure remotelogin and other secure network services over an insecure network.
This document describes the SSH Connection Protocol. It providesinteractive login sessions, remote execution of commands, forwardedTCP/IPconnections, and forwarded X11 connections. All of these channels aremultiplexed into a single encrypted tunnel.
The SSH Connection Protocol has been designed to run on top of theSSH transport layer and user authentication protocols.
Table of Contents
- Channel Mechanism
- Interactive Sessions
- X11 Forwarding
- TCP/IP Port Forwarding
- Additional Information
References
Authors' Addresses
Full Copyright Statement
1. Introduction
The SSH Connection Protocol hasbeen designed to run on top of the SSH transport layer and userauthentication protocols. It provides interactive login sessions,remote execution of commands, forwarded TCP/IPconnections, and forwarded X11 connections. The service name for thisprotocol (after user authentication) is 'ssh-connection'.
This document should be read only after reading the SSH architecturedocument [SSH-ARCH]. This document freelyuses terminology and notation from the architecture document withoutreference or further explanation.
2. Global Requests
There are several kinds of requests that affect the state of theremote end 'globally', independent of any channels. An example is arequest to start TCP/IP forwarding for a specific port. All suchrequests use the following format.
Request names follow the DNSextensibility naming convention outlined in [SSH-ARCH].
The recipient will respond to this message with
SSH_MSG_REQUEST_SUCCESS
orSSH_MSG_REQUEST_FAILURE
if `want reply'
isTRUE
.Usually the response specific data is non-existent.
If the recipient does not recognize or support the request, it simplyresponds with
SSH_MSG_REQUEST_FAILURE
.3. Channel Mechanism
All terminal sessions, forwarded connections, etc. are channels.Either side may open a channel. Multiple channels are multiplexed intoa single connection.
Channels are identified by numbers at each end. The number referringto a channel may be different on each side. Requests to open a channelcontain the sender's channel number. Any other channel-relatedmessages contain the recipient's channel number for the channel.
Channels are flow-controlled. No data may be sent to a channel untila message is received to indicate that window space is available.
3.1 Opening a Channel
When either side wishes to open a new channel, it allocates a localnumber for the channel. It then sends the following message to theother side, and includes the local channel number and initial windowsize in the message.
The channel type is a name as described in the SSH architecturedocument, with similar extension mechanisms.
`senderchannel'
is a local identifier for the channel used by the senderof this message. `initial window size'
specifies how manybytes of channel data can be sent to the sender of this message withoutadjusting the window. `Maximum packet size'
specifies themaximum size of an individual data packet that can be sent to the sender(for example, one might want to use smaller packets for interactiveconnections to get better interactive response on slow links).The remote side then decides whether it can open the channel, andresponds with either
where
`recipient channel'
is the channel number given inthe original open request, and `sender channel'
is thechannel number allocated by the other side, orIf the recipient of the
SSH_MSG_CHANNEL_OPEN
messagedoes not support the specified channel type, it simply responds withSSH_MSG_CHANNEL_OPEN_FAILURE
. The client MAY show theadditional information to the user. If this is done, the clientsoftware should take the precautions discussed in [SSH-ARCH].The following reason codes are defined:
3.2 Data Transfer
The window size specifies how many bytes the other party can sendbefore it must wait for the window to be adjusted. Both parties use thefollowing message to adjust the window.
After receiving this message, the recipient MAY send the given numberof bytes more than it was previously allowed to send; the window size isincremented.
Data transfer is done with messages of the following type.
The maximum amount of data allowed is the current window size. Thewindow size is decremented by the amount of data sent. Both parties MAYignore all extra data sent after the allowed window is empty.
Additionally, some channels can transfer several types of data. Anexample of this is stderr data from interactive sessions. Such data canbe passed with
SSH_MSG_CHANNEL_EXTENDED_DATA
messages,where a separate integer specifies the type of the data. The availabletypes and their interpretation depend on the type of the channel.Data sent with these messages consumes the same window as ordinarydata.
Currently, only the following type is defined.
3.3 Closing a Channel
When a party will no longer send more data to a channel, it SHOULDsend
SSH_MSG_CHANNEL_EOF
.No explicit response is sent to this message; however, theapplication may send EOF towhatever is at the other end of the channel. Note that the channelremains open after this message, and more data may still be sent in theother direction. This message does not consume window space and can besent 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, aparty MUST send back a SSH_MSG_CHANNEL_CLOSE
unless it hasalready sent this message for the channel. The channel is consideredclosed for a party when it has both sent and receivedSSH_MSG_CHANNEL_CLOSE
, and the party may then reuse thechannel number. A party MAY send SSH_MSG_CHANNEL_CLOSE
without having sent or received SSH_MSG_CHANNEL_EOF
.This message does not consume window space and can be sent even if nowindow space is available.
It is recommended that any data sent before this message is deliveredto the actual destination, if possible.
3.4 Channel-SpecificRequests
Many channel types have extensions that are specific to thatparticular channel type. An example is requesting a pty (pseudoterminal) for an interactive session.
All channel-specific requests use the following format.
If
want reply
is FALSE
, no response will besent to the request. Otherwise, the recipient responds with eitherSSH_MSG_CHANNEL_SUCCESS
orSSH_MSG_CHANNEL_FAILURE
, or request-specific continuationmessages. If the request is not recognized or is not supported for thechannel, SSH_MSG_CHANNEL_FAILURE
is returned.This message does not consume window space and can be sent even if nowindow space is available. Request types are local to each channeltype. Workspaces v0 9 3.
The client is allowed to send further messages without waiting forthe response to the request.
request type names follow the DNS extensibility naming conventionoutlined in [SSH-ARCH]
These messages do not consume window space and can be sent even if nowindow space is available.
4. Interactive Sessions
A session is a remote execution of a program. The program may be ashell, an application, a system command, or some built-in subsystem. Itmay or may not have a tty, and may or maynot involve X11 forwarding. Multiple sessions can be activesimultaneously.
4.1 Opening a Session
A session is started by sending the following message.
Client implementations SHOULD reject any session channel openrequests to make it more difficult for a corrupt server to attack theclient.
4.2 Requesting aPseudo-Terminal
A pseudo-terminal can be allocated for the session by sending thefollowing message.
The encoding of terminal modes is described in Section Encoding ofTerminal Modes (Section 6). Zero dimensionparameters MUST be ignored. The character/row dimensions override thepixel dimensions (when nonzero). Pixel dimensions refer to the drawablearea of the window.
The dimension parameters are only informational.
The client SHOULD ignore pty requests.
4.3 X11 Forwarding
4.3.1 Requesting X11Forwarding
X11 forwarding may be requested for a session by sending
It is recommended that the authentication cookie that is sent be afake, random cookie, and that the cookie is checked and replaced by thereal cookie when a connection request is received.
X11 connection forwarding should stop when the session channel isclosed; however, already opened forwardings should not be automaticallyclosed when the session channel is closed.
If
`single connection'
is TRUE
, only asingle connection should be forwarded. No more connections will beforwarded after the first, or after the session channel has beenclosed.The
`x11 authentication protocol'
is the name of the X11authentication method used, e.g. 'MIT-MAGIC-COOKIE-1'
.The
x11 authentication cookie
MUST be hexadecimalencoded.X Protocol is documented in [SCHEIFLER].
4.3.2 X11 Channels
X11 channels are opened with a channel open request. The resultingchannels are independent of the session, and closing the session channeldoes not close the forwarded X11 channels.
The recipient should respond with
SSH_MSG_CHANNEL_OPEN_CONFIRMATION
orSSH_MSG_CHANNEL_OPEN_FAILURE
.Implementations MUST reject any X11 channel open requests if theyhave not requested X11 forwarding.
4.4 Environment VariablePassing
Environment variables may be passed to the shell/command to bestarted later. Uncontrolled setting of environment variables in aprivileged process can be a security hazard. It is recommended thatimplementations either maintain a list of allowable variable names oronly set environment variables after the server process has droppedsufficient privileges.
4.5 Starting a Shell or aCommand
Once the session has been set up, a program is started at the remoteend. The program can be a shell, an application program or a subsystemwith a host-independent name. Only one of these requests can succeedper channel.
This message will request the user's default shell (typically definedin
/etc/passwd
in UNIX systems) to be started at the otherend.This message will request the server to start the execution of thegiven command. The command string may contain a path. Normalprecautions MUST be taken to prevent the execution of unauthorizedcommands.
This last form executes a predefined subsystem. It is expected thatthese will include a general file transfer mechanism, and possibly otherfeatures. Implementations may also allow configuring more suchmechanisms. As the user's shell is usually used to execute thesubsystem, it is advisable for the subsystem protocol to have a 'magiccookie' at the beginning of the protocol transaction to distinguish itfrom arbitrary output generated by shell initialization scripts etc.This spurious output from the shell may be filtered out either at theserver or at the client.
The server SHOULD not halt the execution of the protocol stack whenstarting a shell or a program. All input and output from these SHOULDbe 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 conventionoutlined in [SSH-ARCH].
4.6 Session Data Transfer
Data transfer for a session is done using
SSH_MSG_CHANNEL_DATA
andSSH_MSG_CHANNEL_EXTENDED_DATA
packets and the windowmechanism. The extended data type SSH_EXTENDED_DATA_STDERR
has been defined for stderr data.4.7 Window Dimension ChangeMessage
When the window (terminal) size changes on the client side, it MAYsend a message to the other side to inform it of the new dimensions.
No response SHOULD be sent to this message.
4.8 Local Flow Control
On many systems, it is possible to determine if a pseudo-terminal isusing 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 speedup responses to user requests. This is facilitated by the followingnotification. Initially, the server is responsible for flow control.(Here, again, client means the side originating the session, and servermeans the other side.)
The message below is used by the server to inform the client when itcan or cannot perform flow control (control-S/control-Q processing). If
`client can do'
is TRUE, the client is allowed to do flowcontrol using control-S and control-Q. The client MAY ignore thismessage.No response is sent to this message.
4.9 Signals
A signal can be delivered to the remote process/service using thefollowing message. Some systems may not implement signals, in whichcase they SHOULD ignore this message.
Signal names will be encoded as discussed in the'
exit-signal
' SSH_MSG_CHANNEL_REQUEST
.4.10 Returning ExitStatus
When the command running at the other end terminates, the followingmessage can be sent to return the exit status of the command. Returningthe 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.
The remote command may also terminate violently due to a signal.Such a condition can be indicated by the following message. A zeroexit_status usually means that the command terminated successfully.
The signal name is one of the following (these are from [POSIX])
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 namesit 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 explanationof the error message. The message may consist of multiple lines. Theclient software MAY display this message to the user. If this is done,the client software should take the precautions discussed in [SSH-ARCH].5. TCP/IP Port Forwarding
5.1 Requesting PortForwarding
A party need not explicitly request forwardings from its own end tothe other direction. However, if it wishes that connections to a porton the other side be forwarded to the local side, it must explicitlyrequest this.
`Address to bind'
and `port number to bind'
specify the IP address andport 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 theclient can still filter connections based on information passed in theopen request.)Implementations should only allow forwarding privileged ports if theuser has been authenticated as a privileged user.
Client implementations SHOULD reject these messages; they arenormally 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 availableunprivileged port number and replies with the following message,otherwise there is no response specific data.A port forwarding can be cancelled with the following message. Notethat channel open requests may be received until a reply to this messageis received.
Client implementations SHOULD reject these messages; they arenormally only sent by the client.
5.2 TCP/IP ForwardingChannels
When a connection comes to a port for which remote forwarding hasbeen requested, a channel is opened to forward the port to the otherside.
Implementations MUST reject these messages unless they havepreviously requested a remote TCP/IPport forwarding with the given port number.
When a connection comes to a locally forwarded TCP/IP port, thefollowing packet is sent to the other side. Note that these messagesMAY be sent also for ports for which no forwarding has been explicitlyrequested. The receiving side must decide whether to allow theforwarding.
`Host to connect'
and `port to connect'
specify the TCP/IP host and port where the recipient should connect thechannel. `Host to connect' may be either a domain name or a numeric IPaddress.`Originator IP address'
is the numeric IP address of themachine where the connection request comes from, and `originatorport'
is the port on the originator host from where theconnection came from.Forwarded TCP/IP channels are independent of any sessions, andclosing a session channel does not in any way imply that forwardedconnections should be closed.
Client implementations SHOULD reject direct TCP/IP open requests forsecurity reasons.
6. Encoding of Terminal Modes
Terminal modes (as passed in a pty request) are encoded into a bytestream. It is intended that the coding be portable across differentenvironments.
The tty mode description is a stream of bytes. The stream consistsof 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 tostop (they should only be used after any other data).The client SHOULD put in the stream any modes it knows about, and theserver MAY ignore any modes it does not know about. This allows somedegree of machine-independence, at least between systems that use aPOSIX-like tty interface. The protocol can support other systems aswell, but the client may need to fill reasonable values for a number ofparameters so the server pty gets set to a reasonable mode (the serverleaves all unspecified mode bits in their default values, and only somecombinations make sense).
The following opcodes have been defined. The naming of opcodesmostly follows the POSIX terminal mode flags.
0 TTY_OP_END
Indicates end of options.
1 VINTR
Interrupt character; 255 if none. Similarly for the othercharacters. Not all of these characters are supported on allsystems.
2 VQUIT
The quit character (sends SIGQUIT signal on POSIXsystems).
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/orlinefeed.
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 specialcharacter.
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 flagis
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.
Vssh 1 11 1 – Ssh Protocol Connectivity Tools Pdf
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.
7. Summary of Message Numbers
8. Security Considerations
This protocol is assumed to run on top of a secure, authenticatedtransport. User authentication and protection against network-levelattacks are assumed to be provided by the underlying protocols.
This protocol can, however, be used to execute commands on remotemachines. The protocol also permits the server to run commands on theclient. Implementations may wish to disallow this to prevent anattacker from coming from the server machine to the client machine.
X11 forwarding provides major security improvements over normalcookie-based X11 forwarding. The cookie never needs to be transmittedin the clear, and traffic is encrypted and integrity-protected. Nouseful authentication data will remain on the server machine after theconnection has been closed. On the other hand, in some situations aforwarded X11 connection might be used to get access to the local Xserver across security perimeters.
Port forwardings can potentially allow an intruder to cross securityperimeters such as firewalls. They do not offer anything fundamentallynew that a user could not do otherwise; however, they make openingtunnels very easy. Implementations should allow policy control overwhat can be forwarded. Administrators should be able to denyforwardings where appropriate.
Since this protocol normally runs inside an encrypted tunnel,firewalls will not be able to examine the traffic.
It is RECOMMENDED that implementations disable all the potentiallydangerous features (e.g. agent forwarding, X11 forwarding, and TCP/IPforwarding) if the host key has changed.
9. Intellectual Property
The IETFtakes no position regarding the validity or scope of any intellectualproperty or other rights that might be claimed to pertain to theimplementation or use of the technology described in this document orthe extent to which any license under such rights might or might not beavailable; neither does it represent that it has made any effort toidentify any such rights. Information on the IETF's procedures withrespect to rights in standards-track and standards-related documentationcan be found in BCP-11. Copies of claims of rights made available forpublication and any assurances of licenses to be made available, or theresult of an attempt made to obtain a general license or permission forthe use of such proprietary rights by implementers or users of thisspecification can be obtained from the IETF Secretariat.
The IETF has been notified of intellectual property rights claimed inregard to some or all of the specification contained in this document.For more information consult the online list of claimed rights.
10. Additional Information
The current document editor is: [email protected]. Comments onthis internet draft should be sent to the IETF SECSH working group,details at: http://ietf.org/html.charters/secsh-charter.html
References
Alvestrand, H., 'Tags for the Identification of Languages', RFC 1766, March1995.
Hinden, R., Deering, S. and Editors, 'IP Version 6 AddressingArchitecture', RFC1884, December 1995.
Yergeau, F., 'UTF-8, a transformation format of ISO 10646', RFC 2279, January1998.
Scheifler, R., 'X Window System : The Complete Reference to Xlib,X Protocol, Icccm, Xlfd, 3rd edition.', Digital Press ISBN 1555580882,Feburary 1992.
ISO/IEC, 9945-1., 'Information technology -- Portable OperatingSystem Interface (POSIX)-Part 1: System Application Program Interface(API) C Language', ANSI/IEE Std 1003.1, July 1996.
Ylonen, T., 'SSH Protocol Architecture', I-D draft-ietf-architecture-13.txt,September 2002. [ED: an HTML version of this document is also availablefrom http://java-hush.sourceforge.net/architecture.html]
Ylonen, T., 'SSH Transport Layer Protocol', I-D draft-ietf-transport-15.txt,September 2002. [ED: an HTML version of this document is also availablefrom http://java-hush.sourceforge.net/transport.html]
Ylonen, T., 'SSH Authentication Protocol', I-D draft-ietf-userauth-16.txt,September 2002. [ED: an HTML version of this document is also availablefrom http://java-hush.sourceforge.net/userauth.html]
Ylonen, T., 'SSH Connection Protocol', I-D draft-ietf-connect-16.txt,September 2002. [ED: an HTML version of this document is also availablefrom http://java-hush.sourceforge.net/connection.html]
Authors' Addresses
Tatu Ylonen
SSH Communications Security Corp
Fredrikinkatu 42
HELSINKI FIN-00100
Finland
EMail: [email protected]
SSH Communications Security Corp
Fredrikinkatu 42
HELSINKI FIN-00100
Finland
EMail: [email protected]
Tero Kivinen
SSH Communications Security Corp
Fredrikinkatu 42
HELSINKI FIN-00100
Finland
EMail: [email protected]
SSH Communications Security Corp
Fredrikinkatu 42
HELSINKI FIN-00100
Finland
EMail: [email protected]
Markku-Juhani O. Saarinen
University of Jyvaskyla
University of Jyvaskyla
Timo J. Rinne
SSH Communications Security Corp
Fredrikinkatu 42
HELSINKI FIN-00100
Finland
EMail: [email protected]
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]
SSH Communications Security Corp
Fredrikinkatu 42
HELSINKI FIN-00100
Finland
EMail: [email protected]
Full CopyrightStatement
Copyright © The Internet Society (2002). All RightsReserved.
This document and translations of it may be copied and furnished toothers, and derivative works that comment on or otherwise explain it orassist in its implementation may be prepared, copied, published anddistributed, in whole or in part, without restriction of any kind,provided that the above copyright notice and this paragraph are includedon all such copies and derivative works. However, this document itselfmay not be modified in any way, such as by removing the copyright noticeor references to the Internet Society or other Internet organizations,except as needed for the purpose of developing Internet standards inwhich case the procedures for copyrights defined in the InternetStandards process must be followed, or as required to translate it intolanguages other than English.
The limited permissions granted above are perpetual and will not berevoked 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 TASKFORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOTLIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOTINFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY ORFITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by theInternet Society.
This HTMLversion was prepared by Casey Marshall.
Vssh 1 11 1 – Ssh Protocol Connectivity Tools Download
Verbatim copying and distribution of this entire article is permittedin any medium.
Vssh 1 11 1 – Ssh Protocol Connectivity Tools Free
Please forward any errors, omissions, or other inconsistencies fromthe original Internet-Draft to [email protected].