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

81–90 of 128 posts

Re: Non-interactive SSH password authentication

#81

Post by unixhero »

yetanotherloss wrote: post #67
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…

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 thou…

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

Re: Non-interactive SSH password authentication

#82

Post by noAnswer »

brewedDoritos wrote: post #79
noAnswer wrote: post #73

Earlier quoted context omitted.

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?

No, I haven't tried that.

Re: Non-interactive SSH password authentication

#83

Post by jamespwilliams »

generalizations wrote: post #64
jamespwilliams wrote: post #61

Earlier quoted context omitted.

Something like https://matrixzj.github.io/documentations/idm_decrypt_ssh_pr... (then ssh -i decrypted_key) should work and avoid ssh-agent

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.

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.

Re: Non-interactive SSH password authentication

#84

Post by yetanotherloss »

unixhero wrote: post #81
yetanotherloss wrote: post #67

Earlier quoted context omitted.

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 thou…

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

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.

Re: Non-interactive SSH password authentication

#85

Post by IshKebab »

generalizations wrote: post #66
IshKebab wrote: post #52

Earlier quoted context omitted.

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

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 moder…

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.

Re: Non-interactive SSH password authentication

#86

Post by gnufx »

jamespwilliams wrote: post #61
generalizations wrote: post #42

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

Something like https://matrixzj.github.io/documentations/idm_decrypt_ssh_pr... (then ssh -i decrypted_key) should work and avoid ssh-agent

If you want to remove a passphrase, just use ssh -p.

Re: Non-interactive SSH password authentication

#87

Post by gnufx »

jamespwilliams wrote: post #83
generalizations wrote: post #64

Earlier quoted context omitted.

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.

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.

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

Re: Non-interactive SSH password authentication

#88

Post by gnufx »

vbernat wrote: post #28
latchkey wrote: post #27

Earlier quoted context omitted.

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.

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

That doesn't help with 2FA, though, or on, say, EL8.

Re: Non-interactive SSH password authentication

#89

Post by generalizations »

gnufx wrote: post #87
jamespwilliams wrote: post #83

Earlier quoted context omitted.

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.

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.
Post reply on HN