MUSHclient to *buntu server with SSH possible? Please

MUSHclient to *buntu server with SSH possible? Please


I know it's a huge, kind of silly question, but have there been any updates to getting MUSHclient connecting to a *buntu server via an SSH connection?

And you might ask why are you trying to use MUSHclient instead of PuTTY or some other client but over the last decade and a half (has it been that long?) I've become ridiculously comfortable with working in MUSHclient and am doing some light work remotely now.

I would love to have access to the same GUI style of client-side, regular expression triggers, aliases and lua scripting made on the fly. I'm not too concerned about being unable to send individual characters to the server without having to pressing enter first.

I've searched this site and tried the tip about stunnel with openssh, weven tracking down older versions of both and the newer versions but didn't have any success with the configuration.

For other options, I tried the Zugg version of their telnet client with ssh and rebranded as as professional client but their software has never really been for me.

I came across using cygwin and tintin++ with ssh but it's not nearly as capable of a client as MUSHclient is.

Ultimately what I'd like to do is be able to connect MUSHclient to a *buntu server with ssh via MUSHclient's sock5 proxy just as if the server was a regular telnet MUD... any ideas?

It really makes me happy to see MUSHclient's community is still active after all the time I spent on these forums over the years.

It should work using stunnel, can you describe what you tried, and what happened?

Thanks for the quick for response, sorry for the delay. Have been trying to approach my issues a few different ways.

Most recently I started with the current version of Stunnel installed to C:\stunnel

A version of openssl.exe is already included in the installation directory of stunnel, libeay32.dll is present as well actually but not libssl32.dll, so I'm not sure if the latter is still required.

---

For the heck of it, I also installed the latest OpenSSL Windows binary from here http://slproweb.com/products/Win32OpenSSL.html and and it does unpack the libssl32.dll to my installation directory C:\Openssl/

I've made the stunnel configuration file exactly as described and started stunnel.



That's the initial logfile.

When I connect with Mushclient



You're right, Mushclient does still work using stunnel, just a problem on my end with figuring out what stunnel configuration the server needs most likely. Thanks.

I've just been spoiled by ssh clients working out of the box and never had to mess around with configuring them before. But I'm really determined now to get it sorted because I'd take Mushclient + stunnel over the others any day.

I tried to get it working while I was waiting for a response and got the exact same results as you did. I'm not sure why, it used to work, and it seems to me that the problem is not MUSHclient (which after all just connects via Telnet to stunnel) but something to do with the stunnel configuration, perhaps they have tightened up the way Ubuntu SSH works.

All I can suggest is try tweaking the stunnel.conf file, also check the logs on the Ubuntu end, and maybe try to connect to other things (like earlier versions of Ubuntu if you have them on a bootable CD).

This might help:

http://www.revsys.com/writings/quicktips/ssh-tunnel.html

I'm assuming here that you don't really need SSH in a local environment, but maybe need to use SSH to connect to some remote machine, and want to use MUSHclient's triggers etc.

Setting up a tunnel on a local Ubuntu server as described in that page might be the way to do it.

Also see http://chamibuddhika.wordpress.com/2012/03/21/ssh-tunnelling-explained/

Dang, I think this is the first time in a decade I've seen you stumped :)

Just kidding, thanks for confirming it's not Mushclient and doing the research, will definitely try those links and a few variations of the stunnel.conf file

I believe that's the case about only needing ssh to connect and authenticate, have to find out more info about the server, I don't have root access at the moment.

Now I'm kind of curious how Z**g was able to implement full ssh and even sftp on top of their same old client and charge nearly double the price for having their proprietary scripting in an glorified mud client.

You can probably implement the libraries into the client, it boosts its size, but makes it easier to use. But then you have the issue 5 years down the track when protocols change, and the client stops working. At least with a separate program (like stunnel) you can fix the problem and get it working again.

I'm leaning towards the Unix way of doing things these days, where you don't try to do everything in one monolithic program. However I must admit that I incorporate the SQLite3 library, the PNG library, the PCRE library, and the zLib library simply because I like to distribute something that works out of the box.

Also those libraries tend to change slowly and are generally backwards compatible.

As for charging, I remember I read on a site somewhere (for someone else's software) "why isn't your product free?" with the response: "why isn't everything free?".

I don't have a quick retort to that, but I still believe in having open source as the way to advance knowledge in the world.

All good points, especially with the recent media exposure of the Heartbleed vulnerability, I wouldn't want to be responsible for providing immediate software updates for someone else's problematic code while supporting panicked free users that in a *nix system could simply update an outdated, common library themselves.

At the same time, I've had problems on my Mint install traced back to updating a single shared dependency that plays well with some apps but not others. Eh, it's still voodoo to me, thanks again!

On another note, there's some good advice for tunneling options on those links. I tried using MUSHclient + putty ssh tunnels originally but this definitely expands on that.

This is madness!


With various stunnel options I can either get to where the client hangs on connect

An ssl error in stunnel




Or a pre-authorization protocol error in the client



Creating an ssh tunnel with putty or similar ssh client with port forwarding gets similar protocol errors.

And I thought SSH looked easier to work with even compared to the telnet protocol!

The server owner doesn't have any debugging info about failed login attempts either...

What an effort.

Is it possible running MUSHclient in WINE would make connecting with stunnel or the like any easier?

OK then. I've spent around 3 hours on this trying to make it work. It should be easy ...


I finally understand what is happening, I think. The documentation didn't totally help, nor did some of the suggestions on various web pages.

I tried this first (given that my Ubuntu server is running on 10.0.0.2):



My understanding was (wrongly) that this would tunnel from port 4000 to port 22, thus connecting to the SSH login.

In fact I get:



What the tunnelling actually does is provide an encrypted link between one host and another one but it is unencrypted at the destination.

So, for example, this works to connect to my web server on that host:



I connect (unencrypted) to port 4001 in this case using my web browser, it tunnels through to 10.0.0.2 encrypted, and then connects to the web browser on port 80 unencrypted.

So to use MUSHclient to connect securely to a server elsewhere, you need to run (locally) something like this:



Breaking this up, the -f option goes into the background (forks). The -N option tells it to not execute any command (just forwards the port). The -L option says to take a connection from any interface (*) on port 4000 on the local server, and forward that to port 23 on my_server.com.

The "myname@localhost" part are the credentials (myname) and the server (localhost) to which you are SSHing to.

Note that we use port 23 (telnet) not port 22 (SSH) because the output of the tunnel is not encrypted. You can see you get a similar error message about protocol mismatch if you just telnet to port 22, eg.



This of course opens up your server to people attacking it on port 23 (the telnet port) which is not totally optimal. However you should be able to set up permissions to only allow localhost telnets (which would be from the SSH daemon) and not from outside the server.

You may have to install telnetd to make this work:



I don't know how to fix up the permissions, you will have to read up on that.

You would probably need to set up automatic passwords for SSH for this to work properly (or at all).

Search for:



Basically you add your public key from the outgoing server to the ~/.ssh/authorized_keys file on the incoming server (Or is it the private key? Anyway, read the page to see).

Example explanation:

http://www.rebol.com/docs/ssh-auto-login.html

Thanks again for all the help... I spent all night on this and I'm more confused than I was before.

To clarify, you were able to establish a tunneled connection using only a terminal with ssh and those port forwarding options? You didn't use stunnel?

Or did you have to tweak the remote server as well? Sorry for the confusion.

I don't have administrative access to the remote server I'm trying to connect to so I can't make changes to the remote server installation -- I have only a remote IP:5050, a login name and plaintext password for credentials, so am I out of luck?

The highlight for me was seeing stunnel's debugging output appear in MUSHclient after I tried setting up stunnel as a inetd service for whenever MUSH attempted to connect to a specific localhost:port -- of course the port was already in use from when I was getting familiar with stunnel in Ubuntu.

I didn't use stunnel.

The SSH command was running on a local server.



Do you have telnet access to that server? Or do you have to use SSH?

It seems logical to me that ssh should allow you to tunnel from one machine to sshd on another machine, and log in via it, however that was the part I couldn't get to work.

Unfortunately , no telnet access, would have made things so much simpler, but he insists on ssh only for token security.


Oy, I think I completely misunderstood that stunnel and mushclient page.

I wanted to believe that stunnel wraps telnet protocol packets in ssl, sends to the remote machine's ssh port and and unwraps incoming packets for clients on the localhost.

It seems so logical, but do the differences between the two protocols render them mutually unintelligible and unable to be translated by any known means?

E.g. would telnet commands wrapped in SSL and tunneled to a remote SSH port still be unrecognisable and incomprehensible to a *nix server's expecting only SSH connections and remote commands like plaintext authentication?

Unless it's totally redundant/pointless I still mean to try Mushclient > stunnel > ssh tunnel again.

Otherwise, is there a possibility Mushclient could work if I successfully convinced the server administrator to run/allow telnet connections only from his own server, while the OS receives commands from the remote machine running stunnel as a server or an ssh tunnel that forwards them to the telnet port?




Sorry for the rambling.

I never implemented an SSH MUD server, so I'm not sure. It sounds though like you are right (or one of us is) that the stunnel protocol is secure in transit, but unwrapped back to non-secure at the server end.

If you can convince your server owner to allow telnet, but only from localhost, you might have an answer.

I'm really sorry for not mentioning the server only accepts SSH connections and not telnet with SSL, if I had understood the differences I would have said so upfront.

Otherwise, I suspect your tunnel would have been a beautiful, KISS solution that would have worked flawlessly.

Now that I have the admin's cooperation I'm going to give it one probably final effort to figure out how to make the remote server's telnet only accept localhost connections from unwrapped SSH.

Thanks again truly for all the help this time and years past.