Browse Prior Art Database

Command Hopping (CH) Disclosure Number: IPCOM000248105D
Publication Date: 2016-Oct-26
Document File: 23 page(s) / 1M

Publishing Venue

The Prior Art Database


A method is provided for understanding user commands, stripping of control flows, delaying and formulating complete command sections, before finally running an uninterrupted user script on multiple target endpoints with different shells (or without any shell) that are located more than 2 hops/nodes away from the user terminal/local machine while maintaining a local context of variables.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 23% of the total text.

Page 01 of 23

Command Hopping

Command Hopping


In a complex network structure and hierarchy, sometimes a user is required to go through a jump server (or multiple series of hosts) before they can connect to a target endpoint, which could be due to security reasons or other protocol/compliance purposes. The problem is when the target devices that the user is trying to reach are located 2 hops away (or more) from his local machine/client, and user does not have full control of the jump server/hosts between them (which do not allow installation of script or agent).

Sometimes those target devices are also not known beforehand, which requires the user to first gather this information (number of child devices available) from the host that is connected to them. This means that user cannot directly run a script on the target devices as the commands will be dropped at the

jump server/host before reaching the target. There is also a problem of different hosts having different shells (even custom ones) which requires multiple different scripts for each of them.

A real life scenario of this problem would typically be when deployment engineers need to configure multiple different endpoints (for example in school). They need to manually run their script on each of those endpoints (and knowing all of them beforehand) to make sure that it caters to all the different shells and other limitations. The best they could do is by using macro to carry this out, but it's stillonly limited to the first hopor the immediate target endpoint after the jump server/host, and will still face a problem with target devices being 2 hops away or more from the local machine/client that they are using.

Another real life scenario would be for Cloud deployment. As we know that a typical deployment for Cloud will involve a very complex network structure, yet it still needs to be done rapidly and continuously, and so time saving is of utmost importance for this case. A deployment on Cloud would also involve multiple different types of endpoints, and sometimes not all of them are known beforehand, which means that the ability to perform discovery would be very beneficial.



(((CH CH


Page 02 of 23

Figure 1

1) Cannot run a script directly in a target endpoint located 2 hops or more away from the client.

2) Cannot have a single script to handle all the different variations of available shells in the hosts.

3) Cannot discover how many target endpoints are there before actually prompting the hosts for them.

4) Some SSH clients cannot support environment variables, hence having a terminal specific variable handling mechanism will allow them to use variables without needing to have the knowledge/concept of such variables, and thus enhance their robustness.

5) In the case of Cloud, there is the need to perform deployment rapidly and continuously against a complex network structure with sometimes



Page 03 of 23

different or undiscovered endpoints.

The problems above...