Sign up ×

There are a few things going on here but I think ultimately, either CLish or SSH is returning an exit code that is messing up my work flow.

I'm attempting to connect to a remote machine (CLish shell) using sshpass. The script that is being run is exiting with "exit 0" (and works when I call it directly on my local machine) but the exit code that is returned to my local shell is "255". Yes, confusing, I know, but maybe an example will help. I think I've narrowed down my problem to a simple example.

Connect to server running CLish and drop to bash shell in single command from local machine to server:

me@local$ sshpass -p 'password' ssh -t user@ 'shell'
user@server:~$ exit 0
Connection to closed.

Back on my machine, check the exit code:

me@local$ echo $?

Manually drop to shell on the remote machine with sshpass and CLish:

me@local$ sshpass -p 'password' ssh user@
CLishPrompt> shell
me@server$ exit
CLishPrompt> exit
Connection to closed.

Check the exit code back on my machine:

me@local$ echo $?

I really need to issue the 'shell' command in the same sshpass call as in the first example because I am using redirection to write a script to the server's filesystem and run it (all in a single call). I would like it to return an exit code of "0" like the second example shows. I have been unable to find a work-around this problem. The reason I need exit code "0" is because this script is returning its findings in a Jenkins-CI "build" and I don't know how to tell Jenkins-CI to accept an exit code of 255. If this was bash, then I could check the exit code myself and continue on to the next part of my script.

I need to either get ssh to return "0" or tell Jenkins that "255" is okay in this instance. Do you know what's going on here or have any suggestions?

share|improve this question
Obvious solution^W workaround: write a bash wrapper script, then you can test the return code. –  derobert Apr 16 '13 at 21:38
Obvious solution^W workaround: use public key authentication instead of a password. –  Gilles Apr 16 '13 at 23:34
It's part of a CI thing and public key auth isn't an option at this time. I have added a wrapper which is a great workaround. I guess having jenkins accept other codes is a long, slippery slope that I shouldn't go down but I'm curious as to why the different return codes on the two different methods. It's quite unexpected. –  harperville Apr 17 '13 at 12:20

Your Answer



Browse other questions tagged or ask your own question.