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 Admin Workstation.

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.

Tip

When you SSH into either SecureDrop server, you will be dropped into a tmux session. 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 to use tmux.

Tip

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

sudo reboot

Investigating Logs

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.

Note

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.

Important

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
sudo unattended-upgrades

Note

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.

Application Server

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 ./manage.py in /var/www/securedrop/ 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 manage.py list-disconnected-fs-submissions to see the files affected. As with any manage.py usage, you would run the following on the admin workstation:

ssh app
sudo -u www-data bash
cd /var/www/securedrop
./manage.py list-disconnected-fs-submissions

You then have the option of running:

./manage.py delete-disconnected-fs-submissions

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:

./manage.py list-disconnected-db-submissions

To clean up the affected records you would run (again, preferably after a backup):

./manage.py delete-disconnected-db-submissions

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 Tails.

Monitor Server

Restart OSSEC

If you make changes to your OSSEC monitoring configuration, you will want to restart OSSEC via OSSEC’s control script, ossec-control:

sudo /var/ossec/bin/ossec-control restart