Man Linux: Main Page and Category List

NAME

       sshpass - noninteractive ssh password provider

SYNOPSIS

       sshpass [-ffilename|-dnum|-ppassword|-e] [options] command arguments

DESCRIPTION

       This manual page documents the sshpass command.

       sshpass  is  a utility designed for running ssh using the mode referred
       to as  "keyboard-interactive"  password  authentication,  but  in  non-
       interactive mode.

       ssh  uses  direct  TTY  access to make sure that the password is indeed
       issued by an interactive keyboard user. Sshpass runs ssh in a dedicated
       tty,  fooling  it  into  thinking  it  is  getting the password from an
       interactive user.

       The command to run is specified after sshpass’ own  options.  Typically
       it  will  be "ssh" with arguments, but it can just as well be any other
       command. The  password  prompt  used  by  ssh  is,  however,  currently
       hardcoded into sshpass.

Options

       If  not  option  is given, sshpass reads the password from the standard
       input. The user may  give  at  most  one  alternative  source  for  the
       password:

       -ppassword
              The  password  is  given  on  the  command line. Please note the
              section titled "SECURITY CONSIDERATIONS".

       -ffilename
              The password is the first line of the file filename.

       -dnumber
              number is a  file  descriptor  inherited  by  sshpass  from  the
              runner. The password is read from the open file descriptor.

       -e     The password is taken from the environment variable "SSHPASS".

SECURITY CONSIDERATIONS

       First  and  foremost,  users  of  sshpass  should  realize  that  ssh’s
       insistance on only getting the password interactively  is  not  without
       reason.  It  is close to impossible to securely store the password, and
       users  of  sshpass   should   consider   whether   ssh’s   public   key
       authentication  provides  the same end-user experience, while involving
       less hassle and being more secure.

       The -p option should be considered the least secure of all of sshpass’s
       options.   All  system  users  can see the password in the command line
       with a simple "ps" command.  Sshpass  makes  no  attempt  to  hide  the
       password,  as  such  attempts  create  race conditions without actually
       solving the problem. Users of sshpass are encouraged to use one of  the
       other password passing techniques, which are all more secure.

       In  particular,  people  writing programs that are meant to communicate
       the password programatically are encouraged to use  an  anonymous  pipe
       and pass the pipe’s reading end to sshpass using the -d option.

RETURN VALUES

       As  with  any  other  program, sshpass returns 0 on success. In case of
       failure, the following return codes are used:

       1      Invalid command line argument

       2      Conflicting arguments given

       3      General runtime error

       4      Unrecognized response from ssh (parse error)

       5      Invalid/incorrect password

       6      Host public key is unknown. sshpass exits without confirming the
              new key.

       In addition, ssh might be complaining about a man in the middle attack.
       This complaint does not go to  the  tty.  In  other  words,  even  with
       sshpass,  the  error  message from ssh is printed to standard error. In
       such a case ssh’s return code is reported back. This  is  typically  an
       unimaginative (and non-informative) "255" for all error cases.

EXAMPLES

       Run  rsync over SSH using password authentication, passing the password
       on the command line:

       rsync --rsh=’sshpass -p 12345 ssh -l test’ host.example.com:path .

       To do the same from a bourne shell script in a marginally less  exposed
       way:

       SSHPASS=12345     rsync     --rsh=’sshpass     -e    ssh    -l    test’
       host.example.com:path .

BUGS

       Sshpass is in its infancy at the  moment.  As  such,  bugs  are  highly
       possible.  In  particular,  if  the  password  is  read  from stdin (no
       password option at all), it is possible that some of the input aimed to
       be passed to ssh will be read by sshpass and lost.