I perceive that you will probably need to spawn a child process for each device and to use a message queue. The real difficulty is going to be how to describe the state-machine type logic that must be performed by the main process that is controlling the tests. I vaguely remember encountering such a testing framework – I no longer remember what its name is or was – but it was built using XML, vaguely like what ColdFusion does.
The test file consisted of an arbitrary number of test-nodes, one being designated as the initial-state. Each one had “preconditions,” “actions,” and “effects.” They could be “singleton,” or “parallel.” The test-runner used this information to decide what to tell its slaves to do next. I recall that while the framework worked, it was .. difficult .. to program tests for it . . .
Thinking a little bit more about this, I do believe that it is the right approach to have n processes, one per SSH2 connection, who are basically “proxies” for that connection and who are directly responsible for (a) knowing what that host is or isn’t doing at this time, and (b) telling the host to do whatever-it-is and to correctly report that host’s new status. They are, effectively, “supervisors” for each host, and the first line of defense in dealing with hiccups. Then, the remaining process-of-significance (probably, the last remaining child of the parent) is the test-runner process itself, which acts by sending and receiving messages via IPC queues to each host-supervisor.