1 & 2. Why not use GET and POST over https? For a non-web-based solution (assuming the server is Unix/Linux), you might use scp (part of ssh)? ssh clients are easy to come by, and since the admin process is normal user management it might be easier than trying to web-fronted all that stuff (especially from scratch). The ssh tools are in widespread use too, so that gets to your "bulletproof" point. Just a thought.

If you don't want to offer raw shell access, you could write a pseudo-shell for your clients/users (perhaps even in Perl). Something like KISS, or other menu-driven login. There's no reason users require access to BASH or KORN shells, after all.

3. I don't keep up on what's available, so no comment.

4. You can theoretically expire a cookie on the client side, you can also put a session ID into the cookie and track that, along with a time-limit, on the server side. In a stateless protocol like HTTP you're not going to be able to do a strict timeout, so this would be the next best thing.