man ssh Command

Man page for apt-get ssh Command

Man Page for ssh in Linux

Ubuntu Man Command : man ssh

Man Ssh  Command

This tutorial shows the man page for man ssh in linux.

Open terminal with 'su' access and type the command as shown below:
man ssh

Result of the Command Execution shown below:

SSH(1)                    BSD General Commands Manual                   SSH(1)

NAME
ssh OpenSSH SSH client (remote login program)

SYNOPSIS
ssh [ 1246AaCfgKkMNnqsTtVvXxYy] [ b bind_address] [ c cipher_spec] [ D
[bind_address:]port] [ e escape_char] [ F configfile]
[ i identity_file] [ L [bind_address:]port:host:hostport]
[ l login_name] [ m mac_spec] [ O ctl_cmd] [ o option] [ p port] [ R
[bind_address:]port:host:hostport] [ S ctl_path]
[ w local_tun[:remote_tun]] [user@]hostname [command]

DESCRIPTION
ssh (SSH client) is a program for logging into a remote machine and for
executing commands on a remote machine. It is intended to replace rlogin
and rsh, and provide secure encrypted communications between two
untrusted hosts over an insecure network. X11 connections and arbitrary
TCP ports can also be forwarded over the secure channel.

ssh connects and logs into the specified hostname (with optional user
name). The user must prove his/her identity to the remote machine using
one of several methods depending on the protocol version used (see
below).

If command is specified, it is executed on the remote host instead of a
login shell.

The options are as follows:

1 Forces ssh to try protocol version 1 only.

2 Forces ssh to try protocol version 2 only.

4 Forces ssh to use IPv4 addresses only.

6 Forces ssh to use IPv6 addresses only.

A Enables forwarding of the authentication agent connection. This
can also be specified on a per host basis in a configuration
file.

Agent forwarding should be enabled with caution. Users with the
ability to bypass file permissions on the remote host (for the
agent's Unix domain socket) can access the local agent through
the forwarded connection. An attacker cannot obtain key material
from the agent, however they can perform operations on the keys
that enable them to authenticate using the identities loaded into
the agent.

a Disables forwarding of the authentication agent connection.

b bind_address
Use bind_address on the local machine as the source address of
the connection. Only useful on systems with more than one
address.

C Requests compression of all data (including stdin, stdout,
stderr, and data for forwarded X11 and TCP connections). The
compression algorithm is the same used by gzip(1), and the
``level'' can be controlled by the CompressionLevel option for
protocol version 1. Compression is desirable on modem lines and
other slow connections, but will only slow down things on fast
networks. The default value can be set on a host by host basis
in the configuration files; see the Compression option.

c cipher_spec
Selects the cipher specification for encrypting the session.

Protocol version 1 allows specification of a single cipher. The
supported values are ``3des'', ``blowfish'', and ``des''. 3des
(triple des) is an encrypt decrypt encrypt triple with three dif
ferent keys. It is believed to be secure. blowfish is a fast
block cipher; it appears very secure and is much faster than
3des. des is only supported in the ssh client for interoperabil
ity with legacy protocol 1 implementations that do not support
the 3des cipher. Its use is strongly discouraged due to crypto
graphic weaknesses. The default is ``3des''.

For protocol version 2, cipher_spec is a comma separated list of
ciphers listed in order of preference. See the Ciphers keyword
for more information.

D [bind_address:]port
Specifies a local ``dynamic'' application level port forwarding.
This works by allocating a socket to listen to port on the local
side, optionally bound to the specified bind_address. Whenever a
connection is made to this port, the connection is forwarded over
the secure channel, and the application protocol is then used to
determine where to connect to from the remote machine. Currently
the SOCKS4 and SOCKS5 protocols are supported, and ssh will act
as a SOCKS server. Only root can forward privileged ports.
Dynamic port forwardings can also be specified in the configura
tion file.

IPv6 addresses can be specified with an alternative syntax:
[bind_address/]port or by enclosing the address in square brack
ets. Only the superuser can forward privileged ports. By
default, the local port is bound in accordance with the
GatewayPorts setting. However, an explicit bind_address may be
used to bind the connection to a specific address. The
bind_address of ``localhost'' indicates that the listening port
be bound for local use only, while an empty address or '*' indi
cates that the port should be available from all interfaces.

e escape_char
Sets the escape character for sessions with a pty (default: '~').
The escape character is only recognized at the beginning of a
line. The escape character followed by a dot ('.') closes the
connection; followed by control Z suspends the connection; and
followed by itself sends the escape character once. Setting the
character to ``none'' disables any escapes and makes the session
fully transparent.

F configfile
Specifies an alternative per user configuration file. If a con
figuration file is given on the command line, the system wide
configuration file (/etc/ssh/ssh_config) will be ignored. The
default for the per user configuration file is ~/.ssh/config.

f Requests ssh to go to background just before command execution.
This is useful if ssh is going to ask for passwords or
passphrases, but the user wants it in the background. This
implies n. The recommended way to start X11 programs at a
remote site is with something like ssh f host xterm.

If the ExitOnForwardFailure configuration option is set to
``yes'', then a client started with f will wait for all remote
port forwards to be successfully established before placing
itself in the background.

g Allows remote hosts to connect to local forwarded ports.

I smartcard_device
Specify the device ssh should use to communicate with a smartcard
used for storing the user's private RSA key. This option is only
available if support for smartcard devices is compiled in
(default is no support).

i identity_file
Selects a file from which the identity (private key) for RSA or
DSA authentication is read. The default is ~/.ssh/identity for
protocol version 1, and ~/.ssh/id_rsa and ~/.ssh/id_dsa for pro
tocol version 2. Identity files may also be specified on a per
host basis in the configuration file. It is possible to have
multiple i options (and multiple identities specified in config
uration files).

K Enables GSSAPI based authentication and forwarding (delegation)
of GSSAPI credentials to the server.

k Disables forwarding (delegation) of GSSAPI credentials to the
server.

L [bind_address:]port:host:hostport
Specifies that the given port on the local (client) host is to be
forwarded to the given host and port on the remote side. This
works by allocating a socket to listen to port on the local side,
optionally bound to the specified bind_address. Whenever a con
nection is made to this port, the connection is forwarded over
the secure channel, and a connection is made to host port
hostport from the remote machine. Port forwardings can also be
specified in the configuration file. IPv6 addresses can be spec
ified with an alternative syntax:
[bind_address/]port/host/hostport or by enclosing the address in
square brackets. Only the superuser can forward privileged
ports. By default, the local port is bound in accordance with
the GatewayPorts setting. However, an explicit bind_address may
be used to bind the connection to a specific address. The
bind_address of ``localhost'' indicates that the listening port
be bound for local use only, while an empty address or '*' indi
cates that the port should be available from all interfaces.

l login_name
Specifies the user to log in as on the remote machine. This also
may be specified on a per host basis in the configuration file.

M Places the ssh client into ``master'' mode for connection shar
ing. Multiple M options places ssh into ``master'' mode with
confirmation required before slave connections are accepted.
Refer to the description of ControlMaster in ssh_config(5) for
details.

m mac_spec
Additionally, for protocol version 2 a comma separated list of
MAC (message authentication code) algorithms can be specified in
order of preference. See the MACs keyword for more information.

N Do not execute a remote command. This is useful for just for
warding ports (protocol version 2 only).

n Redirects stdin from /dev/null (actually, prevents reading from
stdin). This must be used when ssh is run in the background. A
common trick is to use this to run X11 programs on a remote
machine. For example, ssh n shadows.cs.hut.fi emacs & will
start an emacs on shadows.cs.hut.fi, and the X11 connection will
be automatically forwarded over an encrypted channel. The ssh
program will be put in the background. (This does not work if
ssh needs to ask for a password or passphrase; see also the f
option.)

O ctl_cmd
Control an active connection multiplexing master process. When
the O option is specified, the ctl_cmd argument is interpreted
and passed to the master process. Valid commands are: ``check''
(check that the master process is running) and ``exit'' (request
the master to exit).

o option
Can be used to give options in the format used in the configura
tion file. This is useful for specifying options for which there
is no separate command line flag. For full details of the
options listed below, and their possible values, see
ssh_config(5).

AddressFamily
BatchMode
BindAddress
ChallengeResponseAuthentication
CheckHostIP
Cipher
Ciphers
ClearAllForwardings
Compression
CompressionLevel
ConnectionAttempts
ConnectTimeout
ControlMaster
ControlPath
DynamicForward
EscapeChar
ExitOnForwardFailure
ForwardAgent
ForwardX11
ForwardX11Trusted
GatewayPorts
GlobalKnownHostsFile
GSSAPIAuthentication
GSSAPIDelegateCredentials
HashKnownHosts
Host
HostbasedAuthentication
HostKeyAlgorithms
HostKeyAlias
HostName
IdentityFile
IdentitiesOnly
KbdInteractiveDevices
LocalCommand
LocalForward
LogLevel
MACs
NoHostAuthenticationForLocalhost
NumberOfPasswordPrompts
PasswordAuthentication
PermitLocalCommand
Port
PreferredAuthentications
Protocol
ProxyCommand
PubkeyAuthentication
RekeyLimit
RemoteForward
RhostsRSAAuthentication
RSAAuthentication
SendEnv
ServerAliveInterval
ServerAliveCountMax
SmartcardDevice
StrictHostKeyChecking
TCPKeepAlive
Tunnel
TunnelDevice
UsePrivilegedPort
User
UserKnownHostsFile
VerifyHostKeyDNS
VisualHostKey
XAuthLocation

p port
Port to connect to on the remote host. This can be specified on
a per host basis in the configuration file.

q Quiet mode. Causes most warning and diagnostic messages to be
suppressed. Only fatal errors are displayed. If a second q is
given then even fatal errors are suppressed, except for those
produced due solely to bad arguments.

R [bind_address:]port:host:hostport
Specifies that the given port on the remote (server) host is to
be forwarded to the given host and port on the local side. This
works by allocating a socket to listen to port on the remote
side, and whenever a connection is made to this port, the connec
tion is forwarded over the secure channel, and a connection is
made to host port hostport from the local machine.

Port forwardings can also be specified in the configuration file.
Privileged ports can be forwarded only when logging in as root on
the remote machine. IPv6 addresses can be specified by enclosing
the address in square braces or using an alternative syntax:
[bind_address/]host/port/hostport.

By default, the listening socket on the server will be bound to
the loopback interface only. This may be overridden by specify
ing a bind_address. An empty bind_address, or the address '*',
indicates that the remote socket should listen on all interfaces.
Specifying a remote bind_address will only succeed if the
server's GatewayPorts option is enabled (see sshd_config(5)).

If the port argument is '0', the listen port will be dynamically
allocated on the server and reported to the client at run time.

S ctl_path
Specifies the location of a control socket for connection shar
ing, or the string ``none'' to disable connection sharing. Refer
to the description of ControlPath and ControlMaster in
ssh_config(5) for details.

s May be used to request invocation of a subsystem on the remote
system. Subsystems are a feature of the SSH2 protocol which
facilitate the use of SSH as a secure transport for other appli
cations (eg. sftp(1)). The subsystem is specified as the remote
command.

T Disable pseudo tty allocation.

t Force pseudo tty allocation. This can be used to execute arbi
trary screen based programs on a remote machine, which can be
very useful, e.g. when implementing menu services. Multiple t
options force tty allocation, even if ssh has no local tty.

V Display the version number and exit.

v Verbose mode. Causes ssh to print debugging messages about its
progress. This is helpful in debugging connection, authentica
tion, and configuration problems. Multiple v options increase
the verbosity. The maximum is 3.

w local_tun[:remote_tun]
Requests tunnel device forwarding with the specified tun(4)
devices between the client (local_tun) and the server
(remote_tun).

The devices may be specified by numerical ID or the keyword
``any'', which uses the next available tunnel device. If
remote_tun is not specified, it defaults to ``any''. See also
the Tunnel and TunnelDevice directives in ssh_config(5). If the
Tunnel directive is unset, it is set to the default tunnel mode,
which is ``point to point''.

X Enables X11 forwarding. This can also be specified on a per host
basis in a configuration file.

X11 forwarding should be enabled with caution. Users with the
ability to bypass file permissions on the remote host (for the
user's X authorization database) can access the local X11 display
through the forwarded connection. An attacker may then be able
to perform activities such as keystroke monitoring.

For this reason, X11 forwarding is subjected to X11 SECURITY
extension restrictions by default. Please refer to the ssh Y
option and the ForwardX11Trusted directive in ssh_config(5) for
more information.

x Disables X11 forwarding.

Y Enables trusted X11 forwarding. Trusted X11 forwardings are not
subjected to the X11 SECURITY extension controls.

y Send log information using the syslog(3) system module. By
default this information is sent to stderr.

ssh may additionally obtain configuration data from a per user configura
tion file and a system wide configuration file. The file format and con
figuration options are described in ssh_config(5).

ssh exits with the exit status of the remote command or with 255 if an
error occurred.

AUTHENTICATION
The OpenSSH SSH client supports SSH protocols 1 and 2. Protocol 2 is the
default, with ssh falling back to protocol 1 if it detects protocol 2 is
unsupported. These settings may be altered using the Protocol option in
ssh_config(5), or enforced using the 1 and 2 options (see above). Both
protocols support similar authentication methods, but protocol 2 is pre
ferred since it provides additional mechanisms for confidentiality (the
traffic is encrypted using AES, 3DES, Blowfish, CAST128, or Arcfour) and
integrity (hmac md5, hmac sha1, umac 64, hmac ripemd160). Protocol 1
lacks a strong mechanism for ensuring the integrity of the connection.

The methods available for authentication are: GSSAPI based authentica
tion, host based authentication, public key authentication, challenge
response authentication, and password authentication. Authentication
methods are tried in the order specified above, though protocol 2 has a
configuration option to change the default order:
PreferredAuthentications.

Host based authentication works as follows: If the machine the user logs
in from is listed in /etc/hosts.equiv or /etc/ssh/shosts.equiv on the
remote machine, and the user names are the same on both sides, or if the
files ~/.rhosts or ~/.shosts exist in the user's home directory on the
remote machine and contain a line containing the name of the client
machine and the name of the user on that machine, the user is considered
for login. Additionally, the server must be able to verify the client's
host key (see the description of /etc/ssh/ssh_known_hosts and
~/.ssh/known_hosts, below) for login to be permitted. This authentica
tion method closes security holes due to IP spoofing, DNS spoofing, and
routing spoofing. [Note to the administrator: /etc/hosts.equiv,
~/.rhosts, and the rlogin/rsh protocol in general, are inherently inse
cure and should be disabled if security is desired.]

Public key authentication works as follows: The scheme is based on pub
lic key cryptography, using cryptosystems where encryption and decryption
are done using separate keys, and it is unfeasible to derive the decryp
tion key from the encryption key. The idea is that each user creates a
public/private key pair for authentication purposes. The server knows
the public key, and only the user knows the private key. ssh implements
public key authentication protocol automatically, using either the RSA or
DSA algorithms. Protocol 1 is restricted to using only RSA keys, but
protocol 2 may use either. The HISTORY section of ssl(8) (on non OpenBSD
systems, see
http://www.openbsd.org/cgi bin/man.cgi?query=ssl&sektion=8


Related Topics

Apt Get Commands