gravitational / teleport Goto Github PK

Here's what we've agreed on:

• admin calls tctl user create --username that generates a web link in the form:

http://<teleport-url>/signup/<unique-token-id>

This unique token id entry is valid for TTL hours (e.g. 5 hours) by default

• when user clicks on the link, they see the webpage that allows them to set password, scan HOTP token and click create
• add just a basic error handling that will not allow them to set empty or not matching passwords.
• Once the user clicked on the link, the link becomes unavailable

Description

Teleport does not validate domain names (AKA host names) when you add nodes to the cluster. I am guessing there are other operations where validation is not happening.

For example I was able to invite a node with the name zeka&#Dfhsiu&^23. I also created a hostname over 1000 characters long. While technically nothing stops us from accepting arbitrary strings, in reality every value needs to conform to some standard. I propose we use a sane subset of RFC1178 as discussed on Wikipedia

Maybe something like this?

/^[a-zA-Z0-9][a-zA-Z0-9-\.]{1,64}$/

How success looks like

• Client API functions in /lib/auth/clt.go return nice error messages when a hostname or domain name does not pass validation.

Looking at the code it appears the "delete user" API call keeps the mappings intact. This presents two problems, one of medium importance and other one is major:

1. Medium severity: garbage data, i.e. the DB will have orphan objects.
2. High severity: if later you create another user with the same login, but with a different set of mappings, there sill be a superset of old and new mappings, so it's a security problem.

Why:

Teleport already supports failover and multiple auth servers, however we haven't documented it and did not add proper support for it in several components before. Now when I'm working on adding/removing servers roadmap I need to use this feature, so I'm asking Alex to add proper documentation/configuration for it and do code changes when necessary.

What:

• Document and probably add missing configuration fields to auth server config to support clustering mode. Documentation should have 2 sections:
  a. How to add one more auth server to existing server
  b. How to add two auth servers at the same time (in this case config of both servers should trust to each other)
• Make sure that failover works: when one auth server goes down, nodes reconnect to the new auth server. Support this use case, add this to the heartbeat
• Reverse tunnel failover scenario. We can set up multiple servers to support reverse tunnel roles. Proxy should support more than one reverse tunnel connection from the same cluster here:

https://github.com/gravitational/teleport/blob/master/lib/reversetunnel/srv.go#L110

and do round robin here as Alex suggested.

Update README with these settings.

Description

Teleport needs a couple of more improvements to reverse tunnel:

• support multiple reverse tunnel instances from a single site
• add ability to turn off reverse tunnels

How success looks like

• teleport proxy load balances two reverse tunnels coming from the single site
• teleport proxy works without reverse tunnel directly dialing into the server

Problem

I have implemented "delete user" and "list users" using Teleport client API. Both are not working. For example, client.DeleteUser() returns a low level (all the way from DB!) error:

Error: {"message":"bucket users not found"}

And client.GetUsers() always returns an empty list. That happens because their implementations look into users "bucket" as shown in /lib/services/user.go:77

func (s *UserService) DeleteUser(user string) error {
    err := s.backend.DeleteBucket([]string{"users"}, user)
    return err
}

Notice that this file does not have any code for creating users! That's because that code for some reason lives in web.go and (I think) a user is created by calling UpsertPasswordHash in /lib/services/web.go and it is using a different bucket (is that true? why are buckets always referenced by a slice?)

Solution

TBD

What success looks like

1. Well, user CRUD API needs to work.
2. It would be nice to get higher level errors, like "user not found" instead of "bucket not found" on the API level.
3. A bit of refactoring would help: user&key storage is a very critical component of Teleport and people will be looking. This code needs to be crisp, documented and, most importantly, kept in one place.

Just as we've discussed today, it would be handy for teleagent to support scp in both directions - small but useful feature that's easy to plug in.

Description

Teleport has user credential issues, as evidenced by failing tests. Attaching the test run output (mixed up with logs) and also copy-pasting the email content which originally described the error.

Details

This is all happening on master. The requrements for tests is that they must run without root or sudo privileges.

Also, attaching the test run with logs. There's some weird shit in there, like this:

SCP sent exit status%!(EXTRA *srv.ctx=sess(127.0.0.1:59550->127.0.0.1:30187, user=Ev Kontsevoy, id=8))" 

Again, why is my full name used inside teleport? Is it again confused with ekontsevoy (my username)? Maybe we should search for user.Name everywhere?

Here's how my /etc/passwd looks like:

ekontsevoy:x:1000:1000:Ev Kontsevoy,,,:/home/ekontsevoy:/bin/bash

Is it possible you have the same "Name" and "Username"?

Attachments

teleport-test-output.txt

How Success Looks Like

make test passes when executed by a user who:

1. Is not root
2. Has username which != full name as can be seen in /etc/passwd

Implement:

Teleport ssh client library

• teleport/lib/client - library that can implement native go ssh clients connecting to teleport and using 2FA to sign private keys. You can use this as an example:

https://github.com/gravitational/gravity/blob/master/tool/gravity/sshtools.go#L27

Once it's done I will remove this code and will start using the library you wrote.

TSH - teleport native shell client

• implement tsh - teleport ssh tool that uses this library and can do several cool commands

# (proxysites)
tsh sites list 

# list servers in a site
tsh servers list

tsh ssh <server-name>
tsh ssh <label-name>=<label-value>

example:

tsh servers list example.com

* mongo1 tags: role=master
* mongo2 tags role=node

tsh ssh role=master ssh

NOTE Ev will probably change the UX once he gets to it, but let's just have these features working.

• tsh authentication behavior - it does not need agent, it can ask for username, password and 2nd factor if locally stored ssh cert has expired or is missing. It can generate new private key every day.

Cleanup tele-agent

• do not use response bodies to identify error, use response codes. If you need your own handling logic, use JSON in bodies and marshal/unmarshal error type
• you are using mix of http.Form and JSON in requests, where individual form fields are treated as JSON fields, this is unusual, and can be done way simpler:

you can POST the whole JSON body:

https://github.com/gravitational/gravity/blob/master/lib/portal/apiclient.go#L74

on server side,just unmarshal the whole body as JSON:

https://github.com/gravitational/gravity/blob/master/lib/portal/api.go#L115

Some places where I found this:

• https://github.com/gravitational/teleport/blob/master/lib/web/multi.go#L160
• https://github.com/gravitational/teleport/blob/master/lib/teleagent/api.go#L46

Dynamic and static labels

Add option for teleport server to heartbeat labels to the auth server:

ssh:
    labels:
       # teleport will always heartbeat this static labels
       - role: master
       - server: linux
    label-commands:
        # teleport will launch goroutine asknig every second for new response and updating
        # heartbeat
        - mongo-role: ['mongocli', '-c', 'select replica role']

Here are some ideas on what should be changed in Teleport before first release in terms of auth handling:

• Teleport servers should only care about checking host and and user certificates, they should not be a user authority itself and should not care about users, teleport-auth should be only host CA.
• Only Telescope will contain user entries and be a user CA
• SSH nodes do not need to have a persistent connection to the Teleport Auth and should be able to operate without it. They should be able to reconnect to the teleport Auth and fetch the latest trusted host and user trusted certificate authority keys periodically. If the connection is down, they will use the local cache.
• teleport should not have control panel
• We should have our own SSH -agent that uses Telescope 2 factor auth to fetch newly generated certificate for the user from the identity server.
• telescope should be split into 3 parts - telescope-identity, telescope-web and telescope-proxy
• teleport should consist of 3 parts - teleport-node, teleport-audit and teleport-auth
• telescope-web should support 2 factor auth only
• telescope-identity should only issue short lived SSH certificates to teleport-proxy and teleport-web

Things to do:

• Plug in Shippable
• Write quick start, user manual, API docs
• Publish releasing script

We need Teleport documentation for launch.

examples:
https://github.com/coreos/etcd
https://github.com/facebook/react-native

Here is a list of issues I noticed. Some of these may not be necessary for release.

• make api.md more readable
• incorporate google doc on design into github
• installation and operating instructions for different scenarios / use cases
• community contact information: mailing list, IRC, security reporting
• bug reporting / issue instructions
• versioning methodology
• faqs
• mkdocs output

Teleport command line API is currently inconsistent and has the following problems:

• Non Posix-compatible flags (should be backend-config not backendConfig)
• Tctl does process does not exit with non zero code if operation ended unsuccessfullyos.Exit(-1)
• Current package for command line handling codegangsta/cli has problems supporting layered commands
• Tests are broken for command line

Fix the mentioned problems and migrate to https://github.com/alecthomas/kingpin

The prototype should have the following capabilities:

• Should support Etcd as a configuration backend
• Should support CA public key authorization
• Authority API and cli for generating and signing public keys
• Tunneling SSH through SSH using Agent forwarding
• Structured logs and tracing of all the session activity
• Multiplexing subsystem for fancy command execution on multiple hosts
• TCP port forwarding through tunnel to any server (mostly care about auth)
• JS shell to any server (figure out the auth)

teleport scp tests fail sometimes

• socket removal is a big thing, always bites on restart
• figure out a way to vendor assets
• records directory can be created, recording should be optional, should not crash if the directory does not exist.
• remote:site auth proxy srv.go 197 use of closed network connection
• file upload and download does not work through lens, says 404 not found
• file upload needs cp server to work, what is weird actually.
• too many flags, domain and fqdn are very confusing to people

Description

Right now when teleport proxy looses connection to the remote server, users see disconnected screen. We should detect connection losses and reconnect automatically

How success looks like

• if connection to the remote server gets lost and restored, teleport proxy web UI will reconnect
• teleport proxy will reconnect with exponential backoff to make sure it does not send browser to reconnect loop.
• users will see "reconnect in ..." message in terminal when this occurs

Description

Proxy should be able to support static OpenSSH servers and SSH into them via CLI and Web. It's clear that some features won't be available, e.g audits and live session sharing.

How success looks like

• Users can add remote SSH servers using API and command line interface, and supply static tags for the servers
• Users can SSH into the servers via web, OpenSSH client and tsh
• Users can copy files and multiplex commands using tsh

Implementation details

The most important part is to let proxy role to have ability to open channel to remote servers without reverse tunnel.

Auth server already has an ability to add servers via /servers interface, so just expose this via command line:

this will add a server to the auth server manually
tctl server add --address=... --tags

after this, proxy will have natural ability to SSH into OpenSSH servers (obviously, after adding auth server's CA as trusted authority)

Right now, we generate SSH keypair for every new web session. That takes about 10 seconds. Let us have a pool of pre-created (unused) pairs we can consume from to speed up sign in process.

I cannot build Teleport on a new machine:

edsger ~/go/src/github.com/gravitational/teleport: make
find . -name flymake_* -delete
go install github.com/gravitational/teleport/tool/teleport
lib/limiter/connlimiter.go:22:2: cannot find package "github.com/alexlyulkov/oxy/connlimit" in any of:
    /opt/go/src/github.com/alexlyulkov/oxy/connlimit (from $GOROOT)
    /home/ekontsevoy/go/src/github.com/alexlyulkov/oxy/connlimit (from $GOPATH)
lib/limiter/ratelimiter.go:24:2: cannot find package "github.com/alexlyulkov/oxy/ratelimit" in any of:
    /opt/go/src/github.com/alexlyulkov/oxy/ratelimit (from $GOROOT)
    /home/ekontsevoy/go/src/github.com/alexlyulkov/oxy/ratelimit (from $GOPATH)
lib/limiter/connlimiter.go:23:2: cannot find package "github.com/alexlyulkov/oxy/utils" in any of:
    /opt/go/src/github.com/alexlyulkov/oxy/utils (from $GOROOT)
    /home/ekontsevoy/go/src/github.com/alexlyulkov/oxy/utils (from $GOPATH)
lib/limiter/ratelimiter.go:27:2: cannot find package "github.com/mailgun/timetools" in any of:
    /opt/go/src/github.com/mailgun/timetools (from $GOROOT)
    /home/ekontsevoy/go/src/github.com/mailgun/timetools (from $GOPATH)
lib/limiter/ratelimiter.go:28:2: cannot find package "github.com/mailgun/ttlmap" in any of:
    /opt/go/src/github.com/mailgun/ttlmap (from $GOROOT)
    /home/ekontsevoy/go/src/github.com/mailgun/ttlmap (from $GOPATH)
Makefile:10: recipe for target 'teleport' failed
make: *** [teleport] Error 1

You've left some unused commented code:

https://github.com/gravitational/teleport/blob/master/auth/ap.go#L59

Please remove it

When I log into a teleport-controlled server using web UI and try to edit any file using vi it disconnects.

I basically typed:

$ vi REAMDE.md

... and hit "enter".

Attaching a screenshot of what happens next.
Also, I cannot reconnect when this happens.

Description

When I add a new SSH node to an auth server, it fails to authenticate with the given token.

SSH node logs

WARN[0006] [srv.go:257]  Get http://stub:0/v1/usermappings: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain  file=srv.go line=207

Auth server logs

INFO[0137] failed to initiate connection, err: EOF       file=server.go line=152
INFO[0137] [::]:3025 accepted connection from 192.168.121.164:48904  file=server.go line=124
INFO[0137] conn(192.168.121.164:48904->192.168.121.1:3025, user=zebra) auth attempt with key [email protected]  file=tun.go line=244
WARN[0137] conn(192.168.121.164:48904->192.168.121.1:3025, user=zebra) ERROR: failed auth user zebra, err: ssh: principal "zebra" not in the set o

Solution

SSH node should use the full principal name instead of the nodename when asking to join the auth server.

Problem:

When teleport clusters are connecting to lens, lens does not check the host key of the client teleport connection.

Steps to reproduce:

• set up lens domain in /etc/hosts:

127.0.0.1 vendor.io lens.vendor.io

• start lens:

notice, that currently lens uses assets (js and css files) from teleport, so you could supply path to teleport installation, otherwise control panel for lens won't start.

    lens -log=console\
         -logSeverity=INFO\
         -dataDir=/var/lib/teleport/lens\
         -assetsDir=${GOPATH}/src/github.com/gravitational/lens\
         -cpAssetsDir=${GOPATH}/src/github.com/gravitational/teleport\
         -fqdn=lens.vendor.io\
         -domain=vendor.io\
         -tunAddr=tcp://lens.vendor.io:34000\
         -webAddr=tcp://lens.vendor.io:35000\
         -backend=bolt\
         -backendConfig='{"path": "/var/lib/teleport/lens.db"}'

• Start teleport auth server with connection to lens:

    teleport -auth\
              ...
         -tun\    # this sets up outgoing connection from teleport auth server to lens
             -tunSrvAddr=tcp://lens.vendor.io:34000

You will see that teleport will start connection attempts to lens, but will be failing, because auth will fail (we will set this up later)

• take lens certificates and install them as remote certificates for teleport, so teleport will trust this lens server.

    lensctl userca pubkey > /tmp/user.pubkey
    lensctl hostca pubkey > /tmp/host.pubkey
    tctl remoteca upsert -type=user -id=user.lens.vendor.io -fqdn=lens.vendor.io -path=/tmp/user.pubkey
    tctl remoteca upsert -type=host -id=host.lens.vendor.io -fqdn=lens.vendor.io -path=/tmp/host.pubkey
    tctl remoteca ls -type=user
    tctl remoteca ls -type=host```

* you should see that teleport has connected to lens and lens is up  and running

* to log in into lens, you can use `lensctl set-pass` command, just like in teleport

As you see, in this model there's no place where lens gets teleport public keys to check them later.
We should fix that by impelenting the same remote-ca feature, but for lens server. Once lens will see the remote host certificate from teleport it will check them against remote certificate stored in remote-ca list.

Description

Running teleport is not friendly in docker containers as it panics:

root@orbit:/# /out/src/github.com/gravitational/teleport/out/teleport start --roles=node --name=bob --token=n203b206238e913e0c57f936e9b3d11895c8c7aeac8ec16ce1158287684dc1b2d --auth-server=127.0.0.1:3025
panic: Unix syslog delivery error

goroutine 1 [running]:
github.com/gravitational/teleport/lib/utils.InitLoggerCLI()
    /home/alex/go/src/github.com/gravitational/teleport/lib/utils/cli.go:40 +0xf7
main.main()
    /home/alex/go/src/github.com/gravitational/teleport/tool/teleport/main.go:36 +0x39

goroutine 17 [syscall, locked to thread]:
runtime.goexit()
    /usr/local/go/src/runtime/asm_amd64.s:1721 +0x1

How success looks like

• Teleport should not panic when running in docker containers without syslog available

Description

Currently teleport executes sessions as a user of the teleport's process:

https://github.com/gravitational/teleport/blob/master/lib/srv/sess.go#L182

This is error-prone as it means that if teleport runs as admin or has superuser privileges any user logging in will be logged in as a root.

Solution Design

We will introduce a new mapping of the users of teleport to the operating system user ids they can execute commands under.

Let's dig into OpenSSH behavior regarding users and then propose an teleport specific mapping of users to operating system users.

OpenSSH authentication behavior

Let's take a look at SSH auth protocol. Authentication requests consist of:

      byte      SSH_MSG_USERAUTH_REQUEST
      string    user name in ISO-10646 UTF-8 encoding [RFC3629]
      string    service name in US-ASCII
      string    method name in US-ASCII
      ....      method specific fields

when ssh client executes ssh admin@host:port, authentication request's user field is set to 'admin'. In case if it's key based auth, OpenSSH by default looks up admin's authorized_keys file and checks if the key is valid. If the key is valid, OpenSSH allows to log in as the OS user.

Teleport new behavior

Teleport will introduce explicit mapping of Teleport's users to operating system users, Teleport will restrict it's users attempting to create processes only to operating system's users that are explicitly allowed by the configuration.

Here's how Teleport will achieve this behavior:

Using principals to identify user's identities

Teleport supports only OpenSSH certificates as it's primary authentication method.

OpenSSH certificates have valid principals field:

"valid principals" is a string containing zero or more principals as
strings packed inside it. These principals list the names for which this
certificate is valid; hostnames for SSH_CERT_TYPE_HOST certificates and
usernames for SSH_CERT_TYPE_USER certificates.

When issuing certificates for user's Teleport will add user name as the only listed "valid principal" and will reject any certificates with empty principals.

Treat auth user name as desired OS user name

Teleport will treat username provided during authentication as a request to login as a particular user with the same name in the operating system. This request will be rejected or denied based on ACL (access control list) rules set up in Teleport (the rules will be introduced below in this doc)

Introduce explicit ACL list for users and cert authorities

Every user in Teleport system is uniquely identified by the following tuple:

(certificate authority id, valid principal name)

• certificate authority id is ethier a local or remote (in teleport terms) trusted certificate authority that signed the certificate
• valid principal name is a username of the user as listed in certificate and is equal to the username entry in teleport auth server

We will create explicit mapping table, where every certificate authority id and valid principal name will be mapped to the list of OS (operating system) users they can log as:

As you've noticed that there are some entries with users marked as .* and some entries with users specified.

Here are some restrictions on the data in the ACL table:

• Only remote authorities can have wildcard user entries (the entries with users set as .*) - the reason for that is that we don't always know the users of the remote organisations.
• Local authorities are not allowed to have wildcard entries for users
• Remote authorities are allowed to have users specified explicitly
• Remote and local authorities are requried to set OS user explicitly all the times
• Multiple entries with the same authority can be specified

Here's the algo of how to evaluate the ACL list:

1. check for direct match of (authority id, user id, desired OS user)
2. if match is found, let user to start session or exec command as desired OS user
3. if match is not found, look for the entry (authority id, .*, desired OS user)
4. if match is found, let user to start session or exec command as desired OS user
5. otherwise, reject.

Teleport SSH client behavior

tsh --proxy-user=alice ssh admin@hostname

will take SSH certificate for valid principal alice and set the SSH user as admin

tsh --proxy-user=alice ssh hostname

will use ssh certificate and ssh user name as the same name alice

OpenSSH client behavior

ssh -i alex admin@hostname

will tell proxy to extract identity from the signed certificate and set user to admin checking against ACL entry table

TCTL design considerations

tctl user add vincent --os-user=admin --os-user=vincent

will add user and the ACL entry:

Note: we need a way for admin to modify ACL rules for user and admin, we will address it in a different issue.

Server side design considerations

Teleport Auth server stores ACL entries in Etcd or Bolt DB backends. Teleport SSH nodes will periodically pull Teleport Auth server for ACL lists (as they do already to get the fresh list of cert authorities) and will check the ACL entries when logging user in.

How success looks like

• Teleport admin can specify mapping of OS users to users when adding user entry via TCTL
• OpenSSH clients can log in using different OS users to teleport servers via proxy
• TSH clients can log in using different OS users to teleport servers via proxy
• Both interactive sessions and exec commands are checked

The detailed list of what needs to be done is listed here:
https://wiki.gravitational.io/outcomes/2/launch-teleport/

There are 3 parts:

• CLI + config (back-end features)
• Bugs (IIRC only one)
• UI/UX work

Teleport should be capable of:

• Setting up maximum number if authorization attempts per client ip and user
• Store private host CA keys and user CA keys in encrypted format

I have two teleport servers, and I am "ev" on both of them. Google iphone app shows "ev@teleport" for both. I could never tell which one is which.

We should probably say: "teleport: ev@hostname" there. Is this possible?

Curently backend is too big:

https://github.com/gravitational/teleport/blob/master/backend/backend.go#L10

All backends should implement just the following methods:

type Backend interface {
    GetKeys(path []string) ([]string, error)
    UpsertVal(path []string, key string, val []byte, ttl time.Duration) error
    GetVal(path []string, key string) ([]byte, error)
    DeleteKey(path []string, key string) error
    DeleteBucket(path []string, bkt string) error
}

All remaining features should go into services:

type LockService interface {
    // Grab a lock that will be released automatically in ttl time
    AcquireLock(token string, ttl time.Duration) error

    // Grab a lock that will be released automatically in ttl time
    ReleaseLock(token string) error
}

type CAService interface {
    // UpsertUserCA upserts the user certificate authority keys in OpenSSH authorized_keys format
    UpsertUserCA(CA) error

    // GetUserCAPub returns the user certificate authority public key
    GetUserCAPub() ([]byte, error)

    // Remote Certificate management
    UpsertRemoteCert(RemoteCert, time.Duration) error
    GetRemoteCerts(ctype string, fqdn string) ([]RemoteCert, error)
    DeleteRemoteCert(ctype string, fqdn, id string) error

    // GetCA returns private, public key and certificate for user CA
    GetUserCA() (*CA, error)

    // UpsertHostCA upserts host certificate authority keys in OpenSSH authorized_keys format
    UpsertHostCA(CA) error

    // GetHostCA returns private, public key and certificate for host CA
    GetHostCA() (*CA, error)

    // GetHostCACert returns the host certificate authority certificate
    GetHostCAPub() ([]byte, error)
}

type  UserService interface {
    // GetUserKeys returns a list of authorized keys for a given user
    // in a OpenSSH key authorized_keys format
    GetUserKeys(user string) ([]AuthorizedKey, error)

    // GetUsers  returns a list of users registered in the backend
    GetUsers() ([]string, error)

    // DeleteUser deletes a user with all the keys from the backend
    DeleteUser(user string) error

    // Upsert Public key in OpenSSH authorized Key format
    // user is a user name, keyID is a unique IDentifier for the key
    // in case if ttl is 0, the key will be upserted permanently, otherwise
    // it will expire in ttl seconds
    UpsertUserKey(user string, key AuthorizedKey, ttl time.Duration) error

    // DeleteUserKey deletes user key by given ID
    DeleteUserKey(user, key string) error
}

type PresenceService {
    // GetServers returns a list of registered servers
    GetServers() ([]Server, error)

    // UpsertServer registers server presence, permanently if ttl is 0 or
    // for the specified duration with second resolution if it's >= 1 second
    UpsertServer(s Server, ttl time.Duration) error
}

type WebService struct {
// UpsertPasswordHash upserts user password hash
    UpsertPasswordHash(user string, hash []byte) error
    // GetPasswordHash returns the password hash for a given user
    GetPasswordHash(user string) ([]byte, error)
    // UpsertSession
    UpsertWebSession(user, sid string, s WebSession, ttl time.Duration) error
    // GetWebSession
    GetWebSession(user, sid string) (*WebSession, error)
    // GetWebSessionsKeys
    GetWebSessionsKeys(user string) ([]AuthorizedKey, error)
    // DeleteWebSession
    DeleteWebSession(user, sid string) error
    UpsertWebTun(WebTun, time.Duration) error
    DeleteWebTun(prefix string) error
    GetWebTun(prefix string) (*WebTun, error)
    GetWebTuns() ([]WebTun, error)
}

type ProvisioningService interface {
    // Tokens are provisioning tokens for the auth server
    UpsertToken(token, fqdn string, ttl time.Duration) error
    GetToken(token string) (string, error)
    DeleteToken(token string) error
}

Both servers and clients should be implementing these interfaces and should use the same test suite.

I recommend not do it all at once, but take chunk by chunk out.

Sasha: "Overall I know that telescope does not have tests yet, can you start adding them here too? E.g. check the connection with and without certificate, with invalid certificate etc."

• Excessive locking in client

https://github.com/gravitational/teleport/blob/master/lib/client/client.go#L174

This lock is unnecessary, so simply remove it

• Magic strings

https://github.com/gravitational/teleport/blob/master/lib/services/provisioning.go#L71

Roles like Node and prefix n should be constants, not local strings

When closing regular ssh client connected to a node via proxy, input connection on the node is not closed.

Description

The outcome spec defines the CLI experience: the commands, flags, and help strings for all 3 teleport tools:

• tctl
• teleport

Solution

Two things:

1. Update kingpin flag configuration to match the CLI UX spec.
2. Make sure all user messages (whatever is printed to the Terminal) goes to stdout, and errors printed to stderr (right now the CLI tools use the log as the only "UI")

How Success Looks Like

Both server-side CLI tools will start speaking according to the spec. Not all commands are implemented, of course ("share" or "join" are missing). They should have default implementation placeholders, like "under construction".

Scenario 1 (On laptop w/ Gravity Proxy)

• The Host user is on their laptop in Terminal
• The Host runs into a problem, is looking for assistance
• Enter Teleport command into terminal: "tctl share --r" or "tctl share --rw" (read/write or read only)
• Link is given back to the user to share with guests
• Guests click on link and view host terminal in browser (see mockups).
• Host may be in native Terminal or go to browser, as well. [Additional points below assumes everyone is in browser; terminal is normal experience except guests can write to host's terminal if write access is given above.]
• Majority of browser window is a terminal emulator. Other elements include: who is present in session, active node, dropdown to navigate to other nodes, button to kill session (for host), button to add node.
• Participants can see who is typing into the terminal (avatar highlighting)
• Selecting a different node starts a new session but doesn't close old session.
• The owner of the node is able to kill the session ("tctl kill" or ctrl-c in terminal or kill button in active session. "tctl kill" would ask if you want to save session before killing and return link, if yes. ctrl-c would just kill automatically.)
• Guests of the session are shown a "This session is over" view once killed
• Once the session is over, the host is prompted to publish this session or not
• If yes to publish: The user is given the link to share and session is saved for some period of time
• If no to publish: The owner of the session is shown a "Thanks for using Teleport to collaborate" view and session is deleted.
• Playback mode should have: Play, Pause and scroll bar to move forward/back in time.

Note: for this scenario, I am thinking that other tabs should be hidden, including:

• Tab with history of all sessions
• Tab with list of all active sessions
• Tab with list of all nodes

Help says I can set up listen IP, but not listen port:

> teleport start --listen-ip=10.5.0.1 --roles=node --auth-server=10.5.0.2 --token=xyz

  Starts a SSH node listening on 10.5.0.1 and authenticating incoming clients via the 
  auth server running on 10.5.0.2. 

I need this to work ASAP because it's preventing me from working/testing the CLI/UI stuff.

Prerequisites

1. You need two nodes to reproduce this. I have assets/vagrant folder where you can do vagrant up and you'll get two machines (you only need one)
2. You must be on ev/105-tctl branch

Steps to reproduce

On your own machine, with a clean /var/lib/teleport start the auth server:

> out/teleport start -d 

-d means "verbose logging to stderr".

Now you can invite a new node called "bob":

> out/tctl node invite bob

Output:

The invite token: n686389ac321a6549b951ceb1607f0f596852f493ec1d5523ee4ff81944689a03
Run this on the new node to join the cluster:
> teleport start --roles=node --name=bob --token=n686389ac321a6549b951ceb1607f0f596852f493ec1d5523ee4ff81944689a03 --auth-server=<IP>

Notes:
  1. This invitation token will expire in 900 seconds.
  2. <Address> is the IP this auth server is reachable at from the node.

Now, log into one of the Vagrant machines and execute:

teleport/out/teleport start -d --roles=node --name=bob --token=n686389ac321a6549b951ceb1607f0f596852f493ec1d5523ee4ff81944689a03 --auth-server=xxx

And you will see that the node cannot join.

Config + Logs of the node:

telenode-a ~: teleport/out/teleport start -d --roles=node --name=klizhentas --token=n686389ac321a6549b951ceb1607f0f596852f493ec1d5523ee4ff81944689a03 --auth-server=192.168.121.1
INFO[0000] Using auth server: tcp://192.168.121.1:3025  
INFO[0000] Using auth token: n686389ac321a6549b951ceb1607f0f596852f493ec1d5523ee4ff81944689a03 
INFO[0000] data_dir: /var/lib/teleport
hostname: klizhentas
auth_servers: [{addr: '192.168.121.1:3025', addrnetwork: tcp, path: ""}]
ssh:
  enabled: true
  token: n686389ac321a6549b951ceb1607f0f596852f493ec1d5523ee4ff81944689a03
  addr:
    addr: 0.0.0.0:3022
    addrnetwork: tcp
    path: ""
  shell: /bin/bash
  limiter:
    rates: []
    max_connections: 25
    max_users: 25
  labels: {}
  label-commands: {}
auth:
  enabled: false
  ssh_addr:
    addr: 0.0.0.0:3025
    addrnetwork: tcp
    path: ""
  host_authority_domain: telenode-a
  token: ""
  secret_key: ""
  allowed_tokens: {}
  trusted_authorities: []
  user_ca_keypair:
    public:
      type: ""
      id: ""
      domain_name: ""
      public_key: ""
    private_key: ""
  host_ca_keypair:
    public:
      type: ""
      id: ""
      domain_name: ""
      public_key: ""
    private_key: ""
  keys_backend:
    type: bolt
    params: '{"path": "/var/lib/teleport/keys.db"}'
    encryption_keys: []
  events_backend:
    type: bolt
    params: '{"path": "/var/lib/teleport/events.db"}'
  records_backend:
    type: bolt
    params: '{"path": "/var/lib/teleport/records.db"}'
  limiter:
    rates: []
    max_connections: 25
    max_users: 25
reverse_tunnel:
  enabled: false
  token: ""
  dial_addr:
    addr: 127.0.0.1:3024
    addrnetwork: tcp
    path: ""
  limiter:
    rates: []
    max_connections: 25
    max_users: 25
proxy:
  enabled: false
  token: n686389ac321a6549b951ceb1607f0f596852f493ec1d5523ee4ff81944689a03
  reverse_tunnel_listen_addr:
    addr: 0.0.0.0:3024
    addrnetwork: tcp
    path: ""
  web_addr:
    addr: 0.0.0.0:3080
    addrnetwork: tcp
    path: ""
  ssh_addr:
    addr: 0.0.0.0:3023
    addrnetwork: tcp
    path: ""
  assets_dir: /var/lib/teleport
  tls_key: ""
  tlscert: ""
  limiter:
    rates: []
    max_connections: 25
    max_users: 25
console: 0

INFO[0000] teleport:register connecting to auth servers n686389ac321a6549b951ceb1607f0f596852f493ec1d5523ee4ff81944689a03 
ERRO[0000] teleport:ssh register failed: [register.go:50]  Post http://stub:0/v1/tokens/register: ssh: handshake failed: ssh: unable to authenticate, attempted methods [password none], no supported methods remain 
ERRO[0001] teleport:ssh register failed: [register.go:50]  Post http://stub:0/v1/tokens/register: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none password], no supported methods remain 
ERRO[0002] teleport:ssh register failed: [register.go:50]  Post http://stub:0/v1/tokens/register: ssh: handshake failed: ssh: unable to authenticate, attempted methods [password none], no supported methods remain 
ERRO[0003] teleport:ssh register failed: [register.go:50]  Post http://stub:0/v1/tokens/register: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none password], no supported methods remain 

Config + Logs on the auth server:

edsger ~/go/src/github.com/gravitational/teleport: out/teleport start -d
INFO[0000] data_dir: /var/lib/teleport
hostname: edsger
auth_servers: [{addr: '0.0.0.0:3025', addrnetwork: tcp, path: ""}]
ssh:
  enabled: true
  token: ""
  addr:
    addr: 0.0.0.0:3022
    addrnetwork: tcp
    path: ""
  shell: /bin/bash
  limiter:
    rates: []
    max_connections: 25
    max_users: 25
  labels: {}
  label-commands: {}
auth:
  enabled: true
  ssh_addr:
    addr: 0.0.0.0:3025
    addrnetwork: tcp
    path: ""
  host_authority_domain: edsger
  token: ""
  secret_key: ""
  allowed_tokens: {}
  trusted_authorities: []
  user_ca_keypair:
    public:
      type: ""
      id: ""
      domain_name: ""
      public_key: ""
    private_key: ""
  host_ca_keypair:
    public:
      type: ""
      id: ""
      domain_name: ""
      public_key: ""
    private_key: ""
  keys_backend:
    type: bolt
    params: '{"path": "/var/lib/teleport/keys.db"}'
    encryption_keys: []
  events_backend:
    type: bolt
    params: '{"path": "/var/lib/teleport/events.db"}'
  records_backend:
    type: bolt
    params: '{"path": "/var/lib/teleport/records.db"}'
  limiter:
    rates: []
    max_connections: 25
    max_users: 25
reverse_tunnel:
  enabled: true
  token: ""
  dial_addr:
    addr: 127.0.0.1:3024
    addrnetwork: tcp
    path: ""
  limiter:
    rates: []
    max_connections: 25
    max_users: 25
proxy:
  enabled: true
  token: ""
  reverse_tunnel_listen_addr:
    addr: 0.0.0.0:3024
    addrnetwork: tcp
    path: ""
  web_addr:
    addr: 0.0.0.0:3080
    addrnetwork: tcp
    path: ""
  ssh_addr:
    addr: 0.0.0.0:3023
    addrnetwork: tcp
    path: ""
  assets_dir: /var/lib/teleport
  tls_key: ""
  tlscert: ""
  limiter:
    rates: []
    max_connections: 25
    max_users: 25
console: 0

INFO[0000] Available 1 local seal keys:                 
INFO[0000] default key                                  
INFO[0000] Starting with an existing backend. Comparing local and remote keys. 
INFO[0000] Backend was initialized                      
INFO[0000] boltRecorder: deleting and closing testRecord 
INFO[0000] Acquire                                      
INFO[0000] Reading secret from /var/lib/teleport/teleport.secret 
INFO[0000] read key from /var/lib/teleport/edsger.key, cert from /var/lib/teleport/edsger.cert 
INFO[0000] Release                                      
INFO[0000] read key from /var/lib/teleport/edsger.key, cert from /var/lib/teleport/edsger.cert 
INFO[0000] read key from /var/lib/teleport/edsger.key, cert from /var/lib/teleport/edsger.cert 
INFO[0000] read key from /var/lib/teleport/edsger.key, cert from /var/lib/teleport/edsger.cert 
INFO[0000] [SSH]   Service is starting on 0.0.0.0:3022  
INFO[0000] [PROXY] Reverse tunnel service is starting on 0.0.0.0:3024 
INFO[0000] [PROXY] Web proxy service is starting on 0.0.0.0:3080 
INFO[0000] created listening socket: [::]:3024          
INFO[0000] [REVERSE TUNNEL] teleport tunnel agent starting 
INFO[0000] [::]:3024 ready to accept connections        
INFO[0000] agent connectting to tcp://127.0.0.1:3024    
INFO[0000] created listening socket: [::]:3022          
INFO[0000] [PROXY] SSH proxy service is starting on 0.0.0.0:3023 
INFO[0000] created listening socket: [::]:3023          
INFO[0000] [::]:3022 ready to accept connections        
INFO[0000] [AUTH]  Auth service is starting on 0.0.0.0:3025 
INFO[0000] [::]:3024 accepted connection from 127.0.0.1:51974 
INFO[0000] [::]:3023 ready to accept connections        
INFO[0000] created listening socket: [::]:3025          
WARN[0000] failed to announce services.Server{ID:"0.0.0.0_3022", Addr:"0.0.0.0:3022", Hostname:"edsger", Labels:map[string]string(nil), CmdLabels:map[string]services.CommandLabel(nil)} presence: Post http://stub:0/v1/servers: dial tcp 0.0.0.0:3025: getsockopt: connection refused 
INFO[0000] [::]:3025 ready to accept connections        
INFO[0000] [::]:3025 accepted connection from 127.0.0.1:48111 
INFO[0000] conn(127.0.0.1:48111->127.0.0.1:3025, user=edsger) auth attempt with key [email protected] 
INFO[0000] [::]:3025 accepted connection from 127.0.0.1:48112 
INFO[0000] conn(127.0.0.1:48112->127.0.0.1:3025, user=edsger) auth attempt with key [email protected] 
INFO[0000] new ssh connection 127.0.0.1:48111 -> 127.0.0.1:3025 vesion: SSH-2.0-Go 
INFO[0000] [AUTH] new channell request: direct-tcpip    
INFO[0000] new ssh connection 127.0.0.1:48112 -> 127.0.0.1:3025 vesion: SSH-2.0-Go 
INFO[0000] [AUTH] new channell request: direct-tcpip    
INFO[0000] checking key(id=local) against host edsger   
INFO[0000] matched key local for edsger                 
INFO[0000] reversetunnelconn(127.0.0.1:51974->127.0.0.1:3024, user=edsger) auth attempt with key [email protected] 
INFO[0000] [::]:3025 accepted connection from 127.0.0.1:48113 
INFO[0000] conn(127.0.0.1:48113->127.0.0.1:3025, user=edsger) auth attempt with key [email protected] 
INFO[0000] new ssh connection 127.0.0.1:48113 -> 127.0.0.1:3025 vesion: SSH-2.0-Go 
INFO[0000] [AUTH] new channell request: direct-tcpip    
INFO[0000] new ssh connection 127.0.0.1:51974 -> 127.0.0.1:3024 vesion: SSH-2.0-Go 
INFO[0000] tunagent(remote={127.0.0.1:3024 tcp }) connection established 
INFO[0000] will handle disconnects                      
INFO[0000] got new channel request: teleport-heartbeat  
INFO[0000] got heartbeat request from agent: &{0xc82023a100 0xc8200f44c0} 
INFO[0000] remoteSite(edsger) -> ping                   
INFO[0005] remoteSite(edsger) -> ping                   
INFO[0010] remoteSite(edsger) -> ping                   
INFO[0015] remoteSite(edsger) -> ping                   
INFO[0020] remoteSite(edsger) -> ping                   
INFO[0020] [::]:3025 accepted connection from 127.0.0.1:48118 
INFO[0020] conn(127.0.0.1:48118->127.0.0.1:3025, user=edsger) auth attempt with key [email protected] 
INFO[0020] new ssh connection 127.0.0.1:48118 -> 127.0.0.1:3025 vesion: SSH-2.0-Go 
INFO[0020] [AUTH] new channell request: direct-tcpip    
INFO[0020] [AUTH] new channell request: direct-tcpip    
INFO[0025] remoteSite(edsger) -> ping                   
INFO[0030] remoteSite(edsger) -> ping                   
INFO[0035] remoteSite(edsger) -> ping                   
INFO[0040] remoteSite(edsger) -> ping                   
INFO[0045] remoteSite(edsger) -> ping                   
INFO[0050] remoteSite(edsger) -> ping                   
INFO[0055] remoteSite(edsger) -> ping                   
INFO[0060] remoteSite(edsger) -> ping                   
INFO[0065] remoteSite(edsger) -> ping                   
INFO[0068] [::]:3025 accepted connection from 192.168.121.224:38670 
INFO[0068] got authentication attempt for user 'klizhentas' type 'provision-token' 
INFO[0068] failed to initiate connection, err: EOF      
INFO[0069] [::]:3025 accepted connection from 192.168.121.224:38671 
INFO[0069] got authentication attempt for user 'klizhentas' type 'provision-token' 
INFO[0069] failed to initiate connection, err: EOF      
INFO[0070] remoteSite(edsger) -> ping                   
INFO[0070] [::]:3025 accepted connection from 192.168.121.224:38672 
INFO[0070] got authentication attempt for user 'klizhentas' type 'provision-token' 
INFO[0070] failed to initiate connection, err: EOF      
INFO[0071] [::]:3025 accepted connection from 192.168.121.224:38673 
INFO[0071] got authentication attempt for user 'klizhentas' type 'provision-token' 
INFO[0071] failed to initiate connection, err: EOF      
INFO[0072] [::]:3025 accepted connection from 192.168.121.224:38674 
INFO[0072] got authentication attempt for user 'klizhentas' type 'provision-token' 
INFO[0072] failed to initiate connection, err: EOF      
INFO[0073] [::]:3025 accepted connection from 192.168.121.224:38675 
INFO[0073] got authentication attempt for user 'klizhentas' type 'provision-token' 
INFO[0073] failed to initiate connection, err: EOF      
INFO[0074] [::]:3025 accepted connection from 192.168.121.224:38676 
INFO[0074] got authentication attempt for user 'klizhentas' type 'provision-token' 
INFO[0074] failed to initiate connection, err: EOF      
INFO[0075] remoteSite(edsger) -> ping                   
INFO[0075] [::]:3025 accepted connection from 192.168.121.224:38677 
INFO[0075] got authentication attempt for user 'klizhentas' type 'provision-token' 
INFO[0075] failed to initiate connection, err: EOF      
INFO[0076] [::]:3025 accepted connection from 192.168.121.224:38678 
INFO[0076] got authentication attempt for user 'klizhentas' type 'provision-token' 
INFO[0076] failed to initiate connection, err: EOF      
INFO[0077] [::]:3025 accepted connection from 192.168.121.224:38679 
INFO[0077] got authentication attempt for user 'klizhentas' type 'provision-token' 
INFO[0077] failed to initiate connection, err: EOF      
INFO[0078] [::]:3025 accepted connection from 192.168.121.224:38680 
INFO[0078] got authentication attempt for user 'klizhentas' type 'provision-token' 
INFO[0078] failed to initiate connection, err: EOF      
INFO[0079] [::]:3025 accepted connection from 192.168.121.224:38681 
INFO[0079] got authentication attempt for user 'klizhentas' type 'provision-token' 
INFO[0079] failed to initiate connection, err: EOF      

I'll start with the TSH bugs & improvements as I'm still working on the configs.

Exiting a session

Closing an active session results in tsh simply printing "logout" and not returning to the prompt like regular ssh would:

> tsh into something
> exit
[logout]

Then you hit Enter and you get your prompt back, but the keyboard is disabled.

TSH is not conforming to SSH options

tsh ssh command does not accept options compatible with ssh. It should support the following syntax:

> tsh ssh -p 61822 [email protected] "ls /"

Similarly, tsh scp should do:

> tsh scp -r -P 61822 ../nginx [email protected]:/etc/nginx

Note: obviously only the subset of openSSH options should be supported, those that make sense for both (like username, port number, hostname, recursive scp or not, etc)

TSH does not use defaults

First of all, teleport (server and client) should use well-defined default ports. Here they are for reference:

3080  - HTTP
3081  - HTTPs 
3022  - SSH
3023  - SSH proxy
3024  - Auth

Now, specifically for tsh:

• tsh must use the current $USER as username (current user - same as $(id -u))
• use the default SSH port (same default port teleport server uses to listen)
• use the default web proxy port (same default port teleport web proxy uses)
• assume that web proxy is the same host as ssh proxy (but listens on web proxy default port)

All these should work:

tsh ssh jenkins.gravitational.io
tsh ssh -p 61822 jenkins.gravitational.io
tsh ssh -p 61822 [email protected]

And this must be invalid (incorrectly specified port):

tsh ssh jenkins.gravitational.io:61822

TSH profiles

In addition to using defaults (like above) tsh should then consultt $HOME/.tshconfig file. That file would store tsh defaults grouped into "environments". Here's an example:

work:
    ssh_proxy_host=bastion.gravitational.io
    ssh_web_proxy=bastion-web.gravitational.io
    username=ekontsevoy
    ssh_proxy_port=61822
    ssh_web_proxy_port=61823

personal:
    ssh_proxy_host=teleport.kontsevoy.com

Then a user may use commands like:

tsh -e work ssh -e work jenkins.gravitational.io

Also, the first environment in the file automatically becomes the default, meaning that its values are always applied unless -e is used with another environment.

Here's the precedence of settings (high to low)

1. Explicit flags, like -p for "port"
2. Values from explicitly specified environment (via -e flag)
3. If no -e flag is given, value from the default environment
4. Hardcoded defaults (like $USER or pre-defined port numbers from above)

To unify the interface, this package:

https://github.com/gravitational/teleport/blob/master/teleport/main.go

should use kingpin and posix-compatible flags too too.

Lens is not really a standalone project. Move it back to teleport and rename it to telescope, a folder inside the teleport main repository.

Right now Teleport UI is vulnerable to CSRF attack

To avoid this problem, I recommend switching to web session HTTPs cooke based storage to avoid XSS attacks that possible with local storage:

https://stormpath.com/blog/token-auth-spa/

However any other suggestions are welcoeme.

In order to deploy Teleport on a real server, the following should be accomplished first:

• Setting up a limit on simultaneous connections per client ip and user
• Setting up maximum number if authorization attempts per client ip and user
• Store private host CA keys and user CA keys in encrypted format
• Develop a policy for choosing OS user when exec commands

Teleport has a set of comprehensive test suits, builds should not be considered a success unless test pass.

Description

It appears Teleport does not validate user logins. For example I just created a user one,two. This presents a number of issues, most of them stemming from the fact that UNIX logins can only be composed of certain characters.

Try adding Linux user:

> useradd  one,two
useradd: invalid user name 'one,two'

Solution

Apply regular UNIX login limits to Teleport logins. There's no POSIX standard for this. The man page for useradd(8) says:

It is usually recommended to only use usernames that begin with a lower
case letter or an underscore, followed by lower case letters, digits,
underscores, or dashes. They can end with a dollar sign. In regular expression
terms: [a-z_][a-z0-9_-]*[$]?

BSD limit on usernames is 32 characters.

What success looks like?

All API calls that create users must return an error message similar to useradd above when the name doesn't conform to the regexp above or its length is greater than 32.

Description

This is related to #93 (read the comments there). We need a way to host mkdocs-generated documentation to Teleport protected by a password.

Solution

The same Jenkins server that serves the Wiki will also serve teleport documentation on a different domain, also protected by oauth2_proxy via Github. Quick & cheap.

What Success Looks Like

Create a similar setup, with Teleport documentation running on https://teleport.gravitational.io/docs. It should be re-deployed after every Teleport deployment

Description

We introduce a new concept of shared sessions, where users can invite and join others using simple commands tsh share and tsh join from the CLI (and as a part of a separate issue in a separate outcome) to users' laptop.

Check out sections about tsh share and tsh join following this link:

https://wiki.gravitational.io/outcomes/2/tsh/

Implementation

Glossary

• session owner - user who called tsh share
• session gues - user who called tsh join
• Hangout - special object and API on the auth server of session owner
• RemoteHangout - entry in the proxy's memory that is associated with reverse tunnel from session owner

Hangouts

To address the feature set, we have to introduce a new concept in Teleport, let's call them hangouts. (we already have sessions reserved in teleport internals, so this will help us to organize.

Here's what properties hangout object has:

• state one of active, replay
• accessMode - rw or ro where rw is read write and ro is read only
• secretToken - CSPRNG random key of 32 bytes that grants read and write access

Hangout state is dynamic:

• When session owner creates a hangout using tsh share the hangout is crated in active state
• Session owner's client then heartbeats it's activity renewing the state property
• If session owner has become inactive or missed heartbeat the session's state will automatically will be set to replay state. (This could be achieved by using etcd expiring keys, where presence of the key means active the absence means replay

IMPORTANT* Hangouts, and all other state is managed on the user's laptop, and not on the proxy. Teleport proxy's behavior is explained below.

TSH share behavior

When user executes tsh share command, the following happens:

• tsh starts local authority server ( to speed up cert generation process for multiple share commands, private key will be created only once, after first tsh share, next calls wil re-use the same private key)
• tsh starts a new ssh node that registers within local authority
• tsh creates a hangout object within it's laptop authority server
• tsh starts a reverse tunnel client dialing remote proxy server. (NOTE: here teleport proxy has to auth remote tunnel's authority, what is described in the separate section)
• tsh provides a secret session id to the proxy server in the heartbeat, so proxy knows the list of remote hangouts and their secret tokens.
• Once user presses CTRL-D tsh will stop ssh server, local auth server and explicitly set hangout to playback state.

TSH join behavior

When user executes tsh join url

• tsh calls proxy's API to access remote user's site auth server by opening direct-tcp-ip channel to the API of the remote auth server started by session owner
• teleport proxy checks if the secret token was presented by any of tsh share commands and rejects the request if it's not valid
• in case if the token is valid, proxy opens a direct tcp ip channel to session owner's authority server so tsh join can call hangouts API
• tsh share then calls session owner's authority server API to add it's public key to remote authorities trusted by her instance of auth server
• auth server of session owner creates a special role for this user based on hangout state:
  • if the access mode is rw and hangout is in active state tsh starts ssh client using proxy as a jump host and tries to ssh into end user's remote node
  • if the access mode is roor session is in playback state tsh starts polling events API of this session and playback it to the user (the events API already provides playback features: https://github.com/gravitational/teleport/blob/master/lib/web/site.go#L126
• session guest calls session owner's auth API to figure out access mode of this hangout and it's state and either calls the events API to playback/stream the realtime events or connects to the node using hangout secret ID as the identifier and joins the user. (Note that regardless of the state, role allows or denies access to certain methods based on the session state, if session is in 'ro' mode, the role would simply not allow connecting to the end server even if session guest wanted to)

*IMPORTANT: Notice that all actual interaction uses standard SSH authorities feature set, and only a small subset of methods uses special auth based on the secret token id. Also note, that Teleport Proxy does never actually encrypt / decrypt the session and acts as a non-intercepting that can not even decrypt the data passing through it.

Also note that in all of these cases, tsh actually uses user's authority's server remote API

Teleport proxy behavior

Teleport proxy will get a special list of RemoteHangouts sessions, just like sites implemented here but limited in scope.

When a new incoming connection from session owner to register a new site happens on the proxy, the proxy will add it to the list of RemoteHangouts, keeping secret tokens for every hangout.

Q: How to allow or not allow RemoteHangouts to be registered within the proxy server?
A: If the proxy server is started in "public" mode for hangouts (only available on gravitational.io website), anyone can register RemoteHangout tunnel. If the proxy server is started in normal mode, all requests will be authenticated by usual method, what means that only session owners who have keys signed by teleport proxy's trusted authority will be able to create RemoteHangout.

Teleport Auth server behavior

Teleport Auth server will have to introduce new roles:

• Remote party read only role for any user identified by remote certificate authority that only allows to call /events/player method to retrieve the list of events
• Remote party read write role that can ssh into the server and call the playback

Teleport web UI behavior

Note, that in case of new UI, the web client will be actually started on laptop as well, and will use the same feature set using direct-tcp IP tunnel talking to remote server's API

Sequence diagram

This design above can be demonstrated by this sequence diagram:

How success looks like

• tsh share and tsh join work as described in https://wiki.gravitational.io/outcomes/2/tsh
• teleport proxy does not store or decrypt any traffic between peers
• all data including events, sessions and other stuff is stored on session owner's laptop
• tsh share and tsh join work on linux and OSX

Launch teleport-embed. Watch htop or top. Should probably plug Sasha into this.