I'm not worried or concerned, but I am curious as to what types of exploitation I might expose my home server to if I leave a putty client connected using SSH.

I am using putty to connect to an EC2 Amazon Web Service hosted virtual Linux box. The server holds a static website that I use for testing on personal projects.

The server uses a python script with flask to run the website, and the script will stop once I log out, so I just leave the connection open, seeing as it doesn't time out automatically.

Are there any vulnerabilities related to leaving a connection open like that? Is there a way to have the script run on the box without having to stay logged in through the putty client?


  • use pm2 to manage (and auto re-launch) long-running processes. screen can keep you from dropping on disconnect, but it still a really amateur way of running node and offers no logging, relaunch, hot reload, etc...
    – dandavis
    Jun 25 '16 at 6:58

Vulnerabilities exist because of session based attacks and the client being open. If you or the client gets compromised, so is your EC2 instance.

As for keeping the script up, bringing it back, stopping it, and restarting it(often called process management) there are some things you'll probably want to look into:

  • Process Managers
    Like PM2 or Supervisor can keep your process running in the background and allow you a way to easily kill the script on your next session(usually with a stop command)

  • Startup and init.d/Bash scripts
    While it takes more preparation, you could actually just have the script start at startup, pull in the latest version, and then just shutdown on timed intervals to re-pull and repopulate, or when the computer is told to turn off using the run time levels and triggers in the startup system your EC2 instance uses

Both of these routes would probably be the best way to go as they both offer startup, revival(meaning you can save money by stopping the instance when you're done), and script flow control.

Screen is an option, but it's completely manual. Wouldn't it be nice to take some initial time and make it automated? Most of us think so and one of the biggest gains is not needing two open connections. One connection is all you need. Sign in and start. Sign in and stop. Simple enough.

Things you should avoid at all costs:

  • Backrounding a script
    requires more involved methods to kill or control the script

  • Leaving a session open
    sessions can be hijacked


Are there any vulnerabilities related to leaving a connection open like that?

Yes in fact you are. An attacker that gains access to your computer can hijack your session with the PUTTY api and use your session as he wishes.

Is there a way to have the script run on the box without having to stay logged in through the putty client?

Yes there is. If you are using a Linux system simply add a & at the end of your script like this:

root@localhost:~$ python script.py &

In general I suggest you use a process manager such as pm2 (http://pm2.keymetrics.io/).

  • 4
    Throwing a process in the background is NOT the way to go. Use screen the moment you log in (type screen) versus throwing a process in the background. The moment you log off, is the moment that process exits. Screen will allow you to detach from the terminal, and re-attach (screen -r PID) to what you were doing. As for vulnerabilities, you would be vulnerable if someone compromised your machine.
    – munkeyoto
    Jun 24 '16 at 17:56
  • how would I execute the script then? ./scriptForServer screen -r PID ? Jun 24 '16 at 18:31
  • 1
    @PositriesElectron no. When you first enter your session before you do anything you type in screen. Do whatever you're going to do in there, on another session type screen -d then exit from both terminals and you are set. Next time you ssh in, type screen -r (this should give throw you right into your screen session, but if you have multiple screens running, it will give you their PIDs)
    – munkeyoto
    Jun 24 '16 at 23:04
  • The same task can be accomplished with tmux. Jun 25 '16 at 15:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.