ssh script returns 255 error

Question

In my code I have the following to run a remote script.

ssh root@host.domain.com "sh /home/user/backup_mysql.sh"

For some reason it keeps 255'ing on me. Any ideas?

I can SSH into the box just fine (passless keys setup)

REMOTE SCRIPT:

MUSER='root' 
MPASS='123123'
MHOST="127.0.0.1"
VERBOSE=0

### Set bins path ###
GZIP=/bin/gzip
MYSQL=/usr/bin/mysql
MYSQLDUMP=/usr/bin/mysqldump
RM=/bin/rm
MKDIR=/bin/mkdir
MYSQLADMIN=/usr/bin/mysqladmin
GREP=/bin/grep

### Setup dump directory ###
BAKRSNROOT=/.snapshots/tmp

#####################################
### ----[ No Editing below ]------###
#####################################
### Default time format ###
TIME_FORMAT='%H_%M_%S%P'

### Make a backup ###
backup_mysql_rsnapshot(){
        local DBS="$($MYSQL -u $MUSER -h $MHOST -p$MPASS -Bse 'show databases')"
        local db="";
        [ ! -d $BAKRSNROOT ] && ${MKDIR} -p $BAKRSNROOT
        ${RM} -f $BAKRSNROOT/* >/dev/null 2>&1
#       [ $VERBOSE -eq 1 ] && echo "*** Dumping MySQL Database ***"
#       [ $VERBOSE -eq 1 ] && echo -n "Database> "
        for db in $DBS
        do
                local tTime=$(date +"${TIME_FORMAT}")
                local FILE="${BAKRSNROOT}/${db}.${tTime}.gz"
#               [ $VERBOSE -eq 1 ] && echo -n "$db.."
                ${MYSQLDUMP} --single-transaction -u ${MUSER} -h ${MHOST} -p${MPASS} $db | ${GZIP} -9 > $FILE
        done
#               [ $VERBOSE -eq 1 ] && echo ""
#               [ $VERBOSE -eq 1 ] && echo "*** Backup done [ files wrote to $BAKRSNROOT] ***"
}

### Die on demand with message ###
die(){
        echo "$@"
        exit 999
}

### Make sure bins exists.. else die
verify_bins(){
        [ ! -x $GZIP ] && die "File $GZIP does not exists. Make sure correct path is set in $0."
        [ ! -x $MYSQL ] && die "File $MYSQL does not exists. Make sure correct path is set in $0."
        [ ! -x $MYSQLDUMP ] && die "File $MYSQLDUMP does not exists. Make sure correct path is set in $0."
        [ ! -x $RM ] && die "File $RM does not exists. Make sure correct path is set in $0."
        [ ! -x $MKDIR ] && die "File $MKDIR does not exists. Make sure correct path is set in $0."
        [ ! -x $MYSQLADMIN ] && die "File $MYSQLADMIN does not exists. Make sure correct path is set in $0."
        [ ! -x $GREP ] && die "File $GREP does not exists. Make sure correct path is set in $0."
}

### Make sure we can connect to server ... else die
verify_mysql_connection(){
        $MYSQLADMIN  -u $MUSER -h $MHOST -p$MPASS ping | $GREP 'alive'>/dev/null
        [ $? -eq 0 ] || die "Error: Cannot connect to MySQL Server. Make sure username and password are set correctly in $0"
}

### main ####
verify_bins
verify_mysql_connection
backup_mysql_rsnapshot

For some reason your *remote* script returns 255, and ssh just delivers its result to you. How about showing us the script? — Anton Kovalenko, Feb 14 '13 at 23:15
As a warning, do not use garbage edits to keep bumping your question to the front of the queue. If you do this again, I will lock this question. — Brad Larson, Feb 20 '13 at 02:22
One thing I often forget when moving the client to another machine is the first time you do it asks you to verify the fingerprint, so if you're not doing it interactively, it fails until you manage to answer that question manually for the same account. — frankieandshadow, May 22 '15 at 14:23
I found my similar problem, so in case it helps anyone else... I could ssh on the command line, but not when run from a script. The problem was I had agent forwarding turned on when I logged into the machine *from which* I was doing the ssh, so the problem with my certificate (which was that it I hadn't got the permissions right) was not showing up because it used my forwarded key instead. I had to turn off agent forwarding to see the error message that the script was presumably also getting but wasn't being captured in the output. — frankieandshadow, May 22 '15 at 16:01
I got error 255 while forwarding a port to a server with *autossh*. Every time my Internet got disconnected, the server wouldn't notice that the connection had terminated, and would not free up the port I was forwarding to. This prevented the new connection initiated by *autossh* from binding to the port, making it fail with error 255. The solution was to set the `ClientAliveInterval` in the `sshd_config` file on the server. — SomeDude, Jun 22 '22 at 19:31

score 55 · Answer 1 · answered Feb 14 '13 at 23:30

55

This is usually happens when the remote is down/unavailable; or the remote machine doesn't have ssh installed; or a firewall doesn't allow a connection to be established to the remote host.

ssh returns 255 when an error occurred or 255 is returned by the remote script:

 EXIT STATUS

     ssh exits with the exit status of the remote command or
     with 255 if an error occurred.

Usually you would an error message something similar to:

ssh: connect to host host.domain.com port 22: No route to host

Or

ssh: connect to host HOSTNAME port 22: Connection refused

Check-list:

What happens if you run the ssh command directly from the command line?
Are you able to ping that machine?
Does the remote has ssh installed?
If installed, then is the ssh service running?

answered Feb 14 '13 at 23:30

P.P

117,907
20
175
238

Then it's the script you run on the remote host that returns 255. – P.P Feb 14 '13 at 23:31
1

It's hard to identify *why* your script returns 255. Most likely it's the function `backup_mysql_rsnapshot` that has the failing part as the other two functions return 999 in case of failure. You can ssh to that machine and test the script? You can use `set -e` in your script to debug it. – P.P Feb 14 '13 at 23:41
script works fine locally. not sure why it is breaking remotely. ;/ – Amanada Smith Feb 14 '13 at 23:43
May be, you can check the return code of each command you run in that function and return unique return code for each failure so that you can identify which command fails. – P.P Feb 14 '13 at 23:57
How would I do that exactly? Thanks. – Amanada Smith Feb 15 '13 at 00:01
2

For example, `${MYSQLDUMP} --single-transaction -u ${MUSER} -h ${MHOST} -p${MPASS} $db || exit 101` etc – P.P Feb 15 '13 at 00:04

score 15 · Answer 2 · answered Jul 11 '14 at 01:59

15

This error will also occur when using pdsh to hosts which are not contained in your "known_hosts" file.

I was able to correct this by SSH'ing into each host manually and accepting the question "Do you want to add this to known hosts".

answered Jul 11 '14 at 01:59

Wes Floyd

346
3
6

3

`-x "-o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no"` worked for me as well – zpon Nov 02 '16 at 06:55

score 8 · Answer 3 · answered Feb 14 '13 at 23:28

If there's a problem with authentication or connection, such as not being able to read a password from the terminal, ssh will exit with 255 without being able to run your actual script. Verify to make sure you can run 'true' instead, to see if the ssh connection is established successfully.

score 5 · Answer 4 · answered Nov 03 '21 at 21:01

5

Isn't the problem in the lines:

### Die on demand with message ###
die(){
  echo "$@"
  exit 999
}

Correct me if I'm wrong but I believe exit 999 is out of range for an exit code and results in a exit status of 255.

answered Nov 03 '21 at 21:01

Alex R.

1
1
3

3

This is an underrated answer. – Robert Baker Dec 22 '21 at 14:15

score 3 · Answer 5 · answered Mar 18 '16 at 21:59

I was stumped by this. Once I got passed the 255 problem... I ended up with a mysterious error code 1. This is the foo to get that resolved:

 pssh -x '-tt' -h HOSTFILELIST -P "sudo yum -y install glibc"

-P means write the output out as you go and is optional. But the -x '-tt' trick is what forces a psuedo tty to be allocated.

You can get a clue what the error code 1 means this if you try:

ssh AHOST "sudo yum -y install glibc"

You may see:

[slc@bastion-ci ~]$ ssh MYHOST "sudo yum -y install glibc"
sudo: sorry, you must have a tty to run sudo
[slc@bastion-ci ~]$ echo $?
1

Notice the return code for this is 1, which is what pssh is reporting to you.

I found this -x -tt trick here. Also note that turning on verbose mode (pssh --verbose) for these cases does nothing to help you.

score 2 · Answer 6 · answered Dec 23 '19 at 10:54

It can very much be an ssh-agent issue. Check whether there is an ssh-agent PID currently running with eval "$(ssh-agent -s)"

Check whether your identity is added with ssh-add -l and if not, add it with ssh-add <pathToYourRSAKey>.

Then try again your ssh command (or any other command that spawns ssh daemons, like autossh for example) that returned 255.

Dmitry · Answer 7 · 2019-09-30T01:32:06.773

0

If above didn't help: check if locale is valid on client and server:
https://www.linuxbabe.com/linux-server/fix-ssh-locale-environment-variable-error
How do not pass locale through ssh

edited Sep 30 '19 at 01:32

answered Sep 29 '19 at 23:22

Dmitry

470
6
9

score 0 · Answer 8 · answered May 05 '22 at 10:18

0

### Die on demand with message ###
die(){
        echo "$@"
        exit 999
}

I don't have the rep to comment on Alex's answer but the exit 999 line returns code 231 on my WSL Ubuntu 20.04.4 box. Not quite sure why that is returned but I understand that it's out of range.

answered May 05 '22 at 10:18

jimbo8098

103
1
7

1

`255 & 999` (bitwise-and) is 231. In other words, 231 is 999 truncated to one byte. – jkinkead Aug 30 '22 at 20:29

ssh script returns 255 error

8 Answers8

Linked