VSX, VSNext access virtual context via SSH

[marcyn]

Hi CheckMates,

I'm playing with VSNext and just wondering about one thing...
... is it possible to directly access virtual context via SSH client.

In VSX we don't have management switch but with VSNext we have it "onboard".
Because of that I thought that it would be good idea to be able to login directly to virtual context via ssh.

A llittle example:
1) I have management network 10.99.99.0/24
2) VS0 has management IP 10.99.99.61
3) VS1 has management IP 10.99.99.71
4) VS2 has management IP 10.99.99.81

Because right now we can even use different management servers for these VS ... and for example VS0 and VS1 are placed in SMS1 and here admin1 is responsible for theirs management.
However VS2 is placed in SMS2 and should be managed by admin2, who should not be allowed to manage VS0 and VS1.

Based on the above example it would be great if this admin2 could access VS2 directly via ssh.
Via Gaia Portal it is of course now possible with VSNext that he will only see VS2, and with that once he will login in Gaia Portal he will be inside VS2 context (not VS0).

But how to do it with ssh ?
I don't want obvious:
1) ssh into vs0
2) vsenv/set virtual-system 2
I want directly ssh into vs2

If we take a look into VS0 and VS2 netstat -anp ... we will see that "nothing" listens on port 22 in VS2:

That's of course why we can't login to VS2 via ssh.
It would be fine for VSX ... because we didn't have this management switch ... but now with VSNext we have it ... so it would be great if we could use "more management aspects" with it... 🙂

Is there any way ?

-
Best
m.

[marcyn]

Hi,
One addition to what I wrote before.
Sure, if I will create a user and assign him a role that limits access to only one VS, for example VS3 ... after he will login via ssh he will go directly to VS3.

But my question is:
Is it possible to achieve the same effect for a user that has a role that gives him access to "all VS" - by default such a user via ssh will go first to VS0 where he can "travel" between VSs (vsenv/set virtual-system).

Is it the only way to create a user and assign him a role that will limit his access to particulat VS ?
If so .. what about if this role will allow him only VS2+VS3... how can he switch between VS2 and VS3 if he will not have feature "virtual-system" ? 🙂

I just make some test, and created in gclish a rba role, new user:

add rba role xyz domain-type System readwrite-feature interface
add rba role xyz virtual-system-access 1
add user m uid 12345 homedir /home/m
add rba user m roles xyz

With that ... after I will login as "m" I will go directly to VS1 and have access only to "interfaces" in gclish/gaia portal.

But when I will change this rile to be something like that:

add rba role xyz virtual-system-access 1,2

When I will login as "m" I will go to VS1 ... but I won't be able to go to VS2 because this user doesn't have "virtual-system" feature.
So the solution is here is:

add rba role xyz domain-type System readwrite-feature interface,virtual-system

And now "m" can go from VS1 to VS2.... and of course can't go to VS0 and any other VS.

So ... I believe that I've found the solution ... but is this the only solution ?
In case user will have access to "all VS" will he always need to start with VS0 ... ?

--
Best
m.

[the_rock]

I set up R82 vsnext in the lab, can test this tomorrow and see if it works.

Andy

[marcyn]

No need Andy, it works like that 🙂
Thanks

--
Best
m.

[the_rock]

I did check it and indeed that is the case.

Andy

[emmap · Accepted solution]

This is the way to configure it, there is no way currently to set a 'default' VS context to land in when SSH'ing in. 

[marcyn]

OK, thank you for this confirmation.
I thought so to be honest ... but it's always good to ask 🙂

--
Best
m.

[PhoneBoy]

For my own edification, does SSH always drop you into vs0 in the case of VSnext? 

[marcyn]

@PhoneBoy
We will see what @emmap will reply.

But I will add something to you query from my side.
In case of user that has access to VS0 and other VSs he will go directly to VS0.
In case other user that has a role that allows access only to one or more VSs ... he will go to this one with the lowest number (ex. he has VS1 VS2 VS3 ... them he will login to VS1) ... when he will login to IP address of VS0.

But .. with VSNext we have management switch so I thought that why not ssh directly to the management IP of chosen VS (not this one that VS0 has) ? ... and this is not working for me.

A little lab on TechPoint (ElasticXL environment) - everybody can do that easly.

1) EXL-Member-1 (10.160.0.15) was removed from ElasticXL.

2) After reboot:
add vsnext virtual-gateway interfaces eth5 id 2 one-time-password 1234 instances 1 instances6 0 wait-for-task true

3) Then:
set virtual-system 2

show interfaces
eth5
wrp128

set interface wrp128 ipv4-address 10.160.0.99 mask-length 24

show interface wrp128 ipv4-address
1_01:
ipv4-address 10.160.0.99/24

4) Testing time:
first try - VS0:
C:\Users\Administrator>ssh admin@10.160.0.15
The authenticity of host '10.160.0.15 (10.160.0.15)' can't be established.
ECDSA key fingerprint is SHA256:uKy0ADO+rxnnrTBGxsV7AJdbRjlngok2U0MbEIxYYLU.
Are you sure you want to continue connecting (yes/no)?

so it works

now VS2:
C:\Users\Administrator>ssh admin@10.160.0.99
ssh: connect to host 10.160.0.99 port 22: Connection refused

so it doesn't work

meanwhile on VS2:
[Expert@gw-1-s01-01:2]# cppcap -i any -f "port 22 and host 10.160.0.99"
05:38:35.285471 In [Mgmt] 10.160.0.100:53234 > 10.160.0.99:22 IPP 6
05:38:35.285488 In [magg1] 10.160.0.100:53234 > 10.160.0.99:22 IPP 6
05:38:35.285500 Out [wrpj128] 10.160.0.100:53234 > 10.160.0.99:22 IPP 6
05:38:35.285512 In [wrp128] 10.160.0.100:53234 > 10.160.0.99:22 IPP 6
05:38:35.285711 Out [wrp128] 10.160.0.99:22 > 10.160.0.100:53234 IPP 6
05:38:35.285733 In [wrpj128] 10.160.0.99:22 > 10.160.0.100:53234 IPP 6
05:38:35.285737 Out [magg1] 10.160.0.99:22 > 10.160.0.100:53234 IPP 6
05:38:35.285744 Out [Mgmt] 10.160.0.99:22 > 10.160.0.100:53234 IPP 6

[Expert@gw-1-s01-01:2]# fw ctl zdebug + drop | egrep ':22|,22'
(nothing)

BTW
I received information from one of Check Point's employee that he can directly login to management IP of chosen VS ... but it was on phisical appliance, not virtual ... it would be really strange ...
So ... I'm confused right now a little bit ... will need to check it on phisical appliance when it will be possible 🙂

--
Best
m.

[PhoneBoy]

The lowest numbered VS the user has access to (which includes vs0), got it 🙂
Given the sshd only listens on the vs0 IP, it would require some sort of kernel process to redirect the traffic from the relevant vs management IP.

I suspect what you're asking for is an RFE, though.

[emmap]

I haven't tried specifically SSH'ing into VSs in VSNext, but certainly to restrict admins you use the RBA as described in this thread.

[ShaiF · Accepted solution]

Hi @marcyn ,

In our near roadmap is to support the option to activate optional daemons per VS. in your example you will be able to activate sshd on relevant VSs and have the ability to ssh with the VS mgmt ip directly to this VS.

Regards,

Shai.

[marcyn]

Hi @ShaiF

Perfect! 😀

Best

m.

[genisis__]

Do we know if VSLS will be supported in VSNext soon? and if I use traditional VSX to use VSLS, can I still use ElasticXL or must this be ClusterXL (which I suspect it does).

Reading the support notes it looks like in order to user VSNext with ElasticXL the trade off would be the ability to distribute the VS's across different nodes.

Also would like to know id vsx_provisioning tool can still be used?

[emmap]

VSLS is supported in VSNext as of R82 JHF take 14. You configure it directly on the cluster in gclish instead of using the vsx_util vsls tool. 

Traditional VSX is only supported on CXL, VSNext is only supported on EXL. 

vsx_provisioning_tool is only supported with traditional VSX.

[genisis__]

Awesome!  So VSNext in VSLS mode running over ElasticXL is supported from take JHFA14.

Can we also confirm the exact procedure (ideally a short video), on how to uninstall a jumbo and install a new one, without this being replicated to the other member.  In this way we would running mixed jumbos for a small period to determine if there are an issues, and the ideally run a command to replicate, which should uninstall the old jumbo and install the new one, on the slave member.

Once thing I noticed in the release notes for JHFA14 there is no mention of VSLS support, unless I've missed it?

[emmap]

Patching procedure is in the admin guide. It's the same as Maestro SGM procedure, so any video about that will be relevent.

https://sc1.checkpoint.com/documents/R82/WebAdminGuides/EN/CP_R82_ScalablePlatforms_AdminGuide/Conte...

Search for PRJ-58348 in the R82 JHF notes and you'll find the entry for VSLS.

[genisis__]

Ok had a look at the link but if we are using VSNext, we would not create a security group (at I don't believe we do), so the procedure in the admin guide talks about SGs, so even though it may be a good guide, its not exactly the same at least from what I read.
Note:
It may be something that is cleared up when actually doing it.

[PhoneBoy]

While I don't recall exactly when VSX was released, I can assure you it was before REST APIs were even a thing. 😉
vsx_provisioning_tool was created to allow for limited automation with Legacy VSX.
There are several things in the design of legacy VSX that are incompatible with REST APIs, which is why none are provided and none are planned.

Meanwhile, ElasticXL and VSnext were designed with REST APIs in mind (API-first).
ElasticXL and VSnext uses regular gateway objects, which have REST API support: https://sc1.checkpoint.com/documents/latest/APIs/index.html#cli/add-simple-gateway~v2%20
The actual cluster is configured on the gateways using the Gaia API: https://sc1.checkpoint.com/documents/latest/GaiaAPIs/#web/add-cluster-member~v1.8%20 
VSnext, you can add and configure Virtual Gateways and Virtual Switches via REST API.

[APopisteru]

I have it (JHF T14, VSLS configured with set cluster configuration high-availability mode 3 in VS0 and, for example, set cluster configuration high-availability vs site_priority "2 1" in VS context) working in a production environment, dual-site, one SGM per site. In my setup there are no inter-VS connections via vswitches and no inter-VS traffic (non-0 VSes have only physical interfaces attached, apart from management interface and there is no traffic between VS-es, especially between the VSes running on different SGMs).

[genisis__]

Great!
 Found it in this link:set cluster configuration high-availability

Configures the Dual Site mode:

• 0 - No primary Site ("Active Up" Mode)

• 1 - "Primary Up" Mode

• 2 - "Active Active" Mode

• 3 - Traditional VSX Virtual System Load Sharing (VSLS) Mode

[APopisteru]

Recap: TCP with VS-not-0-IP:22 is working, but there is no sshd daemon listening, because sshd, launched as a SystemV init daemon, is not context or VS aware.

For the particular case of sshd, one part of the per-vs feature might be easily added, namely sshd becoming aware of the interfaces and IPs of a VS (sshd listens by default on all available IPs).

I've just tested launching sshd in the network namespace of a virtual gateway (CTX00001) with 

ip netns exec CTX00001 /usr/sbin/sshd

from host VS (VS0) and to my awe and awesome, sshd answered from within correct VS (CTX00001) so some detection logic of the type of VS (we don't want to launch sshd in the network namespace of a virtual switch) could be added to /etc/init.d/sshd to spawn multiple VS network namespace aware sshd instances.

I remember myself that VSX was introduced in the same time if not even before namespaces were introduced in linux kernel (2002 mount, 2003 uts, 2007 netns, 2008 pid, 2013 user), solving the complex problems of traffic and administration separation way ahead its time, so what might be looking trivial today in the containers world (linking network namespaces with veths, running namespace-aware daemons as systemd services) might not be so easy to implement in an architecture that is evolving while proving viable for about two decades.

[marcyn]

Hi @APopisteru,

Thank you for this workaround - I can confirm that it's working fine.

--
Best
m.

[PhoneBoy]

Added to R82 JHF 25: 

PRJ-60148, PMTR-113933

VSNext

UPDATE: Rather than using the management switch, it is now possible to choose a different management interface for each virtual system (VS).

Which suggests we have a proper fix for this now.

[marcyn]

Hi @PhoneBoy

Yes, I saw this ... but to be honest I'm a little bit confused with this.
Before Take25 it was also possible to select different management interface instead of management switch...
But anyway ... even with Take25 nothing listenes on port 22 on VS.

It looks like that still the only solution that works is this one from APopisteru (ip netns) ... which is exacly what I wanted to achieve here.

--
BR
m.