If you want the system to create home directory for login user after login in via SSH, add the configuration below into
$ echo 'session required pam_mkhomedir.so skel=/etc/skel/ umask=0022' >> /etc/pam.d/sshd
We often create a special user account whose privilege is restricted for a certain purpose that we deploy application to remote server by the user account. To realize such a way to deploy, we can add real user accounts’ SSH public keys to the user account’s
STNS allows us to easily bundle deploy users using the
[users.deploy] id = 1 group_id = 1 link_users = ["example1","example2"] [users.example1] id = 2 group_id = 1 keys = ["ssh-rsa aaa"] [users.example2] id = 3 group_id = 1 keys = ["ssh-rsa bbb"]
With the configuration above, the users shown as
example2 can login to a server as
deploy user attempts to login to a server via SSH, STNS server returns to STNS client keys for both
ssh-rsa aaa) and
ssh-rsa bbb). That is, the users are linked.
It’s a common requirement to control who can access to a server with respect to organizational structure. Imagine such a case like that we want to give read and write privilege to ones in a division, and, at the same time, we want to add read-only privilege to ones in a department to which the division belong.
STNS meets such a complicated requirement.
[groups.department] users = ["user1"] link_groups = ["division"] [groups.division] users = ["user2"]
In the configuration above,
user1 belongs to
department group and
user2 belongs to
link_group is set to link
department group to
As a result:
user2belongs to both
You can confirm it by executing
id command like below:
$ id user2 uid=1001(user1) gid=1002(division) groups=1001(department),1002(division)
STNS provides two ways to manage password for
You can create a special user account for
sudo like below. It can be considered like a secondary root password.
[sudoers.example] password = "$6$ZbcEUwqLWMcV7fr5$4krw.1ULrmZytoMwuV5.pIqjEo1Ngc9K15zYQ..."
You can use stns-passwd to get such a hashed password.
Configuration for STNS client is needed in turn.
#%PAM-1.0 auth sufficient libpam_stns.so sudo example auth include system-auth account include system-auth password include system-auth session optional pam_keyinit.so revoke session required pam_limits.so
You have to notice the two arguments which follows
libpam_stns.so. The first one is to enable
sudo authorization and the second one is to set the user name for
example user is set at above).
If you configure
/etc/sudoers correctly, you will successfully be authorized by
sudo using the password which is set in
[sodoers.example] section in the STNS server configuration.
You can also set hashed passwords for each users like below:
[users.example] id = 1000 group_id = 1000 directory = "/home/example" password = "$6$ZbcEUwqLWMcV7fr5$4krw.1ULrmZytoMwuV5.pIqjEo1Ngc9K15zYQ..."
Client can be configured as below:
#%PAM-1.0 auth sufficient libpam_stns.so auth include system-auth account include system-auth password include system-auth session optional pam_keyinit.so revoke session required pam_limits.so
You have to notice, at this time, that there’s no arguments which follows
libpam_stns.so. If no arguments set, STNS uses Linux user account and process the authorization using the hashed password set in the server configuration.
In other way, you can use the hashed password for each users set in STNS server configuration for login authentication.
/etc/pam.d/system-auth (RHEL) or
/etc/pam.d/common-auth (Debian Family):
#%PAM-1.0 #%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. auth required pam_env.so auth sufficient libpam_stns.so …
This theme is a fork of Solo.