SSHLibrary | Robot Framework test library for SSH and SFTP

Ssh tunnels should work in a way that that you establish SSH connection to another host and expose a PORT in localhost that will then tunnel a traffic from that port in localhost to a IP/PORT in the end point of the tunnel ..

So, lets say you have a host at 192.168.100.10 where your robotframework is running and it needs to connect to a database in 192.168.50.100:

If the postgres is accessible via ssh directly:

Your server seems to issue two keyboard-interactive authentication challenges

• First, a prompt for a password
• Second, a banner with no prompts.

So you will have to do something like this:

1. If it's possible to login as root add your public key and login with keyword Login With Public Key.

2. If you can't connect to server as root user you try interactive shell instead

Like this

The issue was the stream return on the curl command.

While stdout had no information, stderr had the information regarding the "connection was reset".

Even when I added return_stderr=True to "execute command", it did not work.

"execute command" keyword has a number of multiple return options, stdout enabled by default.

When using both the stdout and stderr, my variable became a list and the "should contain" keyword only checked the first record of the list [0]. The solution is to either disable the default stdout and enable stderr if we want to use one variable OR use multiple variables.

${variable} = execute command curl -v example.com return_stdout=False return_stderr=True

${stdout} ${stderr} ${rc} = execute command curl -v example.com return_stderr=True return_rc=True

The use case you describe - a browser to be opened & controlled on a remote machine, is precisely what Selenium solves.
Though in day-to-day work or debugging we are usually starting a local browser, SE is preliminary designed for remote execution. So head to www.selenium.dev, and focus on the Grid - that's the component you are after.

I'm that approach, answers to your specific questions:

1. no, you need Robot Framework and selenium library on the local machine, and only selenium & webdriver on the remote.
2. you don't need the drivers on the client - the selenium library is all you communicate with in your code; you need them installed in the remote only.
3. on the local you will get the logs of the webdriver commands execution; actual browser manipulation logs are only on the remote and the hub (but these are really debugging ones, everything high-level for the functional execution is local).
4. you don't really log into RDP with this approach (RDP is totally out of the picture here), and yes - your code is the same as running on local browser - Open Browser, Get Text, etc - but, executed on a remote machine.

If you want to see why 1) and 2), head to the answer over here (shameless plug 🙂)

As you said login.login That tells me you have probably another library that has keyword login. In this case you have to specify that you want to use SSH library. You can do this with

The detection of robot executable is not dependent on the version of RIDE, but on the installed version in Python. But this may result in different robot being executed when running tests. When the test is executed, it should use the robot as it would if launched from command line.

Like was mentioned by Bence Kaulics, pybotwas renamed to robot from certain version. And in version 3.1.x, robot was changed to an executable instead of a .bat file (in Windows). That was the reason to have both robot and robot 3.1. So, in Windows, when selecting robotyou may be executing a robot.cmd script. The same is valid for pybot.bat with profile pybot.

EDIT: You can compare the settings.cfg file from the two machines. See it at ~/.robotframework/ride/settings.cfg (or %APPDATA%\robotframework\ride\settings.cfg ), on the [Plugins][[Test Runner]] section, the run_profiles property is defined there.

You have to take a look at the arguments for SSHLibrary - Login keyword.
As seen in the documentation Login first argument is username.
However, in your code you give 127.0.0.1 as username.
login 127.0.0.1 gfi
And I assume that is not the username.

You can also see this in the log message, that it try to login 127.0.0.1:2123 as 127.0.0.1.
INFO : Logging into '127.0.0.1:2123' as '127.0.0.1'.

If you update the code and call login keyword with username and password as expected, it should run fine.
login

I would consider a reasonable increase of the SSH timeout to resolve the issue. These are your options:

1. You can set a timeout at library import.