Register forum user name Search FAQ

Gammon Forum

Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to verify your details, confirm your email, resolve issues, making threats, or asking for money, are spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the password reset link.

Due to spam on this forum, all posts now need moderator approval.

Entire forum ➜ MUSHclient ➜ General ➜ MUSHclient to *buntu server with SSH possible? Please

*MUSHclient to buntu server with SSH possible? Please**

It is now over 60 days since the last post. This thread is closed. Refresh page

Posted by

RichKK (33 posts) Bio

Date

Tue 13 May 2014 11:12 AM (UTC)

Amended on Tue 13 May 2014 11:23 AM (UTC) by RichKK

Message

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.

Posted by

Nick Gammon Australia (23,173 posts) Bio Forum Administrator

Date

Reply #1 on Wed 14 May 2014 01:34 AM (UTC)

Message

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

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Posted by RichKK (33 posts) Bio

Date

Reply #2 on Thu 15 May 2014 11:48 AM (UTC)

Amended on Thu 15 May 2014 12:47 PM (UTC) by RichKK

Message

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.

2014.05.15 08:39:35 LOG5[4848]: stunnel 5.01 on x86-pc-msvc-1500 platform
2014.05.15 08:39:35 LOG5[4848]: Compiled/running with OpenSSL 1.0.1g-fips 7 Apr 2014
2014.05.15 08:39:35 LOG5[4848]: Threading:WIN32 Sockets:SELECT,IPv6 SSL:ENGINE,OCSP,FIPS
2014.05.15 08:39:35 LOG5[4848]: Reading configuration from file stunnel.conf
2014.05.15 08:39:35 LOG5[4848]: FIPS mode disabled
2014.05.15 08:39:35 LOG5[4848]: Configuration successful

That's the initial logfile.

When I connect with Mushclient

2014.05.15 08:41:24 LOG5[1264]: Service [1] accepted connection from 127.0.0.1:50573
2014.05.15 08:41:24 LOG5[1264]: s_connect: connected [my external server address]
2014.05.15 08:41:24 LOG5[1264]: Service [1] connected remote server from [my ip]
2014.05.15 08:41:24 LOG3[1264]: SSL_connect: 1408F10B: error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number
2014.05.15 08:41:24 LOG5[1264]: Connection reset: 0 byte(s) sent to SSL, 0 byte(s) sent to socket

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.

Posted by

Nick Gammon Australia (23,173 posts) Bio Forum Administrator

Date

Reply #3 on Thu 15 May 2014 08:43 PM (UTC)

Message

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/

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Posted by

RichKK (33 posts) Bio

Date

Reply #4 on Fri 16 May 2014 12:39 AM (UTC)

Amended on Fri 16 May 2014 12:41 AM (UTC) by RichKK

Message

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.

Posted by

Nick Gammon Australia (23,173 posts) Bio Forum Administrator

Date

Reply #5 on Fri 16 May 2014 10:38 AM (UTC)

Message

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.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Posted by

RichKK (33 posts) Bio

Date

Reply #6 on Fri 16 May 2014 12:03 PM (UTC)

Amended on Fri 16 May 2014 12:11 PM (UTC) by RichKK

Message

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.

Posted by RichKK (33 posts) Bio

Date

Reply #7 on Sat 17 May 2014 07:35 PM (UTC)

Amended on Sat 17 May 2014 07:36 PM (UTC) by RichKK

Message

This is madness!

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

An ssl error in stunnel


LOG7[6896]: SSL state (connect): before/connect initialization
LOG7[6896]: SSL state (connect): SSLv3 write client hello A
LOG7[6896]: SSL alert (write): fatal: protocol version

Or a pre-authorization protocol error in the client


SSH-2.0-OpenSSH_5.9p1 Debian-5ubuntu1.4

Protocol mismatch.

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?

Posted by Nick Gammon Australia (23,173 posts) Bio Forum Administrator

Date Reply #8 on Sat 17 May 2014 10:59 PM (UTC)

Message

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):


ssh -f -L 4000:10.0.0.2:22 -N nick@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:


SSH-2.0-OpenSSH_5.9p1 Debian-5ubuntu1.3

Protocol mismatch.
Connection closed by foreign host.

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:


ssh -f -L *:4001:10.0.0.2:80 -N 10.0.0.2

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:


ssh -f -L *:4000:my_server.com:23 -N myname@localhost

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.


$ telnet localhost 22

Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
SSH-2.0-OpenSSH_5.9p1 Debian-5ubuntu1.3

Protocol mismatch.
Connection closed by foreign host.

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:


sudo apt-get install telnetd

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

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Posted by Nick Gammon Australia (23,173 posts) Bio Forum Administrator

Date

Reply #9 on Sat 17 May 2014 11:08 PM (UTC)

Amended on Sat 17 May 2014 11:09 PM (UTC) by Nick Gammon

Message

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

Search for:


ssh auto login

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

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Posted by

RichKK (33 posts) Bio

Date

Reply #10 on Sun 18 May 2014 08:22 AM (UTC)

Message

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.

Posted by

Nick Gammon Australia (23,173 posts) Bio Forum Administrator

Date

Reply #11 on Sun 18 May 2014 07:55 PM (UTC)

Message

I didn't use stunnel.

The SSH command was running on a local server.

Quote:

I don't have administrative access to the remote server I'm trying to connect to ...

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.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Posted by RichKK (33 posts) Bio

Date

Reply #12 on Mon 19 May 2014 09:02 PM (UTC)

Amended on Mon 19 May 2014 09:05 PM (UTC) by RichKK

Message

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?


                My computer                  |                 Remote server
[ Mushclient ----> SSH/stunnel client ---->] | [ssh/stunnel server---> telnet service --> command line]

Sorry for the rambling.

Posted by

Nick Gammon Australia (23,173 posts) Bio Forum Administrator

Date

Reply #13 on Tue 20 May 2014 04:13 AM (UTC)

Message

RichKK said:

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.

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.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Posted by

RichKK (33 posts) Bio

Date

Reply #14 on Wed 21 May 2014 12:15 PM (UTC)

Amended on Wed 21 May 2014 12:16 PM (UTC) by RichKK

Message

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.

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.

48,353 views.

It is now over 60 days since the last post. This thread is closed. Refresh page

Go to topic: Search the forum

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.