4

I have two images (image1.png and image2.png) in the same folder on my server, I want to run a command that overwrites image2.png to image1.png. I prefer to overwrite the image instead of deleting it and then replace it by the other one. How can I achieve that via ssh command line?

5
ssh host "cd path/to/directory && cp image1.png image2.png"

The && is safer than ; in case the cd fails, e.g. because of a typo: in such a case, the cp won't be executed instead of possibly copying a wrong file.

  • why not a mv instead of a cp? – iruvar Jul 26 '14 at 0:20
  • @1_CR The OP didn't say that he wanted to remove image1.png. But he can use mv if this gives the behavior he wants... – vinc17 Jul 26 '14 at 0:23
  • Thanks for the answer but I got "operation not permitted" – Mina Hafzalla Jul 26 '14 at 0:40
  • 1
    @Minalsaac - you have to elevate permissions - if you can. ssh -t ... 'cd $path && sudo cp ./file1 ./file2' - but it might be better if you just logged on to a priveleged account initially when connecting with ssh in the first place. – mikeserv Jul 26 '14 at 3:04
  • 1
    mv would not overwrite the existing file, but replace it. – Gilles Jul 26 '14 at 12:59
1

Without sudo the command ssh server "cd path/to/directory && cp image1.png image2.png" doesn't have privileges to chmod the permissions.

But with sudo it would, but being run after ssh, it never gets password input for it on the remote server, so the solution is use -S and pipe a password for sudo as follows:

ssh server " cd path/to/directory && echo sudo_password | sudo -S chmod 600 image2.png && cp image1.png image2.png"

EDIT:

However, how @terdon marked, we don't need to change permissions here, but use sudo cp ,so it comes to:

ssh server " cd path/to/directory && echo sudo_password | sudo -S cp image1.png image2.png"

or (in case you think that your password can be read)

ssh server -t " cd path/to/directory && sudo cp image1.png image2.png"

UPDATE: also @terdon warned and I added this, because I think it's important to stress and make an accent on such possible realization:

I really would remove this suggestion of using -S, it is not needed and very dangerous (see @mikserv's comments and my answer). It is also pointless. The only "advantage" you mention, that of being able to pipe is a fringe case and in most situations you could just pipe on the server instead. You can also use sshpass as you suggested or set up passwordless sudo. All sorts of ways that don't store a server's password as plaintext. – terdon

On the one hand this is good for the automation with no getting sudo password promts and, to have completely automated code/script you would add sshpass -p password ssh....

However on the server where others can easily read your sudo password provided as open text during the ssh session that's not recommended from the security perspectives. So, to have a sudo with ssh and be safe use ssh -t

ssh -t server "cd path/to/directory && sudo chmod 600 image2.png && cp image1.png image2.png"

Nevertheless, with -t it's impossible to pipe ssh "sudo command"| command for example ssh -t server "cd path/to/directory && sudo"|grep "text" but it IS possible with ussage of -S and echoing password, e.g. ssh server 'echo password | sudo -S ls -l'| grep 'a'

  • yikes. you should probably have a look at one or two of those processs' /proc/$PID/cmdline when doing stuff like that - you will probably quit doing it. easier still - ps -o args= -C ssh will - as I think - print your password at you. yeah - if I run ssh localhost 'ps -o args= -C ssh' it prints ssh localhost ps -o args= -C ssh – mikeserv Jul 26 '14 at 5:55
  • 1
    I'm talking about your broadcasting your sudo password to anyone on the system with read access to proc - or with permissions to run ps for that matter. The only saving grace to the rest of sudo's madness is that it doesn't require sysadmins to pass around a privileged password - they use their own. You just threw that out the window here - making your plaintext password world readable for the life of the ssh process. Stop that. – mikeserv Jul 26 '14 at 6:16
  • And no, my comment said specifically: ssh -t ... sudo ... - the -t flag specifies that ssh get a pty so it can run sudo. – mikeserv Jul 26 '14 at 6:20
  • 2
    maybe. Most questions don't explicitly require that you refrain from implementing an easy means of snooping their password - but answers that do should still be downvoted. – mikeserv Jul 26 '14 at 6:45
  • 1
    I really would remove this suggestion of using -S, it is not needed and very dangerous (see @mikserv's comments and my answer). It is also pointless. The only "advantage" you mention, that of being able to pipe is a fringe case and in most situations you could just pipe on the server instead. You can also use sshpass as you suggested or set up passwordless sudo. All sorts of ways that don't store a server's password as plaintext. – terdon Jul 26 '14 at 11:06
1

In order to connect to a server via ssh and run a specific command, all you need is ssh "command"

In your case, you want to copy a file (it overwrites by default) so you want the cp command. It works like cp /path/to/original /path/to/copy. Now, you said in your comments that trying this gives you a permission denied error. This means that you will need to run the command as root. This is done using sudo, so sudo cp /path/to/original /path/to/copy.

The next issue is that ssh runs a non-interactive shell with no tty so sudo can't ask for a password. You will need to use ssh's -t for that. So, putting all this together, you can do:

ssh -t user@server sudo cp /path/to/image2.png /path/to/image1.png

Do not ever echo your sudo password as suggested by another answer. That is extremely dangerous since it will make it visible to any users connected on the system and it will also be kept in your history file in plain text. This means that all I need to do is grep sudo ~youruser/.bash_history and I have your password and complete access to the server. So any attacker who gains access to the server can now do anything they like.

  • Wow - I really didn't think of that - that makes it all the more scary. At first I was thinking the history thing might depend on the sudoers config and the value of $HOME - but even that matters not at all. Of course regardless of how that is setup you still do the echo before ever sudo is invoked at all. Yikes. – mikeserv Jul 26 '14 at 15:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.