samuong / alpaca

A local HTTP proxy for command-line tools. Supports PAC scripts and NTLM authentication.
Apache License 2.0
184 stars 31 forks source link

Running alpaca non-interactively? #67

Closed carlosaya closed 3 years ago

carlosaya commented 3 years ago

Hi, sorry if I have missed something, but is there a recommended way to store credentials and then run alpaca non-interactively - preferably at start up? Thanks.

samuong commented 3 years ago

If you're running macOS, you have NoMAD installed, and have it configured to store your AD credentials in the System Keyring, Alpaca will use that. If you're also using Homebrew you can also use brew services to start Alpaca when you log in. See the README for instructions on how to set this up.

Unfortunately for anyone not using macOS and NoMAD, there is no way to store credentials and run non-interactively. This has been in the back of my mind for a while now, but I haven't yet found the time to fix it.

samuong commented 3 years ago

The easiest way to fix this is probably to have Alpaca read the credentials from an environment variable. For example, ALPACA_NTLM_CREDENTIALS could be set to user@domain:password or user@domain:hash. In the latter case, the hash could be generated via a call to alpaca -H (similar to cntlm -H). This wouldn't be particularly secure, but could help avoid someone nearby reading the password off of your screen.

carlosaya commented 3 years ago

Thanks for the quick response. I am actually running Windows with WSL2 inside Parallels on macOS. I have installed this on the Mac, however, I cannot access it from Windows or WSL2 since it is bound to 127.0.0.1. Is there by any chance an undocumented switch to bind alpaca to a specific interface or just 0.0.0.0 so that I can access it remotely? Thanks again.

camh- commented 3 years ago

Windows, Linux AND Mac. oh my :)

Alpaca explicitly does not listen on an external interface because it has your credentials and it would turn your machine into an open proxy through the authenticating proxy - the sort of thing that may get people fired from organisations that feel the need to deploy authenticating proxies.

That said, maybe it would be acceptable to have a flag that allows you to specify a different bind address, which if used carefully (perhaps with a firewall blocking external non-vm traffic from reaching it) that would be safe enough.

In the mean time, you may be able to set up an ssh tunnel or similar from the windows VM through to the mac OS host so that alpaca running on the mac can be reached from inside the VM.

samuong commented 3 years ago

This should be fixed by #70, which will be part of the next release.

I'm not sure that it's a good idea to add a flag to let you bind to a different address. I doubt many people will go to the trouble of setting up a local firewall if they don't already have one, and it would be just as easy to just run another instance of Alpaca in the VM with credentials in the environment.

@carlosaya if this doesn't work for your use case, please reopen this issue?