[prev in list] [next in list] [prev in thread] [next in thread] 

List:       dante-misc
Subject:    [dante-misc] How to configure Dante to ignore wrong socks user authentication and pass?
From:       Patrick Schleizer <patrick-mailinglists () whonix ! org>
Date:       2022-09-26 12:35:10
Message-ID: 7638c2ec-0c53-591e-e39b-763b4874bc64 () whonix ! org
[Download RAW message or body]

For a local-only use case (Dante running locally and only locally
running applications connecting to it), "socksmethod: none /
clientmethod: none" works great.

However, for 1 application that should use Dante socks:

- The application doesn't attempt to negotiate the socks authentication
method to be "none". (curl is more clever here. Even if curl is supposed
to use a username/password, it won't, even if Dante offers socksmethod
"none".) Additionally, even "socksmethod: none username / clientmethod:
none" won't work since the application will always send a socks user name.

- The application uses many "random" different user names. These are
non-existing Linux user accounts, so PAM will report "invalid user".
Therefore Dante will refuse the connection since authentication failed.

- It's not an option to create these user accounts. The desired result
is that Dante simply accepts the authentication without any checks

- It is difficult (time consuming) to modify the application so I didn't
attempt to.

Instead, I hacked sockd/accesscheck.c Dante source code file.

int
accesscheck(s, auth, src, dst, emsg, emsgsize)
   int s;
   authmethod_t *auth;
   const struct sockaddr_storage *src, *dst;
   char *emsg;
   size_t emsgsize;
{
   int match, authresultisfixed;
   match = 1;

   return match;
}

Now it's working. The application chooses "random" socks user names.
Dante accepts the authentication unconditionally. That is the feature /
behavior / option I am looking for.

Questions:

1) Does Dante have a feature "even if a socks user name is given, ignore
it and just accept everything"?

2) If there isn't, could you add this feature please?

3) Would you merge a patch if provided?

Cheers,
Patrick

[prev in list] [next in list] [prev in thread] [next in thread]