Hi,
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 stunnel.conf: --- 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 redirected...)
Cheers, Toby.