KeePassRPC port issue on terminal servers

[wschlich]

Hi,

when using KeePass with KeePassRPC on a terminal server with multiple users, it's quite a hassle to change the KeePassRPC port for every user in:

• KeePass config (or KeePassRPC plugin options dialog)
• Firefox Kee Plugin
• Chrome Kee Plugin

By default (using KeePassRPC Port 12546), user A (with KeePass opened) could get quickly irritated and annoyed by "authorise a new connection" popups triggered repeatedly by user B (with browser and Kee Plugin opened).

Normally, I'd suggest choosing a random port from a port range (for example 29170-29998) on the first KeePassRPC startup, but I believe there's no easy way for the Kee browser plugin to get to know this user specific port automatically, right?

Cheers,
Wolfram

[thespooler]

This is indeed a problem and not only for terminal servers. Fast user switching exhibits the same behaviour.
For example, on a computer with multiple users. When the first user logs-in, start FFox and KP (thus KPRPC), then switches to another account without closing KP, FireFox and signing-out, on the second account, FFox KPRPC will keep trying to establish a connection with the KP in the first session, prompting user action in the first session. Conversely, if KP is closed in the 1st session, but FFox is still loaded, KP in the second session will keep prompting for access, never succeeding.
Perhaps something like Native messaging and per-user Native_manifests?

[kohtala]

Native messaging looks nice. It requires some more setup and preferably an installer, which would not be so bad anyway, because the KeePass plugin install manually is anyway rather difficult.

If I understood right, it requires an executable the browser will launch and communicate with through stdin/stdout. This executable needs to find the per session KeePass.

On Windows KeePassRPC plugin could expose endpoint named after the Logon SID. Unfortunately I do not think the browser plugin has direct access to Logon SID, so the native client is needed. The endpoint could be via Named Pipe (or RPC). The KeePassRPC should protect the named pipe using Logon SID in ACL and maybe also deny access to NT AUTHORITY\NETWORK to further enforce no remote access. I don't think any of this reduces the need for each end to authenticate the other end of the link.

[luckyrat]

As already mentioned, I don't think there is any way to avoid these limitations of TCP port communications so a switch to using native messaging may be the only possible way forward (even then, I don't know enough about terminal servers to be certain it would solve all the configuration challenges).

A switch to using native messaging is already being tracked in the browser addon repo - kee-org/browser-addon#23 . Although changes to the KeePassRPC plugin are likely required, I think it will be the needs of the browser extension that will drive the development and determine what we need to do here. I'll keep this issue open as a reminder to consider the information you've all supplied when I next investigate the feasibility of using native messaging in Kee but note that in future, using the community forum will likely result in a faster response (I've just added a GitHub issue template to make that clearer for people arriving at this repo from routes that don't already mention that).