SecureDrop always attempts installation via Tor if -ssh.auth_private files exist on Admin Workstation

[nathandyer]

Description

This may be a bug with SecureDrop, or may instead be an opportunity for us to improve our documentation. In situations where a SecureDrop user had previously installed the system successfully and enabled SSH over Tor, but then elected to re-provision the servers with a clean installation of Ubuntu Server, when trying to re-run the playbooks they will fail with an SSH error because Ansible attempts to use onion services (which are no longer running on the servers) because it's only checking for the presence of the -ssh.auth_private files to determine how to connect to the servers.

Steps to Reproduce

1. Install SecureDrop with SSH-over-Tor enabled
2. Reinstall Ubuntu Server on App and Mon
3. Remove .ssh/config and generate new SSH keys
4. Copy SSH keys onto the new servers
5. Verify that ssh app and ssh mon work as expected
6. Run ./securedrop-admin install

Expected Behavior

The install run completes as expected.

Actual Behavior

The install run fails due to an SSH error.

Comments

A viable workaround is to rename the -ssh.auth_private files to -ssh.auth_private.bak (or remove them), which will cause Ansible to fall back to the LAN addresses.

[zenmonkeykstop]

The overall issue is valid - but I don't see how the STR would work here unless you also nuke .ssh/config and somehow replace it with a version that uses IP addresses for the host aliases for app and mon.

[nathandyer]

Thanks @zenmonkeykstop, you're right - that is a necessary part of the steps to reproduce that I didn't specify; I've updated the issue report to add that in.