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 an LDAP interface by changing the startup command
$ stns --protocol ldap
STNS can read configuration files from s3
$ stns --config s3://bucketname/config.toml
This theme is a fork of Solo.