Running SCP in batch mode

(source :

SCP (Secure CoPy) can be used in batch mode without asking for passwords. That is very convenient for scripts.

Instructions to do so are a little ambiguous in different places . (See some references below). This worked in my case, using OpenSSH both in the server and the client.


1. The user should be the same in both machines. Instructions for different usernames could differ from these (but see note below!)

2. The user keys will be stored in ~/.ssh in both machines.

3. At the client, run ssh-keygen -d to generate a key pair. Accept default options by pressing return. Specially, do not enter any passphrase. (Option -d seems to be an alias of -t dsa).

4. Change the permissions of the generated .pub file to 600 by commanding chmod 600

5. Copy the public key to the server with scp 'user@server:~/.ssh/authorized_keys'. (If that destination file already exists on the server, copy first to a different file foo and then append the contents with cat foo >> authorized_keys on the server).

6. Done! Verify that now you can connect directly from the client with ssh user@server without being prompted for a password.

7. If it worked, you can now run SCP in batch mode with the -B option, as in scp -B foofile 'user@server:~/foodir/'.


The name of the server must have been registered in the known_hosts. This can be done with a regular (with password) ssh connection, and accepting the host as known. Then, the host name should be the same as the one accepted! If you used user@server first, do not use later on!

SSH protocol 2 is assumed in this procedure (it uses dsa keys). If your ssh configuration files (at /etc/ssh/) do not establish this as a default, you may have to force it with the -2 option of the ssh and scp. Moreover, if the default public key is not configured to be "" you can specify what key to use for identification with the -i option.

The same procedure worked fine when the username was different in both machines. I simply copied userA's public key at the end of userB's authorized_keys file, then I could login from my client as userA with ssh userB@server.