Problem with dropbear known_hosts file location

I have a script that uses ssh to connect to a remote server. It works fine when run from command line as root.

When it is run from a late stage START=99 /etc/init.d task, the ssh fails because the remote server does not match a known host.

Does the /etc/init.d task run as root by default? I do not see in the docs where it specifies this.

As a temporary work around I have copied the contents of /root/.ssh/known_hosts to /.ssh/known_hosts and it seems to function. This suggests either that the /etc/init.d task is running as a different user or there is a problem in dropbear when used at that time.

Thanks!

Yes, procd is run as root, and executes those scripts as root.

I don't know where dropbear expects root's known_keys to reside. Your "workaround" might be consistent with its behavior.

See also

1 Like

It looks like the problem in in OpenWRT since the following are not set before running init.d scripts
USER='root'
LOGNAME='root'
Thus the home directory is also not set.

Looks like you're right. A quick test with

jeff@devel:~$ cat /etc/init.d/test0 
#!/bin/sh /etc/rc.common
# Copyright (C) 2006 OpenWrt.org

START=99
boot() {
    echo $0
    env
}

shows

2018 Sep 12 15:01:53 devel notice procd: /etc/rc.d/S99test0: /etc/rc.common
2018 Sep 12 15:01:53 devel notice procd: /etc/rc.d/S99test0: SHLVL=1
2018 Sep 12 15:01:53 devel notice procd: /etc/rc.d/S99test0: HOME=/
2018 Sep 12 15:01:53 devel notice procd: /etc/rc.d/S99test0: TERM=linux
2018 Sep 12 15:01:53 devel notice procd: /etc/rc.d/S99test0: PATH=/usr/sbin:/usr/bin:/sbin:/bin
2018 Sep 12 15:01:53 devel notice procd: /etc/rc.d/S99test0: PWD=/

I tried --login as one "easy" way to get root's "normal" environment set up with

jeff@devel:~$ cat /etc/init.d/test1 
#!/bin/sh --login /etc/rc.common
# Copyright (C) 2006 OpenWrt.org

START=99
boot() {
    echo $0
    env
}

but it failed to be enable-ed and, if manually symlinked in, failed to produce log entries. I'm guessing that it failed to run.

I have opened a bug tracker for this issue. It has one vote, whatever that means.

https://bugs.openwrt.org/index.php?do=details&task_id=1931