[stunnel-users] Spawning a shell
tdussa at rz.uni-karlsruhe.de
Wed Oct 29 14:21:28 CET 2008
On Wed, Oct 29, 2008 at 02:07:27PM +0100, Ludolf Holzheid wrote:
> To be honest, I don't understand what you are trying to do.
All right, I'll try to explain myself more clearly. ;-)
> Or do you want to provide SSL protected telnet connections? Then a
> stunnel daemon (in server mode) could do the authentification /
> decryption / encryption stuff and redirect the pain TCP traffic to the
> telnet port of the server.
There are three reasons why this is no good in my particular case:
- There is no telnetd available in the environment.
- The user should be able to log in just using her certificate
without having to provide a username/password combination. rshd
instead of telnetd would probably do the trick, but alas, that is
not available either.
- The shell should only be spawned when a secure connection is
opened; if a local rshd (instead of telnetd, see above) were bound
to a port on localhost, then anyone on the machine would be able to
just telnet to the port and get a shell.
So, basically, I want to be able to open an SSL connection to stunnel,
using a client-side certificate for authentication, and get a shell.
In essence, a rsh session secured over SSL.
Naively, it should suffice to put this in the accept section of
pty = yes
exec = /bin/sh
execargs = /bin/sh -l
However, this does leads to the above-mentioned terminal problems.
(Incidentally, it turns out that part of my problem could be fixed
rather easily. By reading the source code, I found that if stunnel is
not forked to the background, then stderr is deliberately kept to the
original tty, even though new ptys are created for stdin and stdout.
However, while debugging, I naturally kept stunnel in the foreground.
It didn't really occur to me that this might cause stderr not to be
The nine most terrifying words in the English language are: I'm from
the government and I'm here to help.
More information about the stunnel-users