unexpected SSH behavior when run in subshell

Question

we have a private network that we connect to using openconnect, then we run ssh to the server we want to work

I have a file named ssh.sh:

#!/usr/bin/expect -f

set timeout -1

spawn ssh -L 3306:localhost:3306 -L 8600:localhost:8600 -L 5672:localhost:5672 -L 5000:localhost:5000 myusername@xx.xxx.xxx.xxx

expect "myusername@xx.xxx.xxx.xxx's password:"
send -- "mypass\r"

expect eof

when I call it by ./ssh.sh command, it works. but when I call this script in another one by ./ssh.sh command, it says:

spawn ssh -L 3306:localhost:3306 -L 8600:localhost:8600 -L 5672:localhost:5672 -L 5000:localhost:5000 myusername@xx.xxx.xxx.xxx
The authenticity of host 'xx.xxx.xxx.xxx (xx.xxx.xxx.xxx)' can't be established.
ED25519 key fingerprint is SHA256:AkfGt+ZPLk5EnMl+QR4Lg1bJZwolgk%KTf1o4iFoP3E.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])?

UPDATE: it works correctly when I just call ./ssh.sh, but not when called as subshell

even if I say yes to that message, it still doesn't connect

Are you running it from the same username? This depends on settings in the user's `.ssh/config` file. — Barmar, Jul 31 '21 at 07:33
There must be something different. Subshells have no effect on how SSH runs. — Barmar, Jul 31 '21 at 07:44
Does the other script `cd` to the correct directory before using `./ssh.sh`? If not, it might not be running the correct `ssh.sh` script. I suggest you use full paths instead of relative paths. — Barmar, Jul 31 '21 at 07:46
they are both in the same directory, I still think something is different between shells — arianpress, Jul 31 '21 at 07:47
It doesn't matter if they're in the same directory. Pathnames are interpreted relative to the user's working directory, not the directory of the script. — Barmar, Jul 31 '21 at 07:48
I have both of them in home directory of my user and I run them from there — arianpress, Jul 31 '21 at 07:51

score 0 · Answer 1 · answered Jul 31 '21 at 07:34

SSH uses a key fingerprint method to determine if you are in a secure channel. This means that the host that they are contacting provides an unfalsifiable fingerprint. However, this method requires that you actually acknowledge the their fingerprint is the right one the first time you connect, and check it on next connections. This is what

The authenticity of host 'xx.xxx.xxx.xxx (xx.xxx.xxx.xxx)' can't be established.
ED25519 key fingerprint is SHA256:AkfGt+ZPLk5EnMl+QR4Lg1bJZwolgk%KTf1o4iFoP3E.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])?

means.

Therefore, your problem likely arises from the fact that SSH saves the host fingerprint somewhere where it can access it when you call it by hand, but cannot on the other case (ie. you call it being an other user).

A solution would be, instead of accepting by hand to remember the fingerprint, to let ssh.sh do the work, with the following snippet:

expect {
    "key fingerprint" {send "yes\r"; exp_continue}
    "password:" {send "$pass\r"}
}

unexpected SSH behavior when run in subshell

1 Answers1