Uso de OpenSSH Server sin usuario local

Actualmente he notado que cuando uso el servidor OpenSSH con PAM y, por ejemplo, RADIUS, aunque puedo hacer que el usuario se autentique correctamente con PAM, todavía necesito una cuenta de usuario local en / etc / passwd, por ejemplo, agregada con useradd en la caja.

¿Hay alguna configuración en OpenSSH para decir que no es necesario que un usuario local sea / etc / passwd? ¿Y en cambio, la shell / home dir / sesión se inicializará a través de alguna configuración predeterminada? No he podido encontrar ninguna forma de hacer esto en línea.

— David Mokon Bond
fuente

La configuración /etc/nsswitch.confestablece el orden en que se buscarán los usuarios. Puede consultar getent passwd $USERcómo se resuelve su usuario. No es necesario que un usuario tenga una cuenta local para iniciar sesión. Enlace las bases de datos passwdy a ldap, nis y / o sss y use el módulo PAM adecuado en la pila.group/etc/nsswitch.conf

Un caso de uso usando SSSD y FreeIPA , donde los usuarios, grupos, cáscara de inicio de sesión, reglas sudo, las asignaciones de SELinux, etc, se almacenan en el directorio gestionado por FreeIPA. Tenga en cuenta que SSHD usa GSSAPI para autenticarse contra kerberos, cuya base de datos también se almacena en el directorio:


 # cat /etc/krb5.conf
 [logging]
  default = FILE:/var/log/krb5libs.log
  kdc = FILE:/var/log/krb5kdc.log
  admin_server = FILE:/var/log/kadmind.log
 [libdefaults]
  default_realm = DOMAIN.COM
  dns_lookup_realm = false
  dns_lookup_kdc = true
  rdns = false
  ticket_lifetime = 24h
  forwardable = yes
 [realms]
  DOMAIN.COM = {
   kdc = ipaserver.domain.com:88
   master_kdc = ipaserver.domain.com:88
   admin_server = ipaserver.domain.com:749
   default_domain = domain.com
   pkinit_anchors = FILE:/etc/ipa/ca.crt
 }
 [domain_realm]
  .crapsteak.org = DOMAIN.COM
  crapsteak.org = DOMAIN.COM
 [dbmodules]
   DOMAIN.COM = {
     db_library = ipadb.so
   }

# 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/domain.com]
 cache_credentials = True
 krb5_store_password_if_offline = True
 ipa_domain = domain.com
 id_provider = ipa
 auth_provider = ipa
 access_provider = ipa
 ipa_hostname = somehost.domain.com
 chpass_provider = ipa
 ipa_server = ipaserver.domain.com
 ldap_tls_cacert = /etc/ipa/ca.crt
 [sssd]
 services = nss, pam, ssh
 config_file_version = 2
 domains = domain.com

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

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

— Dawud
fuente

Gracias, eso ayuda mucho, pero en mi caso realmente no me importa el usuario home / shell por usuario. Todos los usuarios pueden usar el mismo hogar y todos usarán el mismo shell. Tengo curiosidad si tiene una sugerencia sobre la base de datos correcta para usar en un caso como ese. No quiero tener la carga de que el usuario tenga que configurar y agregar todos los usuarios a un servidor ldap, etc. ¿Alguna sugerencia?

— David Mokon Bond

Realmente no tienes que hacerlo. Defina un shell predeterminado (y, además, una asignación de usuario SELinux predeterminada, un grupo predeterminado, etc.) en el esquema proporcionado. El equipo de freeIPA se ha esforzado mucho para proporcionar un esquema muy completo. Alternativamente, hay módulos PAM para casi cualquier cosa que se te ocurra. Es una cuestión de escala, tal vez.

— dawud

Solo un seguimiento parece que pam solo no es suficiente para esto. Esperaba que el uso de pam_radius para auth / account y pam_permit para la sesión funcionara, pero desde el principio parece que sshd todavía llama con nsswitch.conf. Si bien sssd y freeipa parecen agradables en mi caso de uso, serán demasiado pesados. No puedo requerir que alguien tenga un servidor que los ejecute. Hasta ahora parece que la mejor solución es implementar un módulo nss que funcione para passwd devolviendo una cadena predeterminada / etc / passwd sin importar a quién se llame. ¿Se te ocurre alguna otra opción de peso ligero mejor?

— David Mokon Bond

Según algunas búsquedas rápidas, parece que todo el mundo se queja de que falta libnss_radius además de glibc para poder agregar el servicio al nsswitch. Me temo que la opción ligera sería un backend de Protocolo ligero de acceso a directorios para su servidor Radius.

— dawud