Logging in via SSH
Server SSH Access
Generally, you should avoid directly SSHing into the servers in favor of using
the Admin Interface or
securedrop-admin. However, in some cases,
you may need to SSH in order to troubleshoot and fix a problem that cannot be
resolved via these tools.
You can access your Application Server and Monitor Server via SSH by
using either the
ssh app or
ssh mon commands (respectively) from an
For quick access, use the “SSH into the App Server” and “SSH into the Monitor Server” options in the SecureDrop Menu.
In this section we cover basic commands you may find useful when you SSH into the Application Server and Monitor Server.
When you SSH into either SecureDrop server, you will be dropped into a
tmux is a screen multiplexer - it allows you to tile
panes, preserve sessions to keep your session alive if the network
connection fails, and more. Check out this tmux tutorial to learn how
If you want a refresher of the Linux command line, we recommend this resource to cover the fundamentals.
Shutting Down the Servers
sudo shutdown now -h
Rebooting the Servers
Consult our Investigating Logs topic guide for locations of the most relevant log files you may want to examine as part of troubleshooting, and for how to enable error logging for the Source Interface.
You can use the
securedrop-admin tool to extract logs to
send to Freedom of the Press Foundation for analysis. Run the following
command on your Admin Workstation:
cd ~/Persistent/securedrop ./securedrop-admin logs
This command will produce encrypted tarballs containing logs from each server. See the command output for more information.
Immediately Apply a SecureDrop Update
SecureDrop will update and reboot once per day. However, once a SecureDrop update is announced, you can opt to fetch the update immediately.
Except where otherwise indicated, make sure to update both your Application Server and your Monitor Server.
To update your servers immediately, you can SSH
into each server (via
ssh app and
ssh mon) and run the following commands:
sudo apt update
Depending on the nature of the update (e.g., if the
tor package is
upgraded and you are using SSH-over-Tor), your SSH connection may be
interrupted, and you may have to reconnect to see the full output.
Adding Users (CLI)
After the provisioning of the first admin account, we recommend using the Admin Interface web application for adding additional journalists and admins.
However, you can also add users via
as described during first install.
You can use this command line method if the web application is unavailable.
Restart the Web Server
If you make changes to your Apache configuration, you may want to restart the web server to apply the changes:
sudo service apache2 restart
Cleaning up deleted submissions
When submissions are deleted through the web interface, their database records are deleted and their encrypted files are securely wiped. For large files, secure removal can take some time, and it’s possible, though unlikely, that it can be interrupted, for example by a server reboot. In older versions of SecureDrop this could leave a submission file present without a database record.
As of SecureDrop 1.0.0, automated checks send OSSEC alerts when this
situation is detected, recommending you run
list-disconnected-fs-submissions to see the files affected. As with
manage.py usage, you would run the following on the admin
sudo -u www-data bash
You then have the option of running:
to clean them up. As with any potentially destructive operation, it’s recommended that you back the system up before doing so.
There is also the inverse scenario, where a database record could point to a file that no longer exists. This would usually only have happened as a result of disaster recovery, where perhaps the database was recovered from a failed hard drive, but some submissions could not be. The OSSEC alert in this case would recommend running:
To clean up the affected records you would run (again, preferably after a backup):
Even when submissions are completely removed from the application
server, their encrypted files may still exist in backups. We recommend
that you delete old backup files with
shred, which is available on
If you make changes to your OSSEC monitoring configuration, you will want to
restart OSSEC via OSSEC’s control script,
sudo /var/ossec/bin/ossec-control restart