userify/shim

The Userify Shim (cloud agent)

Userify Shim

Userify SSH Key Manager

The Userify shim creates users, manages sudo permissions, etc based on the user accounts that you've configured in the Userify web console or through the API. It wakes up once every ten seconds or so, checks for things to do, and goes back to sleep.

The shim is designed to be lightweight and easy to integrate and customize into Terraform, Ansible, Cloud Formation, Chef, Puppet, etc via the Userify dashboard, which automates the installation for you.

The Userify shim is designed to have minimal working requirements (curl, any version of Python since 2009, the Linux adduser command, and sudo.) These basics are built-in to most Linux distributions including Red Hat, Debian, Ubuntu, RHEL, CentOS, SLES, Gentoo, etc.

What does the installer do?

• Create /opt/userify and credentials file in it (creds.py)
• Creates an uninstall script at /opt/userify/uninstall.sh
• Kicks off shim between every 10 and 180 seconds (set by the server)
• Sets the shim to automatically start on boot
• The shim itself (the python script) automatically syncs user accounts.

Support

For free, fast, and friendly support, please email [email protected].

Get In Touch

We are available to assist with questions, custom installations, directory integrations or deployments, and self-hosted installations. Please contact support for assistance or open an issue in this repository.

shim's Issues

Shim sometimes using high CPU

Reported by two customers; shim is using high CPU:

 Traceback (most recent call last):
  File "<stdin>", line 436, in <module>
  File "<stdin>", line 403, in main
  File "<stdin>", line 355, in https
  File "/usr/lib/python2.7/httplib.py", line 958, in request
    self._send_request(method, url, body, headers)
  File "/usr/lib/python2.7/httplib.py", line 992, in _send_request
    self.endheaders(body)
  File "/usr/lib/python2.7/httplib.py", line 954, in endheaders
    self._send_output(message_body)
  File "/usr/lib/python2.7/httplib.py", line 814, in _send_output
    self.send(msg)
  File "/usr/lib/python2.7/httplib.py", line 776, in send
    self.connect()
  File "/usr/lib/python2.7/httplib.py", line 1161, in connect
    self.sock = ssl.wrap_socket(sock, self.key_file, self.cert_file)
  File "/usr/lib/python2.7/ssl.py", line 381, in wrap_socket
    ciphers=ciphers)
  File "/usr/lib/python2.7/ssl.py", line 143, in __init__
    self.do_handshake()
  File "/usr/lib/python2.7/ssl.py", line 305, in do_handshake
    self._sslobj.do_handshake()
SSLError: _ssl.c:489: The handshake operation timed out 

Some Linux distributions may not have /opt

We've had reports that, even though /opt/ is a UNIX/Linux standard and part of the FHS (http://www.pathname.com/fhs/2.2/fhs-3.12.html), some Linux images at Digital Ocean may not have /opt created by default.

Questions about different usage scenarios

Hello,
I have single account (everyone) that everyone is allowed to login (of course if I add proper key to authorized_keys file).

1. Is managing this possible with userify? (I assign users to server and their public keys are added to ~everyone/.ssh/authorized_keys file or better some other file which user everyone is not allowed to edit - to prevent users from adding their own keys).
2. Is userify able to force specific set of public keys (if someone add something outside of userify this key will be removed on next run)?

Is self-hosted installation available?

Hi Userify,

I'm looking for tool for manage our public key access and found your
project is interesting. Glad to know if Userify able to host in our local environment seem our environment is complying by PCI-DSS.

UID's on restored home directories are incorrect.

@szelechoski : "If a user has permissions, is then removed, and then added back. permissions on the home directory get old uid."

The Userify shim has a feature where someone who was accidentally deleted has their directory automatically restored when their user account is restored. (It's renamed to username:deleted.; since Userify usernames are non-overlapping, it can only ever be the same user.)

However, the user directory is not re-chowned after rename, even though that user's UID may have been created differently (particularly if additional users were added since, changing the next available UID.)

To correct this problem (and as a temporary workaround), the shim should chown -R username:username the restored directory.

Timeouts issue when license expired (Enterprise)

When the license has expired on a Userify Enterprise server, the server responds after a delay, which means that the timeouts expires in the shim. (Some of the timeouts wrap the whole request, while others just wrap one part of it.)

The biggest issue with this is that there's no reasonable error message in the shim... it should say 403 License Expired, but instead it says SSL Read Failed.

Possible fixes:

1. Change the timeout settings in the shim to be more generous and include all segments of the connection
2. Decrease the delay for expired licenses on the server

Failure to install on Ubuntu 18

Creating Userify directory (/opt/userify/)
Creating uninstall script (/opt/userify/uninstall.sh)
Creating API login config (/opt/userify/creds.py)
Creating shim (/opt/userify/shim.{sh,py})
Removing exit 0 from rc.local (if there)
Checking Shim Startup

We tried to detect this Linux distro, but still unable to set start at bootup.
You'll have to set shim to startup on its own: create an init script that
launches /opt/userify/shim.sh on startup.  In most distributions, this would
have been a single line in /etc/rc.local, but you may need to do something more
exotic. Please contact us ([email protected]) with Linux version information
so we can get working on support.


Here's some debug info, if available on your platform:

NAME="Ubuntu"
VERSION="18.04 LTS (Bionic Beaver)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 18.04 LTS"
VERSION_ID="18.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=bionic
UBUNTU_CODENAME=bionic
Distributor ID:	Ubuntu
Description:	Ubuntu 18.04 LTS
Release:	18.04
Codename:	bionic
Linux <removed> 4.15.0-20-generic #21-Ubuntu SMP Tue Apr 24 06:16:15 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

SSL connect error on RHEL/CentOS 6.x

We are having the following issues when running shim on

I will submit a pull request soon. With my fix.
I am only running a CentoOS 6 environment and have only tested in a CentoOS environment.
This is related to the following issue http://lwn.net/Articles/682553/
cat /etc/issue
CentOS release 6.7 (Final)

On the initial install

curl -v -sS "https://static.userify.com/installer.sh" | api_key="jNNGyRNkeLVL2TFjJs8FucD5CoAAX8284EFmrLM2RgYgwcaxR6" api_id="4vDX5uRZXdZM887CEWXgQc_user" static_host="static.userify.com" shim_host="configure.userify.com" self_signed=0 sudo -sE

• About to connect() to static.userify.com port 443 (#0)
• Trying 104.20.15.168... connected
• Connected to static.userify.com (104.20.15.168) port 443 (#0)
• Initializing NSS with certpath: sql:/etc/pki/nssdb
• CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
• NSS error -12188
• Closing connection #0
• SSL connect error

Error

curl: (35) SSL connect error

In the shim script it is also not running correctly.

curl -vv -f${SELFSIGNED}Ss https://$static_host/shim.py

• About to connect() to static.userify.com port 443 (#0)
• Trying 104.20.15.168... connected
• Connected to static.userify.com (104.20.15.168) port 443 (#0)
• Initializing NSS with certpath: sql:/etc/pki/nssdb
• CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
• NSS error -12188
• Closing connection #0
  • SSL connect error

curl --version
curl 7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.19.1 Basic ECC zlib/1.2.3 libidn/1.18 libssh2/1.4.2
Protocols: tftp ftp telnet dict ldap ldaps http file https ftps scp sftp
Features: GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz

I fixed the install by add -1 force TLS.

curl -v -1 -sS "https://static.userify.com/installer.sh" | api_key="jNNGyRNkeLVL2TFjJs8FucD5CoAAX8284EFmrLM2RgYgwcaxR6" api_id="4vDX5uRZXdZM887CEWXgQc_user" static_host="static.userify.com" shim_host="configure.userify.com" self_signed=0 sudo -sE

• About to connect() to static.userify.com port 443 (#0)
• Trying 104.20.15.168... connected
• Connected to static.userify.com (104.20.15.168) port 443 (#0)
• Initializing NSS with certpath: sql:/etc/pki/nssdb
• CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
• SSL connection using TLS_RSA_WITH_AES_128_GCM_SHA256
• Server certificate:
• subject: CN=ssl369667.cloudflaressl.com,OU=PositiveSSL Multi-Domain,OU=Domain Control Validated
• start date: Mar 30 00:00:00 2016 GMT
• expire date: Oct 02 23:59:59 2016 GMT
• common name: ssl369667.cloudflaressl.com
• issuer: CN=COMODO RSA Domain Validation Secure Server CA 2,O=COMODO CA Limited,L=Salford,ST=Greater Manchester,C=GB
  GET /installer.sh HTTP/1.1
  User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.19.1 Basic ECC zlib/1.2.3 libidn/1.18 libssh2/1.4.2
  Host: static.userify.com
  Accept: /

< HTTP/1.1 200 OK
< Server: cloudflare-nginx
< Date: Wed, 06 Apr 2016 09:51:52 GMT
< Content-Type: application/octet-stream
< Content-Length: 10185
< Connection: keep-alive
< Set-Cookie: __cfduid=d6614791bdd559f0016321dab061a86341459936311; expires=Thu, 06-Apr-17 09:51:51 GMT; path=/; domain=.userify.com; HttpOnly
< Last-Modified: Mon, 04 Apr 2016 02:38:38 GMT
< ETag: "5701d3ae-27c9"
< Strict-Transport-Security: max-age=0; includeSubDomains; preload
< Accept-Ranges: bytes
< X-Content-Type-Options: nosniff
< CF-RAY: 28f457fb327515ec-JNB
<
{ [data not shown]

• Connection #0 to host static.userify.com left intact
• Closing connection #0

No license file/notice?

Hi,

apologies if I missed it -- but I can't seem to find any license information on the python shim? I see it's marked as copyright, but can't find any explicit grant for use/redistribution etc? I'm guessing it's probably intended to be under BSD/MIT license?

Should the shim manage users that it didn't create?

Right now, the shim uses a userify- comment field in /etc/passwd in order to only manage those user accounts that it created. (This has a useful side effect: grep userify /etc/passwd to see all of the userify accounts, or grep -v userify /etc/passwd to see all of the non userify accounts.)

We try to minimize statefulness in order to maximize reliability, and be willing to redo an operation repeatedly rather than record if it was already done. This can have its own side effects (an errant shim can use a lot of CPU if it goes bonkers), but the one place you want reliability is being able to get in and fix something else that's less reliable.

A concrete example: what if you accidentally paste a deployment script into a console window on your own desktop and watch your user account get deleted? Sure, you can just click a few buttons to get your home directory restored and permissions set back up, but it just "feels" risky. Not changing user accounts that we didn't create seems safer. (Also, there are corner cases; for example, we only reset UID/GID permissions for home directories. you may have other files elsewhere on the system that we don't fix the permissions for.)

We've had requests to manage the ubuntu, ec2-user, etc user accounts, which of course we didn't create. Our solution has been to add a userify-xxx comment to those fields and Userify will take over management on those fields, but sometimes that's inconvenient (especially on lots of servers, all of which often need those accounts removed.)

We've been looking at accommodating this request in several ways:

1. Users should only be using those accounts in order to accomplish their initial login. Afterward, they should be deleted. So, we could prompt for a list of user accounts to be deleted, even if Userify didn't create them.

2. System accounts, such as accounts used for backups or system daemons etc, are necessary, and right now they're outside the scope of Userify. We will enable creating accounts within Userify soon. One challenge here is ensuring sufficient entropy exists on a cloud instance to safely generate keys. (One would expect this is a solved problem, but in fact it is much more challenging than might be expected, and also affects sshd server keys which are generally generated on first bootup.)

Looking for thoughts on the best ways to approach this. If this affects you, please leave your comment below.

RHEL6/CentOS6 and SELinux=enforcing needs security context restored

Thanks to the platform team at Gannett (esp Brian Lieberman and Rob Gindes) for tracking this down, providing a fix, and for testing the fix on RHEL7/CentOS7 and selinux=permissive. (This was primarily tested with CentOS, but the issue and fix are presumably also relevant to RHEL)

SELinux=enforcing is not the default for CentOS6 at AWS and this apparently doesn't pop up as an issue in 7, but after the user is added, the security context needs to be restored in 6 in order to accept the authorized_keys.

restorecon -Rv /home/$USER/.ssh

This should probably be (after a check to make sure restorecon exists) after the authorized_keys is created, somewhere around here: https://github.com/userify/shim/blob/master/shim.py#L238

Perhaps:
# add quiet flag to qexec
qexec(["restorecon", "-Rv", "/home/$USER/.ssh"], quiet=True)

Please comment if this affects you.

Rename /var/log/shim.log to /var/log/userify-shim.log

Rename /var/log/shim.log to /var/log/userify-shim.log

The name shim.log is not descriptive, so rename to userify-shim.log to assist new users in finding log output. The old shim.log can be manually removed if desired.

Debian 9 doesn't support rc.local

Looks like Debian 9 is dropping support for rc.local.
I have no idea why people like breaking things that work, but it's the world we live in :)

Creating Userify directory (/opt/userify/)
Creating uninstall script (/opt/userify/uninstall.sh)
Creating API login config (/opt/userify/creds.py)
Creating shim (/opt/userify/shim.{sh,py})
Removing exit 0 from rc.local (if there)
Checking Shim Startup
 
Unable to set start at bootup -- no /etc/rc.local file?
You'll have to set shim to startup on it's own: create an
init script that launches /opt/userify/shim.sh on startup.
In most distributions, this would have been a single line
in /etc/rc.local, but you may need to do something more
exotic. Please contact us with Linux version information
and we may have more information for you.
 
root@pve01 [~]: # cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 9 (stretch)"
NAME="Debian GNU/Linux"
VERSION_ID="9"
VERSION="9 (stretch)"
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL=https://bugs.debian.org/

Amazon|Fedora Linux: shim doesn't always start on reboot

The shim.sh on Amazon Linux doesn't always start on reboot.

Additional details:

• cannot find modifications of rc.local or any start script.
• no shim.py, shim.sh, and/or sleep shows in ps ax
• /var/log/userify_shim.log shows log messages from prior to reboot only

Ubuntu install flaky

Ubuntu: 14.04.1
Bug:
1st ran: After the shim is installed,the log file is not created as well as the home directories are not created. But it said it installed fine.
2nd run: everything installed fine.

Deleting zenhub auto-created issue.

Deleting zenhub integration.

Add support for wget

It'd be relatively simple to add a check for wget instead of curl, since Debian and FreeBSD in minimal installs don't have curl.

Proxy support

@purinda at News Corp added support for environment proxy variables:

https://github.com/news-life-media/shim/blob/master/shim.py#L124

CentOS 6.5/RHEL 6.5 do not support CloudInit method of installation

RHEL/CentOS 6.x do not support CloudInit and so can't support the UserData script generated at Userify.com. This is a vendor limitation.

RHEL7 and later does (in Amazon AMI's).

Use the standard method of installation (shell script, copy and paste the curl line into a console) instead. If desired, the server can be bundled into an AMI or auto-scaling group as well.

Authorized keys can't be found due to non-standard /home folders

Unable to add SSH key for user it-ab: [Errno 2] No such file or directory: u'/home/it-ab/.ssh/authorized_keys'

Not surprising, since that isn't the path to the user's home folder ... When it's a "userify-converted" user, you should check the home folder listed in /etc/passwd:

In this instance:

it-ab:x:501:501:userify-converted:/home/ashley:/bin/bash

Seems like a simple check ... "let me see what the user's home folder is, before I assume it to be /home/user" ...

This would also be an issue for a lot of AD bound systems, as they tend to use the home path format of "/home/DOMAIN/userid"

@Shley

shim.py does not work in FIPS environment.

The shim does not work correctly when FIPS is enabled because the MD5 hash is disabled for cryptographic functions.

Switching to SHA265 should be fairly trivial.

Shim updating non-userify users with same username

A user reported that the shim is modifying users (updating authorized_keys and sudoers) with the same username (as you might expect), but not removing them (as you also might expect).

It appears that this is due to current_userify_users() only within the removal loop. This check should be done probably here (https://github.com/userify/shim/blob/master/shim.py#L432) as well, or at each step, or make it possible to opt-in or out at the server configuration level.

https://github.com/userify/shim/blob/master/shim.py#L446

Verify succeeds when install actually fails

Install claims success when it actually failed. Thx to Paul Fordahl & Matthew Unger @ Sleep Number for reporting.

I've heard of this occurring a few times - if anyone has details, please add them here:

 # command you ran to install (without api key)
 sudo cat /var/log/shim.log
 sudo ls -al /opt/userify/
 sudo grep userify /var/log/{messages,syslog,kernel.log}

Shim installation did not utilize certificate signatures

The shim installer by default wouldn't check certificates (curl -k) and now it will unless self-signed is explicitly enabled (in self-hosted Enterprise or Pro installations).

CoreOS support

CoreOS has no Python and needs to have libraries installed.

We don't have a statically compiled shim yet, but it's under development. In the interim, testing with a dynamically linked shim:

core@ip-172-31-14-236 ~/shim-static-compile $ LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/core/shim-static-compile/libpython2.7.so.1.0 ./shim
Could not find platform independent libraries
Could not find platform dependent libraries <exec_prefix>
Consider setting $PYTHONHOME to [:<exec_prefix>]
ImportError: No module named site

In order to support this use case (and other extremely minimal distributions without Python, such as IoT), it probably makes sense to statically compile Python and link as much as possible of the stdlib.

An alternative approach, such as userifier (https://github.com/ess/userifier), is a minimal version of the shim in Golang. Both of these languages produce large binaries.

A third approach will be for us to provide a minimal API resource that provides newline-delimited users in a strictly correct, pre-sanitized version (i.e., whitelisted characters, C POSIX locale, etc) and write a minimal bash version. This would mean a very fast startup as well, but less capabilities down the road. For lightweight containers, this approach is probably optimal.

Community feedback gratefully accepted.

Userify shim doesn't install Python properly on Red Hat Enterprise Linux

This might have worked before in the past, but it doesn't now:

Proposing explicit python3 installation rather than just 'python', because there is no longer a 'python' package available in base Red Hat Enterprise Linux:

    sudo yum install -y python >/dev/null || \
        sudo yum install -y python3 >/dev/null

logging to tty0

Would you guys consider not logging to tty0? this is a major annoyance when a vm or cloud instance loses connectivity. I can't edit files or do anything without having:

rc.local[466]: curl: (6) Could not resolve host: static.userify.com
rc.local[466]: curl: (6) Could not resolve host: static.userify.com

Spamming the console every second.

It's driving me insane. This is especially brutal in cloud config setups since tty0 is used as the actual console.

The only thing I can do is uninstall userify, then I have to install again later.

Support for self-signed HTTPS

Newer versions of Python 2.7 and later perform certificate verification by default (which is great), but Userify Enterprise is often run on self-signed HTTPS certificates and the shim needs to support self-signed.

Need to add protocol changes to the hostname changes for Enterprise.

Available shell list doesn't include zsh

The shim should check for shell availability before user creation and then the list could include unusual shells. The shell selection list is a good start in this direction but currently only includes very common shells. (If your chosen shell isn't available on a given instance, you won't be able to log in. A fallback list would be ideal.)

This would allow using shells not installed by default such as /bin/zsh while sensibly falling back to /bin/bash or /bin/sh if not available.

Caveats:
This would probably require a pre-defined list of fallback shells, probably user's preferred shell first, /bin/bash if available, /bin/ash, /bin/sh, or first 'sh' shell in /etc/shells. Is /etc/shells POSIX standard and does it exist on *bsd?

Add verbose flag to shim.

Add verbose flag to shim to aid in debugging new build environments that can be turned on and off on the fly.

Install.sh should deposit public key

Signed code would enhance security, but the public key needs to be deployed somehow (in traditional packaging systems, this is similar to rpm --import or apt-key add).

TLS already checks server certicates to prevent active MITM attacks, so this would be an enhancement for future signed code:

1. Deploy a GPG pub key for signed file checks into the install directory during install in order to bootstrap trust.
2. If gpg/pgp not available in the system path, notify installer via stderr and return status -1

This will let future versions of shim.sh check the gpg key and discard unsigned or illegitimate shims.

FreeBSD and OSX support

I started taking a look at getting this working on FreeBSD. Needs Python, curl, and bash installed, which the new FreeBSD 10.3 AMI's (huge thx to Colin Percival for his years-long effort on FreeBSD at AWS) do not have installed by default, but they're just a pkg install away. The upcoming check in installer for curl vs wget (#27) would resolve the curl dep.

Once that's done and a few minor hacks for things like /bin/bash relocation, the shim successfully pulls the JSON, but then has problems parsing /etc/passwd. A cursory review doesn't review any obvious issues, so that'll have to wait until later.

After that, there'll probably be the regular fixes and patches for inline sed (not easily available on *BSD since it's not POSIX), possibly adjusting useradd etc switches for creating new user accounts, adjusting for relocated /home (although it looks like it might 'just work'), and starting on reboot.

Add troubleshooting section to the README

I just spent an hour banging my head against my monitor because I had two calls to curl -1 -sS "https://static.userify.com/installer.sh" in my cloud-init file. Unfortunately, due to the way cloud-init works, of course that just meant that I couldn't ssh into my server to figure out what was causing things to fail.

Would it be too much ask to add a simple troubleshooting section in the README for poor souls like me? ;)

Shim Version 2 Brainstorm

Holding place for a wishlist for the next version of the shim.

things to hold onto..
0. no local dependencies except for things that are usually built-in (i.e., curl, bash, python)

1. instant installation and deployment
2. bullet-proof. If anything fails, just try again. above all, updates should never corrupt working install.
3. works almost everywhere (see 1)
4. simplicity, readable code, and modifiable source
5. server upgradeability

Separate Logrotate?

Should there be a separate means of handling the logrotate functions? As in, offloading that logging management from the shim to the system-built logrotate. This way, if we want a longer log, or a corporation has a different type of requirement, they can have and manage that separately.

Starts up twice on Amazon Linux 2016

The shim starts up twice on Amazon Linux 2016, but only on the first boot (might be only for CloudFormation).

This is completely harmless except for a few error messages in the log, (any errors are immediately resolved, and no concurrency issues), but tracking this as a bug.

Simultaneous Python3 and 2 support

The shim needs to be ported to Python3 to allow support for newer distributions, while still allowing execution in python 2 environments.

Uninstall needs to be run twice?

Reported by Select Comfort/BAM Labs devops Thomas T.: uninstall may not always completely remove or at least might be providing spurious error messages. User indicates that the second time always works.

Userify shim on CentOS/RHEL 6.5 or later doesn't start on reboot

We've done some additional testing on CentOS 6.5 and it seems to work with this AMI at AWS: ami-bc8131d4.

However, that AMI (and probably most RHEL6/CENT6) does not support CloudInit and so can't support the UserData script generated at Userify.com. Using the regular shell script installer instead (ie curl) works great (just paste it into a console and then bundle the server into an AMI if desired.)

Worse, it does not start automatically on reboot, so you'll have to install manually and set a startup script to launch:

 /opt/userify/shim.sh &

It's also feasible to deploy the /opt/userify directory into an RPM with a separate starting script. Note the /etc/rc.local doesn't seem to function, and RHEL/Cent6 does not support systemd. Looking for a simple installer solution for cross-platform sysV init scripts. This issue applies to Cent6 and Cent7.

The CentOS 7 AMI's support CloudInit and work perfectly but also do not start the shim on reboot. To see if it's running, check ps or

cat /var/log/shim.log

Shim sometimes launches two instances

Rarely, the shim.sh launches two copies of itself (as seen in the process list.) We can confirm this is an issue but it seems rare, and it seems to disappear after reboot.

If you have any information, esp as to circumstances (before or after reboot post-install), please add a comment.

OS/platform support requests

This issue is to consolidate OS/platform support requests.

The Userify shim is known to work on most distributions that support GNU utils, bash, and Python 2 or 3, including Debian-based distributions such as Ubuntu, Red Hat based distributions such as Alma, Rocky, Amazon, etc, and Arch based distributions such as Artix.

This covers nearly all Linux distributions. Here are a few that may not work properly. Please comment if you'd like to see any of these (or something else) supported!

• SLES / OpenSUSE
• Alpine and Void Linux

The following non-Linux operating systems are also targeted for support at some point in the near future, please cast your vote below if you could use this now:

• FreeBSD and OpenBSD
• Mac OS
• Windows (native)
• Windows subsystem for Linux

Temp files should be in /opt/userify

Temp files should be in /opt/userify

"In shim.py, on line 118, you do a rename to update the shim.sh
However, since the temp file is not created in the same directory, it could end up being on a different partition, in which case you get this error:
Unable to update shim.sh: [Errno 18] Invalid cross-device link"

Windows support

Windows Server is getting a new Powershell-backed OpenSSH implementation. This is a placeholder issue for supporting it. (It'll be particularly awesome with Userify Enterprise's new Active Directory integration, which synchronizes with AD when available but doesn't need AD running to operate!)

Userify Enterprise (the server itself, not the shim) is probably not too far off from running on Windows as well... that'd be an interesting setup.

Alpine Linux Support

Would like to use Userify with Moby, which is based on Alpine Linux, that unfortunately has a non-standard useradd (adduser).

SUSE support

Please integrate modifications from pull request #13 to support SUSE/OpenSUSE user/directory/startup changes.