10 ms·
Non-interactive SSH password authentication
- dtgriscom 3y agoSeems overly complicated; sshpass works fine for me. (And the passh examples of why sshpass is broken seem contrived to me.)
- flyingcircus3 3y agoOverly contrived examples are the hallmark of software zealots. I knew to stop reading after "its more correct variant".
- IshKebab 3y agoIgnoring failures because they're moderately unlikely is the hallmark of a bad developer. It's an extremely common attitude unfortunately - you can see it all over the place, especially in the Unix/Linux world e.g. * People thinking sysvinit (janky Bash scripts) are fine. * 50% of Linux software doesn't work if you have spaces in your path. GNU Make explicitly doesn't support that. * Over use of text based APIs, e.g. /proc and /sys.
- generalizations 3y agoOn the other hand, text-based line-oriented APIs are a force multiplier that lets one solo dev/sysadmin be capable of administering (troubleshooting and building out and keeping alive) far more infrastructure than can be reasonably expected. And it's not sysvinit you should critique, but runit (fast and bulletproof - two things the other modern alternative doesn't really do). > Ignoring failures because they're moderately unlikely is the hallmark of a bad developer. Totally agree.
- IshKebab 3y agoI dunno I think something like JSON would still allow solo dev/sysadmins to get a lot done without the risk and effort of having to hand-roll separate parsers for every API. Then you could also offer something like Fuchsia's FIDL for programs to interface with - it allows generating the interface code fully typed in whatever language you want. No need to hand-roll a parser at all! > runit First I've heard of that. Looks interesting, but it doesn't seem like it has nearly enough features to run a modern desktop system? It just starts daemons and keeps them running as far as I can see.
- generalizations 3y agoI'm not familiar with Fuschia's FIDL system, but it looks intriguing. Though it's still pretty hard to beat using pipes and cut to ingest a line-oriented stream of text. If Fuchsia had beaten out UNIX in some parallel universe, it does look like we'd all be happier. Ha. Runit is pretty good - it's the default in the Void Linux OS that I use on my personal machines. Definitely good enough for a modern desktop system, though it's not aimed at the same crowd as Ubuntu and Fedora.
- IshKebab 3y ago> Though it's still pretty hard to beat using pipes and cut to ingest a line-oriented stream of text. Well, a) that's fine for interactive use but awful for unattended use because it's so likely to go wrong, and b) it is actually pretty easy to beat that - JSON and jq is much easier, nicer and more reliable. Or Nushell/Powershell structured pipes. Or an autogenerated properly typed Python interface. Take a look at /proc/self/status before you tell me you'd rather use some awk/cut monstrosity than `jq .ppid`. > If Fuchsia had beaten out UNIX in some parallel universe, it does look like we'd all be happier. I'd definitely be happier - I wouldn't spend so much time debugging why Linux stuff breaks!
- qweqwe14 3y ago1) How are shell scripts janky? Could you elaborate on that? Obviously if someone doesn't know shell very well they will write suboptimal scripts. Personally I use runit init, which uses shell scripts for services and it works well. 2) No idea where you got that from, I never had a problem with this (as a full-time Linux user) 3) Mixed opinions on this one. There's a ton of various info in /proc that could theoretically be exposed via different syscalls, or maybe a single syscall? But having a text-based API in this case isn't a big issue really.
- IshKebab 3y ago1. Sounds like you have written very few shell scripts if you don't know the issues and think you can just "don't make mistakes" (a classic fallacy). You can Google it and there are a ton of articles. Here's the first one I found which is decent but doesn't even mention some big issues like quoting: https://pythonspeed.com/articles/shell-scripts/ https://pythonspeed.com/articles/shell-scripts/ 2. Try putting a space in your home directory and let me know how that goes... 3. Most programs don't resort to reading /proc or /sys because it is such a pain! I bet there's a ton of undiscovered vulnerabilities in programs that do.
- qweqwe14 3y ago1. The real fallacy here is assuming "it requires experience so it's impossible to do". Everything described in that article is trivial and anyone with experience in writing shell scripts knows about these things. People just instinctively go "this doesn't do what I expect therefore it's bad" instead of trying to understand the reasoning behind that. tl;dr Classic skill issue 2. Another fallacy. Obviously there will be badly written programs that don't handle paths properly. And I'm sure that if I put a space there it will screw things up. But it doesn't mean that most programs do that? 3. It's not a pain. It's absolutely trivial to do, and people whose code is vulnerable in this case are most likely just bad at programming and shouldn't be writing at such a low level as to cause vulnerabilities anyway. These are the type of people referred to as "developers" instead of "programmers". (Source: I personally parsed /proc entries without third party libraries, can't say it was hard)
- rubicks 3y agoSame. As soon as I read the title: "Surely `sshpass` still works in this instance? Yup." Even if avoiding good practices with PKI was defensible (and it definitely is not), further avoiding `sshpass` in favor of this more contorted trickery is (imho) probably the wrong choice.
- linsomniac 3y agoI like the trick of setting the sticky bit to indicate that it's taking a second kick at the can.
- yanko 3y agoUsed 'expect' like 20 years ago...
- nulbyte 3y agoI was waiting for the article to mention why the author chose not to employ that option. Though the author mentions in passing that one solution is brittle because it requires parsing output, I don't see why that's a problem. It's exactly what 'expects was designed to do.
- Joel_Mckay 3y agoexpect/tcl offers many options, but does have some quirks with remote shells. What it does do well: 1. can validate a key signature issue 2. firewall port-knocking (extra http ports interleaved with instant ban ports) 3. ssh over https setup 4. IDS tripwire Morse-code knocking 5. reverse-proxy configuration for trusted zone ingress This approach helps solve several issues: i. distributed firewall probes or nuisance traffic ii. brute force attempts or nuisance traffic iii. obscures security posture identification (what got an IP blacklisted might have occurred several minutes ago) Indeed, I also <3 autoexpect for quickly making monotonous tasks feasible. Good luck =)
- dthakur 3y agoI disable password login all my hosts but good to know people do this.
- midasuni 3y agoCan’t do that in some cases. Tacacs for example doesn’t allow for private keys
- vinay_ys 3y agoDon't use that then. Tell that vendor their security posture is bad.
- blueflow 3y agoIts Cisco. They already know that.
- nixgeek 3y agoI’ve worked at more than one place where you SSH into a Linux host (often just for that datacenter) using certificate-based authentication, only to be printed a JIT (just in time) password for TACACS-based usage in that datacenter, and which is only valid for a few minutes. Workarounds are many for network devices it seems!
- alsetmusic 3y agoWait, why aren't we using SSH keys? I just did a search on the page for 'key' and didn't see an explanation for why that's not the best option.
- infotogivenm 3y agoIt’s covered under footnote #1: > First, some vendors make it difficult to associate an SSH key with a user. Then, many vendors do not support certificate-based authentication, making it difficult to scale. Finally, interactions between public-key authentication and finer-grained authorization methods like TACACS+ and Radius are still uncharted territory Keys (with/without certs) are the best route, but not always possible for every situation.
- squeaky-clean 3y agoHonest question, unless it's mandated by your employer, or you don't personally care, why would you ever choose to use a service that doesn't offer that?
- nine_k 3y agoIt may be a box configured and serviced by a vendor, and your org may be short on IT staff.
- daneel_w 3y agoYou may be in a position where you must employ and interact with networked equipment that does not support pubkey authentication.
- wkat4242 3y agoYeah this is why fido2 doesn't work either. Most embedded ssh implementations don't support it.
- tialaramex 3y agoPublic 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"
- dark-star 3y agoThe 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?
- erinnh 3y agoI’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.
- nine_k 3y agoWhat, how about scp and sshfs? I can argue that SSH password auth only makes sense.as in interactive affair; for non-interactive auth cases, there are public keys, certificates, smart cards, etc.
- deleted 3y ago[deleted]
- dark-star 3y agoI totally agree, but sometimes you have no other choice (e.g. devices that only offer password auth), and in that case it is claimed that sspass is bad ("broken by design" according to the passh author) and passh is good. And that's what I'm confused about
- vbernat 3y agoAuthor 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-broken.md https://github.com/clarkwang/passh/blob/master/sshpass-broke....
- rovr138 3y agohttps://github.com/clarkwang/passh/ 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.
- latchkey 3y agoI ran about 30k machines with sshpass and it worked just fine. Easy to script. I don’t understand at all why we need something else here.
- vbernat 3y agoWhat about: this is now somewhat builtin into SSH, so you don't need an additional tool (or more accurately, this additional tool could be far simpler and more robust).
- latchkey 3y agoOk. That is helpful, but ssh server or client? No way I would bother upgrading the server on all those boxes just to get to a point that is already working with sshpass.
- vbernat 3y agoClient. OpenSSH 8.4 has SSH_ASKPASS_REQUIRE that allows one to always invoke SSH_ASKPASS, notably when run from a terminal (previously, it was only invoked when there was no terminal to prompt the password).
- MikePlacid 3y ago> I ran about 30k machines with sshpass and it worked just fine. Easy to script. I don’t understand at all why we need something else here. Do you keep all your passwords in one directory or in something more complicated?
- gg2424 3y ago[flagged]
- Lvl999Noob 3y agoIs this a chatgpt written summary?
- brewedDoritos 3y agoRecently I tried to use an sftp script created with expect that ran fine on the command line, but the same script failed to run under cron. I made sure that all environment variables were properly set, but sftp didn't ask me for a password. I think it might have been an issue with the absence of a tty sshpass didn't work, ended up rewriting the whole thing in Paramiko ... only to find out it doesn't respect the http_proxy environment variable. That was not a good day
- rubicks 3y agoWorking with less-than-stellar tools --- ahem ROS --- has taught me how to placate commands that assume interactivity and/or a tty. To wrap up the offending command with a "fake" `tty`, I do script -qfec "mycommand" /dev/null If the thing insists on interactive input, then I break out the big guns: https://manpages.debian.org/bookworm/expect/expect.1.en.html https://manpages.debian.org/bookworm/expect/expect.1.en.html
- brewedDoritos 3y agoI've actually tried script and expect, but they didn't work. I had enabled the debug option on expect and I couldn't see the password prompt when the program ran under cron (i was redirecting the script output to a log file). It did appear when running on the prompt though. I couldn't figure how the sftp program was determining that it was running under cron. I suspect that it was inspecting if stdin was connected to a terminal or not, but I gave up around 4 am.
- MobiusHorizons 3y agoStrace is your friend in such circumstances.
- noAnswer 3y agoThe other month I had to wrap a commercial server program with 'screen'. 'script' wasn't enough. If you would run it in the background "./program &" and then exited ssh it would also exit. It wouldn't run with cron until: export TERM=vt100 script -c "screen /foo/bar/program" /dev/null All the program did on the console was print to stdout. How are you even program shit like this!?
- adontz 3y agoI believe privileged access management is the proper way to manage access to a password protected systems. It is basically a terminal server, proxy, bastion or anything similar. You log in there with federated identity (for example AD) and it logs you in into target system with some shared or temporary user. Usually it also records session and does other security/compliance related things. Examples are Delinea (former Thycotic), CyberArk, To some extent Apache Guacamole can be used as PAM.
- steve1977 3y agoWhy not use something like Kerberos (for example) and have the proper identity also on the system where you log in to via SSH?
- adontz 3y agoKerberos is a) relatively complex to set up properly if its not a Windows in AD b) an SSO, not federated ID. Which means reasking MFA is not possible.
- josephcsible 3y ago> reasking MFA is not possible Isn't reasking MFA on purpose just a way to make people hate MFA? Shouldn't everything support a "Trust this device" option and then never ask again from it?
- adontz 3y agoI'd rather reask credentials before elevating effective access level. Just like sudo reasks password. I don't mean reasking MFA to access corporate intranet website with a blog no one reads, I mean reasking for administrative access.
- gnufx 3y agoIf you want a session with extra permissions you use an appropriate Kerberos principal, e.g. admin/...
- generalizations 3y agoWhat bit me recently was trying to set up non interactive password protected ssh keys. (The use case is wrapping the ssh functionality inside another program.) Turns out, if you want to script the use of an ssh key that requires a decryption password, you can’t do it without ssh-agent (which isn’t really the best solution for a multi user program).
- jamespwilliams 3y agoSomething like https://matrixzj.github.io/documentations/idm_decrypt_ssh_private_key_with_openssl.html https://matrixzj.github.io/documentations/idm_decrypt_ssh_pr... (then ssh -i decrypted_key) should work and avoid ssh-agent
- generalizations 3y agoThanks for the link. It's ironic that in the name of security, that solution is probably one of the best available. SSH is so protected against footguns that legitimate use cases are forced to use demonstrably worse security practices, just because some people might shoot themselves in the foot. I'm stuck with either that option, expect, or a total misuse of ssh-agent.
- jamespwilliams 3y agoDepending on your use case it might be better to just store the key unencrypted. There’s not really much point encrypting it if you’re storing the passphrase on disk alongside the key anyway.
- gnufx 3y agoRight (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).
- gnufx 3y agoPassword authentication for SSH is often paired with OTP (by people who think that it's somehow more secure to force me to store two lots of credentials for convenience or non-interactive use than keys, and won't do Kerberos or certificate authN). There's a version of sshpass supporting that: https://github.com/dora38/sshpass https://github.com/dora38/sshpass
- throwaway892238 3y agoWrapping SSH requires handling a lot of different exceptions. If you want to avoid bugs and errors, find someone else's library for handling SSH that deals with things like host key prompts, changed fingerprints, filesystem permissions, connection errors and reconnects. If you're running commands, some may need things like proper PTY handling.
- mrstone78 3y agoI am looking into how to automate the totp authentication with SSH. Would an approach similar to this work?
- unixhero 3y agoGreat thread. Many insightful perspectives on AAA here
- qweqwe14 3y agoIn Dropbear SSH client, you can provide the password with DROPBEAR_PASSWORD environment variable
- Inetgate 3y agoIt's interesting. So, I wonder the difference between this method and expect command?