

Show HN: Automatic account and SSH access provisioning tool for server admins - skyraider
https://bastio.com/

======
staunch
Sorry to be another debbie downer, but this is not a good idea.

1\. It's a huge security no-no. Much better would be having users run a daemon
that polls for updates. At least that could _probably_ be done while
maintaining _some_ semblance of security.

2\. Admins don't need help with this, not really. Any competent admin will run
Puppet (or Chef, or LDAP), which makes this stuff the most trivial thing you
do.

I'd recommend a quick pivot (like let people run it themselves against their
own servers) or just abort mission and chalk it up as a learning experience.

~~~
skyraider
How is what we're doing less secure than, say, provisioning servers through a
provider like Linode that gives customers a web-based access panel? (One can
use their provisioning tools to create users with root access.) Also, running
a daemon may make folks more comfortable, but the reality is that the daemon
still has the ability to add users, which in turn can be used to log in.
Running things through a daemon certainly makes monitoring and firewall setup
more manageable, though, and we're working on it.

LDAP is a bit of a headache to set up for some shops.

~~~
staunch
A daemon could be smart. Only allowing certain operations (e.g. adding non-
root users) and it could send email directly to the account holder informing
them every time it does so. SSH access doesn't even need to be open for a
daemon to poll. Even if a hacker managed to add an account they might not be
able to use it.

Whereas your current method requires remote root SSH to be accessible from at
least your network. Hacking you means immediate unfettered access to every one
of your users.

I'd recommend a daemon and explicitly telling people to firewall off SSH from
anywhere that isn't their own network.

~~~
skyraider
I think you're right - we should include those instructions for now, and
provide a bastion-as-a-service later. The daemon route is clearly preferable
for customers, so we'll build that out (we already have manual key-adding
confirmation, and we record the IPs of people who attempt to download/upload
keys).

I would note, though, that if we're hacked, the attacker doesn't get access to
the users. We actually don't store the encryption keys for the deployment
keys; the client does. Still, the daemon route is what we need to do. Thanks
for the feedback.

------
zorlem
I personally don't feel comfortable using your service - too much of a
security risk giving Databracket LLC unrestricted root access. I guess most
other security-minded people would not feel at ease as well.

Having an agent running on the servers would be much better.

First, it will not require unrestricted SSH root access to the servers. Most
of the servers don't allow root to login through SSH at all.

Second, an agent restricts the harm that could be done if somebody hacks their
servers. This could be achieved with restrictions (specific commands, IP
addresses) to the key that is added to root's authorized_key, but there is no
mention of that in the FAQ or the other docs.

Third, firewall management - good luck convincing somebody to modify the
firewall to allow connections to the SSH service on all of their servers. A
restricted agent will be a much easier sell.

~~~
skyraider
Thanks, that's a great point that the agent is an easier sell. We're going to
add one soon so people won't feel uncomfortable opening up their SSH ports.
We've heard this a lot and really appreciate the feedback on this point.

------
jtchang
The idea is nice but the execution is flawed.

When teaching users new to Unix systems I tell them to guard the root password
/ anything that gives you root as closely as possible.

When securing systems you generally even want to disable root logins period.

I don't feel comfortable with giving a 3rd party credentials to my servers and
I don't recommend others do the same.

A downloadable product is really where you want to be headed with this. I'm
okay running putty or winscp where I get to have full control of whatever keys
I put in.

------
crandles
"We require that you deploy our public key to your root account’s
authorized_keys file so that we can provision users on your behalf."

That feels like a big requirement. What is the gain of using your UI/service
over using puppet in-house and creating your own UI?

~~~
skyraider
Well, we talked to server admins (mostly at companies that run servers on
behalf of web design or web services clients) and heard that they didn't want
us to impose the requirement of adding another package to their deploy
scripts. They'd have to keep the version up to date, make sure it's installed
on their machines, etc. That's feedback was really the only reason why chose
to impose this requirement for the beta.

I'd love to hear more about your use case and if you'd feel more comfortable
having a daemon run on your servers (so that our service wouldn't have root
login ability).

~~~
crandles
Just about anything would be better than 100% root access and "employed
measures to make sure that we never have unattended access to your servers",
and there's no reason you can't offer two solutions.

~~~
skyraider
You'll have to develop a cryptographic scheme makes sure that when your
management service is compromised, it does not affect the servers the
management server controls. We've done that work.

Say we have a daemon though - the daemon would require root access in order to
create user accounts. If the management service is compromised, the user
accounts can be created. That's why we've made it infeasible to access SSH
keys even if the management server is compromised.

------
klaruz
I'm not going to comment on the security of giving somebody an ssh key to your
root account... But it's a good idea to look at something like puppet to do
this.

Example: <https://github.com/credativ/puppet-ssh-hiera>

------
Keyneston
$4 a month per server for a rsync script I could write myself combined with
our existing ldap infrastructure? If it were a nice open sourced tool I would
consider it but at hundreds to thousands a month I could never justify it to
myself let alone my boss.

------
gexla
I can largely do all this with Ansible and it's flexible enough that I could
probably get pretty close to being as easy as a good web UI. They devs behind
Ansible are also working on Ansible Commander which will provide a UI. The UI
will likely be the difference maker, so you should include screenshots so that
I don't have to create a new account for yet another service I may never again
log into.

The pricing probably doesn't reflect how people would use this. The free plan
is basically just a way to see how it works as you wouldn't need something
like this for just one server. Maybe you should increase the free plan to a
few servers so that I could see how useful it might be.

~~~
skyraider
Thanks, we've removed the server limit for the moment and put up a screenshots
page. Any feedback you have on the UI and how we could make it more useful to
you than Ansible (besides our autogenerated scripts) would be awesome.

------
nodesocket
Hello guys. Founder of <https://commando.io>. Commando.io is a web based
interface to execute commands on remote servers over SSH. You can write
commands in bash, perl, python, ruby, or even node.js. We seem to share some
of the same ideas and vision. When you generate a public key in bastio.com do
you also add a password to the key as well? I.E. if somebody were to
compromise your server, they would need the SSH key password to SSH into other
users servers?

~~~
skyraider
If someone were to compromise our server, it is extremely unlikely that they
would be able to recover the SSH keys. The keys remain encrypted except when
they're needed to perform an action initiated by an authenticated user.

~~~
DoubleMalt
Sorry, but this sets off my bullshit detector. If someone compromises your
server he also has access to the routines decrypting the ssh keys. How do you
encrypt them?

~~~
skyraider
Hi - It's not enough to compromise the Bastio servers. Some of the data facets
needed to successfully decrypt the SSH keys are stored securely in the
browser. This is why we can't deploy OS users or keys if a Bastio user is not
logged in and active.

~~~
DoubleMalt
That is better but not good enough. If your servers were compromised, that
attacker could add JS code to your page that quietly farms that facets that
are securly stored in the browser, when the user logs in.

Makes it harder against a targeted attack, but does nothing for the average
user.

You can mitigate the problem by having a really good intrusion detection
system, but not eliminate it.

~~~
skyraider
It's harder than it sounds, as we use HttpOnly cookies and, much more
importantly, have little to no XSS attack surface.

As far as injecting JS after server compromise: At that point, an equal
concern is really attacker access to application memory, as we protect against
the (admittedly edge) case where the attacker replaces the served Javascript
but doesn't have access to memory. We've taken steps to reduce the opportunity
for memory compromise.

Also, we are actually working on a reaction-oriented intrusion detection
system that will take appropriate actions when invariants are tripped. But
more importantly, we're moving to the daemon model, where customers have much
more control over the security of their systems at the network level.

Many service providers, including DNS and hosting providers, use web-based
control panels and must properly secure their systems. It's not a requirement
that's unique to us. If you offer SaaS, you have to lock it down.

~~~
DoubleMalt
Of course the requirement exists for all SaaS providers. But while a break in
on Evernote reveals my notes (which would be bad, but not lethal), a break in
at bastio might compromise the servers where I host my SaaS products,
triggering a very nasty chain reaction.

So while the risk you face may be the same, the damage that can be done is
vastly greater. But I'm sure you're aware of that.

Assuming someone gains root level access to one of the boxes bastio is hosted
on, then he could

1a. block all outgoing traffic from the server except for the service (to
avoid alarms getting through) or 1b. replay the heartbeat sent by the server
2\. retrieve the database 3\. Sniff on all incoming traffic for the HttpOnly
Cookies

The worst thing is you might not even know which customers' keys are
compromised.

I'm sure you are thoughtful about security, but of course you are a great
target because of the valuable loot (root access lot's of other servers)

A lot of your concerns are considerations for me too as I am thinking of
launching a distributed SaaS. Just take it as input to your threat analysis :)

~~~
skyraider
Yeah, definitely, it's all an input to the threat analysis. Thanks for the
great discussion. It's interesting stuff and fun+important to just think
through.

Yes, you're right that someone could intercept the HttpOnly cookies, but as
you said, only if they were able to compromise the server, since we use SSL
and won't have any XSS surface.

Also agree that alarm or heartbeat-based IDS stuff won't cut it here. We're
working on an (agent-based, with signed code deployments) IDS
(<https://sentryhq.com/>) that sits on the server and makes decisions to take
certain actions not just when an attack matches some probably-out-of-date
rule, but when some ever-growing list of invariants change. It's kind of like
what banks use, except it responds automatically.

We will eventually be able to overcome all of these concerns (in the daemon-
based model, wherein we don't store server keys) by validating OS user key
distribution commands with secure emails to the people who requested them +
nonces for confirmation. At that point, if we can enforce best practices
amongst our customers, we can probably reduce the security problem to the
trust problem, which is as solid as can be expected.

Actually, what do you think about such an IDS? Usually the tactic is "let my
admins respond," but you are quite correct that that isn't sufficient, as your
IDS may pick up the attack but the response may never come. We are thinking
that the response isn't usually fast enough either.

------
xinternetx
I'm sorry, but LDAP does this on a much larger scale for free. Nice idea,
however wrong way to go about it big time.

------
ammmir
why on earth do you need remote shell access to the machine?!

it seems to me that a self-hosted solution (one-time fee or recurring license
fee would be fine with me) would be ideal, otherwise i'd have to worry about
security of not only my machines, but also yours. plus, i don't even allow
root logins.

perhaps an agent model would provide good middle ground: provide a daemon that
runs on the server and waits for account creation requests pushed from your
service. these wouldn't be executable commands, but rather JSON or some DSL
specifying account username, group, password, initial SSH key, skel, etc. a
compromise of your machines wouldn't allow remote commands to be executed on
your customers' machines (provided the daemon isn't exploitable).

------
ashayh
No serious shop will use this. If you release it as an open source project,
perhaps someone might find it useful. If they aren't using
LDAP/Puppet/Chef/etc . Checkout freeipa.org and
<https://oss.gonicus.de/labs/gosa> .

------
skyraider
Hi, one of the creators here. We build this because we run our own machines
and wanted a easier way to manage our OS user accounts and SSH keys across
machines. We put together a beta service to do just that, and would love to
hear what you think.

~~~
andyl
I can't imaging trusting a 3rd party to provision userId's and SSH keys for my
servers. Am I missing something here?

~~~
SpenserJ
I was thinking the same. Perhaps if the setup procedure included a limited-
access account that could only run useradd/userdel, I'd consider trying it,
but definitely not while root.

~~~
skyraider
Thanks for the feedback. For the one-time server enrollment process, would you
be more comfortable having us set up a limited account using a script we
provide? We were thinking that there's not necessarily a whole lot of
difference between a user who has useradd permissions and a user with root
permissions.

Also, we set up Bastio so that we don't have unattended access to your
servers. We keep everything encrypted until the moment when we need the keys
for account provisioning or keypair deployment.

~~~
SpenserJ
I'm not sure I'd even go that far. A set of commands showing how to lock down
account permissions would work just as well, while allowing me to remain in
control. That is a good point though, as Bastio would be able to create
unrestricted administrative users anyway.

Where are your encryption keys stored in relation to our connection data?

~~~
skyraider
There are multiple layers of encryption and the keys are distributed in such a
way that the client must login and provide the data facet we store in the
browser. The combination of this and other data facets provides the
combination that unlocks the private key we use to conduct deployments.

------
jaequery
with a catchy domain like bastio, perhaps you should try pivot into doing
something actually more useful like bastion host as a service w/ 2-factor
openvpn authentication.

~~~
skyraider
We were originally going to create a bastion but got some early feedback that
server admins wanted user management, and a bastion as a side feature. We've
got two-factor auth right now. Would you use a bastion + user management, or
if not, what's your need for the bastion besides the need for a solid, secure,
locked-down entry point?

~~~
jaequery
to be honest, it'd have to be coupled w/ ec2 or some other cloud providers,
that presets proper deployments with firewall/authentications. that'll be then
something i'll definitely be interested in.

------
kbar13
did you write your own valid email address checker regex? It doesn't follow
<http://tools.ietf.org/html/rfc5233>

