The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Интерактивная система просмотра системных руководств (man-ов)

 ТемаНаборКатегория 
 
 [Cписок руководств | Печать]

ssh2 (1)
  • >> ssh2 (1) ( Solaris man: Команды и прикладные программы пользовательского уровня )
  • 
    NAME
         ssh2 - secure shell client (remote login program)
    
    
    SYNOPSIS
         ssh2 [-l login_name] hostname [command]
    
         ssh2 [-l login_name] [-n]  [+a]  [-a]  [+x]  [-x]  [-i file]
         [-F file]  [-t]  [-v]  [-d debug_level]  [-V]  [-q]  [-f[o]]
         [-e char]    [-c cipher]     [-m MAC]     [-p port]     [-S]
         [-L [protocol/]port:host:hostport]
         [-R [protocol/]port:host:hostport] [+C]  [-C]  [-o `option']
         [-h] [login_name@]hostname[#port] [command]
    
    DESCRIPTION
         Ssh2 (Secure Shell) is a program for logging into  a  remote
         machine  and  executing commands in 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.
    
         Ssh2 connects and logs into  the  specified  hostname.   The
         user  must  prove  his  identity to the remote machine using
         some authentication method.
    
         Public key authentication is based on  the  use  of  digital
         signatures.  Each  user  creates a public / private key pair
         for authentication purposes. The  server  knows  the  user's
         public  key,  and  only  the  user  has the private key. The
         filenames of private keys that are  used  in  authentication
         are  set  in $HOME/.ssh2/identification. When the user tries
         to    authenticate    himself,     the     server     checks
         $HOME/.ssh2/authorization  for  filenames of matching public
         keys and sends a challenge to the  user  end.  The  user  is
         authenticated  by  signing  the  challenge using the private
         key. See the FILES section below  for  more  information  on
         identification and authorization files.
    
         Private  /  public  key  pairs  can  be  created  with  ssh-
         keygen2(1).  See ssh-agent2(1) for information on how to use
         public key authentication in conjunction with an authentica-
         tion agent.
    
         If other authentication methods fail, ssh2 will prompt for a
         password.  Since all communications are encrypted, the pass-
         word will not be available for eavesdroppers.
    
         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 no pseudo tty has been allocated, the  session  is  tran-
         sparent and can be used to reliably transfer binary data.
    
         The session terminates when the command or shell in  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 ssh2.
    
         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  ssh2  will  point  to  the  server
         machine,  but with a display number greater than zero.  This
         is normal, and happens because  ssh2  creates  a  "proxy"  X
         server  on the server machine for forwarding the connections
         over the encrypted channel.
    
         Ssh2 will also automatically set up the Xauthority  data  on
         the  server  machine.   For this purpose, it will generate a
         random authentication cookie, store  it  in  the  Xauthority
         data  on  the  server, and verify that any forwarded connec-
         tions carry this cookie and replace it with 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 the command line or  in  a  configuration
         file.
    
         Forwarding of arbitrary TCP/IP connections over  the  secure
         channel  can be specified either on the command line or in a
         configuration file.   TCP/IP  forwarding  can  be  used  for
         secure connections to electronic purses or for going through
         firewalls.
    
         Ssh2 automatically maintains and checks a database  contain-
         ing  the host public keys. When logging on to a host for the
         first time, the host's  public  key  is  stored  in  a  file
         .ssh2/hostkey_PORTNUMBER_HOSTNAME.pub  in  the  user's  home
         directory. If a host's identification changes, ssh2 issues a
         warning and disables the password authentication in order 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.
    
         Ssh2 has built-in support for SOCKS version 4 for traversing
         firewalls.  See ENVIRONMENT.
    
    OPTIONS
         -l login_name
              Specifies the user for login to the remote machine.
    
         -n   Redirect input from /dev/null, ie.  don't  read  stdin.
              This  option can also be specified in the configuration
              file.
    
         +a   Enable authentication agent forwarding. (default)
    
         -a   Disable authentication agent forwarding.
    
         +x   Enable X11 connection forwarding. (default)
    
         -x   Disable X11 connection forwarding.
    
         -i file
              Specifies the identity file for public key  authentica-
              tion.  This  option can also be specified in the confi-
              guration file.
    
         -F file
              Specifies an alternative  configuration  file  to  use.
              NOTE:   $HOME/.ssh2/ssh2_config  is still read, options
              specified here will be used in addition to those.
    
         -t   For tty allocation, ie. allocate a tty even if  a  com-
              mand is given. This option can also be specified in the
              configuration file.
    
         -v   Enable verbose mode.  Display  verbose  debugging  mes-
              sages.  Equal to `-d 2'. This option can also be speci-
              fied in the configuration file.
    
         -d debug_level
              Print   extensive   debug   information   to    stderr.
              debug_level  is either a number, from 0 to 99, where 99
              specifies  that  all  debug   information   should   be
              displayed,  or  a  comma-separated  list of assignments
              "ModulePattern=debug_level".
    
         -V   Display version string.
    
         -q   Make ssh2 quiet, so that it doesn't display any warning
              messages.  This  option  can  also  be specified in the
              configuration file.
    
         -f [o]
              Fork into background after authentication. This  option
              can  also  be  specified  in  the  configuration  file.
              Implies '-S' and '-n'. With this option, ssh2 stays  in
              the  background,  waiting  for connections indefinitely
              (it has to be killed for it to stop listening). With an
              optional  `o'  argument,  it goes to ``one-shot'' mode,
              which means that once all  channels  are  closed,  ssh2
              exits.
    
         -e char
              Set the escape character. Use ``none'' to disable. This
              option can also be specified in the configuration file.
              (default: ~)
    
         -c cipher
              Select the encryption algorithm.  Multiple  -c  options
              are  allowed  and  a  single  -c flag can have only one
              cipher. This option can also be specified in the confi-
              guration  file.  You  can  use blowfish, twofish, cast,
              arcfour, des, and 3des.
    
         -m MAC
              Select the MAC (Message Authentication Code) algorithm.
              Multiple  -m  options  are allowed and a single -m flag
              can have only one MAC. This option can also  be  speci-
              fied in the configuration file.
    
         -p port
              Port to connect to on the remote host. This option  can
              also be specified in the configuration file.
    
         -S   Don't request a session channel. This can be used  with
              port-forwarding requests if a session channel (and tty)
              isn't needed, or the server doesn't give one.
    
         -L [protocol/]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
              be  listened port on the local side. Whenever a connec-
              tion is made to this port, the connection is  forwarded
              over  the  secure  channel  and a connection is made to
              host:hostport from the remote machine.   Port  forward-
              ings  can  also be specified in the configuration file.
              Only root can  forward  privileged  ports.  Giving  the
              argument  protocol  enables  the protocol-specific for-
              warding. The protocols implemented are tcp (default, no
              special  processing) and ftp (temporary forwardings are
              created for ftp data channels, effectively securing the
              whole ftp session).
    
         -R [protocol/]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:hostport   from   the   local   machine.
              Privileged  ports can be forwarded only when logging in
              as root on the remote machine. Giving the argument pro-
              tocol enables the protocol-specific forwarding. See the
              section for option -L for a list of possible protocols.
    
         +C   Enable compression.
    
         -C   Disable compression. (default)
    
         -o 'option'
              Can be used to specify options in the  format  used  in
              the configuration files.  This is useful for specifying
              options for which there are  no  separate  command-line
              flags.  The option has the same format as a line in the
              configuration file.  Comment lines  are  not  currently
              accepted via this option.
    
         -h   Display a short help on command-line options.
    
    
    CONFIGURATION FILES
         Ssh2 obtains configuration data from the  following  sources
         (in  this  order): system's global configuration file (typi-
         cally  /etc/ssh2/ssh2_config),  user's  configuration   file
         ($HOME/.ssh2/ssh2_config) and the command line options.  For
         each parameter, the last obtained value will be effective.
    
         For format of ssh2_config, see ssh2_config(5).
    
    
         Ssh2 supports escape sequences that enable you to have  some
         manageability  with  the  session.  In  order for any escape
         sequences to take effect, you will need to  have  entered  a
         newline  character  (read: press enter before actually doing
         any of these operations). What you need to do after that  is
         manually  enter  the  characters  (for example, a newline, a
         tilde ~, and the appropriate character for  the  appropriate
         task).
    
         ~.   Terminate the connection.
    
    
         ~^Z  Suspend the session (press control-Z, not ^ and Z).
    
         ~~   Send the escape character.
    
         ~#   List forwarded connections.
    
         ~-   Disable the escape character uncancellably.
    
         ~?   See a summary of escape sequences.
    
         ~r   Initiate rekeying manually.
    
         ~s   Give all sorts of statistics on the connection, includ-
              ing server and client version, compression, packets in,
              packets out, compression, key exchange algorithms, pub-
              lic key algorithms and symmetric ciphers.
    
         ~V   Dump the client version number to  stderr  (useful  for
              troubleshooting).
    
    
         Ssh2 will normally set the following environment variables:
    
         DISPLAY
              The DISPLAY variable indicates the location of the  X11
              server.   It is automatically set by ssh2 to point to a
              value of the form "hostname:n" where hostname indicates
              the  host  where the shell runs, and n is an integer >=
              1.  Ssh2 uses this special value to forward X11 connec-
              tions  over  the  secure channel.  The user should nor-
              mally not set DISPLAY explicitly, as that  will  render
              the  X11 connection insecure (and will require the user
              to manually copy any required authorization cookies).
    
         HOME Set to the path of the user's home directory.
    
         LOGNAME
              Synonym for USER; set for  compatibility  with  systems
              using this variable.
    
         MAIL Set to point the user's mailbox.
    
         PATH Set to the default PATH, as  specified  when  compiling
              ssh2   or,   on   some   systems,  /etc/environment  or
              /etc/default/login.
    
         SSH_SOCKS_SERVER
              If SOCKS is used, it is configured with this  variable.
              The       format      of      the      variable      is
              socks://username@socks_server:port/network/netmask,network/netmask
              ...   for   example  by  setting  environment  variable
              SSH_SOCKS_SERVER                                     to
              socks://mylogin@socks.ssh.com:1080/203.123.0.0/16,198.74.23.0/24
              uses host socks.ssh.com port 1080 as your SOCKS  server
              if   connection   is   attempted  outside  of  networks
              203.123.0.0 (16 bit  domain)  and  198.74.23.0  (8  bit
              domain) which are connected directly.
    
              A default value for SSH_SOCKS_SERVER  variable  can  be
              specified  at  compile time by specifying --with-socks-
              server=VALUE on the configure command line when compil-
              ing ssh2. The default value can be cancelled by setting
              SSH_SOCKS_SERVER to an empty string, and overridden  by
              setting  SSH_SOCKS_SERVER  to  a  new  value.   If  the
              SSH_SOCKS_SERVER variable  is  set,  it  should  almost
              always  contain local loopback network (127.0.0.0/8) as
              network that is connected directly.
    
         SSH2_AUTH_SOCK
              If this exists, it is used to indicate the  path  of  a
              unix-domain socket used to communicate with the authen-
              tication agent (or its local representative).
    
         SSH2_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.
    
         SSH2_ORIGINAL_COMMAND
              This will be the original command given to  ssh2  if  a
              forced  command  is  run. It can be used to fetch argu-
              ments etc.  from the other end. This does not  have  to
              be  a  real command, it can be the name of a file, dev-
              ice, parameters or anything else.
    
         SSH2_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 (the
              daemon passes the value to new connections).
    
         USER Set to the name of the user logging in.
    
         Additionally,    ssh2     reads     /etc/environment     and
         $HOME/.ssh2/environment,   and  adds  lines  of  the  format
         VARNAME=value to the environment.   Some  systems  may  have
         still  additional mechanisms for setting up the environment,
         such as /etc/default/login on Solaris.
    
    
    
    FILES
         $HOME/.ssh2/random_seed
              Used for seeding the  random  number  generator.   This
              file contains sensitive data and its permissions should
              be 'read/write' for the user and 'not  accessible'  for
              others.   This  file is created the first time the pro-
              gram is run and it is updated automatically.  The  user
              should never need to read or modify this file.
    
         $HOME/.ssh2/ssh2_config
              This is the per-user configuration file.  The format of
              this file is described above.  This file is used by the
              ssh2 client.  This file does not  usually  contain  any
              sensitive  information, but the recommended permissions
              are 'read/write' for the user, and 'not accessible' for
              others.
    
         $HOME/.ssh2/identification
              contains information on how the user wishes to  authen-
              ticate himself when contacting a specific host.
    
              The identification file has the same general syntax  as
              the  configuration files. The following keywords may be
              used:
    
         IdKey
              This is followed by the filename of a  private  key  in
              the  $HOME/.ssh2 directory used for identification when
              contacting a host.  If there are more than one IdKeys ,
              they  are  tried  in  the order that they appear in the
              identification file.
    
         PgpSecretKeyFile
              This is followed by the filename of the user's  OpenPGP
              private  keyring in the $HOME/.ssh2 directory.  OpenPGP
              keys listed after this line are expected  to  be  found
              from  this  file.   Keys  identified  with "IdPgpKey*"-
              keywords are used like ones  identified  with  "IdKey"-
              keyword.
    
         IdPgpKeyName
              This is followed by the OpenPGP key name of the key  in
              PgpSecretKeyFile file.
    
         IdPgpKeyFingerprint
              This is followed by the OpenPGP key fingerprint of  the
              key in PgpSecretKeyFile file.
    
         IdPgpKeyId
              This is followed by the OpenPGP key ID of  the  key  in
              PgpSecretKeyFile file.
    
         $HOME/.ssh2/authorization
              contains information on how the server will verify  the
              identity of an user.
    
              The authorization file has the same general  syntax  as
              the  configuration files. The following keywords may be
              used:
    
         Key  This is followed by the filename of a public key in the
              $HOME/.ssh2  directory  that is used for identification
              when contacting the host.  If there are more  than  one
              key, they are all acceptable for login.
    
         PgpPublicKeyFile
              This is followed by the filename of the user's  OpenPGP
              public  keyring in $HOME/.ssh2 directory.  OpenPGP keys
              listed after this line are expected to  be  found  from
              this file.  Keys identified with "PgpKey*"-keywords are
              used like ones identified with "Key"-keyword.
    
         PgpKeyName
              This is followed by the OpenPGP key name.
    
         PgpKeyFingerprint
              This is followed by the OpenPGP key fingerprint.
    
         PgpKeyId
              This is followed by the OpenPGP key ID.
    
         Command
              This  keyword,  if  used,  must  follow  the  "Key"  or
              "PgpKey*"  keyword  above.  This  is  used to specify a
              "forced command" that will be executed  on  the  server
              side  instead of anything else when the user is authen-
              ticated. The command supplied by the user (if  any)  is
              put       in       the       environment       variable
              "SSH2_ORIGINAL_COMMAND". The command is run on a pty if
              the  connection  requests  a  pty;  otherwise it is run
              without a tty. A quote may be included in  the  command
              by  quoting  it  with a backslash. This option might be
              useful for restricting certain public keys  to  perform
              just  a  specific  operation. An example might be a key
              that permits remote backups but  nothing  else.  Notice
              that  the client may specify TCP/IP and/or X11 forward-
              ings, unless they are explicitly prohibited.
    
    
         $HOME/.ssh2/hostkeys/key_xxxx_yyyy.pub
              These files are the public keys of the hosts  you  con-
              nect  to.  These  are updated automatically, unless you
              have set StrictHostKeyChecking to "yes".  If  a  host's
              key  changes,  you  should  put  here the new key. (But
              don't do that, unless you can be sure the key is valid,
              ie.  that  no  man-in-the-middle  attack has occurred!)
              The "xxxx" is the port on the server, where sshd2 runs,
              and the "yyyy" is the host (specified on command-line).
    
    
         /etc/ssh2/hostkeys/key_xxxx_yyyy.pub
              If  a  host  key  is   not   found   from   the   users
              "$HOME/.ssh2/hostkeys"  directory,  this  is  the  next
              location to be checked. These files have to be  updated
              manually; no files are put here automatically.
    
    
         $HOME/.rhosts
              This file contains host-username pairs, separated by  a
              space, one per line.  The given user on the correspond-
              ing host is permitted to log in without password.   The
              same  file  is used by rlogind and rshd.  sshd2 differs
              from rlogind and rshd in that it requires  public  host
              key  authentication  in addition to validating the host
              name retrieved from domain name servers. The file  must
              be writable only by the user; it is recommended that it
              not be accessible by others.
    
              It is also possible  to  use  netgroups  in  the  file.
              Either host or user name may be of the form +@groupname
              to specify all hosts or all users in the group.
    
         $HOME/.shosts
              For ssh2, this file is exactly the same as for .rhosts.
              However,  this  file is not used by rlogin and rshd, so
              using this permits access using ssh2 only.
    
         /etc/hosts.equiv
              This file is used during  .rhosts  authentication.   In
              its  simplest  form, this file contains host names, one
              per line.  Users on those hosts are permitted to log in
              without  a  password,  provided that they have the same
              user name on both machines.  The host name may also  be
              followed  by  a  user name; such users are permitted to
              log in as any  user  on  this  machine  (except  root).
              Additionally, the syntax +@group can be used to specify
              netgroups.  Negated entries start with '-'.
    
              If the client host/user is successfully matched in this
              file,  login  is automatically permitted, provided that
              the client and server user names are the  same.   Addi-
              tionally,  successful public key host authentication is
              normally required.  This file must be writable only  by
              root; it is recommended that it be world-readable.
    
              Warning: It is almost never a good  idea  to  use  user
              names in hosts.equiv.  Note that this really means that
              the named user(s) can log in as anybody, including bin,
              daemon,  adm,  and  other  accounts  that  own critical
              binaries and directories.  Using a  user  name  practi-
              cally  grants the user root access.  The only valid use
              for user names should be  in  negative  entries.   Note
              that this warning also applies to rsh/rlogin.
    
         /etc/shosts.equiv
              This is processed exactly as /etc/hosts.equiv. However,
              this  file  may  be useful in environments that want to
              run both rsh/rlogin and ssh2.
    
    
         $HOME/.ssh2/knownhosts/xxxxyyyy.pub
              These are the public hostkeys  of  hosts  that  a  user
              wants  to  log  from  using  "hostbased"-authentication
              (equivalent with ssh1's RhostsRSAAuthentication). Also,
              a  user has to set up her/his $HOME/.shosts (which only
              ssh uses) or $HOME/.rhosts file. (This is insecure,  as
              the  file is used also by the r*-commands.) If username
              is the same in both hosts, it is adequate  to  put  the
              public  hostkey  to  /etc/ssh2/knownhosts  and  add the
              host's name to /etc/shosts.equiv (or /etc/hosts.equiv).
    
              xxxx denotes the hostname (FQDN) and yyyy the publickey
              algorithm of the key.
    
              For example, zappa.foo.fi's hostkey algorithm  is  ssh-
              dss.  The  hostkey  would  be  named "zappa.foo.fi.ssh-
              dss.pub" in the knownhosts-directory.
    
              Possible names for publickey-algorithms  are  "ssh-dss"
              and "ssh-rsa" (without the quotes).
    
    
         /etc/ssh2/knownhosts/xxxxyyyy.pub
              As above, but system-wide. These settings can be  over-
              ridden by the user by putting a file with the same name
              to her/his $HOME/.ssh2/knownhosts directory.
    
    
    AUTHORS
         SSH Communications Security Corp
    
         For more information, see http://www.ssh.com.
    
    
    SEE ALSO
         ssh2_config(5),  sshd2(8),  ssh-keygen2(1),   ssh-agent2(1),
         ssh-add2(1), scp2(1), sftp(1) rlogin(1), rsh(1), telnet(1)
    
    


    Поиск по тексту MAN-ов: 




    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру