Running SCP in batch mode
SCP (Secure CoPy) and SSH in general 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.
Procedure
1. In these instructions, the user name is the same in both machines. Instructions for different user names could differ from these (but see note below!!!)
2. The user keys will be stored in ~/.ssh
in both machines.
ssh-keygen -t dsa
-d
seems to be an alias of -t dsa
in some platforms).
4. Change the permissions of the generated .pub
file to 600 by commanding chmod 600 id_dsa.pub
scp id_dsa.pub user@server:~/.ssh/authorized_keys
foo
and then append the contents with cat foo >> authorized_keys
executed 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 or username.
7. If it doesn't work, verify that in the server your home directory, the ~/.ssh
subdirectory, and the authorized_keys file do not have writing permissions to others. If they do, they won't be considered to grant access. You can correct this with something like:
chmod 755 ~ 0 chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys
8. If it still doesn't work, try changing the authorized_keys
file name to authorized_keys2
, or ask your system administrator what file name is ssh actually using.
scp -B foofile user@server:~/foodir/
Notes
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 user@server.domain.tk 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 "id_dsa.pub" 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
.
References
This article is part of the SVI-wiki on 3D microscopy and image restoration. Scientific Volume Imaging is the maker of the Huygens Software.