ssh(1) 맨 페이지 - 윈디하나의 솔라나라

개요

섹션
맨페이지이름
검색(S)

ssh(1)

Name
     ssh - secure shell client (remote login program)

Synopsis
     ssh [-l login_name] hostname | user@hostname [ command]


     ssh [-afgknqstvxACNTX1246] [-b bind_address] [-m mac_spec]
          [-c cipher_spec] [-e escape_char] [-i identity_file]
          [-i PKCS#11-URI]
          [-l login_name] [-F configfile] [-o option] [-p port]
          [-L [bind_address:]port:host:hostport]
          [-R [bind_address:]port:host:hostport]
          [-D [bind_address:]port] hostname | user@hostname [command]

Description
     ssh (Secure Shell) 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 to 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.


     This implementation of ssh supports both SSH  protocol  ver-
     sions 1 and 2 simultaneously. Because of security weaknesses
     in the v1 protocol, only v2 should be run, if possible.


     Support for v1 is provided to help sites with  existing  ssh
     v1 servers to transition to v2. v1 might not be supported in
     a future release.


     ssh connects and logs into the specified hostname. The  user
     must  prove  his or 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 /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 (and primary) authentication method is the rhosts
     or hosts.equiv method combined with RSA-based host authenti-
     cation. It means that if the login  would  be  permitted  by
     $HOME/.rhosts,     $HOME/.shosts,    /etc/hosts.equiv,    or
     /etc/shosts.equiv, and if additionally the server can verify
     the client's host key (see /etc/ssh_known_hosts in the FILES
     section), only then is login permitted. This  authentication
     method  closes security holes due to IP spoofing, DNS spoof-
     ing, 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 cryptogra-
     phy. There are cryptosystems where encryption and decryption
     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
     in the form of a random number, encrypted by the user's pub-
     lic  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 or she
     knows the private key  but  without  disclosing  it  to  the
     server.


     ssh implements the  RSA  authentication  protocol  automati-
     cally.  The  user creates his or 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 or 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 authentica-
     tion is much more secure than rhosts authentication.

     The most convenient way to use  RSA  authentication  can  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
     The SSH version 2 protocol supports multiple user  authenti-
     cation methods, some of which are similar to those available
     with  the  SSH  protocol  version  1.  These  authentication
     mechanisms are negotiated by the client and server, with the
     client trying methods in the order specified in the  Prefer-
     redAuthentications  client  configuration option. The server
     decides when enough authentication methods have passed  suc-
     cessfully  so as to complete the authentication phase of the
     protocol.


     When a user connects by using protocol  version  2,  similar
     authentication  methods  are  available.  Using  the default
     values for PreferredAuthentications,  the  client  tries  to
     authenticate  first  by  using the hostbased method. If this
     method  fails,  public  key  authentication  is   attempted.
     Finally,  if  this  method  fails,  keyboard-interactive and
     password authentication are 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  or  her  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_keys and grants access if both the key
     is  found and the signature is correct. The session identif-
     ier 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, or an extended prompt/reply  proto-
     col can be engaged.


     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-sha2-256,  hmac-sha2-256-96,
     hmac-sha2-512,  hmac-sha2-512-96,  hmac-sha1, and hmac-md5).
     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 specified 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 is automatically encrypted.


     If a pseudo-terminal has been allocated (normal  login  ses-
     sion),  the  user can use the escape characters noted below.
     If a pseudo-terminal has been allocated (normal  login  ses-
     sion), the user can disconnect with ~., and suspend ssh with
     ~^Z. All forwarded connections can be listed with ~#. If the
     session  blocks  waiting for forwarded X11 or TCP/IP connec-
     tions  to  terminate,  ssh  can  be  backgrounded  with  ~&,
     although  this  should  not  be used while the user shell is
     active, as it can cause the shell  to  hang.  All  available
     escapes can be listed with ~?.


     A single tilde character can be sent as ~~, or by  following
     the tilde with 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 or on the command line.


     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"  also
     makes 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 with a character other than those described below.

     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.


     ~?
            Display a list of escape characters.


     ~B
            Send a break to the remote system.  Only  useful  for
            SSH protocol version 2 and if the peer supports it.


     ~C
            Open command line. Only useful for adding  port  for-
            wardings using the -L and -R options).


     ~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 ForwardX11 variable is set to ``yes''  (or,  see  the
     description  of  the  -X and -x options described later) and
     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) goes through the
     encrypted channel, and the connection to the real  X  server
     is 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 points to the  server  machine,
     but  with a display number greater than zero. This is normal
     behavior, because ssh creates a "proxy" X11  server  on  the
     server  machine  for  forwarding  the  connections  over the
     encrypted channel.


     ssh also automatically sets up Xauthority data on the server
     machine.  For this purpose, it generates a random authoriza-
     tion cookie, store it in Xauthority on the server, and  ver-
     ify  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 ForwardAgent variable is set to "yes"  (or,  see  the
     description  of  the  -A and -a options described later) and
     the user is using an authentication agent, the connection to
     the agent is automatically forwarded to the remote side.


     Forwarding of arbitrary TCP/IP connections over  the  secure
     channel  can be specified either on the command line or in a
     configuration file. One possible application of TCP/IP  for-
     warding  is  a  secure  connection  to  an electronic purse.
     Another possible application is firewall traversal.

  Server Authentication
     ssh automatically maintains and checks a database containing
     identifications  for  all  hosts it has ever been used with.
     Host keys are stored in $HOME/.ssh/known_hosts in the user's
     home  directory. Additionally, the file /etc/ssh_known_hosts
     is automatically checked for known hosts.  The  behavior  of
     ssh  with  respect to unknown host keys is controlled by the
     StrictHostKeyChecking parameter. 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 attacks by intermediaries which could  otherwise  be
     used to circumvent the encryption. The StrictHostKeyChecking
     option can be used to prevent logins to machines whose  host
     key is not known or has changed.


     However, when using key exchange protected by  GSS-API,  the
     server  can  advertise  a host key. The client automatically
     adds   this   host   key   to   its   known   hosts    file,
     $HOME/.ssh/known_hosts,  regardless  of  the  setting of the
     StrictHostKeyChecking option, unless the advertised host key
     collides with an existing known hosts entry.


     When the user's GSS-API credentials expire, the client  con-
     tinues  to  be  able to rekey the session using the server's
     public host key to protect the key exchanges.

  GSS-API User and Server Authentication
     ssh uses the user's GSS-API credentials to authenticate  the
     client  to  the server wherever possible, if GssKeyEx and/or
     GssAuthentication are set.


     With GssKeyEx, one can have an SSHv2 server that has no host
     public  keys,  so  that only GssKeyEx can be used. With such
     servers, rekeying fails  if  the  client's  credentials  are
     expired.


     GSS-API user authentication has  the  disadvantage  that  it
     does not obviate the need for SSH host keys, but its failure
     does not impact rekeying. ssh can try  other  authentication
     methods (such as public key, password, and so on) if GSS-API
     authentication fails.


     Delegation of GSS-API credentials can be quite  useful,  but
     is  not  without danger. As with passwords, users should not
     delegate GSS  credentials  to  untrusted  servers,  since  a
     compromised  server  can  use a user's delegated GSS creden-
     tials to impersonate the user.


     GSS-API user authorization is covered in gss_auth_rules(5).


     Rekeying can be used to redelegate credentials when GssKeyEx
     is "yes". (See ~R under Escape Characters above.)


     Configure ssh with:

       UseFIPS140 yes




     ...to run OpenSSL in FIPS-140 mode. Only SSH  Protocol  Ver-
     sion 2 is supported. SunSSH may still delegate cryptographic
     operations for user/host authentication to  other  parts  of
     Solaris  which  may  or  may  not be FIPS 140-certified. The
     default value of UseOpenSSLEngine option is no, and the set-
     ting  of  UseOpenSSLEngine to yes does not have an effect in
     FIPS mode. As a further requirement to run ssh  in  FIPS-140
     mode, the client needs to generate the user's private key in
     PKCS#8 format with the ssh-keygen -8 command.

     For the case of ssh with FIPS-140 enabled, when logging into
     a non-FIPS-140 sshd, the supported and approved FIPS ciphers
     must be explicitly specified in  the  sshd_config(4),  using
     "Ciphers" for this scenario.

Options
     The following options are supported:

     -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
         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.

         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, the attacker can perform operations on the keys
         that enable the attacker to authenticate using the iden-
         tities loaded into the agent.


     -b bind_address
         Specifies the interface to  transmit  from  on  machines
         with multiple interfaces or aliased addresses.

     -c cipher_spec
         Selects the cipher specification for encrypting the ses-
         sion.

         For protocol version 1, cipher_spec is a single  cipher.
         See the Cipher option in ssh_config(4) for more informa-
         tion.

         For protocol version 2, cipher_spec is a comma-separated
         list  of  ciphers listed in order of preference. See the
         Ciphers option in ssh_config(4) for more information.


     -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).  The  gzip  man  page  is  available in the
         SUNWsfman package. The "level" can be controlled by  the
         CompressionLevel option (see ssh_config(4)). Compression
         is desirable on modem lines and other slow  connections,
         but only slows down things on fast networks. The default
         value can be set on a host-by-host basis in  the  confi-
         guration   files.   See   the   Compression   option  in
         ssh_config(4).


     -D [bind_address:]port
         Specifies a local dynamic  application-level  port  for-
         warding.  This works by allocating a socket to listen to
         port on the local side, optionally bound to  the  speci-
         fied bind_address. Whenever a connection is made to this
         port, the connection is forwarded over the secure  chan-
         nel.  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
         acts  as  a  SOCKS  server.  Only  a  user  with  enough
         privileges  can  forward  privileged ports. Dynamic port
         forwardings can also be specified in  the  configuration
         file.

         IPv6 addresses can be specified with an alternative syn-
         tax:  [bind_address/]port or by enclosing the address in
         square brackets. By default, the local port is bound  in
         accordance  with  the  GatewayPorts setting. However, an
         explicit bind_address can 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 * indicates that the
         port should be available from all interfaces.

     -e ch | ^ch | none
         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  fol-
         lowed by a dot (.) closes the connection. If followed by
         CTRL-z, the escape character suspends the connection. If
         followed  by  itself,  the escape character sends itself
         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 the -n option. The recommended
         way to start X11 programs at a remote site is with some-
         thing like ssh -f host xterm.


     -F configfile
         Specifies an alternative per-user configuration file. If
         a  configuration  file is specified on the command line,
         the system-wide configuration file, /etc/ssh_config,  is
         ignored. The default for the per-user configuration file
         is $HOME/.ssh/config.


     -g
         Allows remote hosts to connect to local forwarded ports.


     -i identity_file
         Selects a file from which the identity (private key) for
         RSA  or  DSA  authentication  is  read.  The  default is
         $HOME/.ssh/identity  for   protocol   version   1,   and
         $HOME/.ssh/id_rsa  and  $HOME/.ssh/id_dsa  for  protocol
         version 2. Identity files can 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).


     -I PKCS#11-URI
         Works with a certificate and a private key stored in the
         PKCS#11  token,  instead  of  an  identify file. See the
         Using X.509 Certificates section  in  the  sshd(1M)  man
         page for details.

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


     -L [bind_address:]port:host:hostport
         Specifies that the specified port on the local  (client)
         host  is  to be forwarded to the specified host and port
         on the remote side. This works by allocating a socket to
         listen  to  the port on the local side, optionally bound
         to the specified bind_address. Then, whenever a  connec-
         tion  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. Only  a
         user  with  enough  privileges  can  forward  privileged
         ports. IPv6 addresses can be specified with an  alterna-
         tive  syntax:  [bind_address/]port/host/hostport  or  by
         enclosing the address in square brackets.

         By default, the local port is bound in  accordance  with
         the   GatewayPorts   setting.   However,   an   explicit
         bind_address can be used to bind  the  connection  to  a
         specific  address.  The  bind_address of localhost indi-
         cates that the listening port be  bound  for  local  use
         only,  while  an  empty  address or * indicates that the
         port should be available from all interfaces.


     -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  key-
         word for more information.


     -n
         Redirects stdin from /dev/null (actually, prevents read-
         ing  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 &


         starts an emacs on shadows.cs.hut.fi, and the  X11  con-
         nection  is  automatically  forwarded  over an encrypted
         channel. The ssh program is put in the background.  This
         does  not  work  if  ssh  needs to ask for a password or
         passphrase. See also the -f option.


     -N
         Does 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
         configuration   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
         configuration file.


     -p port
         Specifies the port to connect to  on  the  remote  host.
         This  can be specified on a per-host basis in the confi-
         guration file.


     -P
         Obsoleted  option.  SSHv1  connections  from  privileged
         ports are not supported.


     -q
         Quiet mode. Causes all warning and  diagnostic  messages
         to be suppressed. Only fatal errors are displayed.


     -R [bind_address:]port:host:hostport
         Specifies that the specified port on the remote (server)
         host  is  to be forwarded to the specified host and port
         on the local side. This works by allocating a socket  to
         listen  to the port on the remote side. Then, whenever a
         connection 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  for-
         wardings  can  also  be  specified  in the configuration
         file. Privileged ports can be forwarded only  when  log-
         ging  in  on  the  remote  machine as a user with enough
         privileges.

         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 is  bound
         to  the  loopback interface only. This can be overridden
         by specifying 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  only succeeds if the server's GatewayPorts
         option is enabled. See sshd_config(4).


     -s
         Can be used to request invocation of a subsystem on  the
         remote system. Subsystems are a feature of the SSH2 pro-
         tocol which facilitate the use of SSH as a secure  tran-
         sport  for  other  applications,  for example, sftp. The
         subsystem is specified as the remote command.


     -t
         Forces pseudo-tty allocation. This can be used  to  exe-
         cute   arbitrary   screen-based  programs  on  a  remote
         machine, which can be very  useful,  for  example,  when
         implementing  menu  services.  Multiple -t options force
         allocation, even if ssh has no local tty.


     -T
         Disables  pseudo-tty  allocation  (protocol  version   2
         only).


     -v
         Verbose mode. Causes ssh  to  print  debugging  messages
         about its progress. This is helpful in debugging connec-
         tion, authentication, and configuration problems. Multi-
         ple -v options increase 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.

         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 can  then  be  able  to  perform
         activities such as keystroke monitoring.

         For this reason, X11 forwarding might  be  subjected  to
         X11   SECURITY  extension  restrictions.  Refer  to  the
         ForwardX11Trusted directive in  ssh_config(4)  for  more
         information.

         If X11 forwarding is  enabled,  remote  X11  clients  is
         trusted  by  default.  This  means  that  they have full
         access to the original X11 display.

Environment Variables
     ssh normally sets the following environment variables:

     DISPLAY
         The DISPLAY variable must be set for  X11  display  for-
         warding to work.


     SSH_ASKPASS
         If ssh needs a passphrase, it reads the passphrase  from
         the  current  terminal if it was run from a terminal. If
         ssh does not have a  terminal  associated  with  it  but
         DISPLAY and SSH_ASKPASS are set, it executes the program
         specified by SSH_ASKPASS and opens an X11 window to read
         the passphrase. This is particularly useful when calling
         ssh from a .Xsession or related script. On some machines
         it  might  be  necessary  to  redirect  the  input  from
         /dev/null to make this work. The system is shipped  with
         /usr/lib/ssh/ssh-askpass  which is the default value for
         SSH_ASKPASS


     SSH_AUTH_SOCK
         Indicates the path of a unix-domain socket used to  com-
         municate with the agent.


     SSH_LANGS
         A  comma-separated  list  of  IETF  language  tags  (see
         RFC3066) indicating the languages that the user can read
         and write. Used for negotiation of  the  locale  on  the
         server.


     LANG, LC_ALL, LC_COLLATE, LC_CTYPE,
     LC_MESSAGES, LC_MONETARY, LC_NUMERIC, LC_TIME
         The values of these environment variables can be set  in
         remote  sessions according to the locale settings on the
         client  side  and  availability  of  support  for  those
         locales on the server side. Environment Variable Passing
         (see RFC 4254) is used for  passing  them  over  to  the
         server side.



     See the ENVIRONMENT VARIABLES section in  the  sshd(1M)  man
     page  for  more  information  on  how  locale setting can be
     further changed depending on server side configuration.

Exit Status
     The status of the remote program is  returned  as  the  exit
     status  of ssh. 255 is returned if an error occurred at any-
     time during the ssh connection, including  the  initial  key
     exchange.

Files
     $HOME/.ssh/known_hosts
                               Records host keys  for  all  hosts
                               the  user has logged into that are
                               not  in  /etc/ssh/ssh_known_hosts.
                               See sshd(1M).


     $HOME/.ssh/identity
     $HOME/.ssh/id_dsa
     $HOME/.ssh/id_ssa
                               Contains the authentication  iden-
                               tity  of the user. These files are
                               for protocol  1  RSA,  protocol  2
                               DSA,  and  protocol 2 RSA, respec-
                               tively. These files contain sensi-
                               tive  data  and should be readable
                               by the user but not accessible  by
                               others  (read/write/execute).  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 is used to encrypt  the
                               sensitive  part of this file using
                               3DES.


     /etc/ssh/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 sshd(1M) for more
                               information.


     $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 sshd(1M) for more
                               information.


     $HOME/.ssh/environment
                               Contains  additional   definitions
                               for   environment  variables.  See
                               ENVIRONMENT VARIABLES.

Attributes
     See attributes(5) for descriptions of the  following  attri-
     butes:



     tab() box; cw(2.75i) |cw(2.75i) lw(2.75i) |lw(2.75i)  ATTRI-
     BUTE  TYPEATTRIBUTE VALUE _ Availabilitynetwork/ssh _ Inter-
     face StabilitySee below.



     The command line syntax  is  Committed.  The  remote  locale
     selection  through  passing  LC_*  environment  variables is
     Uncommitted.

See Also
     rlogin(1), rsh(1), scp(1),  ssh-add(1),  ssh-agent(1),  sshkeygen(1),
     ssh-http-proxy-connect(1),   ssh-socks5-proxyconnect(1),
     telnet(1),     sshd(1M),      ssh_config(4),
     sshd_config(4),   attributes(5),   gss_auth_rules(5),   kerberos(5),
     privileges(5)


     See   the   discussion   of    the    .k5login    file    in
     krb5_auth_rules(5).


     RFC 1928


     RFC 4254
맨 페이지 내용의 저작권은 맨 페이지 작성자에게 있습니다.
RSS ATOM XHTML 5 CSS3