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

41–50 of 128 posts

Re: Non-interactive SSH password authentication

#41

Post by bnny »

RedShift1 wrote: post #32
vbernat wrote: post #21

Earlier quoted context omitted.

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.

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.

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

Re: Non-interactive SSH password authentication

#42

Post by generalizations »

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

Re: Non-interactive SSH password authentication

#43

Post by MikePlacid »

latchkey wrote: post #20

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.

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

Re: Non-interactive SSH password authentication

#44

Post by vbernat »

bnny wrote: post #41
RedShift1 wrote: post #32

Earlier quoted context omitted.

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.

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

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.

Re: Non-interactive SSH password authentication

#45

Post by adontz »

steve1977 wrote: post #35
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…

Why not use something like Kerberos (for example) and have the proper identity also on the system where you log in to via SSH?

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.

Re: Non-interactive SSH password authentication

#46

Post by rubicks »

dtgriscom wrote: post #2

Seems overly complicated; sshpass works fine for me. (And the passh examples of why sshpass is broken seem contrived to me.)

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.

Re: Non-interactive SSH password authentication

#47

Post by rovr138 »

vbernat wrote: post #22
dark-star wrote: post #13

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

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.

Re: Non-interactive SSH password authentication

#48

Post by latchkey »

MikePlacid wrote: post #43
latchkey wrote: post #20

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.

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

  User: user
  Pass: 1
Lol

Re: Non-interactive SSH password authentication

#49

Post by josephcsible »

adontz wrote: post #45
steve1977 wrote: post #35

Earlier quoted context omitted.

Why not use something like Kerberos (for example) and have the proper identity also on the system where you log in to via SSH?

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.

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

Re: Non-interactive SSH password authentication

#50

Post by rubicks »

brewedDoritos wrote: post #26

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

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