Ssh script возвращает ошибку 255

В моем коде у меня есть следующее, чтобы запустить удаленный script.

ssh [email protected] "sh /home/user/backup_mysql.sh"

По какой-то причине он держится на мне. Любые идеи?

Я могу использовать SSH в коробке очень хорошо (настройка беспроблемных клавиш)

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 "[email protected]"
        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

Ответы

Ответ 1

Это обычно происходит, когда пульт недоступен/недоступен; или на удаленном компьютере не установлено ssh; или брандмауэр не позволяет установить соединение с удаленным хостом.

ssh возвращает 255 при возникновении ошибки или возвращается 255 удаленным script:

 EXIT STATUS

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

Обычно у вас есть сообщение об ошибке, похожее на:

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

или

ssh: connect to host HOSTNAME port 22: Connection refused

Контрольный список:

Что произойдет, если вы запустите команду ssh непосредственно из командной строки?
Можете ли вы ping эту машину?
Установлен ли пульт ssh?
Если установлено, то работает ли служба ssh?

Ответ 2

Эта ошибка также возникает при использовании pdsh для хостов, которые не содержатся в файле "known_hosts".

Я смог исправить это SSH'ing на каждом хосте вручную и принять вопрос "Хотите добавить это к известным хостам".

Ответ 3

Если возникает проблема с аутентификацией или подключением, например, невозможность чтения пароля с терминала, ssh завершит работу с 255 без возможности запуска вашего фактического script. Убедитесь, что вы можете запустить 'true' вместо этого, чтобы проверить, успешно ли установлено соединение ssh.

Ответ 4

Я был в шоке от этого. Как только я получил проблему 255... Я закончил с таинственным кодом ошибки 1. Это foo, чтобы решить эту проблему:

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

-P означает запись вывода по ходу и необязательна. Но трюк -x '-tt' - это то, что заставляет выделять psuedo tty.

Вы можете понять, что означает код ошибки 1, если вы попытаетесь:

ssh AHOST "sudo yum -y install glibc"

Вы можете видеть:

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

Обратите внимание, что код возврата для этого - 1, что и сообщает pssh.

Я нашел здесь -x-трюк здесь. Также обратите внимание, что включение подробного режима (pssh --verbose) для этих случаев не помогает вам.

Ответ 5

Как написали @wes-floyd и @zpon, добавьте эти параметры в SSH, чтобы обойти "Вы уверены, что хотите продолжить подключение (да/нет)?"

-o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no

Ответ 6

Если приведенное выше не помогло: проверьте, действителен ли языковой стандарт для клиента и сервера:
https://www.linuxbabe.com/linux-server/fix-ssh-locale-environment-variable-error
Как не передать локаль через ssh

Ответ 7

SSH Очень критическая проблема на производстве. SSH-debug1: выход из состояния 255

Я работал с Live Server, и многие вещи застряли. Я пытаюсь исправить многие вещи, но точная проблема 255 не выясняется.

Даже я решил проблему 100%

Заменить мой файл sshd_config на аналогичный другой мой сервер Debian

[email protected]: ~ # cp sshd_config sshd_config.snippetbucket.com.bkp # сохранить мой файл резервной копии

[email protected]: ~ # echo ""> sshd_config

[email protected]: ~ # nano sshd_config # заменяет весь контент другим точно таким же сервером

[email protected]: ~ # служба sudo ssh restart # нормально перезапустить сервер

Эти 100% решают мою проблему немедленно.

# SnippetBucket-Tip: Всегда делайте резервную копию файлов, связанных с ssh, что помогает при быстром восстановлении.

Примечание: после применения данных изменений вам необходимо выйти из режима восстановления и перезагрузить ваш vps/выделенный сервер в обычном режиме, чем работает ваше ssh-соединение.

В режиме восстановления ssh не позволяет пользователю входить в систему как обычно. работает только спасение связанных с ssh логин и пароль.