When you run a script, it creates a subshell where the command executes. Any processes including background processes that are run, such as the ssh command are attached to this subshell. If the subshell is terminated, the background process is killed too. Instead, try running the ssh process as a nohup command within script 1.
Answer inspired by: Start a background process from a script and manage it when the script ends
Commands sent through ssh are attached to the ssh process, and the ssh process must continue to run in order for the commands to complete. Exiting the ssh process will terminate any background processes on Machine B, since they're attached to the subshell created for script 2. Nohup comes in handy here as well.
But since your process is executing on Machine B but apparently hanging and not being terminated prematurely, it doesn't seem that a premature termination of the ssh process appears to be a problem.
Network issues are also unlikely since they would likely terminate the ssh process and terminate the processes running on Machine B. Additionally, if networking issues aren't so bad that terminate the ssh process, they shouldn't affect processes running on Machine B. There's likely something in script 2 on machine B that's causing the stall. One way to prove that this logic is wrong is to kill the ssh process on Machine A and see what happens on Machine B.
Finally, your best bet is to run your ssh command as a nohup process as suggested in the earlier link. Additionally, if your commands in script 2 are not sequentially dependent, I'd run each one using nohup as well. (https://askubuntu.com/questions/349262/run-a-nohup-command-over-ssh-then-disconnect). I'm assuming nothing in script 1 on machine A is dependent on script 2 executing based on the fact that you have the ssh command running as a background process.