[HN Gopher] Non-interactive SSH password authentication
___________________________________________________________________
Non-interactive SSH password authentication
Author : jandeboevrie
Score : 193 points
Date : 2023-12-25 12:55 UTC (10 hours ago)
(HTM) web link (vincent.bernat.ch)
(TXT) w3m dump (vincent.bernat.ch)
| dtgriscom wrote:
| Seems overly complicated; sshpass works fine for me. (And the
| passh examples of why sshpass is broken seem contrived to me.)
| flyingcircus3 wrote:
| Overly contrived examples are the hallmark of software zealots.
| I knew to stop reading after "its more correct variant".
| IshKebab wrote:
| Ignoring 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 wrote:
| On 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 wrote:
| I 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.
| rubicks wrote:
| Same. 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 wrote:
| I like the trick of setting the sticky bit to indicate that it's
| taking a second kick at the can.
| yanko wrote:
| Used 'expect' like 20 years ago...
| nulbyte wrote:
| I 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 wrote:
| expect/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 wrote:
| I disable password login all my hosts but good to know people do
| this.
| midasuni wrote:
| Can't do that in some cases. Tacacs for example doesn't allow
| for private keys
| vinay_ys wrote:
| Don't use that then. Tell that vendor their security posture
| is bad.
| blueflow wrote:
| Its Cisco. They already know that.
| nixgeek wrote:
| I'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 wrote:
| Wait, 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 wrote:
| It'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 wrote:
| Honest 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 wrote:
| It may be a box configured and serviced by a vendor, and
| your org may be short on IT staff.
| daneel_w wrote:
| You may be in a position where you must employ and interact
| with networked equipment that does not support pubkey
| authentication.
| wkat4242 wrote:
| Yeah this is why fido2 doesn't work either. Most embedded
| ssh implementations don't support it.
| tialaramex wrote:
| 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"
| wtallis wrote:
| That doesn't mean it's always easy to install and manage
| keys. For example, the author of the passh tool
| recommended by this post somehow managed to come away
| with the impression that OpenWRT's ssh server only
| supports password authentication.
| justsomehnguy wrote:
| Dell PowerConnect 5500 series has a very picular SSH
| implementation, which could be described as 'allow all
| SSH proxy for telnet'
| varenc wrote:
| Another example: Ubiquiti gateway consoles like the UDM-
| Pro. You can install an SSH key but these are erased on
| reboot. So after every reboot I have a script that uses
| the SSH user password to re-install an SSH key but this
| can't be relied upon and I haven't found a way to make an
| SSH key persist.
| tsimionescu wrote:
| That doesn't mean that a device that doesn't offer pub
| key storage is not accessible over SSH.
| vbernat wrote:
| There are not many network vendors. Check the link in the
| first footnote for an example how Cisco, the leader in the
| field, makes it difficult to deploy SSH keys. This is
| getting better. For example, Juniper (another network
| vendor) now supports SSH certificates.
| RedShift1 wrote:
| I have no idea what's going on in the footnote, but
| deploying SSH keys on Cisco equipment is like 3 commands
| (conf t, user x, ssh something something) to deploy
| public keys, not hard at all.
| vbernat wrote:
| Not on IOS XR:
| https://vincent.bernat.ch/en/blog/2020-syncing-ssh-keys-
| iosx.... The commands you mention are for NXOS.
| bnny wrote:
| It's been a few years, but this requires manually
| deploying keys and adding/removing users on all your
| devices. Most use TACACS+ and/or Radius to centrally
| manage users, which don't support keys in that way (or at
| least didn't the last time I worked with them.)
| vbernat wrote:
| There is an implementation with an extension:
| https://github.com/MarcJHuber/event-driven-
| servers/wiki/TACA.... But I don't know if there are any
| supported clients.
|
| Another possibility would be to use CA certificates for
| authentication and only TACACS+ for authorization and
| accounting. Juniper now supports CA certificates. Cisco
| may in 10 years.
| infotogivenm wrote:
| One good example is bringing up equipment that comes out-
| the-box with a default password. This is common on BMCs for
| example, and you have to initially provision things
| somehow.
| dark-star wrote:
| 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?
| erinnh wrote:
| 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.
| nine_k wrote:
| What, 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.
| vbernat wrote:
| 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....
| rovr138 wrote:
| 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.
| bityard wrote:
| You may wish to edit your comment to clarify that the author of
| https://github.com/clarkwang/passh claims sshpass is broken by
| design, not the author of the linked article.
| MikePlacid wrote:
| 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.
| latchkey wrote:
| 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.
| vbernat wrote:
| What 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 wrote:
| Ok. 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 wrote:
| Client. 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).
| latchkey wrote:
| Interesting then! Makes sense. Thanks for the
| explanation.
| gnufx wrote:
| That doesn't help with 2FA, though, or on, say, EL8.
| MikePlacid wrote:
| > 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?
| latchkey wrote:
| User: user Pass: 1
|
| Lol
| gossamer wrote:
| I kinda like the way ansible does it. There is a concept of
| a vault. You put all the passwords in that file and they
| are all encrypted. You use one password when running the
| command or playbook and all of the keys are decrypted as
| needed.
|
| I don't know if that is efficient for 30K machines though.
| latchkey wrote:
| It isnt. I ended up building a small golang binary that
| ran as root and I could hit it with http calls to execute
| whatever I wanted. Built a message queue that would work
| through all the machines for eventual consistency. Worked
| great.
| brewedDoritos wrote:
| Recently 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 wrote:
| Working 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
| brewedDoritos wrote:
| I'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 wrote:
| Strace is your friend in such circumstances.
| noAnswer wrote:
| The 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!?
| brewedDoritos wrote:
| > If you would run it in the background "./program &" and
| then exited ssh it would also exit.
|
| Just wondering... have you tried running it with nohup
| and in the background?
| noAnswer wrote:
| No, I haven't tried that.
| adontz wrote:
| I 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 wrote:
| Why not use something like Kerberos (for example) and have the
| proper identity also on the system where you log in to via SSH?
| adontz wrote:
| Kerberos 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 wrote:
| > 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 wrote:
| I'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 wrote:
| If you want a session with extra permissions you use an
| appropriate Kerberos principal, e.g. admin/...
| mmh0000 wrote:
| Check out FreeIPA (or Red Hat IdM if you like paying for
| things.). It's Kerberos and a few other utilities in a very
| easy to setup package. It also support OTP MFA
|
| https://www.freeipa.org/
|
| https://www.freeipa.org/page/V4/OTP
| gnufx wrote:
| MIT Kerberos supports preauth with OTP, or PKINIT (X.509
| certifies); I don't know what Heimdal currently has.
| FreeIPA has been doing good work past that, on
| integrating FIDO, for instance, and can issue tickets on
| the basis of external identity providers. It certainly
| does more -- like a souped-up AD.
| gnufx wrote:
| I don't see how setting up MIT or Heimdal Kerberos is
| complex compared with AD (which is more than Kerberos);
| they seem easy enough to me. SSO seems to me what you want,
| and Kerberos is the reasonable implementation.
| bityard wrote:
| These are a good idea for large enterprise organizations. We
| are using a product called Securden which offers PAM features.
|
| (But I much prefer keys/certs over passwords where possible.)
| 616c wrote:
| They become a very high value target though and I have learned
| "security software" devs are as fallible as all devs, sometimes
| more.
|
| Thycotic had some vulnerability with a symmetric recovery key a
| few years ago. But comprehensive product like this or roll your
| own this is frequent so I'd rather do keys and certs like
| others suppose
| cmrx64 wrote:
| I fully agree. Essentially, the PAM wraps a pure knowledge-
| based "keys as capabilities" model into a much richer "real
| capabilities" model.
| johann8384 wrote:
| There are multiple proper ways depending on your needs and the
| context. I've used systems like this and I completely agree
| with you for many cases.
| pphysch wrote:
| If using OpenSSH, you can roll your own solution by setting
| AuthorizedKeysCommand to curl a secure internal auth server.
| yetanotherloss wrote:
| I've been moving away from this model towards user-asssociated
| VPNs or (inverse) captive portals.
|
| Used Powerbroker and cyberark for a long time and while they're
| good at stated purpose the integration with more flexible and
| modern auth systems has had a lot of friction.
|
| The particular regulatory area I work in is also just a non-
| starter for federated AAA from outside the regulated systems
| which colors my opinion though.
|
| Combined with command restrictions in openssh and sudo etc you
| end up with several wholly disjoint attack surfaces, decent
| logging, and granular user restrictions.
| unixhero wrote:
| >I've been moving away from this model towards user-
| asssociated VPNs or (inverse) captive portals.
|
| Would you care to share how you achieve this/what does the
| implementation of these two look like?
| yetanotherloss wrote:
| The terminology varies by vendors but essentially there are
| authentication portals that users will log into and receive
| auth tickets. These are forwarded to network gateways,
| usually encrypted in a vpn tunnel, that allow traffic based
| on user RBAC, sometimes region or time, etc.
|
| Captive portals are web auth pages for use cases the more
| structured method doesn't work for. They were envisioned as
| making you sign in hotel wifi and such but work in the
| other direction as well by forcing a web user login before
| allowing traffic from a host for some period of time.
| oneplane wrote:
| PAM does not preclude having everything secure instead of some
| sort of 'hardened' bastion and 'soft' destination.
|
| Everything should be 'hardened'. This also means everything has
| to do proper authentication and authorisation, and skipping
| that step by letting some proxy do that just creates a
| bottleneck in security, reliability, availability, and
| performance.
|
| It also doesn't really matter how it's done, a Kerberos Ticket,
| x509 client certificate, JWT or multiple credentials (i.e.
| username with a password and MFA token) are all plenty valid.
| Granted, a ticket, certificate or token allows shipping claims
| or attributes allows for directory-less access control, but
| that doesn't mean that having to do directory lookups is not
| feasible anymore.
|
| Most of the other things like f5, pa, Citrix, powerbroker and
| bomgar are just really shoddy software that you setup to
| attempt to not have to bear responsibility or know what you're
| doing (or it's clipboard/checklist-based security...), but that
| just bypasses fulfilling the actual need of a good IAM and PAM
| implementation. None of those products do it better than what
| is natively supported, and they are consistently more
| problematic (be it performance, cost or actual security).
| generalizations wrote:
| What 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 wrote:
| Something like
| https://matrixzj.github.io/documentations/idm_decrypt_ssh_pr...
| (then ssh -i decrypted_key) should work and avoid ssh-agent
| generalizations wrote:
| Thanks 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 wrote:
| Depending 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 wrote:
| 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).
| gnufx wrote:
| If you want to remove a passphrase, just use ssh -p.
| gnufx wrote:
| Password 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
| throwaway892238 wrote:
| Wrapping 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 wrote:
| I am looking into how to automate the totp authentication with
| SSH. Would an approach similar to this work?
| unixhero wrote:
| Great thread. Many insightful perspectives on AAA here
___________________________________________________________________
(page generated 2023-12-25 23:00 UTC)