Bug 2545 - Second authentication to agent causes issues
Summary: Second authentication to agent causes issues
Status: NEW
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: VSM Server (show other bugs)
Version: pre-1.0
Hardware: PC Linux
: P2 Enhancement
Target Milestone: MediumPrio
Assignee: Peter Åstrand
URL:
Keywords:
: 121 1771 (view as bug list)
Depends on:
Blocks: 121
  Show dependency tree / graph
 
Reported: 2007-10-18 08:29 CEST by Pierre Ossman
Modified: 2024-10-31 09:46 CET (History)
3 users (show)

See Also:
Acceptance Criteria:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Description Pierre Ossman cendio 2007-10-18 08:29:21 CEST 
When bug 1283 is solved, we will have reduced our three authentications to just two. It would be nice if we could take the final step and get down to just a single authentication. This has a number of benefits:

- Client doesn't have to cache any information (passphrase, second reply, more things in the future)

- Backend systems that count logins will work. (e.g. grace logins in eDirectory)

- No need for a token caching server when using OTP

- Smart card readers with pin pad won't have to ask for the pin twice.

To solve this we have to make the agent check with the server if the user is authenticated somehow. One solution is to have the vsmserver give the client a temporary password to be used on the agent. The agent could then be set up to talk to a RADIUS server inside vsmagent.
Comment 1 Pierre Ossman cendio 2007-10-18 08:29:46 CEST 
A BSD licensed Python RADIUS server can be found here:

http://www.wiggy.net/code/pyrad/
Comment 2 Pierre Ossman cendio 2007-10-18 08:55:09 CEST 
To clarify, the RADIUS server would be in vsmserver and the client would be pam_radius on the agents.
Comment 3 Pierre Ossman cendio 2011-01-17 16:15:08 CET 
This is causing problems again with OTP setups. Specifically, Nordic Edge has a hack for ThinLinc but it only works for OTP:s generated by their server, not things like OATH (Yubikey). Disabled the OTP caching in the client for this customer so things can work (although they have to enter two OTPs).
Comment 4 Pierre Ossman cendio 2013-07-19 14:45:46 CEST 
Duplicate of bug 1771?
Comment 6 Pierre Ossman cendio 2016-11-01 14:56:43 CET 
Duplicate of bug 121?
Comment 11 Pierre Ossman cendio 2022-03-29 14:26:27 CEST 
*** Bug 121 has been marked as a duplicate of this bug. ***
Comment 12 Pierre Ossman cendio 2022-03-29 14:26:56 CEST 
*** Bug 1771 has been marked as a duplicate of this bug. ***
Comment 15 Pierre Ossman cendio 2022-10-04 09:58:15 CEST 
This also causes problems when using smart cards with pin pads, as we cannot cache the pin there and hide the second input from the user. See bug 3349.
Comment 16 Pierre Ossman cendio 2022-12-09 14:09:25 CET 
Another option could perhaps be to issue a temporary SSH key for the client to use in the second step. There are various restrictions that could be placed on the key, most prominently "expiry-time". We could also use the "AuthorizedKeysCommand" setting if we want to avoid having to manipulate users' authorized_keys files.
Comment 17 Pierre Ossman cendio 2022-12-09 14:16:44 CET 
Actually, you can specify multiple authorized_keys. So we could also solve it by having a second one in some protected directory.
Note You need to log in before you can comment on or make changes to this bug.