square / sharkey Goto Github PK

It would be nice if migrations could be handled in the same binary/with the same config, that way we could avoid having a separate dbconf.yml for goose. We can use goose as a library and just pass in the DB config from the sharkey config.yml file: https://godoc.org/bitbucket.org/liamstask/goose/lib/goose

Dependabot can't resolve your Go dependency files.

As a result, Dependabot couldn't update your dependencies.

The error Dependabot encountered was:

go: gopkg.in/[email protected]: invalid version: git fetch -f https://gopkg.in/check.v1 refs/heads/*:refs/heads/* refs/tags/*:refs/tags/* in /opt/go/gopath/pkg/mod/cache/vcs/9241c28341fcedca6a799ab7a465dd6924dc5d94044cbfabb75778817250adfc: exit status 128:
	error: RPC failed; curl 18 transfer closed with outstanding read data remaining
	fatal: The remote end hung up unexpectedly
	fatal: early EOF
	fatal: index-pack failed

If you think the above is an error on Dependabot's side please don't hesitate to get in touch - we'll do whatever we can to fix it.

View the update logs.

It seems like it should be fairly straightforward to use a PKCS11 HSM to hold the CA.

We can use https://github.com/letsencrypt/pkcs11key to get a crypto.Signer and then x/crypto/ssh's NewSignerFromSigner

I wrote a design doc, which should be published in this repo (minus any proprietary stuff).

Sharkey-client should be made idempotent, and only update known_hosts and the signed certificate if Sharkey's version differs from whats on disk.

We could publish RFC 4255 records.

https://tools.ietf.org/html/rfc4255

Travis CI is broken, we should consider moving to Actions. Some relevant links for how we might do this: https://freek.dev/1590-how-to-use-a-mysql-database-on-github-actions https://docs.github.com/en/actions/using-containerized-services/about-service-containers

• ROCA rsa keys
• debian weak keys
• too small keys (eg, 1024 bit rsa)
• algorithm policy (eg, require ed25519)

We should support

• a known_hosts of registered hosts (what we have right now)
• a known_hosts with the CAs used for all currently issued certs (today, we only support one, so just that)
• or both.

Sharkey-client should grab both by default.

I heard a bunch of feedback that user keys would be a desired feature, so we could support those.

I don't think we should try to build any sort of user verification into this service though. There's just too many ways to do that. We should provide an API for a trusted service to request certs on behalf of a user.

The usual thing for our services would be to define an ACL saying which x509 client certs are allowed to request user's ssh client certs, and it tells us what user it's for.
We could support the username in an X-Remote-User (or customizable) HTTP Header for use behind a reverse proxy that handles auth (eg, Sandstorm.io uses X-Sandstorm-User-Id, and SSO proxies may use other ones) and the user just makes requests through it.
Additionally, we might want to support usernames in the URL (because setting headers in other contexts is a little unusual)

Build RPMs in Travis for CentOS 7 and possibly CentOS 6.

• Figure out the best way to install Go in CentOS as RPMs are only at 1.4.2 even though RHEL is shipping 1.6.3.
• Create Dockerfile
• Update .travis.yml

We should have a small admin dashboard to show server status, and perform some administrative actions (like manually submitting or signing a host key), or some database operations.

#82 added additional endpoint, which is now covered by the integration-test.sh test script, but sharkey is lacking more Go HTTP tests.

When a host enrolls itself, we should support SANs, not just the CN

Allow the client to include multiple alias hostnames in its enrollment request, where the additional hostnames are added as aliases in known_hosts output. This will be useful for multi-homed clients. The aliases should be validated against the client SSL cert.

We should have integration tests that grab various OpenSSH versions and run them in a docker container with Sharkey, to ensure we're compatible and our certs actually work

We use "ON DUPLICATE UPDATE" in the database tracking host key, and return the row ID. But that doesn't work if a host changes hostkey

We should run unit tests and integration tests in Travis

We shell out to sudo mv. That lets us have to have the client able to write files it doesn't have permission to, but that behavior may not always be wanted. For example, integration tests shouldn't need root.

We don't have an instructions or tools to create the needed database tables

Today, sharkey requires having an x.509 certificate for the host.

AWS has instance identity documents: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-identity-documents.html

Perhaps we could support a client that submits an identity document instead of authenticating with a client certificate.

We'd still need a way to tie an instance document to the hostname(s) we should allow that instance to have, and we should be careful about the security implications here.

How do you configure SSH to use this?
What other settings are useful?
Ensure host names are canonicalized http://blog.djm.net.au/2014/01/hostname-canonicalisation-in-openssh.html

The --suffix flag should probably be a config option, not a flag. cc @christodenny