Repository: freedomofpress/securedrop

Issue:
[docs] Document from-scratch reprovisioning of Admin Workstation
If an admin does not have a working copy of their Admin Workstation, they may need to manually re-provision it from scratch -- using either a partially working copy, or only the data on their server. We have documented the process for updating *old* Admin Workstations in various update guides, but we have not documented the process for creating a new Admin Workstation for an existing installation.

# User Story

As an admin, I don't want to have to call FPF if my admin workstation is borked, so I can solve problems quickly on my own.


Discussion:
Note: There are a couple of old mega-issues related to this, credential recovery (#1091) and disaster recovery (#1128). Those old issues merit updating and refactoring into more organized epics, but documenting this particular task would help with a common issue and get us one step closer to the bigger goal of fully fleshed out recovery procedures.
There are existing ad-hoc docs for this - one concern might be that this would *also* be a guide to cloning the admin workstation given just temporary access to the SecureDrop servers. Nothing that a capable adversary wouldn't be able to figure out independently, but 'drive-by' adversaries (nosy contractors or disgruntled employees left alone in the DC) could use it.

Explicitly making the USB backup part of setup, and having better docs for restoring from backups, might be as useful here.
> Explicitly making the USB backup part of setup, and having better docs for restoring from backups, might be as useful here.

I agree those do need to be done, but given the number of existing installs & the fact that not all admins follow the instructions, I don't think we can get around the need for recovery docs.

I personally don't think it significantly expands the risk of malfeasance -- a disgruntled staffer with the criminal energy, motivation, and access to the servers who can follow such docs would likely also be able to find another way to do comparable harm. But flagging to @emkll as well.
> There are existing ad-hoc docs for this - one concern might be that this would also be a guide to cloning the admin workstation given just temporary access to the SecureDrop servers. Nothing that a capable adversary wouldn't be able to figure out independently, but 'drive-by' adversaries (nosy contractors or disgruntled employees left alone in the DC) could use it.

That's a good point, but I think it would be safe to say that any malicious actor that has physical access to the servers and run arbitrary commands and install whatever software they want, without resorting to an SD admin stick. As part of this docs update, it might be worth restarting the importance of physical security, given the lack of disk encryption.

Another point that might be worth raising in this docs update is credential rotation for departing admins: each user (and admin) has their account on the Journalist interface, but we do not have any docs to rotate workstation private keys, which might be useful in case an admin is departing a news org.

Given recent user reports of the process not yet added to the official docs for this, it will probably need to be made simpler. Right now it involves:
- optionally resetting the server admin password on the console, 
- pulling in a new SSH key, 
- transcribing hidden service addresses manually, 
- and then pulling a bunch of config information from the servers over SSH-over-Tor to rebuild the Admin Workstation config.

A more automatable process might be:
- optionally resetting the server admin password via the console
- adding an iptables rule allowing SSH from the Admin Workstation IP when connected to the FW.
- connecting the Admin WS to the firewall, doing `ssh-copy-id` and either doing the manual config steps mentioned above or running a new `securedrop-admin` command that also does them.
- running `./securedrop-admin install` when done to ensure the state of the servers, including iptables rules, is correct.

(Re: @emkll's comment, to encourage people to rotate keys in this scenario, `~/.ssh/authorized_keys` could also be deleted during the console-based step above. Probably less error-prone than doing it after the fact.)

Resolving patch:
diff --git a/admin/securedrop_admin/__init__.py b/admin/securedrop_admin/__init__.py
--- a/admin/securedrop_admin/__init__.py
+++ b/admin/securedrop_admin/__init__.py
@@ -761,6 +761,17 @@ def set_default_paths(args):
     return args
 
 
+def reset_admin_access(args):
+    """Resets SSH access to the SecureDrop servers, locking it to
+    this Admin Workstation."""
+    sdlog.info("Resetting SSH access to the SecureDrop servers")
+    ansible_cmd = [
+        'ansible-playbook',
+        os.path.join(args.ansible_path, 'securedrop-reset-ssh-key.yml'),
+    ]
+    return subprocess.check_call(ansible_cmd, cwd=args.ansible_path)
+
+
 def parse_argv(argv):
     class ArgParseFormatterCombo(argparse.ArgumentDefaultsHelpFormatter,
                                  argparse.RawTextHelpFormatter):
@@ -814,6 +825,10 @@ class ArgParseFormatterCombo(argparse.ArgumentDefaultsHelpFormatter,
                                        help=get_logs.__doc__)
     parse_logs.set_defaults(func=get_logs)
 
+    parse_reset_ssh = subparsers.add_parser('reset_admin_access',
+                                            help=reset_admin_access.__doc__)
+    parse_reset_ssh.set_defaults(func=reset_admin_access)
+
     return set_default_paths(parser.parse_args(argv))
 
 


Test patch: