Hi everybody,
maybe I'm missing something real obvious here, but I can't figure out what's going wrong.
I'm trying to make stunnel spawn a regular shell when it gets a connect. As far as I understand, the pty option should allocate a virtual tty, so I ought to be able to just exec() a shell. However, this won't work; apparently some more magic is required. I do get the basic interactive functionality to work (i. e., I can enter, say, ls and get back a directory listing), but the terminal won't work properly: Unwanted echoes (stty -echo doesn't help). Furthermore, for some reason stderr is not connected to the new pty but sticks to stunnel's original pty.
I have tried spawning a shell directly from stunnel (with exec), spawning a script which redirects stdin/-out/-err to the proper pty, then execs a shell, spawning a script which execs login, spawning a script which execs getty. (The latter being closest to what I want, but not good enough.)
I'm running out of ideas. Anyone ever did this? Any comments?
(Incidentally, if anyone has a better idea how to create the possibility to log in with an X.509 certificate without using stunnel, I'm all ears.)
I'm running stunnel4 on Debian etch: --- stunnel 4.18 on i486-pc-linux-gnu with OpenSSL 0.9.8c 05 Sep 2006 Threading:PTHREAD SSL:ENGINE Sockets:POLL,IPv6 Auth:LIBWRAP
Global options debug = 5 pid = /var/run/stunnel4.pid RNDbytes = 64 RNDfile = /dev/urandom RNDoverwrite = yes
Service-level options cert = /etc/stunnel/stunnel.pem ciphers = ALL:!ADH:+RC4:@STRENGTH key = /etc/stunnel/stunnel.pem session = 300 seconds sslVersion = SSLv3 for client, all for server TIMEOUTbusy = 300 seconds TIMEOUTclose = 60 seconds TIMEOUTconnect = 10 seconds TIMEOUTidle = 43200 seconds verify = none ---
Cheers, Toby.
On Wed, 2008-10-29 12:49:18 +0100, Tobias Dussa wrote:
Hi everybody,
maybe I'm missing something real obvious here, but I can't figure out what's going wrong.
I'm trying to make stunnel spawn a regular shell when it gets a connect. [..]
Hello Tobias,
To be honest, I don't understand what you are trying to do.
If you just want to have a SSL protected telnet session, why don't you let stunnel run as a deamon (in client mode) and invoke telnet?
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.
Do you want to accomplish something else?
Ludolf
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.
-
Ludolf Holzheid -
Tobias Dussa -
Tobias Dussa