I can confirm that this works fine on the latest 1.3 nightly.

I cannot replicate this in 1.2.8 or 1.3.0-rc5. No matter how long vyos-router.service (even absurdly high times) stalls, ssh.service happily starts. This was probably resolved a long time ago, making this a ghost bug.

@trae32566 I can't replicate this. Can you post your config?

Now that the Paramiko and Cryptography versions have been updated, does this problem persist with the newer nightlies? @SrividyaA @FileGo

Done with generate public-key-command. loadkey is deprecated and will be removed in a future version.

Now that all major instances of curl have been replaced with the in-house script, we can begin to backport these changes to v1.3 in small pieces ahead of the first stable version.

Now I see the problem. paramiko.client.SSHClient().close() calls paramiko.transport.Transport().close() which implicitly calls socket.close() regardless of whether the socket was internally created or externally provided. This is a bit counterintuitive but I'll simply remove the socket closing logic then.

copy file still depends on vyatta-image-tools.pl. I think it merits a rewrite, maybe a simple file transfer script that uses a couple of basic routines for file:// and running:// and remote.py for everything else.

@trae32566 Does this problem still persist in the newest rolling release?

This is resolved for 1.4. Do you still have this problem in 1.3 as of RC4? If so, I'll need to backport the changes.