We should test for any wonky behavior in the code. That includes race conditions and any invalid memory operations. We do not want the server to be taken down, as it will be "daemonized".
Potential Problems
Attackers can choose to never quit their SSH session, which will hog resources. We should limit connection time. In addition, we should limit the size containers can grow to, and remove containers FIFO for older containers.
I also see a potential issue with the mapping data structure I use to store username and password data. Not sure if this should be protected with mutual exclusion (are maps thread safe?), but this is something we can include in our robustness testing.
Limit number of bytes transferred? Because we're logging the data to a database, issue could be that they decide to type a command that creates a lot of output to fill up the SQLite database.
Issue Summary
We should test for any wonky behavior in the code. That includes race conditions and any invalid memory operations. We do not want the server to be taken down, as it will be "daemonized".
Potential Problems
Attackers can choose to never quit their SSH session, which will hog resources. We should limit connection time. In addition, we should limit the size containers can grow to, and remove containers FIFO for older containers.
I also see a potential issue with the mapping data structure I use to store username and password data. Not sure if this should be protected with mutual exclusion (are maps thread safe?), but this is something we can include in our robustness testing.