Copy a file and overwrite the existing file

Question

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?

Solution 1

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.

Solution 2

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.

Solution 3

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'

Comments

[Mathias Begert]

why not a mv instead of a cp?

[vinc17]

@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...

[Mina Hafzalla]

Thanks for the answer but I got "operation not permitted"

[vinc17]

@MinaIsaac Then, before the cp, you should do a chmod. For instance: ... && chmod 600 image2.png && cp image1.png image2.png (this is just an example, you can do something slightly different, e.g. with cp options to preserve the permissions of image1.png).

[Mina Hafzalla]

I tried what you said but the file always reset back to its default permissions. Is there any method I can use to force permissions change? Thank you.

[mikeserv]

@RuslanGerasimov - but you need to ensure you get a -tty with ssh or you may not be able to use sudo at all.

[Ruslan Gerasimov]

@mikeserv I agree with your comment, so find please my answer and see the explanation on how to use ssh with sudo

[mikeserv]

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]

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]

And no, my comment said specifically: ssh -t ... sudo ... - the -t flag specifies that ssh get a pty so it can run sudo.

[Ruslan Gerasimov]

@mikeserv the question didn't require any security goals, but anyway I added some explanation to my answer.

[mikeserv]

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]

it is not impossible. Neither is that a specified case here. But then again - neither were the user permissions in the first place - and that's why my comment was just a comment. The other answer addressed all aspects of the question as asked but a future one - I only tried to help out by suggesting the flag. I reversed my vote because you're being sensible - I'll remove the comments when you remove the -S altogether. maybe not so sensible...

[Ruslan Gerasimov]

@mikeserv thank you for your attention to some critical moments.

[vinc17]

@MinaIsaac For the permission, you can use the -p option of cp or another chmod after the cp: cp ... && chmod your_permissions image2.png.

[vinc17]

Normally you don't need sudo... unless the OP hasn't said something particular about the accounts (but in such a case, a better ssh configuration may be better than sudo).

[terdon]

Why are you changing the permissions of the files? That is neither requested nor necessary. All you need is sudo cp img1 img2.

[Ruslan Gerasimov]

@terdon thank you, I added this point to the answer's edit.

[terdon]

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.

[Ruslan Gerasimov]

@terdon please be aware that I found your comment useful and quoted your warning in the answer. You can find it in update. Thanks

[smw]

The message operation not permitted (as opposed to permission denied) usually indicates a problem with extended file attributes (lsattr/chattr) rather than basic file permissions.

[Gilles 'SO- stop being evil']

mv would not overwrite the existing file, but replace it.

[mikeserv]

@Gilles - good point - an unlink operation vs a < stream >

[mikeserv]

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]

@vinc17 - my sentiments exactly.