Crash on running `demo.py start` as scp does not know which SSH key to use

[slarse]

After the start command has set up the VMs, I get a crash when the script tries to run scp.

Traceback (most recent call last):
  File "/home/slarse/Documents/github/work/trustfull-demonstrator/scripts/demo.py", line 752, in <module>
    sys.exit(main(parse_args()))
  File "/home/slarse/Documents/github/work/trustfull-demonstrator/scripts/demo.py", line 259, in main
    return globals()[f"{args.subparser_name}_main"](args)
  File "/home/slarse/Documents/github/work/trustfull-demonstrator/scripts/demo.py", line 310, in start_main
    vm.get_prot_info()
  File "/home/slarse/Documents/github/work/trustfull-demonstrator/scripts/demo.py", line 89, in get_prot_info
    scp(
  File "/home/slarse/Documents/github/work/trustfull-demonstrator/scripts/demo.py", line 476, in scp
    return subprocess.run(["scp", src, dest], check=True)
  File "/usr/lib/python3.9/subprocess.py", line 528, in run
    raise CalledProcessError(retcode, process.args,
subprocess.CalledProcessError: Command '['scp', 'vmn@94.245.109.30:~/election/0/protInfo.xml', '0-protInfo.xml']' returned non-zero exit status 1.

How is scp supposed to know which SSH key to use here? The IP addresses of the servers are dynamically allocated in Azure, so I can't configure by host.

I worked around this by putting a catch-all in my SSH config:

Host *
    User vmn
    IdentityFile ~/.ssh/azure_vmn

But that seems a little bit dirty? Do you have a better way of doing it?

[orestisfl]

My ssh / scp by default try all available private keys under ~/.ssh, doesn't it do this for you? Maybe it's not as standard as I thought. From the ssh -v log:

debug1: Will attempt key: Verificatum azure server key RSA SHA256:… agent
[…]
debug1: Next authentication method: publickey
debug1: Offering public key: Verificatum azure server key RSA SHA256:… agent
debug1: Server accepts key: Verificatum azure server key RSA SHA256:… agent
debug1: Authentication succeeded (publickey).

We can also add a --key argument.

[slarse]

I think that's ssh-agent doing some work, I don't have that running.

I'll try with ssh-agent, and then we can recommend that.

[slarse]

With ssh-agent running and the verificatum key added, the correct key was identified automatically. So perhaps resolve this by simply stating that ssh-agent must be running and have the private key added? I think ssh-agent is part of OpenSSH, so if there's SSH stuff on a machine, ssh-agent is all but guaranteed to be there as well.

[orestisfl]

Ok, I'll do both: update the README and add a key argument