Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Currently I've noticed when I use the OpenSSH Server with PAM and for instance RADIUS while I can get the user to authenticate successfully with PAM, I still need a local user account in /etc/passwd, e.g. added with useradd on the box.

Is there any setting in OpenSSH to say there does not need to be a local user is /etc/passwd. And instead the shell/home dir/session will be initialized through some default setting? I have been unable to locate any way to do this online.

share|improve this question
up vote 2 down vote accepted

The configuration in /etc/nsswitch.conf sets the order in which users will be looked up. You can check with getent passwd $USER how your user is resolved. There is no need for a user to have a local account in order to login. Bind the passwd and group databases in /etc/nsswitch.conf to ldap, nis and/or sss and use the proper PAM module in the stack.

A use case using SSSD and freeIPA, where users, groups, login shell, sudo rules, SELinux mappings, etc, are stored in the directory managed by freeIPA. Note that SSHD uses GSSAPI to authenticate against kerberos, whose database is stored in the directory as well:

 # cat /etc/krb5.conf
  default = FILE:/var/log/krb5libs.log
  kdc = FILE:/var/log/krb5kdc.log
  admin_server = FILE:/var/log/kadmind.log
  default_realm = DOMAIN.COM
  dns_lookup_realm = false
  dns_lookup_kdc = true
  rdns = false
  ticket_lifetime = 24h
  forwardable = yes
   kdc =
   master_kdc =
   admin_server =
   default_domain =
   pkinit_anchors = FILE:/etc/ipa/ca.crt
 [domain_realm] = DOMAIN.COM = DOMAIN.COM
     db_library =

# grep sss /etc/nsswitch.conf passwd: files sss shadow: files sss group: files sss services: files sss netgroup: files sss automount: files sss

# cat /etc/sssd/sssd.conf [domain/] cache_credentials = True krb5_store_password_if_offline = True ipa_domain = id_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = chpass_provider = ipa ipa_server = ldap_tls_cacert = /etc/ipa/ca.crt [sssd] services = nss, pam, ssh config_file_version = 2 domains =

# grep sss /etc/pam.d/{password,system}-auth-ac /etc/pam.d/password-auth-ac:auth sufficient use_first_pass /etc/pam.d/password-auth-ac:account [default=bad success=ok user_unknown=ignore] /etc/pam.d/password-auth-ac:password sufficient use_authtok /etc/pam.d/password-auth-ac:session optional /etc/pam.d/system-auth-ac:auth sufficient use_first_pass /etc/pam.d/system-auth-ac:account [default=bad success=ok user_unknown=ignore] /etc/pam.d/system-auth-ac:password sufficient use_authtok /etc/pam.d/system-auth-ac:session optional

# grep GSS /etc/ssh/sshd_config GSSAPICleanupCredentials yes GSSAPIAuthentication yes

share|improve this answer
Thanks that helps a lot but in my case I really don't care about the user home/shell on a per user basis. All user can use the same home and they will all use the same shell. I'm curious if you have a suggestion on the correct database to use in a case like that. I don't want to have the burden of the user having to setup and add all the users to an ldap server etc... Any suggestions? – David Mokon Bond Apr 8 '13 at 18:18
You don't really have to. You define a default shell (and additionally a default SELinux user mapping, default group, etc...) in the provided schema. The freeIPA team has gone to great lenghts to provide a very comprenhensive schema. Alternatively, there are PAM modules for almost anything you can think of. It is a matter of scale, maybe. – dawud Apr 8 '13 at 18:27
thanks for the help – David Mokon Bond Apr 8 '13 at 18:30
Just a follow up it seems pam alone isn't sufficient for this. I was hoping that using pam_radius for auth/account and pam_permit for session would work but from the strace it looks like sshd still calls with nsswitch.conf. While sssd and freeipa seem nice in my use case they will be too heavy handed. I can't require someone to have a server running those. So far it seems the best solution is to implement a nss module that works for passwd by returning a default /etc/passwd string no matter who is called. Can you think of any other better light weight option? – David Mokon Bond Apr 8 '13 at 20:16
From some quick searchs, it looks like everybody complains of a missing libnss_radius addition to glibc to be able to add the service to the nsswitch. The lighweight option would be a Lightweight Directory Access Protocol backend for your Radius server, I'm afraid. – dawud Apr 8 '13 at 20:29

Your Answer


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.