Партнёры:
Хостинг:
NAME
ssh - OpenSSH SSH client (remote login program)
SYNOPSIS
ssh [-l login_name] [hostname | user@hostname] [command]
ssh [-afgknqstvxACNPTX1246] [-c cipher_spec] [-e
escape_char] [-i identity_file] [-l login_name] [-m
mac_spec] [-o option] [-p port] [-L port:host:hostport ] [-R
port:host:hostport ] [hostname | 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/IP
ports can also be forwarded over the secure channel.
ssh connects and logs into the specified hostname . The
user must prove his/her identity to the remote machine using
one of several methods depending on the protocol version
used:
SSH protocol version 1
First, if the machine the user logs in from is listed in
/etc/hosts.equiv or /usr/local/sparcv9/etc/shosts.equiv on
the remote machine, and the user names are the same on both
sides, the user is immediately permitted to log in. Second,
if .rhosts or .shosts exists in the user's home directory on
the remote machine and contains a line containing the name
of the client machine and the name of the user on that
machine, the user is permitted to log in. This form of
authentication alone is normally not allowed by the server
because it is not secure.
The second authentication method is the rhosts or
hosts.equiv method combined with RSA-based host authentica-
tion. It means that if the login would be permitted by
$HOME/.rhosts, $HOME/.shosts, /etc/hosts.equiv, or
/usr/local/sparcv9/etc/shosts.equiv, and if additionally the
server can verify the client's host key (see
/usr/local/sparcv9/etc/ssh_known_hosts and
$HOME/.ssh/known_hosts in the FILES section), only then
login is permitted. This authentication method closes secu-
rity holes due to IP spoofing, DNS spoofing and routing
spoofing. [Note to the administrator: /etc/hosts.equiv,
$HOME/.rhosts, and the rlogin/rsh protocol in general, are
inherently insecure and should be disabled if security is
desired.]
As a third authentication method, ssh supports RSA based
authentication. The scheme is based on public-key cryptog-
raphy: there are cryptosystems where encryption and decryp-
tion are done using separate keys, and it is not possible to
derive the decryption key from the encryption key. RSA is
one such system. 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. The file $HOME/.ssh/authorized_keys lists the
public keys that are permitted for logging in. When the
user logs in, the ssh program tells the server which key
pair it would like to use for authentication. The server
checks if this key is permitted, and if so, sends the user
(actually the ssh program running on behalf of the user) a
challenge, a random number, encrypted by the user's public
key. The challenge can only be decrypted using the proper
private key. The user's client then decrypts the challenge
using the private key, proving that he/she knows the private
key but without disclosing it to the server.
ssh implements the RSA authentication protocol automati-
cally. The user creates his/her RSA key pair by running
ssh-keygen(1). This stores the private key in
$HOME/.ssh/identity and the public key in
$HOME/.ssh/identity.pub in the user's home directory. The
user should then copy the identity.pub to
$HOME/.ssh/authorized_keys in his/her home directory on the
remote machine (the authorized_keys file corresponds to the
conventional $HOME/.rhosts file, and has one key per line,
though the lines can be very long). After this, the user
can log in without giving the password. RSA authentication
is much more secure than rhosts authentication.
The most convenient way to use RSA authentication may be
with an authentication agent. See ssh-agent(1) for more
information.
If other authentication methods fail, ssh prompts the user
for a password. The password is sent to the remote host for
checking; however, since all communications are encrypted,
the password cannot be seen by someone listening on the net-
work.
SSH protocol version 2
When a user connects using the protocol version 2 different
authentication methods are available. Using the default
values for PreferredAuthentications , the client will try to
authenticate first using the public key method; if this
method fails password authentication is attempted, and
finally if this method fails keyboard-interactive authenti-
cation is attempted. If this method fails password authen-
tication is tried.
The public key method is similar to RSA authentication
described in the previous section and allows the RSA or DSA
algorithm to be used: The client uses his private key,
$HOME/.ssh/id_dsa or $HOME/.ssh/id_rsa, to sign the session
identifier and sends the result to the server. The server
checks whether the matching public key is listed in
$HOME/.ssh/authorized_keys2 and grants access if both the
key is found and the signature is correct. The session
identifier is derived from a shared Diffie-Hellman value and
is only known to the client and the server.
If public key authentication fails or is not available a
password can be sent encrypted to the remote host for prov-
ing the user's identity.
Additionally, ssh supports hostbased or challenge response
authentication.
Protocol 2 provides additional mechanisms for confidential-
ity (the traffic is encrypted using 3DES, Blowfish, CAST128
or Arcfour) and integrity (hmac-md5, hmac-sha1). Note that
protocol 1 lacks a strong mechanism for ensuring the
integrity of the connection.
Login session and remote execution
When the user's identity has been accepted by the server,
the server either executes the given command, or logs into
the machine and gives the user a normal shell on the remote
machine. All communication with the remote command or shell
will be automatically encrypted.
If a pseudo-terminal has been allocated (normal login ses-
sion), the user may use the escape characters noted below.
If no pseudo tty has been allocated, the session is tran-
sparent and can be used to reliably transfer binary data.
On most systems, setting the escape character to ``none''
will also make the session transparent even if a tty is
used.
The session terminates when the command or shell on the
remote machine exits and all X11 and TCP/IP connections have
been closed. The exit status of the remote program is
returned as the exit status of ssh.
Escape Characters
When a pseudo terminal has been requested, ssh supports a
number of functions through the use of an escape character.
A single tilde character can be sent as ~~ (or by following
the tilde by a character other than those described above).
The escape character must always follow a newline to be
interpreted as special. The escape character can be changed
in configuration files using the EscapeChar configuration
directive or on the command line by the -e option.
The supported escapes (assuming the default `~' ) are:
~. Disconnect
~^Z Background ssh
~# List forwarded connections
~& Background ssh at logout when waiting for forwarded
connection / X11 sessions to terminate (protocol ver-
sion 1 only)
~? Display a list of escape characters
~R Request rekeying of the connection (only useful for SSH
protocol version 2 and if the peer supports it)
X11 and TCP forwarding
If the user is using X11 (the DISPLAY environment variable
is set), the connection to the X11 display is automatically
forwarded to the remote side in such a way that any X11 pro-
grams started from the shell (or command) will go through
the encrypted channel, and the connection to the real X
server will be made from the local machine. The user should
not manually set DISPLAY. Forwarding of X11 connections can
be configured on the command line or in configuration files.
The DISPLAY value set by ssh will point to the server
machine, but with a display number greater than zero. This
is normal, and happens because ssh creates a ``proxy'' X
server on the server machine for forwarding the connections
over the encrypted channel.
ssh will also automatically set up Xauthority data on the
server machine. For this purpose, it will generate a random
authorization cookie, store it in Xauthority on the server,
and verify that any forwarded connections carry this cookie
and replace it by the real cookie when the connection is
opened. The real authentication cookie is never sent to the
server machine (and no cookies are sent in the plain).
If the user is using an authentication agent, the connection
to the agent is automatically forwarded to the remote side
unless disabled on command line or in a configuration file.
Forwarding of arbitrary TCP/IP connections over the secure
channel can be specified either on command line or in a con-
figuration file. One possible application of TCP/IP
forwarding is a secure connection to an electronic purse;
another is going through firewalls.
Server authentication
ssh automatically maintains and checks a database containing
identifications for all hosts it has ever been used with.
RSA host keys are stored in $HOME/.ssh/known_hosts and host
keys used in the protocol version 2 are stored in
$HOME/.ssh/known_hosts2 in the user's home directory. Addi-
tionally, the files /usr/local/sparcv9/etc/ssh_known_hosts
and /usr/local/sparcv9/etc/ssh_known_hosts2 are automati-
cally checked for known hosts. Any new hosts are automati-
cally added to the user's file. If a host's identification
ever changes, ssh warns about this and disables password
authentication to prevent a trojan horse from getting the
user's password. Another purpose of this mechanism is to
prevent man-in-the-middle attacks which could otherwise be
used to circumvent the encryption. The StrictHostKeyCheck-
ing option (see below) can be used to prevent logins to
machines whose host key is not known or has changed.
The options are as follows:
-a Disables forwarding of the authentication agent connec-
tion.
-A Enables forwarding of the authentication agent connec-
tion. This can also be specified on a per-host basis
in a configuration file.
-c blowfish|3des
Selects the cipher to use for encrypting the session.
3des is used by default. It is believed to be secure.
3des (triple-des) is an encrypt-decrypt-encrypt triple
with three different keys. It is presumably more
secure than the des cipher which is no longer fully
supported in ssh. blowfish is a fast block cipher, it
appears very secure and is much faster than 3des .
-c cipher_spec
Additionally, for protocol version 2 a comma-separated
list of ciphers can be specified in order of prefer-
ence. See Ciphers for more information.
-e ch|^ch|none
Sets the escape character for sessions with a pty
(default: `~' ) . The escape character is only recog-
nized 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 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.
-g Allows remote hosts to connect to local forwarded
ports.
-i identity_file
Selects the file from which the identity (private key)
for RSA or DSA authentication is read. Default is
$HOME/.ssh/identity in the user's home directory.
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 configuration files).
-k Disables forwarding of Kerberos tickets and AFS tokens.
This may also be specified on a per-host basis in the
configuration file.
-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 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 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.)
-N Do not execute a remote command. This is useful if you
just want to forward ports (protocol version 2 only).
-o option
Can be used to give options in the format used in the
config file. This is useful for specifying options for
which there is no separate command-line flag. The
option has the same format as a line in the configura-
tion file.
-p port
Port to connect to on the remote host. This can be
specified on a per-host basis in the configuration
file.
-P Use a non-privileged port for outgoing connections.
This can be used if your firewall does not permit con-
nections from privileged ports. Note that this option
turns off RhostsAuthentication and RhostsRSAAuthentica-
tion for older servers.
-q Quiet mode. Causes all warning and diagnostic messages
to be suppressed. Only fatal errors are displayed.
-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 application (eg. sftp). The subsys-
tem is specified as the remote command.
-t Force pseudo-tty allocation. This can be used to exe-
cute arbitrary screen-based programs on a remote
machine, which can be very useful, e.g., when imple-
menting menu services. Multiple -t options force tty
allocation, even if ssh has no local tty.
-T Disable pseudo-tty allocation.
-v Verbose mode. Causes ssh to print debugging messages
about its progress. This is helpful in debugging con-
nection, authentication, and configuration problems.
Multiple -v options increases the verbosity. Maximum
is 3.
-x Disables X11 forwarding.
-X Enables X11 forwarding. This can also be specified on
a per-host basis in a configuration file.
-C Requests compression of all data (including stdin,
stdout, stderr, and data for forwarded X11 and TCP/IP
connections). The compression algorithm is the same
used by gzip(1), and the ``level'' can be controlled by
the CompressionLevel option (see below). 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 Compress option below.
-L 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, and whenever a con-
nection is made to this port, the connection is for-
warded 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 confi-
guration file. Only root can forward privileged ports.
IPv6 addresses can be specified with an alternative
syntax: port/host/hostport
-R 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 con-
nection is made to this port, the connection is for-
warded 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 confi-
guration file. Privileged ports can be forwarded only
when logging in as root on the remote machine. IPv6
addresses can be specified with an alternative syntax:
port/host/hostport
-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.
CONFIGURATION FILES
ssh obtains configuration data from the following sources
(in this order): command line options, user's configuration
file ($HOME/.ssh/config,) and system-wide configuration file
(/usr/local/sparcv9/etc/ssh_config.) For each parameter,
the first obtained value will be used. The configuration
files contain sections bracketed by ``Host'' specifications,
and that section is only applied for hosts that match one of
the patterns given in the specification. The matched host
name is the one given on the command line.
Since the first obtained value for each parameter is used,
more host-specific declarations should be given near the
beginning of the file, and general defaults at the end.
The configuration file has the following format:
Empty lines and lines starting with `#' are comments.
Otherwise a line is of the format ``keyword'' arguments .
The possible keywords and their meanings are as follows
(note that the configuration files are case-sensitive):
Host Restricts the following declarations (up to the next
Host keyword) to be only for those hosts that match one
of the patterns given after the keyword. `*' and `?'
can be used as wildcards in the patterns. A single `*'
as a pattern can be used to provide global defaults for
all hosts. The host is the hostname argument given on
the command line (i.e., the name is not converted to a
canonicalized host name before matching).
AFSTokenPassing
Specifies whether to pass AFS tokens to remote host.
The argument to this keyword must be ``yes'' or ``no''.
This option applies to protocol version 1 only.
BatchMode
If set to ``yes'', passphrase/password querying will be
disabled. This option is useful in scripts and other
batch jobs where you have no user to supply the pass-
word. The argument must be ``yes'' or ``no''. The
default is ``no''.
CheckHostIP
If this flag is set to ``yes'', ssh will additionally
check the host IP address in the known_hosts file.
This allows ssh to detect if a host key changed due to
DNS spoofing. If the option is set to ``no'', the
check will not be executed. The default is ``yes''.
Cipher
Specifies the cipher to use for encrypting the session
in protocol version 1. Currently, ``blowfish'' and
``3des'' are supported. The default is ``3des''.
Ciphers
Specifies the ciphers allowed for protocol version 2 in
order of preference. Multiple ciphers must be comma-
separated. The default is
Bd -literal
``aes128-cbc,3des-cbc,blowfish-cbc,cast128-
cbc,arcfour,
aes192-cbc,aes256-cbc'' Ed
Compression
Specifies whether to use compression. The argument
must be ``yes'' or ``no''. The default is ``no''.
CompressionLevel
Specifies the compression level to use if compression
is enabled. The argument must be an integer from 1
(fast) to 9 (slow, best). The default level is 6,
which is good for most applications. The meaning of
the values is the same as in gzip(1). Note that this
option applies to protocol version 1 only.
ConnectionAttempts
Specifies the number of tries (one per second) to make
before falling back to rsh or exiting. The argument
must be an integer. This may be useful in scripts if
the connection sometimes fails. The default is 4.
EscapeChar
Sets the escape character (default: `~' ) . The
escape character can also be set on the command line.
The argument should be a single character, `^' followed
by a letter, or ``none'' to disable the escape charac-
ter entirely (making the connection transparent for
binary data).
FallBackToRsh
Specifies that if connecting via ssh fails due to a
connection refused error (there is no sshd(8) listening
on the remote host), rsh(1) should automatically be
used instead (after a suitable warning about the ses-
sion being unencrypted). The argument must be ``yes''
or ``no''. The default is ``no''.
ForwardAgent
Specifies whether the connection to the authentication
agent (if any) will be forwarded to the remote machine.
The argument must be ``yes'' or ``no''. The default is
``no''.
ForwardX11
Specifies whether X11 connections will be automatically
redirected over the secure channel and DISPLAY set.
The argument must be ``yes'' or ``no''. The default is
``no''.
GatewayPorts
Specifies whether remote hosts are allowed to connect
to local forwarded ports. The argument must be ``yes''
or ``no''. The default is ``no''.
GlobalKnownHostsFile
Specifies a file to use for the protocol version 1
global host key database instead of
/usr/local/sparcv9/etc/ssh_known_hosts.
GlobalKnownHostsFile2
Specifies a file to use for the protocol version 2 glo-
bal host key database instead of
/usr/local/sparcv9/etc/ssh_known_hosts2.
HostbasedAuthentication
Specifies whether to try rhosts based authentication
with public key authentication. The argument must be
``yes'' or ``no''. The default is ``yes''. This
option applies to protocol version 2 only and is simi-
lar to RhostsRSAAuthentication .
HostKeyAlgorithms
Specfies the protocol version 2 host key algorithms
that the client wants to use in order of preference.
The default for this option is: ``ssh-rsa,ssh-dss''
HostKeyAlias
Specifies an alias that should be used instead of the
real host name when looking up or saving the host key
in the host key database files. This option is useful
for tunneling ssh connections or if you have multiple
servers running on a single host.
HostName
Specifies the real host name to log into. This can be
used to specify nicknames or abbreviations for hosts.
Default is the name given on the command line. Numeric
IP addresses are also permitted (both on the command
line and in HostName specifications).
IdentityFile
Specifies the file from which the user's RSA or DSA
authentication identity is read (default
$HOME/.ssh/identity in the user's home directory).
Additionally, any identities represented by the authen-
tication agent will be used for authentication. The
file name may use the tilde syntax to refer to a user's
home directory. It is possible to have multiple iden-
tity files specified in configuration files; all these
identities will be tried in sequence.
KeepAlive
Specifies whether the system should send keepalive mes-
sages to the other side. If they are sent, death of
the connection or crash of one of the machines will be
properly noticed. However, this means that connections
will die if the route is down temporarily, and some
people find it annoying.
The default is ``yes'' (to send keepalives), 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.
To disable keepalives, the value should be set to
``no'' in both the server and the client configuration
files.
KerberosAuthentication
Specifies whether Kerberos authentication will be used.
The argument to this keyword must be ``yes'' or ``no''.
KerberosTgtPassing
Specifies whether a Kerberos TGT will be forwarded to
the server. This will only work if the Kerberos server
is actually an AFS kaserver. The argument to this key-
word must be ``yes'' or ``no''.
LocalForward
Specifies that a TCP/IP port on the local machine be
forwarded over the secure channel to given host:port
from the remote machine. The first argument must be a
port number, and the second must be host:port. Multi-
ple forwardings may be specified, and additional for-
wardings can be given on the command line. Only the
superuser can forward privileged ports.
LogLevel
Gives the verbosity level that is used when logging
messages from ssh. The possible values are: QUIET,
FATAL, ERROR, INFO, VERBOSE and DEBUG. The default is
INFO.
MACs Specifies the MAC (message authentication code) algo-
rithms in order of preference. The MAC algorithm is
used in protocol version 2 for data integrity protec-
tion. Multiple algorithms must be comma-separated.
The default is
Bd -literal
``hmac-md5,hmac-sha1,hmac-ripemd160,hmac-
ripemd160@openssh.com,
hmac-sha1-96,hmac-md5-96'' Ed
NumberOfPasswordPrompts
Specifies the number of password prompts before giving
up. The argument to this keyword must be an integer.
Default is 3.
PasswordAuthentication
Specifies whether to use password authentication. The
argument to this keyword must be ``yes'' or ``no''.
The default is ``yes''.
Port Specifies the port number to connect on the remote
host. Default is 22.
PreferredAuthentications
Specifies the order in which the client should try pro-
tocol 2 authentication methods. This allows a client to
prefer one method (e.g. keyboard-interactive ) over
another method (e.g. password ) The default for this
option is: ``publickey,'' password, keyboard-
interactive
Protocol
Specifies the protocol versions ssh should support in
order of preference. The possible values are ``1'' and
``2''. Multiple versions must be comma-separated. The
default is ``2,1''. This means that ssh tries version
2 and falls back to version 1 if version 2 is not
available.
ProxyCommand
Specifies the command to use to connect to the server.
The command string extends to the end of the line, and
is executed with /bin/sh. In the command string, `%h'
will be substituted by the host name to connect and
`%p' by the port. The command can be basically any-
thing, and should read from its standard input and
write to its standard output. It should eventually
connect an sshd(8) server running on some machine, or
execute sshd -i somewhere. Host key management will be
done using the HostName of the host being connected
(defaulting to the name typed by the user). Note that
CheckHostIP is not available for connects with a proxy
command.
PubkeyAuthentication
Specifies whether to try public key authentication.
The argument to this keyword must be ``yes'' or ``no''.
The default is ``yes''. This option applies to proto-
col version 2 only.
RemoteForward
Specifies that a TCP/IP port on the remote machine be
forwarded over the secure channel to given host:port
from the local machine. The first argument must be a
port number, and the second must be host:port. Multi-
ple forwardings may be specified, and additional for-
wardings can be given on the command line. Only the
superuser can forward privileged ports.
RhostsAuthentication
Specifies whether to try rhosts based authentication.
Note that this declaration only affects the client side
and has no effect whatsoever on security. Disabling
rhosts authentication may reduce authentication time on
slow connections when rhosts authentication is not
used. Most servers do not permit RhostsAuthentication
because it is not secure (see RhostsRSAAuthentication
). The argument to this keyword must be ``yes'' or
``no''. The default is ``yes''. This option applies
to protocol version 1 only.
RhostsRSAAuthentication
Specifies whether to try rhosts based authentication
with RSA host authentication. The argument must be
``yes'' or ``no''. The default is ``yes''. This
option applies to protocol version 1 only.
RSAAuthentication
Specifies whether to try RSA authentication. The argu-
ment to this keyword must be ``yes'' or ``no''. RSA
authentication will only be attempted if the identity
file exists, or an authentication agent is running.
The default is ``yes''. Note that this option applies
to protocol version 1 only.
ChallengeResponseAuthentication
Specifies whether to use challenge response authentica-
tion. Currently there is only support for skey(1)
authentication. The argument to this keyword must be
``yes'' or ``no''. The default is ``no''.
StrictHostKeyChecking
If this flag is set to ``yes'', ssh will never automat-
ically add host keys to the $HOME/.ssh/known_hosts and
$HOME/.ssh/known_hosts2 files, and refuses to connect
to hosts whose host key has changed. This provides
maximum protection against trojan horse attacks. How-
ever, it can be somewhat annoying if you don't have
good /usr/local/sparcv9/etc/ssh_known_hosts and
/usr/local/sparcv9/etc/ssh_known_hosts2 files installed
and frequently connect to new hosts. This option
forces the user to manually add all new hosts. If this
flag is set to ``no'', ssh will automatically add new
host keys to the user known hosts files. If this flag
is set to ``ask'', 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 automati-
cally in all cases. The argument must be ``yes'',
``no'' or ``ask''. The default is ``ask''.
UsePrivilegedPort
Specifies whether to use a privileged port for outgoing
connections. The argument must be ``yes'' or ``no''.
The default is ``no''. Note that you need to set this
option to ``yes'' if you want to use RhostsAuthentica-
tion and RhostsRSAAuthentication with older servers.
User Specifies the user to log in as. This can be useful if
you have a different user name on different machines.
This saves the trouble of having to remember to give
the user name on the command line.
UserKnownHostsFile
Specifies a file to use for the protocol version 1 user
host key database instead of $HOME/.ssh/known_hosts.
UserKnownHostsFile2
Specifies a file to use for the protocol version 2 user
host key database instead of $HOME/.ssh/known_hosts2.
UseRsh
Specifies that rlogin/rsh should be used for this host.
It is possible that the host does not at all support
the ssh protocol. This causes ssh to immediately exe-
cute rsh(1). All other options (except HostName ) are
ignored if this has been specified. The argument must
be ``yes'' or ``no''.
XAuthLocation
Specifies the location of the xauth(1) program. The
default is /usr/openwin/bin/xauth.
ENVIRONMENT
ssh will normally set the following environment variables:
DISPLAY
The DISPLAY variable indicates the location of the X11
server. It is automatically set by ssh to point to a
value of the form ``hostname:n'' where hostname indi-
cates the host where the shell runs, and n is an
integer >= 1. ssh uses this special value to forward
X11 connections over the secure channel. The user
should normally not set DISPLAY explicitly, as that
will render the X11 connection insecure (and will
require the user to manually copy any required authori-
zation cookies).
HOME Set to the path of the user's home directory.
LOGNAME
Synonym for USER; set for compatibility with systems
that use this variable.
MAIL Set to point the user's mailbox.
PATH Set to the default PATH, as specified when compiling
ssh.
SSH_AUTH_SOCK
indicates the path of a unix-domain socket used to com-
municate with the agent.
SSH_CLIENT
Identifies the client end of the connection. The vari-
able contains three space-separated values: client ip-
address, client port number, and server port number.
SSH_ORIGINAL_COMMAND
The variable contains the original command line if a
forced command is executed. It can be used to extract
the original arguments.
SSH_TTY
This is set to the name of the tty (path to the device)
associated with the current shell or command. If the
current session has no tty, this variable is not set.
TZ The timezone variable is set to indicate the present
timezone if it was set when the daemon was started
(i.e., the daemon passes the value on to new connec-
tions).
USER Set to the name of the user logging in.
Additionally, ssh reads $HOME/.ssh/environment, and adds
lines of the format ``VARNAME=value'' to the environment.
FILES
$HOME/.ssh/known_hosts, $HOME/.ssh/known_hosts2
Records host keys for all hosts the user has logged
into (that are not in
/usr/local/sparcv9/etc/ssh_known_hosts for protocol
version 1 or /usr/local/sparcv9/etc/ssh_known_hosts2
for protocol version 2). See sshd(8).
$HOME/.ssh/identity, $HOME/.ssh/id_dsa, $HOME/.ssh/id_rsa
Contains the authentication identity of the user. They
are for protocol 1 RSA, protocol 2 DSA, and protocol 2
RSA, respectively. These files contain sensitive data
and should be readable by the user but not accessible
by others (read/write/execute). Note that ssh ignores
a private key file if it is accessible by others. It
is possible to specify a passphrase when generating the
key; the passphrase will be used to encrypt the sensi-
tive part of this file using 3DES.
$HOME/.ssh/id_rsa.pub
$HOME/.ssh/identity.pub, $HOME/.ssh/id_dsa.pub,
Contains the public key for authentication (public part
of the identity file in human-readable form). The con-
tents of the $HOME/.ssh/identity.pub file should be
added to $HOME/.ssh/authorized_keys on all machines
where you wish to log in using protocol version 1 RSA
authentication. The contents of the
$HOME/.ssh/id_dsa.pub and $HOME/.ssh/id_rsa.pub file
should be added to $HOME/.ssh/authorized_keys2 on all
machines where you wish to log in using protocol ver-
sion 2 DSA/RSA authentication. These files are not
sensitive and can (but need not) be readable by anyone.
These files are never used automatically and are not
necessary; they are only provided for the convenience
of the user.
$HOME/.ssh/config
This is the per-user configuration file. The format of
this file is described above. This file is used by the
ssh client. This file does not usually contain any
sensitive information, but the recommended permissions
are read/write for the user, and not accessible by oth-
ers.
$HOME/.ssh/authorized_keys
Lists the RSA keys that can be used for logging in as
this user. The format of this file is described in the
sshd(8) manual page. In the simplest form the format
is the same as the .pub identity files (that is, each
line contains the number of bits in modulus, public
exponent, modulus, and comment fields, separated by
spaces). This file is not highly sensitive, but the
recommended permissions are read/write for the user,
and not accessible by others.
$HOME/.ssh/authorized_keys2
Lists the public keys (RSA/DSA) that can be used for
logging in as this user. This file is not highly sen-
sitive, but the recommended permissions are read/write
for the user, and not accessible by others.
/usr/local/sparcv9/etc/ssh_known_hosts, /etc/ssh_known_hosts2
Systemwide list of known host keys.
/usr/local/sparcv9/etc/ssh_known_hosts contains RSA and
/usr/local/sparcv9/etc/ssh_known_hosts2 contains RSA or
DSA keys for protocol version 2. These files should be
prepared by the system administrator to contain the
public host keys of all machines in the organization.
This file should be world-readable. This file contains
public keys, one per line, in the following format
(fields separated by spaces): system name, number of
bits in modulus, public exponent, modulus, and optional
comment field. When different names are used for the
same machine, all such names should be listed,
separated by commas. The format is described on the
sshd(8) manual page.
The canonical system name (as returned by name servers)
is used by sshd(8) to verify the client host when log-
ging in; other names are needed because ssh does not
convert the user-supplied name to a canonical name
before checking the key, because someone with access to
the name servers would then be able to fool host
authentication.
/usr/local/sparcv9/etc/ssh_config
Systemwide configuration file. This file provides
defaults for those values that are not specified in the
user's configuration file, and for those users who do
not have a configuration file. This file must be
world-readable.
$HOME/.rhosts
This file is used in .rhosts authentication to list the
host/user pairs that are permitted to log in. (Note
that this file is also used by rlogin and rsh, which
makes using this file insecure.) Each line of the file
contains a host name (in the canonical form returned by
name servers), and then a user name on that host,
separated by a space. On some machines this file may
need to be world-readable if the user's home directory
is on a NFS partition, because sshd(8) reads it as
root. Additionally, this file must be owned by the
user, and must not have write permissions for anyone
else. The recommended permission for most machines is
read/write for the user, and not accessible by others.
Note that by default sshd(8) will be installed so that
it requires successful RSA host authentication before
permitting .rhosts authentication. If your server
machine does not have the client's host key in
/usr/local/sparcv9/etc/ssh_known_hosts, you can store
it in $HOME/.ssh/known_hosts. The easiest way to do
this is to connect back to the client from the server
machine using ssh; this will automatically add the host
key to $HOME/.ssh/known_hosts.
$HOME/.shosts
This file is used exactly the same way as .rhosts. The
purpose for having this file is to be able to use
rhosts authentication with ssh without permitting login
with rlogin(1) or rsh(1).
/etc/hosts.equiv
This file is used during .rhosts authentication. It
contains canonical hosts names, one per line (the full
format is described on the sshd(8) manual page). If
the client host is found in this file, login is
automatically permitted provided client and server user
names are the same. Additionally, successful RSA host
authentication is normally required. This file should
only be writable by root.
/usr/local/sparcv9/etc/shosts.equiv
This file is processed exactly as /etc/hosts.equiv.
This file may be useful to permit logins using ssh but
not using rsh/rlogin.
/usr/local/sparcv9/etc/sshrc
Commands in this file are executed by ssh when the user
logs in just before the user's shell (or command) is
started. See the sshd(8) manual page for more informa-
tion.
$HOME/.ssh/rc
Commands in this file are executed by ssh when the user
logs in just before the user's shell (or command) is
started. See the sshd(8) manual page for more informa-
tion.
$HOME/.ssh/environment
Contains additional definitions for environment vari-
ables, see section ENVIRONMENT above.
AUTHORS
OpenSSH is a derivative of the original and free ssh 1.2.12
release by Tatu Ylonen. Aaron Campbell, Bob Beck, Markus
Friedl, Niels Provos, Theo de Raadt and Dug Song removed
many bugs, re-added newer features and created OpenSSH.
Markus Friedl contributed the support for SSH protocol ver-
sions 1.5 and 2.0.
SEE ALSO
rlogin(1), rsh(1), scp(1), sftp(1), ssh-add(1), ssh-
agent(1), ssh-keygen(1), telnet(1), sshd(8) Rs %A T. Ylonen
%A T. Kivinen %A M. Saarinen %A T. Rinne %A S. Lehtinen %T
"SSH Protocol Architecture" %N draft-ietf-secsh-
architecture-07.txt %D January 2001 %O work in progress
material Re
|
Закладки на сайте Проследить за страницей |
Created 1996-2024 by Maxim Chirkov Добавить, Поддержать, Вебмастеру |