[Bug]: Permission problem when running ssh command to root

[wallart1]

Is there an existing issue for this?

• I have searched the existing issues

What happened?

I'm missing something simple.

From one machine that is running Cronicle, I am running a script in the shell plugin that does an ssh command to another (local fileserver) VM, which invokes a command that requires root privilege.

The Cronicle job log shows:

+ ssh root@fileserver cp /etc/fstab /etc/fstab.bak
Permission denied, please try again.
Permission denied, please try again.
root@fileserver: Permission denied (publickey,password).

If I ssh from the root user (using keys, not passwords) on the Cronicle machine to the root user on the fileserver machine using gnome-terminal running bash, I have absolutely no problems.

I've looked around for more information in the logs (only syslog has anything), but no further information is provided.

I've tried resetting the ssh keys (ssh-copy-id -f), but that doesn't help.

Does Cronicle have some other context that, when run in a Cronicle shell plugin, causes ssh to get its keys from somewhere other than /root?

What am I forgetting about??

EDIT to add: I am doing this same thing with another local VM, and it works perfectly.

Operating System

Linux Mint 22

Node.js Version

v20.17.0

Cronicle Version

Version 0.9.59

Server Setup

Single Server

Storage Setup

Local Filesystem

Relevant log output

Mar 09 12:36:12 Fileserver sshd[10708]: Failed password for root from 10.0.0.68 port 45072 ssh2
Mar 09 12:36:12 Fileserver sshd[10708]: Failed password for root from 10.0.0.68 port 45072 ssh2
Mar 09 12:36:12 Fileserver sshd[10708]: Connection closed by authenticating user root 10.0.0.68 port 45072 [preauth]

Code of Conduct

• I agree to follow this project's Code of Conduct

[wallart1]

Cronicle is running as a systemd service:

root@foghorn:~# systemctl cat cronicle
# /etc/systemd/system/cronicle.service
[Unit]
Description=Node Cronicle
After=network.target

[Service]
Type=forking
ExecStart=/opt/cronicle/bin/control.sh start
ExecStop=/opt/cronicle/bin/control.sh stop

[Install]
WantedBy=multi-user.target

[jhuckaby]

So, the important thing to understand about Cronicle is, it doesn't run commands as "you". It runs them in a sort of "blank" shell that has none of your environment variables, user profile, SSH keys, or any of that stuff. Sure, if the UID is "root" it'll run the script with root permissions, but it doesn't have any of root's environment, or even know where its home directory is, so it can't find SSH keys, etc. This is especially true if you launch Cronicle as a systemd service.

If you want Cronicle jobs to be able to do things like SSH to remote servers, then you need to tell it where your home directory and SSH keys live. There are many ways to do this. Here are a few:

First, set the HOME environment variable. If root's home directory is /root, and its SSH keys are located in /root/.ssh/, then setting this at the top of your shell script may do the trick:

export HOME=/root

Also, you may need to "source" (evaluate / execute) your shell profile, so it sets all the necessary environment variables. This file is typically executed when you (a real human user) logs into the server, and starts a shell with a TTY attached. This file is typically in your home directory and named .profile or .bash_profile or .zshrc. For example:

source /root/.profile

There are a lot of different names for this file, so you may have to go look at what it is on your system.

Finally, you may simply need to tell SSH exactly where the SSH key is that it should use to make the remote connection. You can do this with the -i switch on the SSH command. Example:

ssh -i /root/.ssh/id_rsa root@fileserver "command here"

Good luck.

[wallart1]

Thanks for the Sunday reply! :-)

But none of that works. :-(

Here is a different job that does a similar thing, but on a different VM. It works fine:

#!/bin/bash
set -x

ssh root@seeder	rm -R /home/dan/.cache/mesa_shader_cache/
ssh root@seeder	rm -R /home/dan/.cache/BraveSoftware/Brave-Browser/
ssh root@seeder	rm -R /home/dan/.cache/kio_http/
ssh root@seeder	rm -R /home/dan/.local/share/qBittorrent/logs/qbittorrent.log.bak*

ssh root@seeder clamscan --recursive --infected \
--max-filesize=100M \
--exclude=/sys/ \
--exclude=xmrig \
--exclude=-scantem. \
--exclude=/NFS1 \
--exclude=/mnt \
--log=/var/log/clamscan.log \
/

ssh root@seeder clamscan --recursive --infected \
--max-filesize=1000M \
/mnt

[wallart1]

I guess there is something wrong on the VM side. I'll understand if you make this issue out-of-scope.

[jhuckaby]

I'm so sorry 😞 I don't know what else to try, as this seems really specific to your unique setup 😞

This output is very typical when the SSH command cannot locate your user's SSH key:

root@fileserver: Permission denied (publickey,password).

You can add -vvv to the SSH command to increase the verbosity, so it outputs verbose debugging information. This may give you a clue as to why it is failing, and instead prompting you for a password. Example:

ssh -vvv root@seeder rm -R /home/dan/.cache/mesa_shader_cache/

Good luck, and sorry I could not help. I'll leave this issue open so maybe others from the community can chime in.