Closed cpswan closed 1 month ago
Now that npt is available, I'm even more inclined to say we shouldn't. I think the bar for entry is at least "knows / needs to know how to use ssh", otherwise why aren't they using npt.
Thus, I think -s and -i should not do these automatically, since the default behavior would then be the opposite of what people expect ssh to do. Additionally, ssh has a built in default identity file order, so if they choose to upload that, then they will not need to specify -i on successive requests.
From the man page:
-i identity_file
Selects a file from which the identity (private key) for public key authentication is read. You can also specify a public key file to use the corresponding private key that is loaded in ssh-agent(1) when the private key file is not present locally. The default is ~/.ssh/id_rsa, ~/.ssh/id_ecdsa, ~/.ssh/id_ecdsa_sk, ~/.ssh/id_ed25519, ~/.ssh/id_ed25519_sk and ~/.ssh/id_dsa. Identity files may also be specified on a per-host basis in the configuration file. It is possible to have multiple -i options (and multiple identities specified in configuration files). If no certificates have been explicitly specified by the CertificateFile directive, ssh will also try to load certificate information from the filename obtained by appending -cert.pub to identity filenames.
The default order on my machine/version is: ~/.ssh/id_rsa, ~/.ssh/id_ecdsa, ~/.ssh/id_ecdsa_sk, ~/.ssh/id_ed25519, ~/.ssh/id_ed25519_sk and ~/.ssh/id_dsa
Also, SSH No Ports Desktop we require that the user uploads a public key, since we can't pull from the .ssh directory due to app sandboxing. I think it might be reasonable here to have -s turned on by default.
Discussed this in arch.
Consensus was to make things as easy as possible, so guide through key creation process where needed and make uploading keys the default.
Moving back to Triage so we can decide what to do next.
Don't expect to get to this in PR90, so bumping to PR91
On further reflection I'm inclined towards not having this as a default, particularly as -i
would need to be pointed at the right key.
Is your feature request related to a problem? Please describe.
An install of sshnp into a fresh environment is likely to fail unless keys have already been put in place
Describe the solution you'd like
Use the -s and -i flags in np.sh to ensure that keys on the client machine are transported to the target device.
Describe alternatives you've considered
These could be the default for sshnp itself, but I'm not persuaded that it's a secure default.
Additional context
Do we expect our users to know their way around ssh key management?