OK, I see the difference. In my experience with the backup script above, I was forking first, and then opening ssh connections in the child processes.

You are investigating opening ssh connections, and then forking afterwards.

I think you will always find problems with this, however you do it. The problem is that when you fork both the parent and the child retain all open file descriptors including network sockets. For some of those file descriptors it is probably harmless, or even desirable behaviour that both parent and child keep the file descriptor, but in the case of a state-full protocol such as ssh, it will almost certainly lead to problems.

Like any well engineered security product, ssh (RFC 4251) will include protection against replay attacks, most likely via some sort of sequence number. If you start and ssh connection, and then fork then both parent and child will inherit copies of the connection object, with a sequence number. If both parent and child then use their connections to talk to the server, then the ssh demon on the server will see the sequence number go backwards which would normally only happen if a cracker was attempting a replay attack, so the server will close or otherwise reject the connection.