2

I have this small script for connecting to new machines I don't have ssh-key to:

function my_ssh () {
    ip=$1
    optional_cmd=$2

    ssh -o "BatchMode yes" user_name@$ip exit > /dev/null 2>&1

    if [ $? -gt 0 ]; then
        echo "1st time connection - adding key to authorized keys list"
        sshpass -p "secret_password" ssh-copy-id user_name@$ip
    fi

    echo $optional_cmd
    ssh -X user_name@$ip $optional_cmd
}

This works weel for servers that either have my ssh-key, or only ask for a password in order to use ssh-copy-id. However, some servers require a "yes/no" after the following question:

The authenticity of host 'A.B.C.D ()' can't be established. ECDSA key fingerprint is SHA256:****. Are you sure you want to continue connecting (yes/no)?

How can I add a "yes" string echoed into the server question stdin and then use the sshpass?

ps, I went over the sshpass code from github but it doesn't seem sshpass is designed for something like this. I think I can modify it to suite my needs, but I prefer using a normal Linux mechanism if possible

6
  • 2
    use ssh-copy-id -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null ...
    – pynexj
    Feb 18, 2019 at 12:57
  • cool! that works, but if that option wouldn't have worked (because of a tweaked ssh server) would it still be possible to mimic this behaviour? Feb 18, 2019 at 13:01
  • that's ssh client side options. would not be impacted by ssh server side conf.
    – pynexj
    Feb 18, 2019 at 13:02
  • 1
    @pynexj You should expand that comment into an actual answer :)
    – Byte Commander
    Feb 18, 2019 at 13:07
  • 2
    then you need to use utils like expect or sexpect (Expect for Shells).
    – pynexj
    Feb 18, 2019 at 13:11

3 Answers 3

1

To answer the OP's question about entering "yes" on the ECDSA key fingerprint prompt, and I would only advise this for localhost SSHds - never in anything more than an experimental docker container setup, you can do the following:

sshpass -p 'password' ssh \
  -o StrictHostKeyChecking=no \
  [email protected] -p 2222 'whoami'

A use case? You could have a nobody user that is the only user who is allowed to password-SSH into a machine (all other users are set to require keys). You could then just get some system info you need, say, as you experiment with orchestration.

sshpass -p 'meminfo' ssh \
  -o StrictHostKeyChecking=no \
  [email protected] -p 2222 "egrep 'Mem|Cache|Swap' /proc/meminfo"

The result would be something like this.

Warning: Permanently added '[127.0.0.1]:2222' (ECDSA) to the list of known hosts.
SSHPASS searching for password prompt using match "assword"
[email protected]'s password: 
SSHPASS detected prompt. Sending password.
SSHPASS read: 

MemTotal:       16369628 kB
MemFree:          683412 kB
MemAvailable:    8847748 kB
Cached:          6544572 kB
SwapCached:          460 kB
SwapTotal:       2097148 kB
SwapFree:        2071928 kB

Then you can nmap a cluster or Pis (or docker containers) on your LAN and then automate checking how they are doing without adding NodeJS or Python or a health API service.

If you're finished experimenting and want to clean up those rubber-stamped ECDSA fingerprints, you can run:

ssh-keygen -f "~/.ssh/known_hosts" -R "[127.0.0.1]:2222"

Warning: I must remind everyone that even the above with a nobody user can be dangerous if they find some privileged command that has the suid bit set - nobodys could still run as root!

1
  • please try to keep your eyes on the ball, your -o is passed to ssh NOT to sshpass, not even close the same thing: sshpass -vvv -p password ssh -p 2222 [email protected] SSHPASS searching for password prompt using match "assword" SSHPASS read: The authenticity of host '[target.host]:2222 ([X.X.X.X]:2222)' can't be established. RSA key fingerprint is ... as you can see stupid error is generated by sshpass, NOT by ssh, and also with ssh but without sshpass is working very well and host is saved in know_hosts, also sshpass doesn't know -o option
    – user40404
    Sep 23, 2021 at 13:27
0

I had the same problem, and solved it by ading this two lines:

UserKnownHostsFile=/dev/null
StrictHostKeyChecking=no

in /etc/ssh/ssh_config

seems like sshpass is actually reading that file instead of having an -o option

1
  • It's not sshpass reading this file, it's ssh itself. These are legit options to ssh. The only job of sshpass is to input password into ssh, it does nothing more.
    – raj
    Sep 23, 2021 at 15:12
-1

Workaround:

list.txt
vm1.example.com
vm2.example.com
vm3.example.com
...

for i in $(cat list.txt); do timeout 1 ssh -o StrictHostKeyChecking=no user@$i; done
for i in $(cat list.txt); do ssh-copy-id -i user@$i; done

ssh [email protected] -- no pass

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .