Unix‎ > ‎Solaris‎ > ‎Solaris man pages‎ > ‎1‎ > ‎

ssh


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]
          [-l login_name] [-F configfile] [-o option] [-p port]
          [-L port:host:hostport] [-R port:host:hostport]
          [-D 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.


     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-sha1, 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 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
     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.)

OPTIONS
     The following options are supported:

     -1                          Forces ssh to try protocol  ver-
                                 sion 1 only.


     -2                          Forces ssh to try protocol  ver-
                                 sion 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 connection.


     -A                          Enables   forwarding   of    the
                                 authentication agent connection.
                                 This can also be specified on  a
                                 per-host  basis  in a configura-
                                 tion 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 con-
                                 nection.   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  identi-
                                 ties loaded into the agent.


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


     -c blowfish | 3des | des    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  sup-
                                 ported  in  ssh.  blowfish  is a
                                 fast block  cipher,  it  appears
                                 very  secure  and is much faster
                                 than 3des.


     -c cipher_spec              Additionally, for protocol  ver-
                                 sion 2 a comma-separated list of
                                 ciphers  can  be  specified   in
                                 order  of  preference.  Protocol
                                 version 2 supports 3DES,  Blowf-
                                 ish,  and  AES  128 in CBC mode.
                                 See Ciphers 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 net-
                                 works. The default value can  be
                                 set  on  a host-by-host basis in
                                 the configuration files. See the
                                 Compression       option      in
                                 ssh_config(4).


     -D port                     Specifies  a  local  ``dynamic''
                                 application-level  port forward-
                                 ing. 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 forwarded over
                                 the secure channel. The applica-
                                 tion protocol is  then  used  to
                                 determine  where  to  connect to
                                 from   the    remote    machine.
                                 Currently,  the  SOCKS4 protocol
                                 is supported and ssh acts  as  a
                                 SOCKS4  server.  Only  root  can
                                 forward    privileged     ports.
                                 Dynamic   port  forwardings  can
                                 also be specified in the  confi-
                                 guration file.


     -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
                                 followed  by  a dot (".") closes
                                 the connection. If  followed  by
                                 Control-z,  the escape character
                                 suspends the connection. If fol-
                                 lowed   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  something like ssh -f host
                                 xterm.


     -F configfile               Specifies  an  alternative  per-
                                 user  configuration  file.  If a
                                 configuration file is  given  on
                                 the  command  line,  the system-
                                 wide     configuration     file,
                                 /etc/ssh_config, is ignored. The
                                 default for the per-user  confi-
                                 guration         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 proto-
                                 col  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 multi-
                                 ple identities specified in con-
                                 figuration files).


     -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 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 the port on the local
                                 side. 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  speci-
                                 fied  in the configuration file.
                                 Only root can forward privileged
                                 ports.  IPv6  addresses  can  be
                                 specified  with  an  alternative
                                 syntax: port/host/hostport.


     -m mac_spec                 Additionally, for protocol  ver-
                                 sion 2 a comma-separated list of
                                 MAC   (message    authentication
                                 code)  algorithms  can be speci-
                                 fied in order of preference. See
                                 the MACs keyword for more infor-
                                 mation.


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


                                 starts     an      emacs      on
                                 shadows.cs.hut.fi,  and  the X11
                                 connection is automatically for-
                                 warded  over  an encrypted chan-
                                 nel. 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  com-
                                 mand. 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 confi-
                                 guration 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 configuration file.


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


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


     -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 the port on the remote
                                 side. 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  local  machine.  Port
                                 forwardings can also  be  speci-
                                 fied  in the configuration file.
                                 Privileged  ports  can  be  for-
                                 warded  only  when logging in as
                                 root on the remote machine.


     -s                          Can be used to  request  invoca-
                                 tion   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
                                 applications, for example, sftp.
                                 The  subsystem  is  specified as
                                 the remote command.


     -t                          Forces  pseudo-tty   allocation.
                                 This  can  be  used  to  execute
                                 arbitrary screen-based  programs
                                 on  a  remote machine, which can
                                 be  very  useful,  for  example,
                                 when implementing menu services.
                                 Multiple -t options force  allo-
                                 cation, 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  connection, authenti-
                                 cation, and configuration  prob-
                                 lems.    Multiple   -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  permis-
                                 sions  on  the  remote host (for
                                 the user's X authorization data-
                                 base)  can  access the local X11
                                 display  through  the  forwarded
                                 connection. An attacker can then
                                 be able  to  perform  activities
                                 such as keystroke monitoring.


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.


     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
     anytime 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       Contains the authentication  iden-
     $HOME/.ssh/id_dsa         tity  of the user. These files are
     $HOME/.ssh/id_ssa         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:



     ____________________________________________________________
    |       ATTRIBUTE TYPE        |       ATTRIBUTE VALUE       |
    |_____________________________|_____________________________|
    | Availability                | SUNWsshu                    |
    |_____________________________|_____________________________|
    | Interface Stability         | See 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),  ssh-
     keygen(1),    ssh-http-proxy-connect(1),   ssh-socks5-proxy-
     connect(1),     telnet(1),     sshd(1M),      ssh_config(4),
     sshd_config(4),   attributes(5),   gss_auth_rules(5),   ker-
     beros(5)


     RFC 4254










Man pages from Solaris 10 Update 8. See docs.sun.com and www.oracle.com for further documentation and Solaris information.
Comments