121–128 of 128 posts
Earlier quoted context omitted.
Right (what's the threat model)? The possibilities of restricted passphrase-less keys are under-appreciated for non-interactive use, or even interactive use. I'd rather mint an ephemeral key for an endpoint I control than type credentials or, worse, forward the agent, if I have to call out of an untrusted system (like an HPC login node).
I mean, the use case is I want my GUI wrapper to interactively prompt the user for the decryption password. It’s not getting saved to disk; I just want ssh capabilities (including password protected ssh keys) inside an interactive desktop app.
Earlier quoted context omitted.
You have a fundamental misunderstanding of footguns, and humans. Explaining them is in manual doesn't mean they no longer exist. People often don't read the manual. Nor should they have to. > If you aren't good with shell scripts, why bother? Go use Python or something else entirely I agree! And given that essentially nobody is "good with shell scripts" we can simplify that advice to "don't write shell scripts".
> People often don't read the manual. Nor should they have to. That's some kind of logic right there. If people don't read the manual, they have every right to expect that things will break. It's not surprising or shocking, it's just user error. > we can simplify that advice to "don't write shell scripts". No, we cannot simplify it like that. Shell scripts are a brilliant tool for a certain kind of problem, and they…
This is just fundamentally and absolutely wrong. Completely incorrect.
I could explain it, but others have done better:
https://en.wikipedia.org/wiki/Principle_of_least_astonishmen...
https://notes.rmhogervorst.nl/post/2022/11/21/what-is-a-foot...
https://fstoppers.com/opinion/stop-telling-people-read-manua...
I also recommend the book "The design of everyday things" which isn't about software but the lessons in it are highly applicable.
Good luck learning!
The author claims that sshpass is "broken by design" and goes on to show some examples of why, without ever explaining anything. Can anyone enlighten me why sshpass is broken, or explain the examples on that page?
You are probably asking about the passh page. Examples there show that sshpass creates a new permanent tty entry with each use, while passh does not. More importantly though is that sshpass keeps your password permanently on your computer, thus increasing security risks considerably.
bad:
bash-4.4# tty
/dev/pts/18 // the bash's stdin is also connected to pts/18
bash-4.4# tty
/dev/pts/18 // the bash's stdin is connected to the new pts/36
And yes, if I use either sshpass or passh, the password will have to be "on my computer" (i.e. in a script or text file), that's the whole point of it: accessing devices that don't do public-key authentication non-interactively
Earlier quoted context omitted.
Author here. I don't claim sshpass is "broken by design". I claim it is brittle as it relies on the detection of a password prompt. passh author has several examples here: https://github.com/clarkwang/passh/blob/master/sshpass-broke... .
https://github.com/clarkwang/passh/ On the sidebar, in the about, it says, > sshpass is broken by design This is another repo. But probably where they got it.
The author claims that sshpass is "broken by design" and goes on to show some examples of why, without ever explaining anything. Can anyone enlighten me why sshpass is broken, or explain the examples on that page?
I’ve always been told that ssh is not supposed to work non-interactively. Which is the whole reason for sshpass, to work non-interactively. Ie. Broken by design.
The author claims that sshpass is "broken by design" and goes on to show some examples of why, without ever explaining anything. Can anyone enlighten me why sshpass is broken, or explain the examples on that page?
Author here. I don't claim sshpass is "broken by design". I claim it is brittle as it relies on the detection of a password prompt. passh author has several examples here: https://github.com/clarkwang/passh/blob/master/sshpass-broke... .
Earlier quoted context omitted.
Public key authentication is actually a Must Implement for SSHv2. Since SSHv1 is long obsolete, any gear that doesn't have pubkey doesn't actually have a de jure SSH implementation. "All implementations MUST support this method"
And if you don't, anyway? Do you not get to use the SSH(TM) logo on your product? You're reading MUST a bit too literally.
Do with that whatever you will.