Score:0

Copying files to a protected directory on a remote server

ru flag

I'm working on a script that needs to copy some files from a local machine to a directory on a remote server. The problem I'm running into is that the directory (/etc/init.d) is owned by root so I get permission exceptions if I try to copy files into it. That means I can't use scp without logging in as root.

The closest solution I have found so far is this answer: https://askubuntu.com/a/872537/798391 . Unfortunately, the answer as given doesn't quite work and none of the suggestion given in the comments seem to fix it. If I run

cat myscript.sh | ssh foo@myserver "sudo tee -a /etc/init.d/myscript.sh"

I get the error

sudo: no tty present and no askpass program specified

One of the comments suggested adding -t to the ssh command

cat myscript.sh | ssh -t foo@myserver "sudo tee -a /etc/init.d/myscript.sh"

but that resulted in the error

Pseudo-terminal will not be allocated because stdin is not a terminal.

Another suggested option was to use the -S argument of sudo

cat myscript.sh | ssh foo@myserver "sudo -S tee -a /etc/init.d/myscript.sh"

That at least prompts for the password, but it times out and asks again before the password can be entered completely.

At this point I'm out of ideas. Is there some way to get this command to work? Is there a better alternative solution for copying files to a protected remote location?

Score:0
cn flag
raj

There can be various methods to achieve what you want, it depends on detailed configuration on both machines.

The simplest method would be (if this is possible) to configure key-based ssh authentication so that your local user can ssh as root to the remote machine.

Another method is to use expect to write a script that logs interactively via ssh to the remote machine, does sudo -i (and types the appropriate password) and then copies the file doing scp in reverse direction (ie. scp is executed on the remote server towards your local machine - it must have a ssh server active).

The solution that is probably closest to what you originally tried is the following:

  1. prepare a script (let's call it /tmp/password) with the following content:

     #!/bin/sh
     echo password
    

    where password is the actual password for user foo on remote server.

  2. chmod 700 /tmp/password so that the file is executable and nobody except owner can access it

  3. copy the file (preserving permissions) to remote server with scp -p /tmp/password foo@myserver:/tmp

  4. use the following command:

     cat myscript.sh | ssh foo@myserver "SUDO_ASKPASS=/tmp/password sudo -A tee -a /etc/init.d/myscript.sh"
    
ru flag
I have key based authentication set up, at least I think I do. I'm not entirely sure how that would help since I would still need to run the copy command with elevated permissions on the remote server, and thus would still need to supply a password.
raj avatar
cn flag
raj
@pbuchheit Can you do `ssh root@myserver` ? I meant setting up key authentication so that you will be able to do it.
ru flag
No. I don't actually want to log in as root.
raj avatar
cn flag
raj
@pbuchheit So try the solution I described.
ru flag
which solution? Using expect is a no-go; other team members need to be able to run this script without needing extra libraries. Adding a file containing the password to the remote server seems redundant. I already have key authentication set up.
raj avatar
cn flag
raj
@pbuchheit Maybe try this before commenting that "it seems redundant". This file is used to provide passowrd to sudo (not to ssh) so that it doesn't ask you for it. You asked "Is there some way to get this command to work?". I gave you a **tested** answer, but you say you don't want to try it - it's your problem then.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.