SSH fails with host key error when sending a command, but works without one

0

I am setting up a server to be able to support SSH with host key authentication which is currently handled by an old dying server. As of right now I can successfully connect with SSH and interact in the terminal like normal. However if I include a command or put the SSH in an RSync command I get the error "Host key verification failed".

So this command works:

ssh -o StrictHostKeyChecking=no -i /cygdrive/C/keys/id_rsa user@192.168.0.2

While the following does not:

ssh -o StrictHostKeyChecking=no -T -i /cygdrive/C/keys/id_rsa user@192.168.0.2 ssh 192.168.0.2 mkdir -p /mnt/storage/new_folder

However they both work when pointing to the older server, so the commands themselves should be fine. Additionally if I can manage to not change the commands it would allow us to be backwards compatible.

I'm including the sshd_config settings on the new server (which were set to mimic the old server) below in case they help, the only items here are the ones that were not commented out.

HostbasedAuthentication no
RhostsRSAAuthentication no
PermitEmptyPasswords no
ChallengeResponseAuthentication no
UsePAM yes
X11Forwarding yes
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
AcceptEnv LANG LC_*
Subsystem sftp /usr/lib/openssh/sftp-server
PubkeyAuthentication yes
RSAAuthentication yes
LoginGraceTime 2m
PermitRootLogin yes
StrictModes yes

New server is Ubuntu 17.10 (will be updated to LTS when next one comes out soon). Old server is Debian 6.0.6.

Edit: Forgot to mention, this error is also occurring when I use RSync with '-e'. However I found that in the RSync command, I can fix the issue by using username@192.168.0.2:/mnt/storage/new_folder in the remote path parameter. If I remove "username@" then I get the error again. Again, the failing version works fine on the old serve, only fails with new server. Also keep in mind this is legacy code, so if I can get the old commands to work as-is it'll save me a bunch of time pushing updates.

Stephen Teodori

Posted 2018-03-06T19:10:36.867

Reputation: 13

It looks like the command that you’re trying to run on host B is “connect to host B and then run mkdir there”. Why not just run the mkdir on host B? – Scott – 2018-03-06T19:15:14.193

@Scott This is part of deployed software used within the company and this command is the simplest to debug compared to others. The others get the same error. Actually that reminds me I need to add an edit. – Stephen Teodori – 2018-03-06T19:22:53.437

Oh, two more things: (1) What error message(s) are you getting (exactly)?   And (2) What operating system(s) are your machines running? – Scott – 2018-03-06T20:21:35.523

Answers

1

OK, you’re sitting on host A (unspecified), and, when you run command 1:

ssh -o StrictHostKeyChecking=no -i /cygdrive/C/keys/id_rsa user@192.168.0.2

and you get an interactive shell on host B (192.168.0.2).  But when you run command 2:

ssh -o StrictHostKeyChecking=no -T -i /cygdrive/C/keys/id_rsa user@192.168.0.2 ssh 192.168.0.2 mkdir -p /mnt/storage/new_folder

(from host A), you get an error.

OK, run command 1 from host A and get an interactive shell on host B.  Now, on host B, run command 2b:

ssh 192.168.0.2 mkdir -p /mnt/storage/new_folder

What happens?  If this also fails, then your problem is not that “SSH fails with host key error when sending a command, but works without one”, your problem is that host B can’t ssh to itself — or, more specifically, that “user” on host B isn’t configured to be able to ssh to host B.

And, for completeness, what happens if you run command 2c:

ssh -o StrictHostKeyChecking=no -T -i /cygdrive/C/keys/id_rsa user@192.168.0.2  mkdir -p /mnt/storage/new_folder

(from host A)?

Scott

Posted 2018-03-06T19:10:36.867

Reputation: 17 653

Thank you very much, I didn't know you could ssh into your own machine like that. It did indeed give an error when I followed your steps. The problem was that when I transferred the key file from the old server I only updated the authorized_keys file on the new server. I didn't add the key file in /home/username/.ssh/. Once I added the file and set the permissions it began working in your scenario as well as in my own tests. Thank you very much! – Stephen Teodori – 2018-03-06T20:44:33.203