You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In all migration docs, we should clarify the procedure for preserving SSH access from additional Admin Workstations beyond the one that is used to perform the migration.
Depending on resolution for #174, this may involve copying the SSH keys; it certainly involves copying the Monitor Server's new onion address and v3 keys (its original config is not preserved).
As an admin, I don't want to be caught by surprise after a migration that I can access app but not mon from one of my Admin Workstations, so that I can perform maintenance tasks without issues.
The text was updated successfully, but these errors were encountered:
In all migration docs, we should clarify the procedure for preserving SSH access from additional Admin Workstations beyond the one that is used to perform the migration.
Depending on resolution for #174, this may involve copying the SSH keys; it certainly involves copying the Monitor Server's new onion address and v3 keys (its original config is not preserved).
The Focal Migration docs currently point to https://docs.securedrop.org/en/stable/v3_services.html#update-tails-v3; however, this is written from the point of view of ensuring v3 access after v2 is disabled, and it's not clear that it's a required step even for v3-only instances.
User Story
As an admin, I don't want to be caught by surprise after a migration that I can access
app
but notmon
from one of my Admin Workstations, so that I can perform maintenance tasks without issues.The text was updated successfully, but these errors were encountered: