Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Non-interactive SSH password authentication

vincent.bernat.ch

Post reply on HN
Print view View original

71–80 of 128 posts

Re: Non-interactive SSH password authentication

#71

Post by gnufx »

adontz wrote: post #53
josephcsible wrote: post #49

Earlier quoted context omitted.

> 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?

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.

If you want a session with extra permissions you use an appropriate Kerberos principal, e.g. admin/...

Re: Non-interactive SSH password authentication

#72

Post by gnufx »

mmh0000 wrote: post #51
adontz wrote: post #45

Earlier quoted context omitted.

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.

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

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.

Re: Non-interactive SSH password authentication

#73

Post by noAnswer »

brewedDoritos wrote: post #54
rubicks wrote: post #50

Earlier quoted context omitted.

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

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…

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!?

Re: Non-interactive SSH password authentication

#74

Post by throwaway892238 »

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.

Re: Non-interactive SSH password authentication

#75

Post by latchkey »

gossamer wrote: post #60
latchkey wrote: post #48

Earlier quoted context omitted.

User: user Pass: 1 Lol

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.

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.

Re: Non-interactive SSH password authentication

#77

Post by varenc »

wtallis wrote: post #59
tialaramex wrote: post #57

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"

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.

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.

Re: Non-interactive SSH password authentication

#79

Post by brewedDoritos »

noAnswer wrote: post #73
brewedDoritos wrote: post #54

Earlier quoted context omitted.

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…

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!?

> 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?

Re: Non-interactive SSH password authentication

#80

Post by oneplane »

adontz wrote: post #30

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 (forme…

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).

Post reply on HN