Skip to content
This repository was archived by the owner on Jan 22, 2025. It is now read-only.

Commit d60ba2e

Browse files
authored
Merge pull request #43 from keybase/david/read-the-docs
Migrate documentation to readthedocs.io
2 parents 36a17dc + cec4bf6 commit d60ba2e

File tree

15 files changed

+487
-199
lines changed

15 files changed

+487
-199
lines changed

.gitignore

Lines changed: 5 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -3,4 +3,8 @@ keybaseca.config
33
nohup.out
44
env.sh
55
__pycache__
6-
generated-env
6+
7+
# sphinx generated files:
8+
_build
9+
_static
10+
_templates

README.md

Lines changed: 3 additions & 193 deletions
Original file line numberDiff line numberDiff line change
@@ -22,197 +22,7 @@ This repo provides the pieces for anyone to build this workflow on top of Keybas
2222

2323
Removing a user's ability to access a server is as simple as removing them from the Keybase team.
2424

25-
# Getting Started
25+
# Documentation
2626

27-
kssh allows you to define realms of servers where access is granted based off of
28-
membership in different teams. Imagine that you have a staging environment that everyone should be granted access to and
29-
a production environment that you want to restrict access to a smaller group of people. For this exercise we'll also set
30-
up a third realm that grants root access to all machines. To configure kssh to work with this setup, we will set it up
31-
according to this diagram:
32-
33-
![Architecture Diagram](https://raw.githubusercontent.com/keybase/bot-sshca/master/docs/Architecture%20Diagram.png "Architecture Diagram")
34-
35-
On a secured server that you wish to use to run the CA chatbot:
36-
37-
```bash
38-
git clone git@github.com:keybase/bot-sshca.git
39-
cd bot-sshca/docker/
40-
cp env.sh.example env.sh
41-
keybase signup # Creates a new Keybase user to use for the SSH CA bot
42-
keybase paperkey # Generate a new paper key
43-
# Create `{TEAM}.ssh.staging`, `{TEAM}.ssh.production`, `{TEAM}.ssh.root_everywhere` as new Keybase subteams
44-
# and add the bot to those subteams. Add users to those subteams based off of the permissions you wish to grant
45-
# different users
46-
nano env.sh # Fill in the values including the previously generated paper key
47-
make generate # Generate a new CA key
48-
```
49-
50-
Running `make generate` will output a list of configuration steps to run on each server you wish to use with the CA chatbot.
51-
These commands create a new user to use with kssh (the `developer` user), add the CA's public key to the server, and
52-
configure the server to trust the public key.
53-
54-
Now you must define a mapping between Keybase teams the users and servers that they are
55-
allowed to access. If you wish to make the user foo available to anyone in team.ssh.bar,
56-
create the file `/etc/ssh/auth_principals/foo` with contents `team.ssh.bar`.
57-
58-
More concretely following the current example setup:
59-
60-
* For each server in your staging environment:
61-
1. Create the file `/etc/ssh/auth_principals/root` with contents `{TEAM}.ssh.root_everywhere`
62-
2. Create the file `/etc/ssh/auth_principals/developer` with contents `{TEAM}.ssh.staging`
63-
* For each server in your production environment:
64-
1. Create the file `/etc/ssh/auth_principals/root` with contents `{TEAM}.ssh.root_everywhere`
65-
2. Create the file `/etc/ssh/auth_principals/developer` with contents `{TEAM}.ssh.production`
66-
67-
Now on the server where you wish to run the chatbot, start the chatbot itself:
68-
69-
```bash
70-
make serve # Runs inside of docker for ease of use
71-
```
72-
73-
Now download the kssh binary and start SSHing! See https://github.com/keybase/bot-sshca/releases to download the most
74-
recent version of kssh for your platform.
75-
76-
```bash
77-
sudo mv kssh-{platform} /usr/local/bin/kssh
78-
sudo chmod +x /usr/local/bin/kssh
79-
80-
kssh developer@staging-server-ip # If in {TEAM}.ssh.staging
81-
kssh developer@production-server-ip # If in {TEAM}.ssh.production
82-
kssh root@server # If in {TEAM}.ssh.root_everywhere
83-
```
84-
85-
We recommend building kssh yourself and distributing the binary among your team (perhaps in Keybase Files!).
86-
87-
# Network Architecture
88-
89-
Since all communication between the kssh client and the SSH CA server happens over Keybase chat, it is possible (and recommended)
90-
to firewall off the SSH CA server so it cannot be reached from the general internet. Additionally, note that the SSH servers
91-
that trust the SSH CA do not need to communicate with Keybase's servers or with the CA server and thus it is also possible
92-
to firewall off the SSH servers from the general internet. Clients running kssh need to have Keybase running locally with
93-
a connection to Keybase's servers.
94-
95-
# OS Support
96-
97-
It is recommended to run the server component of this bot on linux and running it in other environments is untested.
98-
`kssh` is tested and works correctly on linux, macOS, and Windows. If running on windows, note that there is a dependency
99-
on the `ssh` binary being in the path. This can be installed in a number of different ways including
100-
[Chocolatey](https://chocolatey.org/packages/openssh) or the
101-
[built in version](https://docs.microsoft.com/en-us/windows-server/administration/openssh/openssh_install_firstuse) on
102-
modern versions of windows.
103-
104-
# Using kssh with jumpboxes and bastion hosts
105-
106-
kssh should work correctly with jumpboxes and bastion hosts as long as they are configured to trust the SSH CA and the usernames are correct. For example:
107-
108-
```
109-
kssh -J developer@jumpbox.example.com developer@server.internal
110-
```
111-
112-
This can also be made easier by setting the kssh default ssh-username locally, then you won't have to specify it for each server.
113-
114-
```
115-
kssh --set-default-user developer
116-
kssh -J jumpbox.example.com server.internal
117-
```
118-
119-
# Contributing
120-
121-
There are two separate binaries built from the code in this repo:
122-
123-
## keybaseca
124-
125-
`keybaseca` is the CA server that exposes an interface through Keybase chat. This binary is meant to be run in a secure
126-
location.
127-
128-
```
129-
NAME:
130-
keybaseca - An SSH CA built on top of Keybase
131-
132-
USAGE:
133-
keybaseca [global options] command [command options] [arguments...]
134-
135-
VERSION:
136-
0.0.1
137-
138-
COMMANDS:
139-
backup Print the current CA private key to stdout for backup purposes
140-
generate Generate a new CA key
141-
service Start the CA service in the foreground
142-
help, h Shows a list of commands or help for one command
143-
144-
GLOBAL OPTIONS:
145-
--help, -h show help
146-
--version, -v print the version
147-
```
148-
149-
## kssh
150-
151-
`kssh` is the replacement SSH binary. kssh handles provisioning (via the keybaseca-bot) new temporary SSH keys and is meant to be installed on each
152-
user's laptop.
153-
154-
```
155-
NAME:
156-
kssh - A replacement ssh binary using Keybase SSH CA to provision SSH keys
157-
158-
USAGE:
159-
kssh [kssh options] [ssh arguments...]
160-
161-
VERSION:
162-
0.0.1
163-
164-
GLOBAL OPTIONS:
165-
--help Show help
166-
-v Enable kssh and ssh debug logs
167-
--provision Provision a new SSH key and add it to the ssh-agent. Useful if you need to run another
168-
program that uses SSH auth (eg scp, rsync, etc)
169-
--set-default-bot Set the default bot to be used for kssh. Not necessary if you are only in one team that
170-
is using Keybase SSH CA
171-
--clear-default-bot Clear the default bot
172-
--bot Specify a specific bot to be used for kssh. Not necessary if you are only in one team that
173-
is using Keybase SSH CA
174-
--set-default-user Set the default SSH user to be used for kssh. Useful if you use ssh configs that do not set
175-
a default SSH user
176-
--clear-default-user Clear the default SSH user
177-
--set-keybase-binary Run kssh with a specific keybase binary rather than resolving via $PATH
178-
```
179-
180-
## Architecture
181-
182-
#### Config
183-
184-
Keybaseca is configured using environment variables (see docs/env.md for information on all of the options). When keybaseca
185-
starts, it writes a client config file to `/keybase/team/{teamname for teamname in $TEAMS}/kssh-client.config`. This
186-
client config file is how kssh determines which teams are using kssh and the needed information about the bot (eg the
187-
channel name, the name of the bot, etc). When keybaseca stops, it deletes all of the client config files.
188-
189-
kssh reads the client config file in order to determine how to interact with a bot. kssh does not have any user controlled
190-
configuration. It does have one local config file stored in `~/.ssh/kssh-config.json` that is used to store a few settings
191-
for kssh. By default, this config file is not used. It is only created and meant to be interacted with via the
192-
`--set-default-bot`, `--clear-default-bot`, `--set-default-user`, `--clear-default-user` flags.
193-
194-
#### Communication
195-
196-
kssh and keybaseca communicate with each other over Keybase chat. If the `CHAT_CHANNEL` environment variable is
197-
specified in keybaseca's environment, keybaseca will only accept communication in the specified team and channel.
198-
This configuration is passed to kssh clients via the client config file(s) stored in KBFS. If the `CHAT_CHANNEL` environment variable
199-
is not specified then keybaseca will accept messages in any channel of any team listed in the `TEAMS` environment variable.
200-
All communication happens via the Go chatbot library.
201-
202-
Prior to sending a `SignatureRequest`, kssh sends a series of `AckRequest` messages. An `AckRequest` message is sent until
203-
kssh receives an `Ack` from keybaseca. This is done in order to ensure that kssh has correctly connected to the chat channel
204-
and that the bot is responding to messages. Afterwards, a `SignatureRequest` packet is sent and keybaseca parses it and
205-
returns a signed key. Note that only public keys and signatures are sent over Keybase chat and private keys never
206-
leave the devices they were generated on.
207-
208-
#### KBFS
209-
210-
In order to ensure that keybaseca can run inside of docker (which does not support FUSE filesystems without adding
211-
the CAP_SYS_ADMIN permission), all KBFS interactions are done via `keybase fs ...` commands. This makes it so that
212-
keybaseca can run in unprivileged docker containers.
213-
214-
# Integration Tests
215-
216-
This project contains integration tests that can be run via `./integrationTest.sh`. The integration tests depend on
217-
docker and docker-compose. The first time you run them, they will walk you through creating two new accounts to be
218-
used in the tests. The credentials for these accounts will be stored in `tests/env.sh`.
27+
See the [documentation website](https://keybase-ssh-ca-bot.readthedocs.io/en/latest/) for information on getting started,
28+
best practices, the architecture, and contributing.

docker/Makefile

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -23,7 +23,7 @@ generate: env-file-exists build
2323
@echo "echo \"AuthorizedPrincipalsFile /etc/ssh/auth_principals/%u\" >> /etc/ssh/sshd_config"
2424
@echo "chmod g-w /etc # On some distributions /etc is group writable which will cause SSH to refuse to run"
2525
@echo "service ssh restart"
26-
@echo -e "\nSee the README for information on how to define which teams are allowed to access which servers"
26+
@echo -e "\nSee the getting started docs for information on how to define which teams are allowed to access which servers"
2727

2828
# Start the CA chatbot in the background
2929
serve: env-file-exists ca-key-exists build

docs/Makefile

Lines changed: 19 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,19 @@
1+
# Minimal makefile for Sphinx documentation
2+
#
3+
4+
# You can set these variables from the command line.
5+
SPHINXOPTS =
6+
SPHINXBUILD = sphinx-build
7+
SOURCEDIR = .
8+
BUILDDIR = _build
9+
10+
# Put it first so that "make" without argument is like "make help".
11+
help:
12+
@$(SPHINXBUILD) -M help "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O)
13+
14+
.PHONY: help Makefile
15+
16+
# Catch-all target: route all unknown targets to Sphinx using the new
17+
# "make mode" option. $(O) is meant as a shortcut for $(SPHINXOPTS).
18+
%: Makefile
19+
@$(SPHINXBUILD) -M $@ "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O)

docs/architecture.md

Lines changed: 17 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,17 @@
1+
# Architecture
2+
3+
The Keybase SSH CA system works according to this diagram:
4+
5+
![Architecture Diagram](https://raw.githubusercontent.com/keybase/bot-sshca/master/docs/Architecture%20Diagram.png "Architecture Diagram")
6+
7+
Note that this means that you do not need to modify your servers in any
8+
way or run any additional processes on your servers other than a standard
9+
OpenSSH daemon.
10+
11+
## Network Architecture
12+
13+
Since all communication between the kssh client and the SSH CA server happens over Keybase chat, it is possible (and recommended)
14+
to firewall off the SSH CA server (where this bot is running) so it cannot be reached from the general internet. Additionally, note that the SSH servers
15+
that trust the SSH CA do not need to communicate with Keybase's servers or with the CA server and thus it is also possible
16+
to firewall off the SSH servers from the general internet. Clients running kssh need to have Keybase running locally with
17+
a connection to Keybase's servers.

docs/bastions.md

Lines changed: 14 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,14 @@
1+
# Jumpboxes and Bastion Hosts
2+
3+
kssh should work correctly with jumpboxes and bastion hosts as long as they are configured to trust the SSH CA and the usernames are correct. For example:
4+
5+
```
6+
kssh -J developer@jumpbox.example.com developer@server.internal
7+
```
8+
9+
This can also be made easier by setting the kssh default ssh-username locally, then you won't have to specify it for each server.
10+
11+
```
12+
kssh --set-default-user developer
13+
kssh -J jumpbox.example.com server.internal
14+
```

docs/best_practices.md

Lines changed: 31 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,31 @@
1+
# Best Practices
2+
3+
## Teams and Channels
4+
5+
The SSH CA bot user needs to have write access in all of the teams used for granting SSH access in order for it to
6+
be able to store config files associated with each team. Since access to a team grants SSH access to servers, it is
7+
recommended to minimize the number of users with admin or owner permissions in the teams. Individual users of kssh
8+
only need to be given the read permission since they do not need to be able to edit or create files associated with
9+
a team.
10+
11+
It is also recommended to mute all notifications in the configured teams in order to minimize the number of notifications
12+
you get.
13+
14+
If you are using other bots in the same teams as the SSH CA bot (or if you wish to have normal conversation in those
15+
teams), you can use the `CHAT_CHANNEL` environment variable in order to configure a specific chat channel for all
16+
SSH CA messages.
17+
18+
## Network Isolation
19+
20+
Due to the highly sensitive nature of the SSH CA bot, it is recommended to configure firewalls in order to block all
21+
access to the server running the CA bot. It is not recommended to use kssh to access the server of the CA bot itself
22+
in order to make it easier to respond to any outages.
23+
24+
## Realms
25+
26+
There are two general approaches one can take when defining realms of servers. The first approach (described in the
27+
getting started directions) is to define realms for staging and production. This approach is useful for the common
28+
scenario where all developers should be given access to the staging environment but only certain people should be given
29+
access to production. The second approach is a more granular approach where you can define realms associated with teams.
30+
For example, one could have a realm of web servers, a realm of database servers, ... where a specific group of people
31+
is responsible for each class of server.

0 commit comments

Comments
 (0)