Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I'm trying to write a PAM module which will on login will compare the username provided against a list of "virtual" user names. If the username provided is a "virtual user" it will complete the authentication, then change the username to some real local user and proceed with the login process.

In trying to do this I've noticed that it's not possible (at least not by default) to change the username under OpenSSH - you're stuck with the one you provide in your first authentication attempt, and you can't use PAM's username-switching functionality to change it.

Is there a way of enabling this? (Modifying OpenSSH code is also a valid option, but surely not a preferred one.)

share|improve this question
2  
Why in the name of everything unholy do you want to do such a thing? No offense, but it seems like an absolutely AWFUL idea, just begging for major security holes... –  voretaq7 May 5 '12 at 22:40
    
@voretaq7 Thanks, I agree this is a bad idea. I Edited my question to clarify what exactly are my needs. I need to switch the username from the one that was inserted by the user to a different one which is also a local account. Meaning - for this issue - i'd create a user named External or Guest for these inputs. Thanks again. –  mseren May 6 '12 at 8:18
    
Much better question with the extra info (I cleaned it up a bit, feel free to revert if you think I botched it). Now that I'm sure you're not trying to do something that would require you to be placed in a nuthouse I even gave you an answer :-) –  voretaq7 May 7 '12 at 5:10
    
@voretaq7 Hi, and sorry for the late response - did not notice that i had new replies. Thanks for the answer, however... it still not is my exact use case. My problem is this: the input should not be an existing user, it should be a user that exists in a remote system and its existence is verified in a pam module. If the user is verified, it has to be changed into External/Guest, since it does not exist in the system and cannot log in. –  mseren May 24 '12 at 8:30
    
that's a substantially different use case than what everyone has assumed you're describing. You may want to try asking a new question, and including all of the relevant information about what you're trying to accomplish (like what kind of external system you're integrating with). The more you tell us the less time we all waste taking guesses that don't match your use case :) –  voretaq7 May 24 '12 at 19:45

3 Answers 3

You don't want to do this.

Bite the bullet, create the users, and give them sudo access.

share|improve this answer

You're trying to solve a problem with a scalpel, but what you need is a big rock. Consider:

Unix usernames are mapped to numeric User IDs.
This is a many to many mapping with no restrictions.
So nothing is stopping you from creating a bunch of accounts (guest, external, random and mapping them all to the same numeric User ID, home directory, etc. -- Simply edit your password file and add multiple users with the same numeric User (and Group) ID.

You could even do this for root (UID 0) if you wanted -- In fact *BSD systems typically come with a toor account with UID 0, that has its password locked out and is unable to log in.
(Most sysadmins remove this account, out of a suitable level of paranoia...)

This is a somewhat brutish solution, lacking any level of style or finesse, but simple is often best.

Caveats:

  1. When these users run whoami, or when you look at them in w/who output you'll usually see the first username that appears in the password file for a given numeric UID, but you'll see that anyway with the solutions you described above.
  2. If you use SSH Keys (authorized_keys file) it will map to the home directory of the user. If all your users share one home directory they share one authorized_keys file.
    You can assign the users independent home directories if this is a concern.
  3. Your login records may show the authentication for the username given (rather than mapping to the first user as noted in (1) above), but this is probably a Good Thing as you can see who is logging in to which accounts from where, at least by IP address.
  4. Your users will have independent unix passwords. This is probably what you want, but if it's not you can write some scripts to synchronize them without too much pain and suffering.
share|improve this answer
    
Another caveat will be the owner of all files/folders regardless of which account was used to create them will show as the first username in the passwd file. –  mhost Oct 12 '13 at 19:47

Have you considered installing a wrapper that does the su(1) as the users shell? Make sure you "su -" ....

I am not claiming this is an entirely safe solution, but it also is not an entirely safe problem.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.