PR: https://github.com/jenkinsci/ssh-steps-plugin/pull/15

Thank you very much Naresh.

It does make sense what you suggested, just to see command output when log level set to OFF.

This has been released 1.2.1, it should available soon in the update center. Thank you vladaurosh and marjohartman for the help reporting this. 

Closing this now, don't mind to reopen or create a new one just in case if there is any issues with this change. Thanks again. 

Hello Naresh.

Sorry to bother again. I just tried latest version, it does look a lot better. But I thinki there's one left over, if sudo is set to true and logLevel is OFF. Still I can see, I would say, some kind of password representation, for example:

d1d24c36-c6e1-4f0c-8294-8461efacf97c

Can this be hidden as well when logLevel is set to OFF?

Thanks,

Vlad

That is an unique id generated for the specific session (nothing related to password or username), unfortunately that is part of underlying library, which I won't be able to alter. Thank you. 

Hello Naresh.

Sorry for opening this again I tested something and I am a bit confused.  I executed couple of commands with and without sudo.

1. working command without sudo

    sshCommand remote: remote, command: "echo regards" 

   Output is:
regards

2. working command with sudo 

   sshCommand sudo: true,remote: remote, command: "echo regards"

   Output is:  
17362243-a06c-4421-bfb1-c15684b3ffc0
regards
 

3. wrong command with sudo

  sshCommand sudo: true,remote: remote, command: "some_command"

  Output is:

 
9b30df7c-86d7-4bdf-a5ed-f956a1286686
sudo: some_command: command not found
I caught exception and it is:

org.hidetake.groovy.ssh.session.BadExitStatusException: Command returned exit status 1: sudo -S -p '9b30df7c-86d7-4bdf-a5ed-f956a1286686' some_command

So looks like if I use
remote.logLevel = 'OFF'
remote.appendName = false

and sudo is set to false (default)  output is not showing unique id.

With sudo set to true we see it in output. 

Looking at exception and how sudo is executed options for sudo are:

-p prompt   The -p (prompt) option allows you to override the default password prompt and use a custom one.

-S          The -S (stdin) option causes sudo to read the password from the standard input instead of the terminal device.  The password must be followed by a newline character.

sudo -S -p should mean sending password, so 9b30df7c-86d7-4bdf-a5ed-f956a1286686 is somehow related to sudo and password.

And as you see in output there is 9b30df7c-86d7-4bdf-a5ed-f956a1286686 which is same as in sudo -S -p '9b30df7c-86d7-4bdf-a5ed-f956a1286686'

Maybe I am wrong in this.

Thanks,

Vlad

Yes, you are right, and that is an expected behavior, sudo command prompts for password, so this plugin is opening up a unique session to interact with actual shell command, and those lines are related to that session. 

For the normal command we just logon to box and execute the command, but for the sudo commands we need to logon to box and up on executing the sudo command which prompts for password again, requires someone manually key in the password, which isn't ideal in case of automation and also Jenkins doesn't support shell interactions. 

vladaurosh so what are you expecting.. or what is the use case that has prompted you to ask this question and reopen this JIRA? 

Thanks for the explanation Naresh.

We should be fine to close this now.

Ideally for me would be not to see for example 9b30df7c-86d7-4bdf-a5ed-f956a1286686 in console output but as you said, it is some other library that is causing it.

Yes, as I mentioned before that is something being printed by dependent library. so I have little control over that one. Thank you.