Question and Possible bug.

[dougreed]

I have an interesting issue.

Your ssh terminal implementation is absolutely beautiful, and I really want to use the code in my project!

I am trying to use your code as a proxy to allow a user to create SSH sessions in a Web based Tomcat network monitoring application. Essentially, I took your source code and dropped it into the 'webapp' directory of a Tomcat application. Hacked 'index.html' slightly to create a file 'ssh.jsp'. It isn't much different except that it has some extra bits to get make it work as a tomcat action target. The rest of your application is unchanged. On the Tomcat Server, I installed your version of wsproxy.

When I finished all of this, it worked if I used 'http' and 'ws' protocol, but it failed if I used 'https' and 'wss'. I got busy and left it alone for a while because I didn't have time to play with it. I recently came back to it, and can no longer duplicate my success even without security. Browsers keep updating their security, and if I remember correctly, it never worked on some browsers (I tested at the time with Chrome, Firefox, Opera, and Safari). I don't recall which browsers did, and did not work. I can't run my application with 'http', especially since browsers are tightening security. I don't much like using wsproxy as it is a huge security hole, but at least my application lives inside a walled environment. I tried building a Webproxy interface in Java through tomcat, so that I could avoid running an external program, which works, but I don't know the subtlety of the security and protocol exchanges. I wish I could just open an SSH session in Java, and tie STDIN, STDOUT, and STDERR to your application, but that might not work over HTTPS, and I don't understand your application enough to try.

... anyway...

I am using valid keys in both Tomcat and wsproxy, and get 'Connection accepted' in wsproxy.

SSHy complains:
'InvalidCharacterError: String contains an invalid character' in the 'atob' call.

I put a try/catch around it, and ran a 'JSON.stringify' on 'e.data' in the catch, and it is simply receiving an empty string '{}'. I looked at the object in debug, and there is not text contained in the 'e.data' object.

I am not sure what it should receive, and why it isn't receiving what it should.

I would love to work with you to resolve it. Feel free to contact me via email if you wish.

[stuicey]

Are you positive you've used the forked version of wsproxy? I know its fumbled a couple people in the past where they've used the normal version.

All wsproxy does is provide a multiplex bridge between websocket connections and raw sockets. So you could write your own java implementation of this pretty easily. It would just need to be able to convert ws://example.com:5999/10.0.0.1:22 to tcp://10.0.0.1:22. Additionally the current implementation converts to & from base64 (though this could be removed).

On the back of your security concerns, SSHy is an end-to-end encrypted system. So running it over WSS doesn't give much benefit on your SSH session. I do understand the desire though when you would get some useful features from HTTPS.

[dougreed]

I am pretty sure I am using the forked version of wsproxy. I compiled it specifically from your most recent branch. Would you be interested in consulting on this? I would be willing to bring you in to look at this if you would be willing to do so. This is quite important to me.

…

On Sat, Feb 15, 2020 at 11:15 AM stuicey ***@***.***> wrote: Are you positive you've used the forked version of wsproxy? I know its fumbled a couple people in the past where they've used the normal version. All wsproxy does is provide a multiplex bridge between websocket connections and raw sockets. So you could write your own java implementation of this pretty easily. It would just need to be able to convert ws://example.com:5999/10.0.0.1:22 to tcp://10.0.0.1:22. Additionally the current implementation converts to & from base64 (though this could be removed). On the back of your security concerns, SSHy is an end-to-end encrypted system. So running it over WSS doesn't give much benefit on your SSH session. I do understand the desire though when you would get some useful features from HTTPS. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#31?email_source=notifications&email_token=AB4HYCBGM5GOX6RQ24ETF73RDAILVA5CNFSM4KUCAVUKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEL3QPBQ#issuecomment-586614662>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB4HYCCFVRKMF2NOTTVFRCTRDAILVANCNFSM4KUCAVUA> .

-- Regards, Doug

[stuicey]

Odd then, I would expect 'String contains an invalid character' to come out if you were using the other version. Do you get anything if you try console.log(e.data) instead of using JSON.stringify()?

I'm happy to provide best endeavors support for this but if you're seeking professional services then we should drop to email or IM.

[dougreed]

it prints Object[], which is why I used stringify. email me at doug.reed@dandallcus.com or r.douglas.reed@gmail.com and we can exchange information.

…

On Sat, Feb 15, 2020 at 3:35 PM stuicey ***@***.***> wrote: Odd then, I would expect 'String contains an invalid character' to come out if you were using the other version. Do you get anything if you try console.log(e.data) instead of using JSON.stringify()? I'm happy to provide best endeavors support for this but if you're seeking professional services then we should drop to email or IM. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#31?email_source=notifications&email_token=AB4HYCCNW2CCDSTR7ZOLGU3RDBG2XA5CNFSM4KUCAVUKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEL3WNCA#issuecomment-586638984>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB4HYCBSP4LKSXFBTYDQYNTRDBG2XANCNFSM4KUCAVUA> .

-- Regards, Doug