
BLESS: SSH Certificate Authority for Ephemeral SSH Sessions - kkl
https://github.com/Netflix/bless
======
IgorPartola
So a couple of things. First off, this is using AWS for two important
services. That is probably a no go for a whole bunch of people right away.

But where it really lost me is that it is "yet another thing with a custom
installer" or YATWACI (tm). Let me say it again: if you want wide adoption of
your software, get it $@&!ing packaged for popular OS's. It is not hard, and
is way nicer than "well first, create a virtualenv..."

~~~
voltagex_
[https://github.com/Netflix/bless/blob/master/Makefile](https://github.com/Netflix/bless/blob/master/Makefile)
shows that it's pretty standard Python stuff, just wrapped up in a Makefile
for ease of use.

Packaging Python apps really really sucks - at least for Debian there's stdeb
-
[https://pypi.python.org/pypi/stdeb/0.8.5](https://pypi.python.org/pypi/stdeb/0.8.5).
No idea if it's lintian-clean though.

~~~
alanfranzoni
Packaging almost anything sucks. Use fpm.

Https://github.com/alanfranz/fpm-within-docker for native packages.

~~~
dozzie
FPM-created packages suck. They often have incorrect metadata format, most of
the time they don't have _any_ dependencies encoded, they often have crappily
written initscripts (less of a problem today, with systemd everywhere) and
similar infrastructural things.

All that while writing RPM specs and proper(ish) debianization are quite easy.

~~~
bbrazil
> (less of a problem today, with systemd everywhere)

Systemd is far from everywhere. Ubuntu 14.04 doesn't use it and is supported
until 2019. Debian Wheezy is supported until 2018. RHEL 6 has support through
to 2021.

Overall this means it'll start to be reasonable to presume systemd sometime
around 2020, and be realistically almost everywhere from say 2025.

Software changes take 5-10 years to roll out everywhere. This is such a core
change that it'll be on the longer side.

~~~
dozzie
Even though I agree with you here (I still use Wheezy, personally and
professionally), most projects don't target that old releases, so they build
mainly for modern mainstream (Debian/Ubuntu and Red Hat/CentOS), which means
systemd.

And that still doesn't change the fact that most programmers produce shitty
packages, if any, so every time I use somebody's software I need to package it
myself to have it properly built.

~~~
voltagex_
If the packaging files are in Git(Hub), raise an issue. A packaging bug is
still a bug.

~~~
dozzie
And for each and every package/project I would need convince the maintainer
that he doesn't understand what he's doing, he's doing it wrong, and he should
learn a correct method? Because it all boils to this (barring a more polite
way of stating the fact).

------
d33
Oh gosh, I thought it's going to be yet another fancy name for a new
vulnerability.

------
sumobob
Can someone explain what this is for? I read the readme but still have no clue

~~~
predakanga
Besides the usual public/private key system, OpenSSH supports a less-used
system called user certificates.

User certificates achieve the same purpose as your normal key but instead of
pre-installing your public key on the server, you present a certificate during
authentication and the server checks that it's signed by a trusted authority -
it's more or less a PKI similar to that used for HTTPS, etc.

One of the key advantages of this approach is that the CA can enforce limits
on the key, such as validity periods and disabling SSH features like port
forwarding, binding a certificate to only run a particular command, or only
allowing it's use from a specific IP.

BLESS appears to be a piece of infrastructure for autonomously signing these
certificates - on it's own that gives you benefits like a proper audit log,
but it seems that it's real purpose is to enable an SSH bastion host[0] to
generate ephemeral keys for the servers it accesses.

[0]: [http://blog.scottlowe.org/2015/11/21/using-ssh-bastion-
host/](http://blog.scottlowe.org/2015/11/21/using-ssh-bastion-host/)

------
therealidiot
While not completely related, can anybody suggest a good, clean way of
implementing centralised login under Linux?

With yp/nis being out of date (and not considered secure?) most things seem to
point to using Kerberos for auth, but how do people then go about syncing
passwd or some other method of getting all user accounts consistent across all
machines?

Then what about files, is nfs still the preferred method of sharing the home
directories?

Some questions. Sorry

~~~
talideon
Set up an LDAP server to handle authentication, and configure PAM to talk to
that LDAP server.

Edit: s/and/an/

