# ssh-keygen -sh: ssh-keygen: not found

[Gert Marginet]

Hi,

I'm a Linux newby.

I'm trying to setup an automated rsync synchronization where my DNS-323 should pull data from an other nas.

I managed to install Alt-F, and I can do the rsync manually.

Now I'm trying to setup public key authentication. In the tutorials I found the first thing I need to do is call the ssh-keygen command on the client (the DNS-323 in my case)

But when I try to do this I get the following error, what am I doing wrong?

# ssh-keygen

-sh: ssh-keygen: not found

Kind regards,

Gert

[Gert Marginet]

Found the solution.

Needed to install openSSH

[João Cardoso]

On Wednesday, September 18, 2013 12:03:53 PM UTC+1, Gert Marginet wrote:

Found the solution.

Needed to install openSSH

Alt-F is not a standard linux distribution, remember that 'dropbear' is already running on port 22, the default for opensshd. Also, sshd is started from inetd. And you might have to create /var/empty (https://sourceforge.net/p/alt-f/tickets/6/)

You already have a backup service (Services->System->Backup) and a rsync setup webUI (Services->Network->inetd->rsync)

[Rafal B]

I have the same issue: how to generate pair of keys?
It seems DropBear SSH implementation is not giving ssh-keygen command:

[root@dns320]# ssh-keygen
-sh: ssh-keygen: not found

and when trying to install openssh I'm getting error:

Installing openssh (6.4p1) to /Alt-F...
Downloading http://sourceforge.net/projects/alt-f/files/pkgs/unstable/openssh_6.4p1_arm.ipk
An error ocurred, return value: 1.
Collected errors:
Package openssh wants to install file /Alt-F/usr/bin/scp
	But that file is already provided by package dropbear

My goal is to copy by crone-based script /tmp/sys/temp1_input and /tmp/sys/fan1_input files from my D-Link DNS-320 to another linux machine. In order to use scp I need to generate public and private keys. How to do this when ssh-keygen is "not found" ?

[Joao Cardoso]

On Monday, March 7, 2016 at 7:17:06 PM UTC, Rafal B wrote:

I have the same issue: how to generate pair of keys?
It seems DropBear SSH implementation is not giving ssh-keygen command:

[root@dns320]# ssh-keygen
-sh: ssh-keygen: not found

and when trying to install openssh I'm getting error:

Installing openssh (6.4p1) to /Alt-F...
Downloading http://sourceforge.net/projects/alt-f/files/pkgs/unstable/openssh_6.4p1_arm.ipk
An error ocurred, return value: 1.
Collected errors:
Package openssh wants to install file /Alt-F/usr/bin/scp
	But that file is already provided by package dropbear

That is definitevely a bug that I missed to fix. I will fill a bug report so that I will forget it again

/usr/bin/scp belongs to both dropbear and openssh.

https://groups.google.com/d/msg/alt-f/jFYY_Lo9BKw/zDiQonX4BwAJ

Not a problem until dropbear is updated with a newer version; until that happens, the dropbear package file list is empty  and there is no conflict.

What Alt-F and dropbear version are you running?

 

My goal is to copy by crone-based script /tmp/sys/temp1_input and /tmp/sys/fan1_input files from my D-Link DNS-320 to another linux machine. In order to use scp I need to generate public and private keys. How to do this when ssh-keygen is "not found" ?

That is fixed in my current sources (and made available for the next release)

You can meanwhile generate them in another computer and copy them to the box. But drobpear (the current sshd server) has its own key format, so you have to convert the current dropbear keys to openssh format using 'dropbearconvert':

All arguments must be specified

Usage: dropbearconvert <inputtype> <outputtype> <inputfile> <outputfile>

CAUTION: This program is for convenience only, and is not secure if used on

untrusted input files, ie it could allow arbitrary code execution.

All parameters must be specified in order.

The input and output types are one of:

openssh

dropbear

Example:

dropbearconvert openssh dropbear /etc/ssh/ssh_host_rsa_key /etc/dropbear_rsa_host_key

See also 'dropbearkey' to get the dropbear public key

Usage: dropbearkey -t <type> -f <filename> [-s bits]

-t type Type of key to generate. One of:

                rsa

                dss

                ecdsa

-f filename     Use filename for the secret key

-s bits Key size in bits, should be a multiple of 8 (optional)

           DSS has a fixed size of 1024 bits

           ECDSA has sizes 256 384 521 

-y              Just print the publickey and fingerprint for the

                private key in <filename>.

[Rafal B]

I'm using the latest Alt-F firmware 01RC4.1 which I downloaded from https://sourceforge.net/projects/alt-f/files/Releases/

Dropbear version is that one which is downloaded from http://sourceforge.net/projects/alt-f/files/pkgs/unstable

Thanks for excellent response (as usual) with workaround how to get pair-keys - will try it when I'm back at home.

And this is real good information that next release of Alt-F will be fixed, so pair-keys can be generated by ssh-keygen command.

What is is the date we might expect new version?

Best regards,

Rafal

[João Cardoso]

On Tuesday, 8 March 2016 08:09:00 UTC, Rafal B wrote:

I'm using the latest Alt-F firmware 01RC4.1 which I downloaded from https://sourceforge.net/projects/alt-f/files/Releases/

Dropbear version is that one which is downloaded from http://sourceforge.net/projects/alt-f/files/pkgs/unstable

I suspect that you updated dropbear while in a previous Alt-F release, such as RC4, and that dropbear version is shadowing the one in the current RC4.1.

You can check that going to Packages->Alt-F and searching for dropbear; if the "Remove" button is active, i.e., not grayed out, that is what is happening. You can hit the dropbear Remove button, and the Remove button should become grayed -- the dropbear version shipped in RC4.1 is now active (and it must be the same version you previously had).

You can now install openssh. This issue continues to be a bug.

 

Thanks for excellent response (as usual) with workaround how to get pair-keys - will try it when I'm back at home.

As a matter of fact, you shouldn't need to use dropbearconvert/dropbearkey (that is mostly for the host keys), just copy your existing private and public openssh keys to the box ~/.ssh/, be sure its permissions are OK and dropbear will work it them. I have just done that:

Mar  8 16:28:35 DNS-320L authpriv.info dropbear[2298]: Child connection from 192.168.1.1:50240

Mar  8 16:28:35 DNS-320L authpriv.notice dropbear[2298]: Pubkey auth succeeded for 'jcard' with key md5 84:68:db:60:2e:0f:2b:94:98:85:32:24:78:83:36:4f from 192.168.1.1:50240

[Rafal B]

Yes, I can confirm this is my case: Remove button is active near to dropbear 2014.66.
Once I have clicked Remove it is uninstalled and now I see Remove button greyed out next to dropbear 2014.63.
So I understand that now I have in the system older version of dropbear installed and I'm OK to install openssh 6.4p1 which will deliver ssh-keygen command. Can you please confirm? I'm a little bit unsure if I will not cause any damage to the system by this action as I'm writing that someone lost ability to ssh to the box once openssh had been installed.
Regarding to the pair of keys public and private: I have generated them on the second linux machine and copied that public key to my D-Link but when I'm trying to scp some files from that another linux machine to D-Link I'm not asked to provide the password (as expected) but copy is not performed - after around of 2-3 minutes I'm getting "timeout" response. Could it be caused by the fact that dropbear is using another format of keys?

/R

[João Cardoso]

On Tuesday, 8 March 2016 17:25:51 UTC, Rafal B wrote:

Yes, I can confirm this is my case: Remove button is active near to dropbear 2014.66.
Once I have clicked Remove it is uninstalled and now I see Remove button greyed out next to dropbear 2014.63.
So I understand that now I have in the system older version of dropbear installed

Yes, dropbear-2014.63 is the version that were shipped with RC4.1 and is flashed; latter dropbear-2014.66 was available and you updated it on disk. That's why you could remove it and the flashed version "reappeared".

and I'm OK to install openssh 6.4p1 which will deliver ssh-keygen command.

Yes, ssh-keygen is on openssh pkg

 

Can you please confirm?

Yes, but I have not tested it.

I expect that when you removed the on-disk dropbear its package file list were also removed, so installing openssh will not generate file conflicts. But then you can't update dropbear to dropbear-2014.66 because the same file conflict will arise...

Anyway, the easiest route is to:

-first update dropbear to  2014.66

-then use the command line to install openssh, allowing file overwrites, using the command:

ipkg -force-overwrite install openssh

 

I'm a little bit unsure if I will not cause any damage to the system by this action

the 'scp' command will be from openssh instead of being from dropbear, and inetd will be listening on port 2222 and launch 'sshd' from openssh when a connection is made -- remember, the default 22 port is still handled by dropbear, port 2222 will be used by opensshd.

You can change that under Network->Services->inetd->sshd (or dropbear)->Configure.

as I'm writing that someone lost ability to ssh to the box once openssh had been installed.

I can't see how that would happens.

And you still have telnet to fix any issue. And even if you have disable telnet (Services->Network->inetd), you still have the last resort back button "pressed for more than 10 seconds (but less than 20)" that launches a no password telnet server on port 26 (if you have not disabled the "Recovery" button in Services->System->sysctrl).

 

Regarding to the pair of keys public and private: I have generated them on the second linux machine and copied that public key to my D-Link but when I'm trying to scp some files from that another linux machine to D-Link I'm not asked to provide the password (as expected) but copy is not performed -

I need logs to diagnose that.

Perhaps the generated keys are using some non-supported cipher or a cipher size that dropbear does not supports.

 

after around of 2-3 minutes I'm getting "timeout" response. Could it be caused by the fact that dropbear is using another format of keys?

Logs. System->Utilities->View Logs, System log. Right after the timeout you refer to above.

[Rafal B]

Hello,
I have followed your advice and installed dropbear 2014.66 by pressing update button and then installed openssh by the command

ipkg -force-overwrite install openssh

I have generated pair of keys using ssh-keygen command, added public's key string to remote machine's authorized_keys file and now I'm able to scp temp1_input, fan1_input files to that remote machine using a crontab.
Everything is OK EXCEPT one thing:

when D-Link is restarted /root/.ssh/ folder is empty so cron job which is doing the command: scp /tmp/sys/*_input ro...@192.168.1.106:/storage/backup/NASTempFan is just failing.
I checked that /home/Rafal/.ssh/ folder is not empty when reboot is completed: id_rsa, id_rsa.pub, known_hosts are still there and I can do successfully above command as Rafal user.
I see that cron's jobs are launched as root user:

Mar  8 23:17:01 dns320 cron.info crond[649]: crond: USER root pid 2167 cmd scp /tmp/sys/*_input ro...@192.168.1.106:/storage/backup/NASTempFan

so the question is (remember: I'm linux's noob :-)) what to do in order to launch cron's jobs as Rafal instead of root?

Would like to say THANK YOU VERY MUCH for your support so far...

[EDIT] I just checked that alternative solution would be to copy id_rsa, id_rsa.pub, known_hosts from /home/Rafal/.ssh/  to /root/.ssh/ That copy need to be launched at Alt-F boot time. I need to find out how to achieve that goal....

/Rafal

[João Cardoso]

On Tuesday, 8 March 2016 22:26:20 UTC, Rafal B wrote:

Hello,
I have followed your advice and installed dropbear 2014.66 by pressing update button and then installed openssh by the command

ipkg -force-overwrite install openssh

I have generated pair of keys using ssh-keygen command, added public's key string to remote machine's authorized_keys file and now I'm able to scp temp1_input, fan1_input files to that remote machine using a crontab.
Everything is OK EXCEPT one thing:

when D-Link is restarted /root/.ssh/ folder is empty

Yes, cron works in a memory filesystem, not disk; the root user home, '/root' is also in a memory filesystem, so none of its contents is saved across reboots. current root crontabs are saved in flash memory when "save settings", but there is no such provision for normal users.

 

so cron job which is doing the command: scp /tmp/sys/*_input ro...@192.168.1.106:/storage/backup/NASTempFan is just failing.
I checked that /home/Rafal/.ssh/ folder is not empty when reboot is completed: id_rsa, id_rsa.pub, known_hosts are still there and I can do successfully above command as Rafal user.
I see that cron's jobs are launched as root user:

Mar  8 23:17:01 dns320 cron.info crond[649]: crond: USER root pid 2167 cmd scp /tmp/sys/*_input ro...@192.168.1.106:/storage/backup/NASTempFan

so the question is (remember: I'm linux's noob :-)) what to do in order to launch cron's jobs as Rafal instead of root?

For the next release, when the Users folder is discovered, the file 'crontab.lst' is searched in each user home directory and crontab uses it. So you might, for future compatibility to save each user crontab there.

For now, you have to deploy that using the "boot user scrip", that is run at boot time, see Services->User->user->Configure, "Script to execute on powerup:". A prototype:

#!/bin/sh

# Script to execute as the root user at boot time.

# You can loose your data or make the system inaccessible

# if using the wrong commands. You have been warned!

 

exec >> /var/log/user.log 2>&1

case $1 in

start)

echo "Starting $0"

echo "Copying root SSH keys"

cp -a /mnt/sda4/.ssh /root/

;;

stop)

echo "Stopping $0"

;;

esac

You might want to add in the start section something like

crontab -u Rafal /home/Rafal home dir/crontab.lst

where crontab.lst is generated by Rafal user after settings its own cron job: 'crontab -l > crontab.lst' 

Would like to say THANK YOU VERY MUCH for your support so far...

[EDIT] I just checked that alternative solution would be to copy id_rsa, id_rsa.pub, known_hosts from /home/Rafal/.ssh/  to /root/.ssh/ That copy need to be launched at Alt-F boot time. I need to find out how to achieve that goal....

See above

[Rafal B]

Thanks for providing next lessons :-)
Before I will continue configuration would like to ask you for the comment on log I'm posting below.
What I have set in system is:
- 30 minutes of inactivity to spin down disks
- cron job triggered every 5 minutes to perform the command: scp /tmp/sys/*_input ro...@192.168.1.106:/storage/backup/NASTempFan

Mar  9 06:53:41 dns320 daemon.info sysctrl: left disk (sda) standby
Mar  9 06:53:41 dns320 daemon.info sysctrl: right disk (sdb) standby
Mar  9 06:53:41 dns320 daemon.info sysctrl: force sdc spindown
Mar  9 06:53:42 dns320 daemon.info sysctrl: usb disk (sdc) standby
Mar  9 06:57:01 dns320 cron.info crond[649]: crond: USER root pid 3918 cmd scp /tmp/sys/*_input ro...@192.168.1.106:/storage/backup/NASTempFan
Mar  9 07:06:23 dns320 daemon.info sysctrl: temp=43.1    pwm=127 fan=3000
Mar  9 07:12:01 dns320 cron.info crond[649]: crond: USER root pid 3930 cmd scp /tmp/sys/*_input ro...@192.168.1.106:/storage/backup/NASTempFan
Mar  9 07:14:23 dns320 daemon.info sysctrl: temp=42.0    pwm=127 fan=3000
Mar  9 07:22:01 dns320 cron.info crond[649]: crond: USER root pid 3938 cmd scp /tmp/sys/*_input ro...@192.168.1.106:/storage/backup/NASTempFan
Mar  9 07:24:09 dns320 daemon.info sysctrl: temp=41.0    pwm=127 fan=3000
Mar  9 07:32:01 dns320 cron.info crond[649]: crond: USER root pid 3946 cmd scp /tmp/sys/*_input ro...@192.168.1.106:/storage/backup/NASTempFan
Mar  9 07:36:39 dns320 daemon.info sysctrl: temp=40.0    pwm=127 fan=3000
Mar  9 07:37:01 dns320 cron.info crond[649]: crond: USER root pid 3951 cmd scp /tmp/sys/*_input ro...@192.168.1.106:/storage/backup/NASTempFan
Mar  9 07:55:10 dns320 daemon.info sysctrl: temp=39.0    pwm=127 fan=3000
Mar  9 08:52:01 dns320 cron.info crond[649]: crond: USER root pid 4012 cmd scp /tmp/sys/*_input ro...@192.168.1.106:/storage/backup/NASTempFan
Mar  9 08:55:56 dns320 daemon.info sysctrl: temp=38.9    pwm=0 fan=0
Mar  9 09:02:01 dns320 cron.info crond[649]: crond: USER root pid 4021 cmd scp /tmp/sys/*_input ro...@192.168.1.106:/storage/backup/NASTempFan
Mar  9 09:05:56 dns320 daemon.info sysctrl: temp=40.0    pwm=0 fan=0
Mar  9 09:07:01 dns320 cron.info crond[649]: crond: USER root pid 4025 cmd scp /tmp/sys/*_input ro...@192.168.1.106:/storage/backup/NASTempFan
Mar  9 09:11:04 dns320 daemon.info smartd[664]: Device: /dev/sda [SAT], SMART Usage Attribute: 194 Temperature_Celsius changed from 123 to 124
Mar  9 09:11:04 dns320 daemon.info smartd[664]: Device: /dev/sdb [SAT], SMART Usage Attribute: 194 Temperature_Celsius changed from 120 to 121
Mar  9 09:12:01 dns320 cron.info crond[649]: crond: USER root pid 4029 cmd scp /tmp/sys/*_input ro...@192.168.1.106:/storage/backup/NASTempFan
Mar  9 09:32:01 dns320 cron.info crond[649]: crond: USER root pid 4045 cmd scp /tmp/sys/*_input ro...@192.168.1.106:/storage/backup/NASTempFan
Mar  9 09:32:12 dns320 daemon.info sysctrl: temp=41.0    pwm=0 fan=0
Mar  9 10:27:01 dns320 cron.info crond[649]: crond: USER root pid 4089 cmd scp /tmp/sys/*_input ro...@192.168.1.106:/storage/backup/NASTempFan
Mar  9 10:29:18 dns320 daemon.info sysctrl: left disk (sda) wakeup
Mar  9 10:29:18 dns320 daemon.info sysctrl: right disk (sdb) wakeup
Mar  9 10:29:18 dns320 daemon.info sysctrl: usb disk (sdc) wakeup
<--- why disks are wakeup here?
Mar  9 10:31:09 dns320 daemon.info sysctrl: temp=42.0    pwm=127 fan=3000
Mar  9 10:42:01 dns320 cron.info crond[649]: crond: USER root pid 313 cmd scp /tmp/sys/*_input ro...@192.168.1.106:/storage/backup/NASTempFan
Mar  9 10:44:39 dns320 daemon.info sysctrl: temp=43.0    pwm=127 fan=3000
Mar  9 10:47:01 dns320 cron.info crond[649]: crond: USER root pid 317 cmd scp /tmp/sys/*_input ro...@192.168.1.106:/storage/backup/NASTempFan
Mar  9 10:51:39 dns320 daemon.info sysctrl: temp=44.0    pwm=127 fan=3000
Mar  9 10:57:01 dns320 cron.info crond[649]: crond: USER root pid 325 cmd scp /tmp/sys/*_input ro...@192.168.1.106:/storage/backup/NASTempFan
Mar  9 10:59:54 dns320 daemon.info sysctrl: temp=45.0    pwm=127 fan=3000
Mar  9 11:00:08 dns320 daemon.info sysctrl: left disk (sda) standby
Mar  9 11:00:08 dns320 daemon.info sysctrl: right disk (sdb) standby
Mar  9 11:00:08 dns320 daemon.info sysctrl: force sdc spindown
Mar  9 11:00:09 dns320 daemon.info sysctrl: usb disk (sdc) standby
<---- now they are again set to standby after 30 minutes of inactivity
Mar  9 11:07:01 dns320 cron.info crond[649]: crond: USER root pid 342 cmd scp /tmp/sys/*_input ro...@192.168.1.106:/storage/backup/NASTempFan
Mar  9 11:11:40 dns320 daemon.info sysctrl: temp=43.1    pwm=127 fan=3000
Mar  9 11:17:01 dns320 cron.info crond[649]: crond: USER root pid 350 cmd scp /tmp/sys/*_input ro...@192.168.1.106:/storage/backup/NASTempFan
Mar  9 11:19:40 dns320 daemon.info sysctrl: temp=42.0    pwm=127 fan=3000
Mar  9 11:27:01 dns320 cron.info crond[649]: crond: USER root pid 360 cmd scp /tmp/sys/*_input ro...@192.168.1.106:/storage/backup/NASTempFan
Mar  9 11:28:41 dns320 daemon.info sysctrl: temp=41.0    pwm=127 fan=3000
Mar  9 11:37:01 dns320 cron.info crond[649]: crond: USER root pid 368 cmd scp /tmp/sys/*_input ro...@192.168.1.106:/storage/backup/NASTempFan
Mar  9 11:40:26 dns320 daemon.info sysctrl: temp=40.0    pwm=127 fan=3000
Mar  9 11:52:01 dns320 cron.info crond[649]: crond: USER root pid 380 cmd scp /tmp/sys/*_input ro...@192.168.1.106:/storage/backup/NASTempFan
Mar  9 11:56:56 dns320 daemon.info sysctrl: temp=39.0    pwm=127 fan=3000
Mar  9 12:47:01 dns320 cron.info crond[649]: crond: USER root pid 424 cmd scp /tmp/sys/*_input ro...@192.168.1.106:/storage/backup/NASTempFan
Mar  9 12:48:43 dns320 daemon.info sysctrl: temp=38.9    pwm=0 fan=0
Mar  9 12:57:01 dns320 cron.info crond[649]: crond: USER root pid 432 cmd scp /tmp/sys/*_input ro...@192.168.1.106:/storage/backup/NASTempFan
Mar  9 12:58:43 dns320 daemon.info sysctrl: temp=40.0    pwm=0 fan=0
Mar  9 13:27:01 dns320 cron.info crond[649]: crond: USER root pid 458 cmd scp /tmp/sys/*_input ro...@192.168.1.106:/storage/backup/NASTempFan
Mar  9 13:28:14 dns320 daemon.info sysctrl: temp=41.0    pwm=0 fan=0
Mar  9 14:07:01 dns320 cron.info crond[649]: crond: USER root pid 488 cmd scp /tmp/sys/*_input ro...@192.168.1.106:/storage/backup/NASTempFan
Mar  9 14:11:04 dns320 daemon.info smartd[664]: Device: /dev/sda [SAT], SMART Prefailure Attribute: 3 Spin_Up_Time changed from 221 to 197
Mar  9 14:11:04 dns320 daemon.info smartd[664]: Device: /dev/sda [SAT], SMART Usage Attribute: 194 Temperature_Celsius changed from 124 to 122
Mar  9 14:11:04 dns320 daemon.info smartd[664]: Device: /dev/sdb [SAT], SMART Usage Attribute: 194 Temperature_Celsius changed from 121 to 118
Mar  9 15:57:01 dns320 cron.info crond[649]: crond: USER root pid 578 cmd scp /tmp/sys/*_input ro...@192.168.1.106:/storage/backup/NASTempFan
Mar  9 16:00:13 dns320 daemon.info sysctrl: left disk (sda) wakeup
Mar  9 16:00:27 dns320 daemon.info sysctrl: usb disk (sdc) wakeup
Mar  9 16:00:37 dns320 daemon.info sysctrl: right disk (sdb) wakeup
<---- but again for unknown for me reason they are wakeup
Mar  9 16:02:01 dns320 cron.info crond[649]: crond: USER root pid 599 cmd scp /tmp/sys/*_input ro...@192.168.1.106:/storage/backup/NASTempFan
Mar  9 16:02:13 dns320 daemon.info sysctrl: temp=42.0    pwm=127 fan=3000


I don't understand why twice disks had been wake up: at 10:29 and 16:00.
Is it possible cron jobs causing it?
/tmp/sys folder is located in memory filesystem? If yes, then scp command should not trigger to wakeup disks.

[João Cardoso]

On Wednesday, 9 March 2016 17:46:44 UTC, Rafal B wrote:

Thanks for providing next lessons :-)

OK, but this is going off-topic, better to restrict posts to the subject.

It depends on what they do... 

 

/tmp/sys folder is located in memory filesystem?

yes

 

If yes, then scp command

But you are using 'scp' from the openssh package, that is installed on disk. If the box had no activity meanwhile, It could even be cached in memory; also ssh key files in the user on-disk home folder are accessed during the ssh negotiation... there are several  factors that can influence disk wakeup (and you have not yet talked about swap ;-)

[Rafal B]

Keys files will be located on memory filesystem (root's account home folder) - this is why I was asking how to copy those keys files from /home/Rafal/.ssh to root's home.
But other parts of the process seems to will cause that cron job will awake HDs: scp location, swap (whatever it means)
Ops, it seems to be more complex than I was thinking even that I was full of hope that I can just send two small files from one linux box to another with memory filesystem usage only (without awaking HDs)
I see another "procedure" how it can be achieved: cron's script should first detect if HDs are spinning and in case they are then send files, otherwise when they are idle just do nothing. But: this is out of my skills of linux programming, so I just abandon my idea :-(
Thanks a lot for all your information and time spent for me.
Wish you all the best,
/Rafal

[João Cardoso]

On Wednesday, 9 March 2016 19:44:14 UTC, Rafal B wrote:

Keys files will be located on memory filesystem (root's account home folder) - this is why I was asking how to copy those keys files from /home/Rafal/.ssh to root's home.
But other parts of the process seems to will cause that cron job will awake HDs: scp location, swap (whatever it means)
Ops, it seems to be more complex than I was thinking even that I was full of hope that I can just send two small files from one linux box to another with memory filesystem usage only (without awaking HDs)
I see another "procedure" how it can be achieved: cron's script should first detect if HDs are spinning and in case they are then send files, otherwise when they are idle just do nothing. But: this is out of my skills of linux programming, so I just abandon my idea :-(

When the main road is jamed we go through the alley :-)

Your cron script can just use the syslog system, using

logger -t myown "Temperature: $(cat /tmp/sys/temp1_input)

to debug it watch the syslog using the 'logread' command, and setup syslog to log to a remote linux computer (Services->System->syslog, Configure, "Log to remote system").

Then  you have to make your other linux syslog to accept incoming log connections. I use 'rsyslog', and see what I get:

[root@DNS-325]# logger "hello rsyslog, that's me again from the dns-325"

silver:~ # grep dns-325 /var/log/messages

2016-03-11T17:53:43+00:00 dns-325.homenet kernel: klogd started: BusyBox v1.20.2 (2015-01-30 16:18:45 WET)

2016-03-11T17:54:16+00:00 dns-325.homenet dropbear[3594]: Child connection from 192.168.1.1:58147

2016-03-11T17:54:16+00:00 dns-325.homenet dropbear[3594]: Pubkey auth succeeded for 'root' with key md5 4c:a8:58:99:9b:d8:55:92:48:58:2a:a8:45:02:90:54 from 192.168.1.1:58147

2016-03-11T18:02:31+00:00 dns-325.homenet root: hello rsyslog, that's me again from the dns-325

[Rafal B]

Hi,
Nice you are continuing linux lessons :-) Now I got more knowledge about logs maintenance in linux.
I told you I'm giving up but it was not true :-) I have had few hours for learning myself linux shell very basic programming so I did that and created my first linux script which fulfill my needs :-)
Background for that script is quite complex: I'm running on that another linux machine "Speed Fan Information" add-on which is even a little bit buggy as it read data from a log file only if it contain more than 15 rows and that log file must have a specific format.
So my assumptions for my script launched every 5 minutes in D-Link's cron are:
- check if D-Link hard drives are in standby. If yes - exit
- check if there is /root/.ssh folder (which is disappearing when D-Link is rebooted) If no - copy ssh-keys from user's home folder to /root/.ssh
- check if on remote machine there is a file SFLog${CURRDATE}.csv if yes - add current temp and fan speed values; if no - delete all files in folder on remote machine, create new file SFLog${CURRDATE}.csv, add header to it and 15 lines with current temp and fan speed values. Values have to be tab separated.

My script is running perfectly and I'm so happy :-)
 
So, once again: thank you very much for all those advises, lessons, solutions. Without them I wont be able to finally achieve my goal.

Best regards,
Rafal