0

I'm currently working on a project I inherited that requires me to document the process for setting up a device we use to reimage our machines and install software on them.

I'm using a Raspberry Pi as the host to install the OS and software and have run into issues with one last part of the installation script which requires me to be able to execute a command via SSH and get the return value. The command I'm trying to execute is as follows:

ssh -o StrictHostKeyChecking=no host uname -a &>/dev/null
rc=$?

That is the command verbatim. No user is specified for the host and no password is passed in, so it is authenticated via keys, I assume. I don't know much about SSH, but since each Pi is supposed to have an identical image on it, I would assume the SSH keys would be the same, so I copied the contents of /etc/ssh from the old one to the new one. I didn't bother to copy the contents of ~/.ssh because the only file in that directory on BOTH devices is known_hosts.

However, despite having the same setup and same SSH keys, the old one is able to execute this command with no fuss, while the new one prompts for the root@host password.

What else could be affecting my ability to execute this command? Am I missing some obscure SSH configuration? I have looked at just about everything I could find on Google and the only answer I could find was to generate a key on the machine that needs to execute the command and install it on the host's authorized_keys file -- but since the Pi does not even have this file, and the old Pi already has keys in /etc/ssh which I assume are used for this purpose, I don't understand why a new Pi with the same setup and same keys should fail to authenticate.

Darin Beaudreau
  • 137
  • 7

2 Answers2

1

For key authentication to work, there has to be the public key in the authorized_keys file, and the file permissions must not allow anybody except the owner to write to the file. The default location for that file is .ssh/authorized_keys .ssh/authorized_keys2, but it can be changed with the AuthorizedKeysFile option in /etc/ssh/sshd_config. Another location for the config file could also be specified on the command line, it is also possible to override options on the command line.

If that doesn't help you fix the problem, you should look at the sshd log to find out what is wrong. You may have to increase the log level (sshd option LogLevel) to VERBOSE or DEBUG.

RalfFriedl
  • 3,008
  • 4
  • 12
  • 17
  • Well, as I said, the authorized_keys file doesn't even exist on the original installation, and that one works. I've just checked, and /etc/ssh/sshd_config has the AuthorizedKeysFile line commented out, and is still set to the default location anyway. I'm assuming setting the SSHD option right before the SSH command in issue would be sufficient? – Darin Beaudreau Nov 20 '18 at 19:04
  • The `sshd_config` is read when `sshd` is started or when it receives a SIGHUP. – RalfFriedl Nov 20 '18 at 19:11
  • Alright, so I can just SSH into the Pi and set that option, that shut it down and do the installation? – Darin Beaudreau Nov 20 '18 at 19:12
  • If you shut it down, it won't accept connections. You can either kill the server (not the process serving your connection) and start it manually with log option, or set the log option in the config file and restart/reload the server. – RalfFriedl Nov 20 '18 at 19:14
  • No, what I mean is set the option, then shut down the Pi and connect it to the machine for installation. – Darin Beaudreau Nov 20 '18 at 19:17
0

Okay, so after some more digging around, I discovered that there was a separate .ssh directory under /root that contained an authorized_keys file. After copying this to the new Pi, it worked. I had been wondering all this time if there was a separate config folder for root, but I've never gone digging around /root, so I wasn't aware that it was there.

Darin Beaudreau
  • 137
  • 7