Ssh – Writing a “telnet server” type program that uses SSH instead of telnet

Short answer: yes, ssh can do this. The answer's in your question: "reverse" tunneling. See the -R option to the ssh client:

-R [bind_address:]port:host:hostport
Specifies that the given port on the remote (server) host is to be forwarded to the given host and port on the local side. This works by allocating a socket to listen to port on the remote side, and whenever a connection is made to this port, the connection is forwarded over the secure channel, and a connection is made to host port hostport from the local machine.

More reading at the ever-useful How To Forge (Reverse SSH Tunneling), but the basic principle is you ssh from your private host to your public one, specifying the port to map back. Remember to set your bind address in the command, otherwise it will only be bound to the local loop by default.

Requiring dual approval for certain actions is part of some security policies; for example:

• In banking, very large transactions typically require validation by two managers.
• Launching heavy weapons such as nukes requires validations by two or more high-ranking officers or decision-makers.
• Approving or rejecting a suggested edit on Stack Overflow requires two users with sufficient reputation to agree.

You'll note that this is not about authentication (e.g. typing a password to show that you're who you pretend to be), but about authorization, i.e. deciding whether a certain action is permitted.

For background reading, I recommend Security Engineering by Ross Anderson. Buy the latest edition if you can, but otherwise the first edition is available online. The most relevant chapter is “Access Control”; there are examples in the chapters on banking and nuclear command.

Unix offers a simple security model, with only two levels: user and superuser. This is both a strength (simple means less room for errors in the design and implementation of the system itself and of security policies) and a weakness (complex security policies cannot be expressed natively). If you're worried about a rogue user gaining root, don't give him root permissions. There are very few checks on what root does; the only constraint would be that the action of gaining root can be logged remotely, as can certain external actions (network traffic). A rogue user could pretend to want to gain root to do a certain thing and actually do another while hiding his actions from the other user. So you would not gain much security by requiring root access to be vetted by another user. Conversely, you would lose security by reducing the availability of root access (I gather you want to give less trusted users root access to serve as back-ups if something goes wrong; dual approval would increase the burden a lot).

Dual approval is useful for specific actions: Alice says “please authorize me do do X”, Bob says “I authorize Alice to do X”, and the system performs X (X can be e.g. transferring $1,000,000,000 from one bank account to another, or nuking Moscow, or rejecting an edit). If Alice says “please authorize me to do anything I want” and Bob agrees, all Bob is doing is echoing what you (the policy maker) already said, namely that Alice can be authorized to do anything. You might as well make Alice a sudoer.

I don't know of any existing system on unix to have multiple users approve specific commands in a sudo-like framework.