Open jl-sitnrw opened 8 months ago
Two things stand out - first:
Python-dotenv could not parse statement starting at line 13
Looks like there's a .env file in your folder with something in it. Not sure if that's distracting the configuration. Second:
MainProcess: MainThread: 1707913123: /run_pool/print_banner/dprint: proxy:username =
...
MainProcess: Thread_0: 1707913133: /do_curl/set_curl_auth/dprint: SSPI not available and no username configured - no auth
Looks like you have no username configured for px to use for kerberos auth. Can you share what your config looks like without any personal info?
I saw that too, couldn't find anything wrong. I never did set the username as I use Kerberos only. NTLM isn't allowed.
As far as I know ,SSPI is windows only. On linux GSSAPI should be used.
❯ curl -V
curl 8.5.0 (x86_64-pc-linux-gnu) libcurl/8.5.0 OpenSSL/3.2.0 zlib/1.3 brotli/1.1.0 zstd/1.5.5 libidn2/2.3.4 libpsl/0.21.2 (+libidn2/2.3.4) libssh2/1.11.0 nghttp2/1.58.0
Release-Date: 2023-12-06
Protocols: dict file ftp ftps gopher gophers http https imap imaps mqtt pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: alt-svc AsynchDNS brotli GSS-API HSTS HTTP2 HTTPS-proxy IDN IPv6 Kerberos Largefile libz NTLM PSL SPNEGO SSL threadsafe TLS-SRP UnixSockets zstd
My config:
❯ grep -Ev "^;" /home/username/.px.ini
[proxy]
server = proxy.ad.company.de:8080
port = 3128
gateway = 0
hostonly = 0
allow = *.*.*.*
noproxy = 127.0.0.1, 192.168.122.*, 192.168.102.*, 10.10.10.21, test.ad.company.de
auth = NEGOTIATE
[settings]
workers = 4
threads = 50
idle = 600
socktimeout = 20.0
proxyreload = 60
foreground = 1
log = 4
I found it in handler.py. I'll send a MR, it's an easy fix.
Thanks for the PR though we need to make it a bit smarter to detect if GSSAPI is available via curl.
MainProcess: MainThread: 1707913123: /__init__/print_curl_version/dprint: CURL_VERSION_SSPI: False
MainProcess: MainThread: 1707913123: /__init__/print_curl_version/dprint: CURL_VERSION_SPNEGO: True
MainProcess: MainThread: 1707913123: /__init__/print_curl_version/dprint: CURL_VERSION_GSSAPI: True
MainProcess: MainThread: 1707913123: /__init__/print_curl_version/dprint: CURL_VERSION_GSSNEGOTIATE: False
MainProcess: MainThread: 1707913123: /__init__/print_curl_version/dprint: CURL_VERSION_KERBEROS5: True
MainProcess: MainThread: 1707913123: /__init__/print_curl_version/dprint: CURL_VERSION_NTLM: True
MainProcess: MainThread: 1707913123: /__init__/print_curl_version/dprint: CURL_VERSION_NTLM_WB: False
I test px on several setups and GSSAPI is not available on many of them. Same applies on Windows too - it should check for SSPI before setting username to :
. I need to see which values from the above values are needed for auth to work - also wonder if there's a way to detect if NTLM/Kerberos is actually setup with a username/password or just generally available. On Windows, I presume SSPI is always available since you log in but not as informed on Kerberos on Linux.
Meanwhile, I am also working on migrating px to use mcurl which was extracted out of this project and made standalone. I made sure those binaries include GSSAPI so we can be assured that it will always be available once we move. Just need additional changes to check for availability.
Just by the way, similar issues on Windows: @genotrance , are you aware of https://github.com/curl/curl/issues/13056?
currently, it needs a manual update of curl for Windows in px-0.9.2 in order to get SSPI, Kerberos and SPNEGO working again on Windows platform - so please definitely update curl for Windows with the next px release...
thx a million! 😃
oops, sorry - turns out I completely missed the 0.9.2 release so far... 😞
so everything should be fine again for Windows as wrt this comment...
Can someone please help me to find some documentation on how this HTTP server principal is created for keytab I guess I am still missing that bit
oops, sorry - turns out I completely missed the 0.9.2 release so far... 😞
so everything should be fine again for Windows as wrt this comment...
Yes - this was fixed in https://github.com/genotrance/px/issues/212.
I test px on several setups and GSSAPI is not available on many of them. Same applies on Windows too - it should check for SSPI before setting username to
:
. I need to see which values from the above values are needed for auth to work - also wonder if there's a way to detect if NTLM/Kerberos is actually setup with a username/password or just generally available. On Windows, I presume SSPI is always available since you log in but not as informed on Kerberos on Linux.
I have to object partially here. SSPI Is available, but you do not have a Kerberos Ticket/Login if you're not in a Windows Domain. Curl still will have "CURL_VERSION_SSPI" set to "True", because it is build with support for it. According to Documentation:
--negotiate
(HTTP) Enables Negotiate (SPNEGO) authentication.
This option requires a library built with GSS-API or SSPI support. Use -V, --version to see if your curl supports GSS-API/SSPI or SPNEGO.
Either of GSS-API or SSPI is fine.
To detect if there is a TGT and an Available serviceprincipal for "HTTP/proxyname@DOMAIN" without an additional lib would be hard if possible at all. I didn't deep dive, but I think curl just tries to get the Token for the service from os and fails to auth, if it doesn't get it.
I'll use the libcurl docs to cover all relevant scenarios. Looks like we need to check GSS-API, NTLM, SPNEGO and SSPI. Checking for username is not required since libcurl will automatically use current credentials. If it fails, we will need to detect the failure from libcurl and log that.
If user does not provide a username, we will attempt single sign-on if it is possible via libcurl. Else user will have to provide both username and password.
Hello,
First thanks for this amazing project, i use it on a daily bases.
Hello,
The Version 0.9.0 doesn't work for me anymore. px doesn't Authenticate with Kerberos anymore. I'm on an Arch Linux with python 3.11.6 for px. PX has it's own venv
The curl for the request with http_proxy set to localhost:3128
The curl with 0.8.4 same config:
Curl itself works with this setting if the company Proxy is set via http_proxy
I don't know where to look.
Any Ideas