Config-Model-OpenSsh
view release on metacpan or search on metacpan
xt/ssh_config.html view on Meta::CPAN
<p style="margin-left:17%; margin-top: 1em">If the
<i>port</i> argument is 0, the listen port will be
dynamically allocated on the server and reported to the
client at run time.</p>
<p style="margin-left:17%; margin-top: 1em">If the
<i>bind_address</i> is not specified, the default is to only
bind to loopback addresses. If the <i>bind_address</i> is
’*’ or an empty string, then the forwarding is
requested to listen on all interfaces. Specifying a remote
<i>bind_address</i> will only succeed if the server’s
<b>GatewayPorts</b> option is enabled (see
sshd_config(5)).</p>
<p style="margin-top: 1em"><b>RequestTTY</b></p>
<p style="margin-left:17%;">Specifies whether to request a
pseudo-tty for the session. The argument may be one of:
<b>no</b> (never request a TTY), <b>yes</b> (always request
a TTY when standard input is a TTY), <b>force</b> (always
request a TTY) or <b>auto</b> (request a TTY when opening a
login session). This option mirrors the <b>-t</b> and
<b>-T</b> flags for ssh(1).</p>
<p style="margin-top: 1em"><b>RevokedHostKeys</b></p>
<p style="margin-left:17%;">Specifies revoked host public
keys. Keys listed in this file will be refused for host
authentication. Note that if this file does not exist or is
not readable, then host authentication will be refused for
all hosts. Keys may be specified as a text file, listing one
public key per line, or as an OpenSSH Key Revocation List
(KRL) as generated by ssh-keygen(1). For more information on
KRLs, see the KEY REVOCATION LISTS section in
ssh-keygen(1).</p>
<p style="margin-top: 1em"><b>SendEnv</b></p>
<p style="margin-left:17%;">Specifies what variables from
the local environ(7) should be sent to the server. The
server must also support it, and the server must be
configured to accept these environment variables. Note that
the TERM environment variable is always sent whenever a
pseudo-terminal is requested as it is required by the
protocol. Refer to <b>AcceptEnv</b> in sshd_config(5) for
how to configure the server. Variables are specified by
name, which may contain wildcard characters. Multiple
environment variables may be separated by whitespace or
spread across multiple <b>SendEnv</b> directives.</p>
<p style="margin-left:17%; margin-top: 1em">See
<i>PATTERNS</i> for more information on patterns.</p>
<p style="margin-left:17%; margin-top: 1em">It is possible
to clear previously set <b>SendEnv</b> variable names by
prefixing patterns with <i>-</i>. The default is not to send
any environment variables.</p>
<p style="margin-top: 1em"><b>ServerAliveCountMax</b></p>
<p style="margin-left:17%;">Sets the number of server alive
messages (see below) which may be sent without ssh(1)
receiving any messages back from the server. If this
threshold is reached while server alive messages are being
sent, ssh will disconnect from the server, terminating the
session. It is important to note that the use of server
alive messages is very different from <b>TCPKeepAlive</b>
(below). The server alive messages are sent through the
encrypted channel and therefore will not be spoofable. The
TCP keepalive option enabled by <b>TCPKeepAlive</b> is
spoofable. The server alive mechanism is valuable when the
client or server depend on knowing when a connection has
become inactive.</p>
<p style="margin-left:17%; margin-top: 1em">The default
value is 3. If, for example, <b>ServerAliveInterval</b> (see
below) is set to 15 and <b>ServerAliveCountMax</b> is left
at the default, if the server becomes unresponsive, ssh will
disconnect after approximately 45 seconds.</p>
<p style="margin-top: 1em"><b>ServerAliveInterval</b></p>
<p style="margin-left:17%;">Sets a timeout interval in
seconds after which if no data has been received from the
server, ssh(1) will send a message through the encrypted
channel to request a response from the server. The default
is 0, indicating that these messages will not be sent to the
server, or 300 if the <b>BatchMode</b> option is set
(Debian-specific). <b>ProtocolKeepAlives</b> and
<b>SetupTimeOut</b> are Debian-specific compatibility
aliases for this option.</p>
<p style="margin-top: 1em"><b>SetEnv</b></p>
<p style="margin-left:17%; margin-top: 1em">Directly
specify one or more environment variables and their contents
to be sent to the server. Similarly to <b>SendEnv</b>, the
server must be prepared to accept the environment
variable.</p>
<p style="margin-top: 1em"><b>StreamLocalBindMask</b></p>
<p style="margin-left:17%;">Sets the octal file creation
mode mask (umask) used when creating a Unix-domain socket
file for local or remote port forwarding. This option is
only used for port forwarding to a Unix-domain socket
file.</p>
<p style="margin-left:17%; margin-top: 1em">The default
value is 0177, which creates a Unix-domain socket file that
is readable and writable only by the owner. Note that not
all operating systems honor the file mode on Unix-domain
socket files.</p>
<p style="margin-top: 1em"><b>StreamLocalBindUnlink</b></p>
<p style="margin-left:17%;">Specifies whether to remove an
existing Unix-domain socket file for local or remote port
forwarding before creating a new one. If the socket file
already exists and <b>StreamLocalBindUnlink</b> is not
enabled, <b>ssh</b> will be unable to forward the port to
the Unix-domain socket file. This option is only used for
port forwarding to a Unix-domain socket file.</p>
<p style="margin-left:17%; margin-top: 1em">The argument
must be <b>yes</b> or <b>no</b> (the default).</p>
<p style="margin-top: 1em"><b>StrictHostKeyChecking</b></p>
<p style="margin-left:17%;">If this flag is set to
<b>yes</b>, ssh(1) will never automatically add host keys to
the <i>~/.ssh/known_hosts</i> file, and refuses to connect
to hosts whose host key has changed. This provides maximum
protection against man-in-the-middle (MITM) attacks, though
it can be annoying when the <i>/etc/ssh/ssh_known_hosts</i>
file is poorly maintained or when connections to new hosts
are frequently made. This option forces the user to manually
add all new hosts.</p>
<p style="margin-left:17%; margin-top: 1em">If this flag is
set to “accept-new” then ssh will automatically
add new host keys to the user known hosts files, but will
not permit connections to hosts with changed host keys. If
this flag is set to “no” or “off”,
ssh will automatically add new host keys to the user known
hosts files and allow connections to hosts with changed
hostkeys to proceed, subject to some restrictions. If this
flag is set to <b>ask</b> (the default), new host keys will
be added to the user known host files only after the user
has confirmed that is what they really want to do, and ssh
will refuse to connect to hosts whose host key has changed.
The host keys of known hosts will be verified automatically
in all cases.</p>
<p style="margin-top: 1em"><b>SyslogFacility</b></p>
<p style="margin-left:17%;">Gives the facility code that is
used when logging messages from ssh(1). The possible values
are: DAEMON, USER, AUTH, LOCAL0, LOCAL1, LOCAL2, LOCAL3,
LOCAL4, LOCAL5, LOCAL6, LOCAL7. The default is USER.</p>
<p style="margin-top: 1em"><b>TCPKeepAlive</b></p>
<p style="margin-left:17%;">Specifies whether the system
should send TCP keepalive messages to the other side. If
they are sent, death of the connection or crash of one of
the machines will be properly noticed. This option only uses
TCP keepalives (as opposed to using ssh level keepalives),
so takes a long time to notice when the connection dies. As
such, you probably want the <b>ServerAliveInterval</b>
option as well. However, this means that connections will
die if the route is down temporarily, and some people find
it annoying.</p>
<p style="margin-left:17%; margin-top: 1em">The default is
<b>yes</b> (to send TCP keepalive messages), and the client
will notice if the network goes down or the remote host
dies. This is important in scripts, and many users want it
too.</p>
<p style="margin-left:17%; margin-top: 1em">To disable TCP
keepalive messages, the value should be set to <b>no</b>.
See also <b>ServerAliveInterval</b> for protocol-level
keepalives.</p>
<p style="margin-top: 1em"><b>Tunnel</b></p>
<p style="margin-left:17%; margin-top: 1em">Request tun(4)
device forwarding between the client and the server. The
argument must be <b>yes</b>, <b>point-to-point</b> (layer
3), <b>ethernet</b> (layer 2), or <b>no</b> (the default).
Specifying <b>yes</b> requests the default tunnel mode,
which is <b>point-to-point</b>.</p>
<p style="margin-top: 1em"><b>TunnelDevice</b></p>
<p style="margin-left:17%;">Specifies the tun(4) devices to
open on the client (<i>local_tun</i>) and the server
(<i>remote_tun</i>).</p>
<p style="margin-left:17%; margin-top: 1em">The argument
must be <i>local_tun</i>[:<i>remote_tun</i>]. The devices
may be specified by numerical ID or the keyword <b>any</b>,
which uses the next available tunnel device. If
<i>remote_tun</i> is not specified, it defaults to
<b>any</b>. The default is <b>any:any</b>.</p>
<p style="margin-top: 1em"><b>UpdateHostKeys</b></p>
<p style="margin-left:17%;">Specifies whether ssh(1) should
accept notifications of additional hostkeys from the server
sent after authentication has completed and add them to
<b>UserKnownHostsFile</b>. The argument must be <b>yes</b>,
<b>no</b> (the default) or <b>ask</b>. Enabling this option
allows learning alternate hostkeys for a server and supports
graceful key rotation by allowing a server to send
replacement public keys before old ones are removed.
Additional hostkeys are only accepted if the key used to
authenticate the host was already trusted or explicitly
accepted by the user. If <b>UpdateHostKeys</b> is set to
<b>ask</b>, then the user is asked to confirm the
modifications to the known_hosts file. Confirmation is
currently incompatible with <b>ControlPersist</b>, and will
be disabled if it is enabled.</p>
<p style="margin-left:17%; margin-top: 1em">Presently, only
sshd(8) from OpenSSH 6.8 and greater support the
"hostkeys@openssh.com" protocol extension used to
inform the client of all the server’s hostkeys.</p>
<p style="margin-top: 1em"><b>User</b></p>
<p style="margin-left:17%; margin-top: 1em">Specifies the
user to log in as. This can be useful when a different user
name is used on different machines. This saves the trouble
of having to remember to give the user name on the command
line.</p>
<p style="margin-top: 1em"><b>UserKnownHostsFile</b></p>
<p style="margin-left:17%;">Specifies one or more files to
use for the user host key database, separated by whitespace.
The default is <i>~/.ssh/known_hosts</i>,
<i>~/.ssh/known_hosts2</i>.</p>
( run in 0.909 second using v1.01-cache-2.11-cpan-39bf76dae61 )