1 of 27

oidc_ssh

Diana Gudu

gudu@kit.edu

2 of 27

Goal

In a federated environment, enable users to ssh to a server

  • using an external authentication system
  • without a priori provisioning of user on the server

2

3 of 27

Goal

In a federated environment, enable users to ssh to a server

  • using an external authentication system PAM module (e.g. OIDC)
  • without a priori provisioning of user on the server

3

4 of 27

Goal

In a federated environment, enable users to ssh to a server

  • using an external authentication system
  • without a priori provisioning of user on the server NSS
    • consistently map remote user to local user
    • provision on successful authentication

4

5 of 27

Main Issue

ssh privilege separation

  • ssh needs user context (uid,gid,...) before authentication starts
  • subsequent changes to user context are ignored by ssh

5

6 of 27

Main Issue

ssh privilege separation

  • ssh needs user context (uid,gid,...) before authentication starts
  • subsequent changes to user context are ignored by ssh

6

A system that can provide the full user context

to ssh before authentication is needed.

7 of 27

Approaches

  • optimistic approach
    • create user before authentication and
    • delete it later if no successful authentication occurred

​

  • pessimistic approach
    • reserve a user before authentication and
    • persist it on successful authentication

7

8 of 27

Approaches

  • optimistic approach
    • create user before authentication and
    • delete it later if no successful authentication occurred

​

  • pessimistic approach
    • reserve a user before authentication and
    • persist it on successful authentication

8

9 of 27

Issues

Both approaches have to address the same issues in practice:

  • reservation management
  • uid handling
  • session tracking

9

10 of 27

Reservation Management

  • create (system local) user context on first contact
  • return the same user context on subsequent contacts

10

11 of 27

Reservation Management

  • create (system local) user context on first contact
  • return the same user context on subsequent contacts

​

Implemented a reservation system

  • reservations
    • are ephemeral representations of the user context that are not persisted
    • expire after a certain timeout if the user did not authenticate successfully
    • are only visible to the ssh authentication system
  • successful authentication => the reservation is persisted and visible system wide

11

12 of 27

UID handling

For reservations, it is necessary to solve the uid problem upfront:

which uids to assign to users

12

13 of 27

UID handling

For reservations, it is necessary to solve the uid problem upfront:

which uids to assign to users

  • mostly subject to policy, but should consider:
    • uniqueness => ensure atomic operations
    • in a certain range / pool for easier management
    • handle uid lifecycle
      • reclaim uids for users that did not authenticate
      • since uids are associated with reservations which might not get fulfilled

13

14 of 27

Session Tracking

Ensure that the persisted user in PAM is consistent with the original user context claimed by ssh.

14

15 of 27

Session Tracking

Ensure that the persisted user in PAM is consistent with the original user context claimed by ssh.

​

  • ssh creates user context (username, uid) upon first contact and creates a reservation
  • PAM has no information of uid, it needs to query the reservation by username
  • between ssh creation and PAM query the reservation might have changed, e.g. (username, id2)
    • pam will persist this new context, and hand over to ssh that still uses the old one

15

16 of 27

Session Tracking

Prone to timing attacks that lead to user "impersonation"

16

alice

ssh: (alice, 1000)

res: (alice, 1000)

17 of 27

Session Tracking

Prone to timing attacks that lead to user "impersonation"

17

alice

bob

ssh: (alice, 1000)

res: (alice, 1000)

res expired

ssh: (bob, 1000)

res: (bob, 1000)

ssh successful, uid 1000

18 of 27

Session Tracking

Prone to timing attacks that lead to user "impersonation"

18

alice

bob

alice

ssh: (alice, 1000)

res: (alice, 1000)

res expired

ssh: (bob, 1000)

ssh successful, uid 1000

ssh: (alice, 1001)

ssh successful, uid 1001

res: (alice, 1001)

res: (bob, 1000)

19 of 27

Session Tracking

Prone to timing attacks that lead to user "impersonation"

19

alice

bob

alice

ssh: (alice, 1000)

res: (alice, 1000)

res expired

ssh: (bob, 1000)

ssh successful, uid 1000

ssh: (alice, 1001)

ssh successful, uid 1001

res: (alice, 1001)

res: (bob, 1000)

ssh successful, uid 1000

20 of 27

Session Tracking

Prone to timing attacks that lead to user "impersonation"

20

alice

bob

alice

ssh: (alice, 1000)

res: (alice, 1000)

res expired

ssh: (bob, 1000)

ssh successful, uid 1000

ssh: (alice, 1001)

ssh successful, uid 1001

res: (alice, 1001)

res: (bob, 1000)

ssh successful, uid 1000

21 of 27

Login Flow

  1. user ssh in with OIDC name, e.g.:

ssh oidcname@oidcprovider@host

  • ssh calls NSS to get user context
  • NSS borrows uid for user
  • NSS creates a reservation for (local user, uid)
  • NSS returns user context to ssh
  • ssh uses PAM to authenticate user (OIDC-specific, prompt & verify token)
  • on PAM auth success, persist reserved user info
  • multiple PAM modules can be chained
  • PAM returns success / fail
  • SSH opens session with user context from step 2

21

SSH

NSS

PAM

1

2

5

6

9

8

7

user

session

10

uid pool

res db

3

4

passwd

22 of 27

Login Flow (marcus version)

  • user ssh in with OIDC name, e.g.:�ssh <user-username>@host
  • ssh calls NSS to get user context
  • NSS checks if user exists
  • If not: NSS creates a temporary reservation for (local temp-user, temp-uid)
  • NSS returns user context to ssh
  • ssh uses PAM to authenticate user (OIDC-specific, prompt & verify token)
  • Verify AccessToken
  • on PAM auth success:
    1. create the user
    2. store mapping
  • Return persistent user
  • PAM returns success / fail�In particular:
  • If permanent user != temporary user:
    • Return a message “user created”
    • SSH will fail
  • If permanent user == temporary user:
    • SSH opens session with user context from step 2

22

SSH

NSS

PAM

1

2

5

6

9

7

8

user

session

10

pool of temp UIDs

3

4

passwd

mapping user-username

pam-username

More here: https://docs.google.com/document/d/1V8I_hxemaKgxW-YT7iNjjL8pnfLqZtwoEcu1BtbaP68/edit

23 of 27

Advantages

Goal reached: secure, on-the-fly user creation without additional registration steps.

  • any authentication mechanism can be plugged in, e.g. OIDC
  • no need to maintain a user mapping DB (remote user -> local user)
  • separate user db:
    • portability
    • no pollution of system db (/etc/passwd) => better integration with configuration management tools
    • shared user db (e.g. in clusters)

23

24 of 27

Username Issue

  • deterministic one-to-one mapping between remote user and local user needed
    • users must know or be able to generate the ssh login name based on their OIDC identity
    • service must be able to map ssh login name to local user without additional (token) info
    • service must be able to verify that token belongs to username
  • technical limitations w.r.t. username length

24

25 of 27

Username Issue

  • deterministic one-to-one mapping between remote user and local user needed
    • users must know or be able to generate the ssh login name based on their OIDC identity
    • service must be able to map ssh login name to local user without additional (token) info
    • service must be able to verify that token belongs to username
  • technical limitations w.r.t. username length

​

  • possible solutions:
    • preferred_username from OP not unique, can be re-assigned, OP-side changes needed
    • hash unique id of user collisions, additional user tool

25

26 of 27

Username Issue

  • deterministic one-to-one mapping between remote user and local user needed
    • users must know or be able to generate the ssh login name based on their OIDC identity
    • service must be able to map ssh login name to local user without additional (token) info
    • service must be able to verify that token belongs to username
  • technical limitations w.r.t. username length

​

  • possible solutions:
    • preferred_username from OP not unique, can be re-assigned, OP-side changes needed
    • hash unique id of user collisions, additional user tool

26

hash (sub + iss) [0:maxlen]

27 of 27

More Issues

  • passing OIDC token through password field in ssh
    • security implications
    • technical limitations (ssh allows max 1K)
  • integration with service-local IdM system
  • group management

27