I want to stop the pi from sleeping
This is an XY problem, except fortunately you sort of mentioned X.
The Pi cannot go to sleep. It has three basic states, one of which is "unplugged". The other two are running and shut down. It cannot come back from the latter without rebooting it by cycling the power.
Your implied problem here is that the web server goes offline. If this is the case, you will have to diagnose that properly, starting by checking the logs.
Whether and when the SSH server on the Pi disconnects is a matter of how it is configured. Try editing
/etc/ssh/sshd_config (you need superuser privileges for that, e.g., use
sudoedit), find these fields, uncomment them (remove the
#), and change their values:
Then restart the server (
sudo systemctl restart ssh <- Hopefully that is the right service name, if not try
sshd). This will cut off your remote connection if that's how you do it, which is okay. You should be able to connect again right away unless you flubbed something in the config file, in which case you will have to fix it on the pi (a good reason to make a back up copy of
sshd_config before you touch it).
To understand better what those options mean, have a look at
man sshd_config. As explained there, this will mean unresponsive clients are cut off after being unresponsive for 40 minutes (120 seconds * 20).
Generally an "unresponsive client" refers to one which did not disconnect properly but is no longer replying to the server, meaning mostly likely the system it is on went offline (e.g., if your laptop goes to sleep).
There may also be parallel settings for PuTTY, I can't help you with that (but it looks like Seamus has already).
Starting processes via SSH
If you start something via the command line in SSH, that process is a child of the interactive shell (i.e., the command line interpreter) from which it was started, which is a child of the
sshd process controlling your session -- which is started by the master
sshd process, which is a child of the system's first process (init/systemd). Ideally, when you exit and the immediate ancestors of that something you started exit with you, the something (now considered an orphan) should be adopted by the first process. However, this may not work out, particularly if that something was running in the foreground.
Instead, you should either:
Start the process via
nohup and background it:
nohup [your process] &
You can start it in the foreground with
nohup, but the output (which is presumably why you wanted to run it in the foreground) will be redirected to a file (
man nohup for its general purpose; in short, it runs a "command immune to hangups". Hangup refers to the fact that when you leave a foreground process without a foreground (which exits with the ssh session), it receives a
SIGHUP from the OS. This can be caught and handled by the process if it was programmed to do so, but if it was not (usually, they are not), the default reaction is to exit.
And your server stops. In my experience a better solution than
setsid, which starts a process "in a new session", meaning it will be a child of the first process (init/systemd) instead of your shell, sshd, etc.
setsid [your process]
By default when run from the command line,
setsid should fork to the background, but it may not if you put it in a script. In this scenario (ssh) you want it to, so if it doesn't, add a
& to the very end of the command (after any output redirection such as
Newer version of setsid have an explicit
--fork option; check
man setsid to find out if this includes yours.
If you want to watch the output, redirect it to a log file:
setsid [your process] ^> my.log
To now watch it, use
tail -f my.log.
You can start a process in the foreground and come back to it latter via
screen. This is not something I've done much, but if you search around online
linux screen tutorial or
gnu screen tutorial you'll find stuff.