ssh_connection
This module provides API functions to send SSH Connection Protocol events to the other side of an SSH channel.
The {ssh_cm, ssh_connection_ref(), ssh_event_msg()}
.
If the ssh_channel behavior is used to
implement the channel process, these messages are handled by
handle_ssh_msg/2.
DATA TYPES
Type definitions that are used more than once in this module, or abstractions to indicate the intended use of the data type, or both:
boolean() =
true | false
string() =
list of ASCII characters
timeout() =
infinity | integer()
in milliseconds
ssh_connection_ref() =
opaque() -as returned by
ssh:connect/3
or sent to an SSH channel processes
ssh_channel_id() =
integer()
ssh_data_type_code() =
1
("stderr") | 0
("normal") are
valid values, see
ssh_request_status() =
success | failure
event() =
{ssh_cm, ssh_connection_ref(), ssh_event_msg()}
ssh_event_msg() =
data_events() | status_events() | terminal_events()
reason() =
timeout | closed
{data, ssh_channel_id(), ssh_data_type_code(), Data :: binary()}
Data has arrived on the channel. This event is sent as a result of calling ssh_connection:send/[3,4,5].
{eof, ssh_channel_id()}
Indicates that the other side sends no more data. This event is sent as a result of calling ssh_connection:send_eof/2.
{signal, ssh_channel_id(), ssh_signal()}
A signal can be delivered to the remote process/service using the following message. Some systems do not support signals, in which case they are to ignore this message. There is currently no function to generate this event as the signals referred to are on OS-level and not something generated by an Erlang program.
{exit_signal, ssh_channel_id(), ExitSignal :: string(), ErrorMsg ::string(),
LanguageString :: string()}
A remote execution can terminate violently because of a signal.
Then this message can be received. For details on valid string
values, see
{exit_status, ssh_channel_id(), ExitStatus :: integer()}
When the command running at the other end terminates, the
following message can be sent to return the exit status of the
command. A zero exit_status
usually means that the command
terminated successfully. This event is sent as a result of calling
ssh_connection:exit_status/3.
{closed, ssh_channel_id()}
This event is sent as a result of calling ssh_connection:close/2. Both the handling of this event and sending it are taken care of by the ssh_channel behavior.
Channels implementing a shell and command execution on the server side are to handle the following messages that can be sent by client- channel processes.
Events that include a WantReply
expect the event handling
process to call
ssh_connection:reply_request/4
with the boolean value of WantReply
as the second argument.
{env, ssh_channel_id(), WantReply :: boolean(),
Var ::string(), Value :: string()}
Environment variables can be passed to the shell/command to be started later. This event is sent as a result of calling ssh_connection:setenv/5.
{pty, ssh_channel_id(),
WantReply :: boolean(), {Terminal :: string(), CharWidth :: integer(),
RowHeight :: integer(), PixelWidth :: integer(), PixelHeight :: integer(),
TerminalModes :: [{Opcode :: atom() | integer(),
Value :: integer()}]}}
A pseudo-terminal has been requested for the
session. Terminal
is the value of the TERM environment
variable value, that is, vt100
. Zero dimension parameters must
be ignored. The character/row dimensions override the pixel
dimensions (when non-zero). Pixel dimensions refer to the
drawable area of the window. Opcode
in the
TerminalModes
list is the mnemonic name, represented
as a lowercase Erlang atom, defined in
Opcode
if the mnemonic name is not listed in the
RFC. Example: OP code: 53, mnemonic name ECHO erlang atom:
echo
. This event is sent as a result of calling ssh_connection:ptty_alloc/4.
{shell, WantReply :: boolean()}
This message requests that the user default shell is started at the other end. This event is sent as a result of calling ssh_connection:shell/2.
{window_change, ssh_channel_id(), CharWidth() :: integer(),
RowHeight :: integer(), PixWidth :: integer(), PixHeight :: integer()}
When the window (terminal) size changes on the client side, it can send a message to the server side to inform it of the new dimensions. No API function generates this event.
{exec, ssh_channel_id(),
WantReply :: boolean(), Cmd :: string()}
This message requests that the server starts execution of the given command. This event is sent as a result of calling ssh_connection:exec/4 .
Functions
adjust_window(ConnectionRef, ChannelId, NumOfBytes) -> ok
ConnectionRef = ssh_connection_ref()
ChannelId = ssh_channel_id()
NumOfBytes = integer()
Adjusts the SSH flow control window. This is to be done by both the client- and server-side channel processes.
Note!
Channels implemented with the ssh_channel behavior do not normally need to call this function as flow control is handled by the behavior. The behavior adjusts the window every time the callback handle_ssh_msg/2 returns after processing channel data.
close(ConnectionRef, ChannelId) -> ok
ConnectionRef = ssh_connection_ref()
ChannelId = ssh_channel_id()
A server- or client-channel process can choose to close their session by sending a close event.
Note!
This function is called by the ssh_channel
behavior when the channel is terminated, see ssh_channel(3). Thus, channels implemented
with the behavior are not to call this function explicitly.
exec(ConnectionRef, ChannelId, Command, TimeOut) -> ssh_request_status() | {error, reason()}
ConnectionRef = ssh_connection_ref()
ChannelId = ssh_channel_id()
Command = string()
Timeout = timeout()
Is to be called by a client-channel process to request that the server starts
executing the given command. The result is several messages according to the
following pattern. The last message is a channel close message, as the exec
request is a one-time execution that closes the channel when it is done.
N x {ssh_cm, ssh_connection_ref(),
{data, ssh_channel_id(), ssh_data_type_code(), Data :: binary()}}
The result of executing the command can be only one line or thousands of lines depending on the command.
0 or 1 x {ssh_cm, ssh_connection_ref(), {eof, ssh_channel_id()}}
Indicates that no more data is to be sent.
0 or 1 x {ssh_cm,
ssh_connection_ref(), {exit_signal,
ssh_channel_id(), ExitSignal :: string(), ErrorMsg :: string(), LanguageString :: string()}}
Not all systems send signals. For details on valid string values, see RFC 4254, Section 6.10
0 or 1 x {ssh_cm, ssh_connection_ref(), {exit_status,
ssh_channel_id(), ExitStatus :: integer()}}
It is recommended by the SSH Connection Protocol to send this message, but that is not always the case.
1 x {ssh_cm, ssh_connection_ref(),
{closed, ssh_channel_id()}}
Indicates that the ssh_channel
started for the
execution of the command has now been shut down.
exit_status(ConnectionRef, ChannelId, Status) -> ok
ConnectionRef = ssh_connection_ref()
ChannelId = ssh_channel_id()
Status = integer()
Is to be called by a server-channel process to send the exit status of a command to the client.
ptty_alloc(ConnectionRef, ChannelId, Options) ->
ptty_alloc(ConnectionRef, ChannelId, Options, Timeout) -> > ssh_request_status() | {error, reason()}
ConnectionRef = ssh_connection_ref()
ChannelId = ssh_channel_id()
Options = proplists:proplist()
Sends an SSH Connection Protocol pty_req
, to allocate a pseudo-terminal.
Is to be called by an SSH client process.
Options:
Defaults to os:getenv("TERM") or vt100 if it is undefined.
Defaults to 80 if pixel_width
is not defined.
Defaults to 24 if pixel_height
is not defined.
Is disregarded if width
is defined.
Is disregarded if height
is defined.
Option can be an empty list. Otherwise, see possible POSIX names
in Section 8 in
reply_request(ConnectionRef, WantReply, Status, ChannelId) -> ok
ConnectionRef = ssh_connection_ref()
WantReply = boolean()
Status = ssh_request_status()
ChannelId = ssh_channel_id()
Sends status replies to requests where the requester has
stated that it wants a status report, that is, WantReply = true
.
If WantReply
is false
, calling this function becomes a
"noop". Is to be called while handling an SSH Connection
Protocol message containing a WantReply
boolean value.
send(ConnectionRef, ChannelId, Data) ->
send(ConnectionRef, ChannelId, Data, Timeout) ->
send(ConnectionRef, ChannelId, Type, Data) ->
send(ConnectionRef, ChannelId, Type, Data, TimeOut) -> ok | {error, timeout} | {error, closed}
ConnectionRef = ssh_connection_ref()
ChannelId = ssh_channel_id()
Data = binary()
Type = ssh_data_type_code()
Timeout = timeout()
Is to be called by client- and server-channel processes to send data to each other.
The function subsystem/4 and subsequent
calls of send/3,4,5
must be executed in the same process.
send_eof(ConnectionRef, ChannelId) -> ok | {error, closed}
ConnectionRef = ssh_connection_ref()
ChannelId = ssh_channel_id()
Sends EOF on channel ChannelId
.
session_channel(ConnectionRef, Timeout) ->
session_channel(ConnectionRef, InitialWindowSize, MaxPacketSize, Timeout) -> {ok, ssh_channel_id()} | {error, reason()}
ConnectionRef = ssh_connection_ref()
InitialWindowSize = integer()
MaxPacketSize = integer()
Timeout = timeout()
Reason = term()
Opens a channel for an SSH session. The channel id returned from this function is the id used as input to the other functions in this module.
setenv(ConnectionRef, ChannelId, Var, Value, TimeOut) -> ssh_request_status() | {error, reason()}
ConnectionRef = ssh_connection_ref()
ChannelId = ssh_channel_id()
Var = string()
Value = string()
Timeout = timeout()
Environment variables can be passed before starting the shell/command. Is to be called by a client channel processes.
shell(ConnectionRef, ChannelId) -> ssh_request_status() | {error, closed}
ConnectionRef = ssh_connection_ref()
ChannelId = ssh_channel_id()
Is to be called by a client channel process to request that the user default shell (typically defined in /etc/passwd in Unix systems) is executed at the server end.
subsystem(ConnectionRef, ChannelId, Subsystem, Timeout) -> ssh_request_status() | {error, reason()}
ConnectionRef = ssh_connection_ref()
ChannelId = ssh_channel_id()
Subsystem = string()
Timeout = timeout()
Is to be called by a client-channel process for requesting to execute a predefined subsystem on the server.
The function subsystem/4
and subsequent calls of
send/3,4,5 must be executed in the same process.