Connecting to a Windows Caché server through SSH (Secure Shell)
Caché running on Windows Server includes a built in telnet service. Unfortunately though telnet is a plain text protocol, which generates a security violation from our network security scanner. Is there a way to replace telnet with SSH to connect to a Caché system running on Windows 2012 R2?
There is no direct way.
BUT:
If SSH is installed on your server you may connect to a CMD session (e.g by using PuTTY) over SSH
[ Windows DOS prompt ]
From there you can run %cachedir%\bin\Csession.exe by local access without using Telnet.
Configuring SSH to connect to Caché, on Windows will be almost the same as doing it on Linux.
You have to install any SSH server, for instance, OpenSSH.
And then configure there default shell, to be something like this
c:\intersystems\cache\bin\cache.exe -s c:\intersystems\cache\mgr
or for iris, use irisdb.exe, instead
c:\intersystems\iris\bin\irisdb.exe -s c:\intersystems\iris\mgr
but it looks, that to change default shell in openSSH, you have to edit the registry.
Thanks Dmitry! This helped, although this solution still has some concerns for my organization. In particular, it means that the Caché user will need a local account on the server in order to log in to the server, via secure shell, before logging in to Caché. This would, unfortunately, open another security concern with my organization. The end user would also be burdened with the hassle of using a separate Windows account for this purpose. It's a shame that Caché on Windows doesn't support an integrated SSH server, as it does for telnet.
You should understand that there are no reasons, to implement something, which can be done better with external solutions. On Linux InterSystems does not have even telnet, for the same reasons. I'm against implementing it directly in Caché/IRIS.
Back to your the next issue. You have to understand that ssh connection should use authentication, and for sure it should be done on InterSystems side, it's should be done on SSH level. And I see only one way, how to implement it, is using Kerberos. I would suggest that, if you have Windows in your park machine, you may have Active Directory, so, Singe Sign On with Active Directory, looks the best way (it's even possible with Linux). Your users in Caché, should be tied with Active Directory accounts. Target Windows server and Caché should be configured for Kerberos authentication, as well as SSH server. In this case, any user already signed on on their machine with Active Directory account, may get fast connection to the system on Caché through SSH, without any prompt for login/password. Using the right SSH client, which will support Kerberos.
It does not matter if you even used Linux, and had to solve the same task, the solution would be exactly the same.
Okay. I'll take a look at both of these ideas, i.e. Single Sign On with Active Directory/Kerberos or moving Caché to Linux.
We still have green-screen parts of the app, so interested in the answer. And is there a way to tie the Windows command app into running cache? (I know very little about Windows.). Thanks.
There is a way to "re-route" telnet over a secure SSH tunnel with a product called 'stunnel.' There are free stunnel implementations for Windows, Linux and AIX, and I have tested using it across architectures (Windows Client to an AIX server, Linux client to Windows server, etc.) so it's basically architecture agnostic.
You will have to install stunnel on the server and every client so there is some work, but it can be done "over time" so there shouldn't be much downtime.
First, install stunnel on your server and configure it for a high port - for this example, let's use 6707. Configure stunnel encrypted SSH traffic on port 6707 and 're-route' the decrypted traffic to port 23, but don't disable port 23 just yet; you'll be able to use both ports temporarily until you get all the workstations switched.. On each workstation, install stunnel and re-route unencrypted port 23 traffic to encrypt and send out on port 6707. Once you get all of the workstations converted (which means you're no longer sending unencrypted traffic) then reconfigure the server to disable any input on port 23 on your network card(s), and rely solely on the SSH traffic on port 6707. Keep in mind, you can't disable port 23 on 127.0.0.1 - stunnel will need that, but as that's wholly internal to the OS it should satisfy your network scanner.
If stunnel & your firewall are set up correctly, it works invisibly with Cache / HealthShare / Iris and every telnet client I've tested (NetTerm, putty, a couple others that don't immediately come to mind) because they still talk on port 23 locally, but stunnel does all the encryption and rerouting automatically. The only issue I've seen is if you _already_ have network issues and timeouts, stunnel can experience disconnects more often than straight telnet due to the increased overhead of the encryption.
Hope this helps!
I tried windows open ssh server and I stopped to use it due to many glitches.
For some version it simply doesn't work (connection failure) for others I got terminal problem after some time of working in ssh session.
Yet another possible variant worth to try.
https://cedocs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?K...
Other words you might try to use telnet protocol over tls.
I never tried it, but you might try since you are motivated to do it.
tls for windows is expected to be robust.
I have successfully tested the Bitvise SSH server, which runs natively on Windows. It's not open source, but the licensing fee is quite reasonable at $99. The only issue for us is that it doesn't integrate with Caché. The user needs to have a separate local or domain Windows account to SSH in to the server prior to logging in to Caché. The integrated telnet service that's included as part of the Caché installation doesn't require users to keep a separate Windows account.
Any SSH server you might try (OpenSSH, etc) would act this way: to start command shell, you need to log in Windows.
I removed my example on PuTTY.
It worked by mistake as the local firewall was switched off
If setup correctly it basically works as described by @Alexey Maslov
and you need to log in separately on the server,
Before switching to Windows Server 2019 we also used Bitvise. Fortunately Windows Server 2019 comes with OpenSSH (it can be installed as a windows feature). OpenSSH works pretty good and so we don't have to pay for the Bitvise license any longer.
man sshd_config
It depends on openssh server config.
AuthenticationMethods = none
gives access without any authentication.
My guess it might global option or for given user.
openssh server I mean https://github.com/PowerShell/Win32-OpenSSH/releases
binary kits.
https://docs.microsoft.com/es-us/windows-server/administration/openssh/openssh_install_firstuse
Charles, consider whether OS authentication in Caché can help you with the issue of two accounts to manage:
https://cedocs.intersystems.com/latest/csp/docbook/Doc.View.cls?KEY=TSQS_OSAuthentication
Erik
Placed on wrong place, see above :-)