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

101–110 of 128 posts

Re: Non-interactive SSH password authentication

#101

Post by oarmstrong »

Too wrote: post #100
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…

Is there any tool out there that can provide this using short lived ssh certificates?

Hashicorp's Vault works quite nicely. Teleport is another tool I believe handles this but haven't used it personally.

Re: Non-interactive SSH password authentication

#102

Post by IshKebab »

qweqwe14 wrote: post #98
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.…

1) 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 theoretica…

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

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.

Re: Non-interactive SSH password authentication

#103

Post by xorcist »

brewedDoritos wrote: post #93
xorcist wrote: post #92

Earlier quoted context omitted.

Avoid sftp and use rsync instead (much better support for more types of metadata, more robust error handling). Avoid passwords and use keys instead (easier to distribute, easier to generate, lets you lock them down to a single command). The above avoids much unnecessary thinking. If you really have to, there's always sshpass. And ssh -t to allocate a tty even if you are running without one. But this is seldom really…

> Avoid sftp and use rsync instead I should have explored rsync better. I asked chatgpt some use cases and it made seem to be a bad fit because I needed to also delete some files on the destination machine. My prompt fu was probably a bit bad at the time. > Avoid passwords and use keys instead . The vendor only provides password authentication in this case > If you really have to, there's always sshpass. I´ve tried i…

Read the man page instead of spending time on text generating tools. There is a batch mode in sftp which you should use. And sshpass will absolutely solve the lack of a missing tty in sftp. (Missing TERM is only a problem when you have a real tty, which you haven't.)

Then again, don't do this. Use rsync. It is more robust and will avoid other problems in the future. And don't accept that a vendor only supports password-interactive authentication, it is unlikely to be the case, nobody implements their own ssh and every standard implementation of ssh accepts more ways of authentication.

Paramiko is a perfectly workable solution, but it's way more complex and requires more maintenance for your eventual successor. Please don't be that guy.

Re: Non-interactive SSH password authentication

#104

Post by xorcist »

latchkey wrote: post #75
gossamer wrote: post #60

Earlier quoted context omitted.

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.

I've used both puppet and ansible at that scale and it's not only workable, it is a good idea.

Re: Non-interactive SSH password authentication

#105

Post by signal11 »

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…

> privileged access management is the proper way to manage access to a password protected systems

Managing access to privileged systems at scale is hard despite these tools. This isn’t a knock on the tools. It’s a people/risk problem. Eg staying on top of those recorded sessions becomes increasingly difficult over time.

The sustainable way is to work with business and compliance and remove the need for privileged access. It’s doable in many scenarios and leaves a very small “rump” of things that do need privileged access, with all the attendant overhead.

In general, challenging teams to do without privileged access and making it a “last resort” thing is a great idea, depending upon your industry / risk profile.

Re: Non-interactive SSH password authentication

#106

Post by [deleted] »

signal11 wrote: post #105
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…

> privileged access management is the proper way to manage access to a password protected systems Managing access to privileged systems at scale is hard despite these tools. This isn’t a knock on the tools. It’s a people/risk problem. Eg staying on top of those recorded sessions becomes increasingly difficult over time. The sustainable way is to work with business and compliance and remove the need for privileged acc…

[deleted]

Re: Non-interactive SSH password authentication

#107

Post by qweqwe14 »

IshKebab wrote: post #102
qweqwe14 wrote: post #98

Earlier quoted context omitted.

1) 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 theoretica…

1. 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/ 2. Try putting a space in your home directory and let me know how that…

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

Re: Non-interactive SSH password authentication

#108

Post by IshKebab »

qweqwe14 wrote: post #107
IshKebab wrote: post #102

Earlier quoted context omitted.

1. 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/ 2. Try putting a space in your home directory and let me know how that…

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

> anyone with experience in writing shell scripts knows about these things

Who wants to have to be an expert in shell scripts to have to write them? In any case you're still wrong. Experts aren't immune to footguns. Post a complex shell script you've written. Let's see.

> Obviously there will be badly written programs that don't handle paths properly.

Like GNU Make?

> It's absolutely trivial to do

Trivial to do so that it works for you. Absolutely not trivial to do so that it always works.

The types of people who know the difference between those are referred to as "senior" instead of "junior". (Source: I personally parsed /proc entries too without third party libraries and there were plenty of footguns that a junior developer would skip over.)

Re: Non-interactive SSH password authentication

#109

Post by fulafel »

oasisaimlessly wrote: post #99
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…

It was probably checking for a 'controlling terminal' by e.g. opening /dev/tty.

Script and expect provide the program a controlling terminal, using the same pty functionality that tmux and X11/Wayland terminal emulators use.

Re: Non-interactive SSH password authentication

#110

Post by brewedDoritos »

xorcist wrote: post #103
brewedDoritos wrote: post #93

Earlier quoted context omitted.

> Avoid sftp and use rsync instead I should have explored rsync better. I asked chatgpt some use cases and it made seem to be a bad fit because I needed to also delete some files on the destination machine. My prompt fu was probably a bit bad at the time. > Avoid passwords and use keys instead . The vendor only provides password authentication in this case > If you really have to, there's always sshpass. I´ve tried i…

Read the man page instead of spending time on text generating tools. There is a batch mode in sftp which you should use. And sshpass will absolutely solve the lack of a missing tty in sftp. (Missing TERM is only a problem when you have a real tty, which you haven't.) Then again, don't do this. Use rsync. It is more robust and will avoid other problems in the future. And don't accept that a vendor only supports passwo…

Point taken about rsync, but you are assuming incorrectly that I haven't read it and that I haven't tried batch mode, but it still failed to run under cron inside an expect script.

It's not my orgunit that manages the contract with the vendor. I will absolutely use paramiko instead of trying to explain a technical problem to two middle managers in another orgunit to take it up with a non technical person on the vendor side whenever they feel like it when my deadline ends at the end of the year

Post reply on HN