Recently a number of VOS and OpenVOS customers have switched from using the standard ftp client (ftp.pm) to the secure ftp client (sftp.pm). There are two primary reasons for using sftp over ftp. First, sftp never sends the password in plaintext; it is always encrypted. Second, sftp encrypts the data during transmission. However, it seems that many customers wrote VOS command macros that supplied a “canned” user ID and password to ftp, and they have noticed that while you can pre-specify the user ID to sftp, there is no way to pre-specify the password. You must wait for the sftp command to prompt for the password, which you then enter on the keyboard.
This is standard procedure for sftp on all operating systems. You might not appreciate the behavior at first, but sftp is doing you a favor. It deliberately reads the password directly from the terminal; it does not read it from “stdin”. The authors of sftp considered that placing a password into a file or shell script was poor practice; it is highly insecure.
Fortunately, the authors of sftp provided a great solution to this problem. They implemented user authentication via a public key mechanism. If you place your private key into the .ssh subdirectory under your home directory on the source module (the machine where you use the sftp or ssh commands), and place your public key into the same directory on the target modules, you can then login (or use sftp) without ever having to supply a password.
This is secure because the software checks to make certain that no one else can modify your home directory, and that no one else can read files in your .ssh subdirectory, before it uses your private key. Since only your public key is ever held on a remote server, even if that remote server is compromised, there is no security issue because your public key is, by definition, public; anyone is allowed to read it. Your private key always remains on your local machine and is never transmitted over the network. This is an essential property of the underlying SSH2 protocol. The computer power necessary to crack this protocol is well beyond what is currently available. The protocol is secure even against someone that can view all of the packets.
So, don’t worry about the fact that the sftp command is not a drop-in replacement for ftp. Take advantage of its improved security while enjoying its improvements in ease-of-use. Get rid of those static passwords and switch to public/private keys.
Company