What's the risk of upgrading over SSH?
@Marco-Ceppi 's solution is already integrated into do-release-upgrade.
When you run do-release-upgrade it starts a screen session automatically. If your ssh session gets disconnected, you can resume the installation. All you have to do is open a new ssh session, and run do-release-upgrade again. It will reconnect to your previous installation.
A second risk, pointed out by @sepp2k is that your sshd server might need to be upgraded, and it could perhaps not restart correctly. Therefore the upgrade program runs a second deamon, at the port specified. You should check your network configuration to make sure you have access through this port, before resuming.
Good luck.
Moreover, the screen-session do-release-upgrade starts by itself is run under the root account, so if your own screen-session crashes, you will be able to recover by running sudo screen -x, if (for some reason) the command do-release-upgrade doesn't recover it by itself, which seems to be common.
What I would recommend doing is launching a screen session on the server and running the upgrade in screen - that way if your SSH session drops (for whatever reason) the upgrade process will not halt.
Screen is a program that allows for persistent terminal(s) on a machine. So you can start a screen session and so long as the machine is on that screen session (and it's history, running programs, etc) will continue to operate though no one user is on the machine. It was designed in the early days to provide a multi-windowed text terminal prior to the days of X Server. You can install it using APT:
sudo apt-get install screen
So you can ssh into your server, start screen, initiate the upgrade process and not have to worry about the upgrade bing botched because you've lost Internet connection or your computer crashed.
If a new version of the ssh daemon is installed as part of the upgrade, the daemon will be restarted. If the update breaks the daemon for some reason, it would fail to start up again and you'd have no way of logging into the machine anymore.
By starting a separate sshd, which is not handled by the init system and thus won't be restarted during the upgrade, it is ensured that the old version of sshd will still be running even if the new version fails to start. Thus you can still log into the system and see what caused the daemon to break.