Comment by chasil
10 hours ago
Several reasons.
-PuTTY pscp allows raw passwords on the command line, or from a file. OpenSSH is unreasonable in refusing to do this.
-Scripting can adapt to a .netrc easily; OpenSSH will never do this.
-Modern OpenSSH is a nightmare when using legacy crypto, while pscp is fluid. There is nothing wrong with hmac-md5, and no reason to refuse it. I will take PuTTY or dropbear in a heartbeat over these burned bridges and workarounds.
https://www.openssh.org/legacy.html
-pscp does not link to dozens of libraries as ssh/scp does, so it is easier to build with less dependency. The ldd output of ssh and scp on rhel9 is 23 libraries, while PuTTY is 3 [package obtained from EPEL].
-pscp strongly leans to SFTP on the backend and can be directed to use it exclusively, so there is no ambiguity.
-Using pscp with a retry on fail is much easier than sftp -b.
-The wacky cipher control on rhel8 does not impact the PuTTY tools.
That is an extensive list.
> -PuTTY pscp allows raw passwords on the command line, or from a file. OpenSSH is unreasonable in refusing to do this.
You can use `sshpass` to force it through a command line argument. However, arguments can be viewed by any process through `/proc`, `ps`, etc. It's pretty reasonable to not support exposure of the password like that, especially since you can force it through using another tool if you really, really need to.
Both pscp and psftp have -pwfile.
It is not reasonable to insist on keys for batch use.
Not at all.
It's completely crazy to use passwords when you needn't. Passwords are a human readable shared secret, they were already obsolete when SSHv1 was invented last century.
From the outset SecSH (SSHv2, the thing you actually use today and if you're younger, likely the only thing you ever have used) has public key authentication as a Mandatory To Implement feature. Implementations where that doesn't work aren't even SSH, they're garbage.
2 replies →