Connect SAS Client to SAS Spawner from Different Private Network

[lalit_Jalkhare]

Hello, We have a SAS Connect spawner running on an RHEL server, and we connect to the SAS Spawner from a SAS Windows client in the same private network with a TCPUNIX.SCR file. It works fine. Now, I want to connect the SAS client from a different private network to the SAS Spawner. However, if I am using a TCPUNIX.SCR file to establish a connection, the firewall blocks it because I think the script uses telnet to log on to the spawner, and our firewall blocks all unencrypted flows. We cannot use scrip less sign-on as our client is fully customized, and it uses customized frames to get the user ID and password of logon. So, is there a way to avoid using telnet or to make the sign-on process encrypted with SSL? We already use 'netencryptionalgorithm=ssl' to invoke our spawner. also please corect me if i am wrong if we use netencryptionalgorithm=ssl to invoke the spawner then it mens our data tranfer is secured with SSL but only telnet is used for logon to the spawner that is our username and password will be exposed if we use telnet ?

Our Spawner Process : -

Our Client's Customized logon Frame 

also we are able to ping the server  from our client from different Private Network.

if i try to telnet the server port which SAS Spawner is listening the screen goes blank i am not sure if the connection is successful or not

Below is the Error i get when trying to logon using script from client of different private network

ERROR:

TRACE:    Echo on;
TRACE:    Log 'NOTE: Script file 'tcpunix.scr' entered.';
NOTE: Script file 'tcpunix.scr' entered.
TRACE:    If not TCP then goto notcp;
TRACE:    If signoff then goto signoff;
TRACE:    Waitfor    'login:',
TRACE:               'Username:',
TRACE:               'Scripted signon not allowed': noscript,
TRACE:               120.0 seconds: noinit;
TRACE: noinit:
TRACE:    Log 'ERROR: Did not understand remote session banner.';
ERROR: Did not understand remote session banner.
TRACE: nolog:
TRACE:    Log 'ERROR: Did not receive userid or password prompt.';
ERROR: Did not receive userid or password prompt.
TRACE:    Abort;
NOTE: End of script file trace.

Please let me know if there is a way to avoid using telnet or to secure the logon process using SSL.

Manny Thanks already

[doug_sas]

You can give these ideas a try:

1) Remove the '-cleartext' option. That makes everything be unencoded/encrypted.

2) Add the '-netencrypt' option. This will force clients to use the encryption you specify.

3) Make sure the port used is not the standard telnet port (23), but rather one that you specify and the firewall knows about. Firewalls may block the default port automatically.

4) You will need to make sure communication can occur between your two private subnets.

[lalit_Jalkhare]

I have made the changes suggested by you 

Spawner Process :-

But Got the Same Error from the new client :(, also we are using a dedicated port for SAS Spawner not the default one, and both out private subnets. can communicate with each other as we have other applications which uses HTTPS ports and we are able to access the server through HTTPS ports

TRACE:    Echo on;
TRACE:    Log 'NOTE: Script file 'tcpunix.scr' entered.';
NOTE: Script file 'tcpunix.scr' entered.
TRACE:    If not TCP then goto notcp;
TRACE:    If signoff then goto signoff;
TRACE:    Waitfor    'login:',
TRACE:               'Username:',
TRACE:               'Scripted signon not allowed': noscript,
TRACE:               120.0 seconds: noinit;

___________________________________________________

also  i trayed to increase the wait time in tcpunix.scr script by 2-3 mins after that also no luck,

Thanks for your Reply please let me know if there is something else that we can try

[doug_sas]

The CONNECT spawner does not use HTTP or HTTPS so it would not be using 80/443. The spawner is using the port defined by the name 'sasspawn' (because you used the option "-service sasspawn").

Make sure whatever port sasspawn translates to is open in your firewall. You may be able to see information from the spawner output. If not, you could add the '-debug' or '-trace/-verbose' options to get more information from the spawner.

[lalit_Jalkhare]

The Port on which SAS Spawner Listens (one mentioned in the -service option) is opened between the PNs 

below if the Screenshot of Openssl to that port of the server from client server

Also Test-Netconnection is successful on that port 

But the Protcol which is mentioned by out network team is "SSL on TCP port 145XX(on which SAS Spawner listens)" i am not sure if telnet will be alowed over this protocol or not. can you please help me with this

[doug_sas]

The spawner protocol is based off of Telnet and uses telnet packets to tell the spawner to switch into encrypted mode. You cannot debug this using openssl or PowerShell commands since they do not provide the correct telnet packets. The only client that does provide the correct information is SAS processing a SIGNON statement.

You are probably going to need to open a tech support track so that they can get CONNECT spawner trace logs from you and work with you on a solution.

[lalit_Jalkhare]

Thanks for your reply, i have raised a service request with SAS team to move forward.

also i checked with our network team they said our protocol templates block unencrypted flows (like telnet) on Application layer lever may be that is the issue.

it will be grateful if you can answer me on below questions :-

1. if we used script base sign on then on application layer level Telnet is used to login to spawner ?

2. if we go with Script less sign on which protocol on application layer will be used like SSH, telnet,SSL etc. ?

3. is there a way to encrypt telnet connection with SSl while logon to SAS Spawner

[SASKiwi]

I highly recommend you try scriptless SIGNONs as it avoids the complication of using scripts, telnet, and having firewall rules for telnet ports.

With scriptless SIGNONs you connect directly to the SASApp Connect server using the default port number 7551 avoiding telnet completely. You can check your actual port number in SMC:

[lalit_Jalkhare]

Hello @SASKiwi Thanks for your Reply, our SAS Spawner run on a Unix Server and We have Defined Spawner to use on port 14555 so just to be clear our Spawner will listen on port 14555 right or it will listen on default port 7551 because port 7551 is not opened between our sever and client PNs.

Also can you tell from where i can launch SMC to check the port SAS Spawner is using ?

Manny thanks in advance for your time.

[doug_sas]

Scripted SIGNONs and scriptless SIGNONs all go to whatever port you tell them to go to in the SIGNON statement. The spawner listens on the port specified by the '-service' option (with the default being the 'telnet' service which is usually mapped to port 23).

Scriptless SIGNONs will start SAS using the command designated by the spawners '-sascmd' option (or execute the command 'sas' if the option is not present) whereas scripted follows logic in the script file.

This is all assuming you are not using information in the metadata server for the CONNECT spawner. If you were, I would expect to see the spawner option '-sasspawnercn' on the command line which references the spawner definition in metadata.

[doug_sas]

The CONNECT protocol from client to spawner starts out using telnet-like protocol to negotiate CONNECT options including encryption. The negotiation is done by the spawner sending telnet bytes to the client asking the client if it supports a specific option  and the client responding with telnet bytes indicating whether it does or not. One of the last options negotiated is the type of encryption. Since you added the '-netencrypt' option, the negotiation will fail if the client is not supporting the specified encryption.

Once the encryption has been negotiated, everything from then on is encrypted including the processing of the script or the handshake for a scriptless connection.

[lalit_Jalkhare]

Okey, Thanks alot for the clear Explanation, so it means anyways we will need our Firewall to allow telnet to do the negotiations whether we go with Script or Script less Signon. Please correct me if i am wrong

[doug_sas · Accepted solution]

If your firewall is looking at the negotiation data and preventing it from passing through then you will either need to change the firewall behavior or create a SSH tunnel from the client machine to the spawner machine.

Here are some links that may help with the SSH tunneling:

• https://support.sas.com/documentation/cdl/en/secref/69831/HTML/default/viewer.htm#p0sv5ora53jf71n1v6...
• https://support.sas.com/resources/papers/proceedings11/359-2011.pdf

[SASKiwi]

@lalit_Jalkhare  - SAS Management Console (SMC) is usually a PC-installed client tool. If you don't have it installed currently then install it from your SAS Software Depot using the SAS Deployment Wizard. 

[doug_sas]

SAS Management Console (SASMC) is a java program that runs on Windows/Linux/UNIX.

It is not a PC program like Enterprise Guide.