从远程会话中运行时 ssh-copy-id 失败

Question

I have a task to copy ssh keys from one node to all others in an array. For this, I wrote a simple bash script which copies itself to other nodes and runs it there. What confuses me is the fact that ssh-copy-id works fine on the node where the script is executed manually but it fails if run remotely in an ssh session. Here's the script:

1   #!/bin/bash
2   # keys-exchange.sh

4   nodes=( main worker-01 worker-02 worker-03 )

6   for n in $( echo "${nodes[@]}" ); do
7     [ $n != $HOSTNAME ] && ssh-copy-id $n
8   done

10  if [ -z $REMOTE ]; then
11    for n in $( echo ${nodes[@]} ); do
12      if [ $n != $HOSTNAME ]; then
13        scp $0 $USER@$n:$0 > /dev/null
14        ssh $USER@$n "REMOTE=yes HOSTNAME=$n $0 ; rm -f $0"
15      fi
16    done
17  fi

The code in rows 6-8 works fine copying the ssh key to all nodes other than itself. Then, if the REMOTE variable is not set, code in rows 11-16 copies the script to remote nodes (except the node it's running on, row 12) and runs it there. In row 14, I set and pass the variable REMOTE to skip the code block in rows 10-17 (so the script copies itself only from the source node to others), and the variable HOSTNAME because I found it's not set in an ssh session. The user's name and the script path are completely the same on the source node and all destination nodes.

When running on the source node, it works properly asking for a confirmation and the remote host's password. But the script that has just run successfully on the source node fails running in the remote ssh session: ssh-copy-id fails with the following error:

/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/username/.ssh/id_rsa.pub"
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: ERROR: Host key verification failed.

At that moment, no .ssh/known_hosts file is present on a remote node so I can't do ssh-keygen -R. What am I missing and how to make it work?

Answer 1

ssh-copy-id is not copying your keys to remote hosts, it's adding them to ~/.ssh/authorized_keys and when you jump to that remote host there are no keys(or are they?) so there is nothig to copy further. And if ssh-copy-id run without -i option it'll copy(add to authorized_keys) all .pub keys from your ~/.ssh dir wich could be not desired so i suggest to run it like this ssh-copy-id -i $key $host

Answer 2

ssh $USER@$n "REMOTE=yes HOSTNAME=$n $0 ; rm -f $0"

Try running ssh with the "-tt" option to request a PTY (pseudo-TTY) for the remote session:

ssh -tt $USER@$n "REMOTE=yes HOSTNAME=$n $0 ; rm -f $0"
    ^^^

In the case that you're describing, you're launching ssh on the remote system to connect to a third system. The ssh instance doesn't have a saved copy of the third host's host key. So you'd normally expect ssh to prompt the user whether to continue connecting to the third host. Except that it's not prompting the user--it's just refusing to connect to the third host.

When ssh is invoked with a command to run on the remote system, by default it runs that command without a TTY. In this case, the remote ssh instance sees that it's running without a TTY and runs non-interactively. When it's non-interactive, it doesn't prompt the user for things like passwords and whether to accept a host key or not.

Running the local ssh instance with "-tt" causes it to request a PTY for the remote session. So the remote ssh instance will have a TTY and it will prompt the user--you--for things like host key confirmations.

Answer 3

Be sure that on the destination side, the /etc/ssh/sshd_config is configured to accept the type of key that was generated.

PubkeyAcceptedKeyTypes ssh-ed25519,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-rsa

I generated the key using "ssh-keygen -t rsa -b 4096 ..." however, up above the following line did not include the ",ssh-rsa" at the end, so even though the ssh-copy-id updated my destination, the sshd did not accept rsa type generated keys. Once i added ",sha-rsa", the did "systemctl restart sshd" it worked!