Second SSH necessary? How to keep the droplet active without an active session?

For your first question, if you’ve already set up SSH access following the first tutorial then no need to do it again while following the second.

For your second question: Yes, closing PuTTY will stop the script if you just started it by running it directly as it logs out your user and ends it session. There are a number of ways to ensure that a long running process persists after logging out. You could use a tool like screen to keep your session open after closing PuTTY. Or you could set up your script to be run like a service.

Debian 8 uses systemd for it’s init system. To run your script as a service, you can create a systemd unit file: /etc/systemd/system/myscript.service

[Unit]
Description=My script

[Service]
Type=simple
ExecStart=/usr/bin/python /path/to/myscript.py

[Install]
WantedBy=multi-user.target

You can then start and stop your script like you would any other system service:

root@debian:~# sudo service myscript start
root@debian:~# sudo service myscript status
● myscript.service - My script
   Loaded: loaded (/etc/systemd/system/myscript.service; disabled)
   Active: active (running) since Fri 2015-10-30 13:33:31 EDT; 1s ago
 Main PID: 1220 (python)
   CGroup: /system.slice/myscript.service
           └─1220 /usr/bin/python /root/myscript.py

You can find some more in-depth info on working with systemd here:

• Systemd Essentials: Working with Services, Units, and the Journal

Heya,

First Question about second SSH:

The second SSH configuration you’re referring to in Step Four is not about setting up a new SSH connection but rather hardening the existing SSH configuration to make it more secure. The changes suggested in the guide include:

• Changing the default SSH port: This helps to fend off automated attacks that target the default port 22.
• Disabling root login: Disabling direct root login ensures that if someone wants to get root access, they first have to break into a normal user account and then escalate their privileges. It adds another layer of security.
• Disabling password authentication: Once you’ve set up key-based authentication, you can disable password-based authentication, making brute-force attacks virtually impossible.

Even if you’re the only one accessing your server, it’s essential to follow these best practices to avoid potential unauthorized access.

Second Question

I’ll recommend using Systemd. Using a service manager like systemd is a more modern and robust approach, especially for long-term and production setups. Here’s how you can run your Python script as a service:

Creating a Service File:

First, you’ll need to create a systemd service file:

sudo nano /etc/systemd/system/myscript.service

[Unit]
Description=My Python Script Service
After=network.target

[Service]
Type=simple
User=username
WorkingDirectory=/path/to/your/script/directory
ExecStart=/usr/bin/python3 /path/to/your/script.py
Restart=always

[Install]
WantedBy=multi-user.target

Replace username with your user’s name and adjust the paths (/path/to/your/script/directory and /path/to/your/script.py) to point to your script.

Starting and Enabling the Service:

Once the service file has been created:

• Reload systemd to recognize your new service, enable it and then start it:

sudo systemctl daemon-reload
sudo systemctl start myscript.service
sudo systemctl enable myscript.service

This approach ensures that your script starts automatically if the server reboots and can be managed using standard systemctl commands. It’s more consistent and integrates well with the system’s standard service management tools.