

Introducing - Scale Access – SSH keys done right - bobsky
https://www.scaleft.com/

======
pquerna
We are just announcing today[1], and I'm one of the co-founders, and happy to
answer anyone's questions about ScaleFT

[1] - [http://venturebeat.com/2015/05/11/scaleft-launches-
with-800k...](http://venturebeat.com/2015/05/11/scaleft-launches-
with-800k-from-cloudkick-founders-and-rackspace/)

------
jordanthoms
Interesting - we have a small team but it's already a pain adding everyone's
keys to each server and rotation would be a pain.

My first concern is - how does this work? If you are generating new keys, does
that mean you could SSH into my servers if you were compromised?

~~~
pquerna
Hi Jordan,

We are essentially acting as an easy-to-use, "client focused", Certificate
Authority for SSH and X.509.

So, in the simplest threat model, yes, if our hosted SaaS version is
compromised, your infrastructure is threatened. We believe many of our larger
customers will adopt an "on premise" style deployment for this and other
reasons -- doing this on premise is not very different than their threat model
for a central LDAP server or other identity provider many have today.

Having said that, we are incorporating all the best practices you would see in
a CA for other purposes, and believe for some segments this is a viable and
major improvement over their current security practices.

------
radoslawc
Looks nice, at least for on-premises deployment of service. Will there be
source available for client?

~~~
rchiniquy
Hi!

I'm also one of the founders. We all have extensive open source experience,
have grown up in open source communities, and love open source. We're not
committing to 100% open source yet. We'll be pragmatic.

We all want to open source as much as useful to the community, rather than
just a code dump. This will probably look like open sourcing the individual
libraries we use to build the client, rather than a single open-but-monolithic
client. The client is written mostly in javascript[1] so we'll be publishing
modules on NPM when the modules we need don't exist already. I think we'll
need to build a Go client library pretty soon also. So, for the purpose of
code re-use and learning, we'll be open source.

I'm sure we'll also be sharing the complete source for the purpose of security
audits. If this is your concern, the answer is Yes, we'll let customers see
the code they're relying on for their infrastructure.

Hope that helps!

rch

1\. [https://github.com/atom/electron](https://github.com/atom/electron)

~~~
radoslawc
Hi, good to hear that. Security audit was my main concern, hence quiestion.

