LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Server (https://www.linuxquestions.org/questions/linux-server-73/)
-   -   copy a file from one server to other through scp command as a cron job (https://www.linuxquestions.org/questions/linux-server-73/copy-a-file-from-one-server-to-other-through-scp-command-as-a-cron-job-4175603094/)

Natarajachar 04-03-2017 07:43 AM

copy a file from one server to other through scp command as a cron job
 
Hi,

I have to create a cron job which copies some files from one server to other. I am planning to use scp -r abc.txt{files} ip.adres:{location} but this query will ask for password to be entered.
nmpt:/ # scp -r scripts.tar.gz 10.10.5.130:/
Password:

But if I create a crontab for this, then I can't enter the password. So I want the password to be entered in the same command line like using sqlplus command:- sqlplus username/password.


Kindly help me to achieve this. Any suggestions would be helpful.

Thanks,
Natraj

TB0ne 04-03-2017 08:01 AM

Quote:

Originally Posted by Natarajachar (Post 5691959)
Hi,
I have to create a cron job which copies some files from one server to other. I am planning to use scp -r abc.txt{files} ip.adres:{location} but this query will ask for password to be entered.
nmpt:/ # scp -r scripts.tar.gz 10.10.5.130:/
Password:

But if I create a crontab for this, then I can't enter the password. So I want the password to be entered in the same command line like using sqlplus command:- sqlplus username/password.

Very easy; swap your SSH keys for the user whose ID is going to be used to run the transfer. In the example you listed, you're doing this as root, which is a VERY BAD IDEA...you should never, EVER allow root to log in via SSH (or over the network), period.

Generate your SSH keys, use ssh-copy-id to copy that key to the remote server (do this interactively), and after that, the user ID you copied won't have to enter a password. Since SCP uses the same authentication key, it won't either, so you can easily cron things.
http://www.thegeekstuff.com/2008/11/...en-ssh-copy-id

Read the scp man page, and pay particular attention to the "-i" flag, so that if you put this cron job in root's crontab, you can specify your non-root user ID to use:
https://linux.die.net/man/1/scp

Also, read the "Question Guidelines" link in my posting signature, and please do some searching first. This has been asked/answered on this site MANY times, and Google has much on this as well.

Turbocapitalist 04-03-2017 08:13 AM

In addition to that good advice, you might look at some of the options available to ssh-keygen listed in the manual:

Code:

man ssh-keygen
In particular, look at -C, -f, and -t.

Using -C to make a comment can help identify the key after time has passed. Usually the comment is used to say where the key is from and follows with the public key over to the remote machine.

Using -f can give the key pair a unique name. Too many of the tutorials both go with the default name and only assume ever having a single key. The key pair's file name can be a useful reminder of which machine and or account the key is for.

Using -t allows you to make the key use one of the elliptic curve algorithms, like Ed25519. You can use RSA for compatibility with older dongles and some programs which require it, but Ed25519 is considered better. Just don't use DSA anymore ever. If you see a guide using it, either skip the guide or substitute RSA or Ed25519.

Habitual 04-03-2017 08:44 AM

no-password, high strength key:
Code:

ssh-keygen -f /path/to/scp_key -t rsa -N '' -b 4096 -q
Comments are good ;)
Code:

ssh-keygen -f /path/to/scp_key -t rsa -N '' -b 4096 -q -C "This key came from Natraj"
after the key is established, it's just
Code:

scp -i /path/to/scp_key scripts.tar.gz 10.10.5.130:/
and a reference because it's just that good.
Simple, Secure Backups for Linux with rsync

Be safe.

TB0ne 04-03-2017 09:25 AM

Honestly, after MANY years using this method/mechanisms, I've not used comments before, but it is blindingly obvious I *SHOULD* be doing that...thanks for showing that option off.

Habitual 04-03-2017 11:46 AM

Quote:

Originally Posted by TB0ne (Post 5692001)
Honestly, after MANY years using this method/mechanisms, I've not used comments before, but it is blindingly obvious I *SHOULD* be doing that...thanks for showing that option off.

Since I had to insert said key in said file on you know where it goes, I too rarely used -C.

-V looks interesting (to me).

Peace.

Turbocapitalist 04-03-2017 11:49 AM

Quote:

Originally Posted by TB0ne (Post 5692001)
Honestly, after MANY years using this method/mechanisms, I've not used comments before, but it is blindingly obvious I *SHOULD* be doing that...thanks for showing that option off.

No problem. By the way, some Desktop Environments have agents that read the public keys and use the comments found there for annotations. Such agents only work well up to six keys though.

Turbocapitalist 04-03-2017 11:59 AM

Quote:

Originally Posted by Habitual (Post 5692038)
-V looks interesting (to me).

That's for use with SSH certificates. They're slightly more "secure" than keys but somewhat non-standard as SSH seems to have its own format.

sundialsvcs 04-03-2017 01:36 PM

I had one idle thought and now I'm curious ...

What if you programmed the crontab-executed script so that it invoked another script using the "[font=courier]sudo -u userid" option? And then, put the necessary certificate in the .ssh/authorized_keys file of that user?

And what if you also used -i (simulate initial login) ??

The primary script that does the job would now be executing in the (non-privileged ...) context of a specified other user-id. Therefore, wouldn't sshd look for the authorized-key in the home directory of that user?

Although we most-frequently use su to reach the context of the root user, the command has very-obviously been carefully constructed to let us leverage the execution context of anyone.

This strategy would not only allow us to compartmentalize (identify ...) the user that is executing the copy, but it would also ensure (in general) that the operation is not occurring with rootly privilege.

Turbocapitalist 04-03-2017 01:55 PM

Sure. You can use sudo to run ssh as an unprivileged user, even from one unprivileged account to another. Just add the right custom formula in sudoers.

No environment variables are used, as far as I know, as long as you avoid the tilde ~

If you want to prevent modification of the authorized_keys file on the remote system then change the AuthorizedKeysFile directive in sshd_config to some path + file that the account can only read but not write. You can have some tokens to stand in as variables. For example:

Code:

AuthorizedKeysFile /etc/ssh/authorized_keys/%u
And then have the directory those files owned by root and not writable. The file must be either world-readable or readable by the specific account.

Natarajachar 04-05-2017 01:01 AM

Could anyone explain me what is ssh key?

Turbocapitalist 04-05-2017 02:35 AM

Not really, it's mostly over my head though I use it all the time. It uses asymmetric encryption to use a private key to make a digital signature for a message composed of specific data which is then sent to the SSH server. The server then uses the corresponding public key to verify that signature. If everything is ok, then the authentication goes ahead. See RFC 4252 in the section, 7. Public Key Authentication Method: "publickey" for the specifics for SSH.

In practice, it is one way that allows you to automate connections, among other advantages.

pan64 04-05-2017 02:45 AM

probably here: https://en.wikipedia.org/wiki/Secure_Shell
ssh-key is something like a key, you store it on your host and ssh can use it to "enter" into another host. But you need to put a lock with a "keyhole" on the server what can be opened only with your key.

Natarajachar 04-11-2017 04:42 AM

Hi,

Please anybody suggest me on which server I need to establish ssh-keys?
Target server or source server?

Thanks,
Natraj

Turbocapitalist 04-11-2017 04:49 AM

The public key goes onto the server you will connect to. Specifically, it goes into ~/.ssh/authorized_keys, unless you or your sysadmin have gone out of your way to make other plans.

The private key goes onto the machine you will connect from. Usually, it goes into the directory ~/.ssh/ unless you or your sysadmin have gone out of your way to make other plans. Also, it is usual to keep a copy of the public key here too but that is not required.


All times are GMT -5. The time now is 03:57 PM.