Store a private key outside of ~/.ssh

Question

I have to deal with a rather annoying situation. I must transfer a file via shell script using scp from one server to another. The problem is that I do not have root access on either of them. I'm not allowed to install any packages like, sshpass, ssh2, expect etc. I don't even have write permission in the home directory of the user I have to use on the second server.

Since I can't use sshpass etc. to enable my script to enter the login credentials, I thought about using an ssh keypair for auth. Actually that was my first thought, but since the user on the second server doesn't have write permissions in its home directory but only in a subsequent directory, ssh-keygen fails as it can't put the keys in ~/.ssh.

Both are Debian servers btw.

Is there any way to generate a ssh keypair and use it outside of ~/.ssh?

Any help is greatly appreciated.

Answer 1

On the clientside yes. However, on serverside, unless configured differently, sshd will expect your credentials in that directory.

If you can scp from the server where you can't access .ssh to the one where you can, you can use -i option to specify the keyfile location.

Do you have an alternative transport mechanism? Can you put the filn your public_html and wget it on the other side?

Answer 2

You can have the keypairs anywhere. What is key is that the permissions are set correctly on the keypair. The ownership needs to be set to the user chown user:user keyfile and the permissions must be chmod 400 keyfile.

Once you have your key moved and permissions set all that's left is to tell scp which key to use. You can do this by using the -i flag.

IE: scp /source/file user@host:/target/location/ -i keyfile

Edit: As Amadan alluded to in his answer - this assumes the server you're connecting to already has the key as an authorized key on the user. If not it would require an /etc/ssh/sshd_config change that only someone with the right access can do. It might be worth trying a cat /etc/ssh/sshd_config on the server if your user has access to it at all right now. If you have read access you'll be able to discern the expected authorized_keys location. It's possible the server admin has already customized the expected key location to something you have write access to.