userify

shim

Python2015–2026

userify / shim

shim

The Userify Shim (cloud agent)

Explore on GitHub Read Hacker News discussions

5Distinct people

13Mentions

0Explicit recommenders

66GitHub stars

REPOSITORY AT A GLANCE

What to know before exploring

What it is

The Userify Shim (cloud agent)

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 4:01:40 AM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year13 dated mentions

Observed mentions: 2015-02-19 01:28:34 UTC to 2026-03-03 23:17:34 UTC.

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges

UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
Period	Start (UTC)	End (exclusive, UTC)	Mentions	Comments
2015	2015-01-01 00:00:00 UTC	2016-01-01 00:00:00 UTC	4	4
2016	2016-01-01 00:00:00 UTC	2017-01-01 00:00:00 UTC	1	1
2017	2017-01-01 00:00:00 UTC	2018-01-01 00:00:00 UTC	1	1
2018	2018-01-01 00:00:00 UTC	2019-01-01 00:00:00 UTC	0	0
2019	2019-01-01 00:00:00 UTC	2020-01-01 00:00:00 UTC	0	0
2020	2020-01-01 00:00:00 UTC	2021-01-01 00:00:00 UTC	0	0
2021	2021-01-01 00:00:00 UTC	2022-01-01 00:00:00 UTC	0	0
2022	2022-01-01 00:00:00 UTC	2023-01-01 00:00:00 UTC	2	2
2023	2023-01-01 00:00:00 UTC	2024-01-01 00:00:00 UTC	1	1
2024	2024-01-01 00:00:00 UTC	2025-01-01 00:00:00 UTC	2	2
2025	2025-01-01 00:00:00 UTC	2026-01-01 00:00:00 UTC	1	1
2026 (partial)	2026-01-01 00:00:00 UTC	2027-01-01 00:00:00 UTC	1	1

What Hacker News says

4 sources

jamiesonbecker·Oct 3, 2015

This isn't the future. This is the present. We built Userify[1] (ssh key management for EC2 & elsewhere) entirely using this model (REST API) because it gives us a clean way to inspect incoming data and respond with pure JSON. Since it's just JSON over HTTPS, clients are all easily implementable in any language (i.e., Javascript and HTML5 for the web app, beta client SDK's currently in Python and JS, more on their way), or just a curl shell script. (The agent[2] is just a single Python script with no dependencies.) And, now, with great tools like Phonegap/Adobe Build/etc, you can convert your responsive mobile web app into an Android or iPhone app in seconds (performance is no longer an issue, either). Best of all, you maintain a clean separation of concerns and isolation between your API resources and the front end. Compared to the serve

Read the rest

r-driven ways from the last century, this is so much better; we can provide a full desktop app experience, make it feel more like a web page, or anywhere in between. AJAX changed everything. This is simply better. 1. https://userify.com 2. https://github.com/userify/shim

In API server and a static front end – the future?

jamiesonbecker·Sep 7, 2015

That's cool. Another way is to localtunnel to TCP forward to endhost in your config (ie two SSH connections, the first to the jump host, the second through the jump host, without agent forwarding), but that gets tedious fast without scripting support, especially if you want to use different portnums to avoid conflicts. ControlMaster would be a good choice to multiplex multiple connections to the same box. > I believe that your solution requires things to be on different subnets to isolate them, with separate jump hosts for each subnet, correct? Here, I only need one sshmux for everyone. Right, we're automating the .ssh/authorized_keys (and sudoers) right now (https://github.com/userify/shim/blob/master/shim.py), so you can set it up however you like, as long as those boxes can get to either Userify for key updates, or your on-premises Use

Read the rest

rify server(s). Only one jumpbox is needed across any network, depending on how you prefer to lockdown your network. (The HOWTO refers to EC2, but it can be built anywhere, exactly the same way.) sshmux looks like an interesting project, and love the simplicity. Wonder if Userify might automate the ProxyCommand setup! Seems really useful. > Good luck with Userify! Thanks! We have 350 companies on the platform right now and growing fast, and Userify Enterprise (on-premise) is in beta at several large enterprises as well. BTW, joushou, we're looking for brilliant SSH and golang hackers.. ping me if you get bored :)

In Sshmuxd: SSH proxy to replace jump hosts

jamiesonbecker·Aug 14, 2015

Well, obviously it's better to not trust anyone, ever. (I have trust issues too:)) You are trusting a third party as soon as you launch stuff in a public cloud or with your OS. For example, entropy.ubuntu.com, your distribution's update mechanism, Android/IOS app store, even Gentoo's github repos. We designed this as safely as we could: Userify doesn't need (or want) secret credentials, only public keys. We encrypt with NaCl before data hits Redis. We only communicate with TLS. The Userify shim does need root permissions because it's managing user accounts. Userify is available for on-premise deployment (currently Enterprise, and, soon, Pro in your AWS VPC), and Cloud is available for people who want free. Soon, we're launching "Pro", which is an in-between product for people who want in-VPC without paying enterprise pricing. (I assume yo

Read the rest

u're talking about RH IPA, which is some nifty wrappers around LDAP. As someone who spent a lot of time implementing LDAP on UNIX at big companies, LDAP and centralized auth in general carries a lot of risks: for example, what happens if just a single one of your boxes is compromised, and rather than just sniff passwords, it starts DoS'ing your LDAP server? oops. now you can't get into any of your servers, even the ones they haven't yet owned.) We focus on a lot more than just authentication. That's just the beginning of the story. Userify Enterprise provides layered role-based access control, a user-friendly front-end for key updates, project functionality, and the ability to remove users across a single project or the entire companies. Ansible or Puppet don't offer any of those things. We have built-in deployment for Chef, for instance. We try hard not to duplicate functionality that you can get elsewhere (for example, systems management, log monitoring.) Those are designed for systems management, and they're good at that. We're designed for complex, multi-tiered user management with a focus on the user, not the system. (Hence our name) We view these as orthogonal directions, and it makes sense to use Userify with a good devops/cf system like Ansible/Chef/Puppet/Salt/etc. Small shops can still manually manage a dozen or so users across a few groups of servers. We've got a bunch of companies with hundreds of servers and less than 10 devops across all of them. For companies like that, Userify gives a bunch of other benefits.. for example, you can rotate your SSH keys without requesting a production code deployment, or update an SSH key without write access to git, or remove a contractor's account on their last day, etc. On-boarding and off-boarding get a lot easier, rotating keys is easier, training users is easier, managing lots of different role sets is easier, and Userify doesn't require any changes to PAM or NSS modules -- installing is a one-liner and it just uses /usr/sbin/adduser and /etc/sudoers.d. The shim is just a few hundred lines.. read through it at https://github.com/userify/shim

In OpenSSH 7.0 released

e12e·Feb 19, 2015

Please note that mixing standard ssh certs and something like userify should be a good mix. From the man-page above, we note that a cert (the signed public key of a user) can include principals -- that is user ids and hostnames (as well as origninatiing IPs) -- and the cert will only be valid for those combinations. So if a service provides users with "session-tickets" (eg: certs valid for 8 hours, or 5 days etc) -- the servers need not call-back to userify. Authorization (for at least part of use-cases) becomes decentralized. Add an api for extending the validity of a cert (client does a lookup, userify checks policies, and if everything is ok, signs the key for a new validity-period) -- and everything should work very nicely indeed. For those interested in ssh certs in general, see also: https://github.com/cloudtools/ssh-ca As for the u

Read the rest

serify shim, even though you've answered my question: https://github.com/userify/shim/issues/4 -- you might still want to include a license file, or something along the lines of: http://www.tarsnap.com/legal.html in the readme. Might also want to have a free/open licensed spec of the api somewhere, so that if someone were to implement a self-hosting, free/open service that could be made api-compatible with userify, there'd be a clear way to do that legally.

In Duplicate SSH Keys Everywhere