ssh-script retourneert 255-fout

In mijn code heb ik het volgende om een script op afstand uit te voeren.

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

Om de een of andere reden blijft het op mij gericht. Enig idee?

Ik kan prima SSH in de box (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

Antwoord 1, Autoriteit 100%

Dit gebeurt meestal wanneer de afstandsbediening is / niet beschikbaar; of de externe machine heeft geen SSH geïnstalleerd; of een firewall staat niet toe dat een verbinding tot op afstand wordt gevestigd.

sshRETOURNEREN 255 Wanneer er een fout is opgetreden of 255 wordt geretourneerd door het afstandscript:

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

Meestal zou u een foutmelding iets vergelijkbaar met:

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

of

ssh: connect to host HOSTNAME port 22: Connection refused

checklist:

  • Wat gebeurt er als u de SSH-opdracht rechtstreeks van de opdrachtregel uitvoert?

  • Bent u in staat om pingdie machine te gebruiken?

  • Heeft de afstandsbediening ssh geïnstalleerd?

  • indien geïnstalleerd, dan is de SSH-service?


Antwoord 2, Autoriteit 33%

Deze fout zal ook optreden bij gebruik van PDSH naar hosts die niet zijn opgenomen in het bestand “Bekend_hosts”.

Ik was in staat om dit te corrigeren door ssh’ing in elke host handmatig en het accepteren van de vraag “Wilt u dit toevoegen aan bekende hosts”.


Antwoord 3, Autoriteit 15%

Als er een probleem is met authenticatie of verbinding, zoals het niet in staat zijn om een ​​wachtwoord uit de terminal te lezen, zal SSH afsluiten met 255 zonder uw eigenlijke script te kunnen uitvoeren. Controleer of u in plaats daarvan ‘TRUE’ kunt uitvoeren, om te zien of de SSH-verbinding met succes is vastgelegd.


Antwoord 4, Autoriteit 8%

Ik was hierdoor stumped. Zodra ik het 255 probleem aankwam … eindigde ik met een mysterieuze foutcode 1. Dit is de foo om dat opgelost te krijgen:

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

-P betekent het uitvoer schrijven terwijl je gaat en is optioneel. Maar de -x ‘-TT’ Trick is wat een Psuedo TTY heeft toegewezen.

U kunt een idee krijgen van de foutcode 1 betekent dit als u het probeert:

ssh AHOST "sudo yum -y install glibc"

Mogelijk ziet u:

[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

Let op dat de retourcode hiervoor 1 is, wat pssh aan u rapporteert.

Ik heb deze -x -tt-truc gevonden hier. Merk ook op dat het inschakelen van de uitgebreide modus (pssh –verbose) voor deze gevallen niets helpt.


Antwoord 5, autoriteit 5%

Het kan heel goed een ssh-agent-probleem zijn.
Controleer of er momenteel een ssh-agent PID actief is met eval "$(ssh-agent -s)"

Controleer of uw identiteit is toegevoegd met ssh-add -len zo niet, voeg deze toe met ssh-add <pathToYourRSAKey>.

Probeer dan opnieuw je ssh-commando (of een ander commando dat ssh-daemons voortbrengt, zoals autosshbijvoorbeeld) dat 255 retourneerde.


Antwoord 6

Als bovenstaande niet heeft geholpen: controleer of de landinstelling geldig is op client en server:
https://www.linuxbabe.com/linux- server/fix-ssh-locale-environment-variable-error
Hoe de landinstelling niet doorgeven via ssh

Other episodes