TBH, memory leak is my "go to" guess when things are sluggish after a few days of running. But as I say, it was just a guess and the only way to be sure, is to diagnose... :)
Also FWIW, ssh (on Linux at least) allows you to crank up the verbosity by adding extra "v"s (to a max of 3). E.g. ssh -vvv root@REMOTE_SERVER. Although in your case, I doubt that will add anything much of value.
The fact that it hangs at "debug1: pledge: network" lead me to find this Q&A on ServerFault. Judging by the range of answers, it seems that there can be a myriad of causes! Note though, that unless you are using something other than default user management (i.e. default Linux user authentication - PAM) I would advise you to NOT test the first answer! Setting "UsePAM no" in your servers sshd_config file WILL BLOCK SSH LOGIN (via PAM authentication)! So don't do that unless you understand the consequence!
I would urge you to not just try any of those suggestions without first confirming that they are relevant and/or ensuring that you understand the potential consequences. But they may give you some pointers in what to be looking our for. Viewing the logs such as the syslog, dmesg and/or systemd journal should give you some more clues.
Your suggested note re the "missing" network share may indeed be a better guess. As noted above, the syslog (/var/log/syslog) and/or dmesg and/or (systemd) journal may assist with confirming that. Also a fairly easy way to test your hypothesis would be to ensure that the shares are unmounted when the remote server (that hosts the shares) is down. If the "hang" goes away with the remote shares unmounted, then that would be pretty good evidence that it is indeed the issue.
If you can confirm that the issue is related to the missing shares, then you could set up a cron job to check the availability of the remote machine. If the remote machine is available and the share isn't mounted, mount it. If the remote machine isn't available and the share is mounted, unmount it.
FWIW, I just did a quick bit of googling and found what appears to be a pretty cool approach. It's quite an old thread on the Ubuntu forums, but if nothing else, it could give some good ideas? (seeing as it's over 10 years old, I personally wouldn't just copy paste it - although it may still work?).
I also found a few other things that may assist; here, here and here.
Memory leak was just a wild guess! :)
TBH, memory leak is my "go to" guess when things are sluggish after a few days of running. But as I say, it was just a guess and the only way to be sure, is to diagnose... :)
Also FWIW, ssh (on Linux at least) allows you to crank up the verbosity by adding extra "v"s (to a max of 3). E.g. ssh -vvv root@REMOTE_SERVER. Although in your case, I doubt that will add anything much of value.
The fact that it hangs at "debug1: pledge: network" lead me to find this Q&A on ServerFault. Judging by the range of answers, it seems that there can be a myriad of causes! Note though, that unless you are using something other than default user management (i.e. default Linux user authentication - PAM) I would advise you to NOT test the first answer! Setting "UsePAM no" in your servers sshd_config file WILL BLOCK SSH LOGIN (via PAM authentication)! So don't do that unless you understand the consequence!
I would urge you to not just try any of those suggestions without first confirming that they are relevant and/or ensuring that you understand the potential consequences. But they may give you some pointers in what to be looking our for. Viewing the logs such as the syslog, dmesg and/or systemd journal should give you some more clues.
Your suggested note re the "missing" network share may indeed be a better guess. As noted above, the syslog (/var/log/syslog) and/or dmesg and/or (systemd) journal may assist with confirming that. Also a fairly easy way to test your hypothesis would be to ensure that the shares are unmounted when the remote server (that hosts the shares) is down. If the "hang" goes away with the remote shares unmounted, then that would be pretty good evidence that it is indeed the issue.
If you can confirm that the issue is related to the missing shares, then you could set up a cron job to check the availability of the remote machine. If the remote machine is available and the share isn't mounted, mount it. If the remote machine isn't available and the share is mounted, unmount it.
FWIW, I just did a quick bit of googling and found what appears to be a pretty cool approach. It's quite an old thread on the Ubuntu forums, but if nothing else, it could give some good ideas? (seeing as it's over 10 years old, I personally wouldn't just copy paste it - although it may still work?).
I also found a few other things that may assist; here, here and here.