Execute Command and proxy environment

Libraries SSHLibrary
1

Hi all,

i have a strange behavior and i think it must have something to do with the SSH Session in SSHLibrary.

So i have a host where i use jfrog-cli to download artifacts from artifactory using this command

CI=true JFROG_CLI_TEMP_DIR=/var/lib/kvmd/msd/ /opt/jf rt download ....

I’m using this for 2 years now without any problem.
For this i use Execute Command from SSHLibrary to run the command. Of course i first do a “Open Connection and Login In” and “Login” with user name and password. In the RF-Logs i can see the login. All good.

Now because of infrastructure changes i have to use a PROXY on the host where i execute the jfrog-cli command. BUT because my jfrog-cli command is used with an internal server i DON’T have to use the proxy that’s why my internal server is on the list for “NO_PROXY”

For this i have setup on my host the /etc/environment as follows

#
# This file is parsed by pam_env module
#
# Syntax: simple "KEY=VAL" pairs on separate lines
#
export https_proxy="http://x.x.x.x:8080"
export HTTPS_PROXY=$https_proxy
export http_proxy="http://x.x.x.x:8080"
export HTTP_PROXY=$http_proxy
export no_proxy="localhost,127.0.0.0/8,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,foo.bar"
export NO_PROXY=$no_proxy

AND i also have done changes to ~/.bashrc and put this

if [ -f /etc/environment ]; then
. /etc/environment
fi

Now if i reboot my device and if i use putty to connect via ssh - EVERYTHING IS WORKING!!
I can dl my artifacts and to test proxy you can use a “ping” like this

/opt/jf rt ping

Again - using putty or using ssh from my ubuntu and connect to my device everything is working fine.

But now using SSHLibrary and Execute Command i get an error on stderr like this

${stderr} = 11:34:51 [Warn] (Attempt 1) - Failure occurred while sending POST request to

This error appears when the /etc/environment is NOT set or is not present in the ssh session.

To me it looks like the SSHLibrary Open Connection Login will create a ssh session and login BUT for some reason the host proxy settings are NOT effective for these kind of ssh sessions.

Does anyone have an idea?

So far i tried to execute “env” first to check the variables for environment and to execute

source /etc/environment

to reload the environment.

Executing “env” i do see that the proxy ARE SET !!! See

['SHELL=/bin/bash\nno_proxy=localhost,127.0.0.0/8,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,foo.bar\nPWD=/root\nLOGNAME=root\nMOTD_SHOWN=pam\nHOME=/root\nhttps_proxy=http://x.x.x.x:xxxx\nSSH_CONNECTION=x.x.x.x 62931 x.x.x.x 22\nUSER=root\nNO_PROXY=$no_proxy\nSHLVL=0\nHTTPS_PROXY=$https_proxy\nHTTP_PROXY=$http_proxy\nhttp_proxy=http://x.x.x.x:xxxx\nSSH_CLIENT=x.x.x.x 62931 22\nPATH=/usr/local/sbin:/usr/local/bin:/usr/bin\nMAIL=/var/spool/mail/root\n_=/usr/bin/env', '0']

Chatgpt told me to set the proxy env variables to my execute command like this - but i’m not sure if this will work (shall i try?)

*** Settings ***
Library SSHLibrary

*** Variables ***
${REMOTE_HOST} your.remote.host
${REMOTE_USER} your_username
${REMOTE_PASSWORD} your_password
${HTTP_PROXY} http://proxy.example.com:8080
${HTTPS_PROXY} http://proxy.example.com:8080
${NO_PROXY} localhost,127.0.0.1

*** Test Cases ***
Test Command With Proxy
Open Connection ${REMOTE_HOST}
Login ${REMOTE_USER} ${REMOTE_PASSWORD}
${command}= Set Proxy Command curl -I http://example.com
${output}= Execute Command ${command}
Log ${output}
Close Connection

*** Keywords ***
Set Proxy Command
[Return] export http_proxy=${HTTP_PROXY} && export https_proxy=${HTTPS_PROXY} && export NO_PROXY=${NO_PROXY} && curl -I http://example.com

Any help is welcome
Br,
Camil

2

Whenever I have problems with Execute Command I use the Write / Read keywords. Maybe you could try to see if it makes a difference.

3

Hi,

yes i did a quick test like this

Write    /opt/jf rt ping
${output}=    Read    delay=0.5s

And in the log it’s working fine - see

KEYWORD SSHLibrary . Write   /opt/jf rt ping
Documentation: 	

Writes the given text on the remote machine and appends a newline.
Start / End / Elapsed: 	20250117 12:59:40.062 / 20250117 12:59:40.067 / 00:00:00.005
12:59:40.067 	INFO 	/opt/jf rt ping 	
00:00:01.004 KEYWORD ${output} =  SSHLibrary . Read   delay=0.5s
Documentation: 	

Consumes and returns everything available on the server output.
Start / End / Elapsed: 	20250117 12:59:40.068 / 20250117 12:59:41.072 / 00:00:01.004
12:59:41.071 	INFO 	[?2004l
OK
[?2004h[[1;31mroot[0m@[1;32mdummy[0m [1;34m~[0m]# 	
12:59:41.072 	INFO 	${output} = [?2004l
OK
[?2004h[[1;31mroot[0m@[1;32mdummy[0m [1;34m~[0m]#

As expected if i execute the jfrog-cli command “rt ping” - i get a simple “OK” returned. This is also the case when i do this using my putty ssh

So why is it not working when i use Execute Command ?
It must be smth. with the shell/terminal session - Looks like the execution is done on a xterm/session where the environment settings were not applied. So all the changes i did with /etc/environment or in ~/.bashrc file are not applied to this session.

4

Yes, that is in the documentation:

image
image945×908 55.2 KB

5

Yes, i also got this - and from the library code you can set the “term_type” in OpenConnection or using Set Client Configuration.

By default term_type is set to “vt100” see

I tried to set this type to “ansi” as this is the only other value for “term_type” - i hoped that using “term_type=ansi” the changes would apply - but NO :frowning_face:

I also configured my device to use systemd proxy-settings and restarted it - the systemd service is running fine - but i still get this error using Execute Command.

The doc says:

  • Execute Command and Start Command. The command is executed in a new shell on the remote machine, which means that possible changes to the environment (e.g. changing working directory, setting environment variables, etc.) are not visible to the subsequent keywords.

Well ok - but for me “new shell” means that environment settings will be applied - its like doing “duplicate session in putty” - no? - i mean the doc says “no” so i can answer this question by myself - but WHY is Execute Command not able to catch up environment settings?? - What’s the point about executing commands but explicit “ignoring” environment settings - it should be the otherway round - by default execute command shall consider env settings and you shall be able to disable this default behaviour.

6

Issue is about Login/Interactive shell versus Non-interactive shell and as Helio said, using read/write will essentially open interactive shell and tends to work :wink:

For example; see answers in this question; Difference between Login Shell and Non-Login Shell? - Unix & Linux Stack Exchange

7

Yes - thx for the link.

I did quick test using execute command and running $0 - here’s the output

3:55:19.011 	INFO 	Executing command 'echo $0'. 	
13:55:19.039 	INFO 	Command exited with return code 0. 	
13:55:19.040 	INFO 	${stdout} = bash

You can see that the output is “bash” and not “-bash” - thus its a non-interactive shell.

The post says that:

### Running a command over ssh remotely with `-t` switch

You can explicitly request interactive shell when you want to run command remotely via ssh 
by using `-t` switch.

So is there something like the -t switch for execute command?
Or do i have to refactor my code to use “Write” :frowning:

8

I found a “good” solution for me which is the following

Execute Command   export NO_PROXY=${NO_PROXY} && /opt/jf rt ping

I just define a variable with NO_PROXY having the internal-network there (which includes the artifactory server) and in this case NO_PROXY will be used for jfrog-cli as it is NOT needed because artifactory is an internal server and proxy shall be used for anything “external”.

I tired it out and it is working - so don’t need to use “Write/Read” but i have to do the export NO_PROXY as the shell is a non-interactive when using Execute Command.

Thx all for the quick reply and help.

1 Like
9

Yes, and because the session was non-interactive, /etc/environment is not automatically applied.

Interactive shell is typically start by -l flag to bash/shell so that shell knows what initialization path it should take. Im not 100% if this happens automatically if ssh requests a tty when connection is formed (you mentioned -t so i thought you where referring to ssh itself) but in any session, tty or not, if you start a new shell with that -l, it is considered as login shell and more default scripts are sourced.

Anyway, i do think the fix you used is the correct one. Less you need to maintain as a state in execution environment, easier they are for you (and also acts as “documentation”).

1 Like