Sziasztok!
Az alábbi a kihívásom:
Adott két szerver egymástól 200Km-re :D
Napi rendszerességgel szeretnék backupot egyikről másikra.
Ami eddig megvan:
Megy a napi mentés, public key segítségével minden nap feltolja SCP-vel másik szerverre.
És most jön a csavar :D Néha nem csinálja! debuglogom szerint az SCP-nél akad el. Azaz nem tölti fel, de azt is autentikációs hiba miatt.
Tehát a dest. szerver utasítja el a kapcsolatot.
Ami még érdekes lehet, hogy ha manuálba indítom el a backup scriptet, akkor 10-ből 10-szer a szemem előtt fel is tolja a dest. szerverre.
Cronnal is csinálja egy darabig, majd 1 hétig nem. Aztán megint csinálja vagy két napig.
Ha valakinek van ötlete, vagy tudja a megoldást az írjon plZ.
Köszi
- 4223 megtekintés
Hozzászólások
Célszerveren, ahova másolsz az sshd_config-ban emeld meg a LogLevel-t (man sshd_config) és nézd meg, hogy a szerver mit ír a dologról.
Ubuntu-n például a /var/log/auth.log-ba kerülnek ezek a bejegyzések.
- A hozzászóláshoz be kell jelentkezni
Hamarosan kipróbálom, köszönöm.
Másik érdekességet is észrevettem ami segíthet megoldani.
Az általam írt script-ben van egy olyan hogy
mv $FILE1 $FILE2;
Amit ha futtatok manuálba (root-ként), akkor hibátlanul működik.
Viszont ha cron futtatja (root-ként), akkor nem írja felül FILE2-t ha létezik.
* html {display: none}
- A hozzászóláshoz be kell jelentkezni
mv -f-el próbáld.
- A hozzászóláshoz be kell jelentkezni
Igen, erre én is gondoltam.
Az mv-t ezzel megoldom, ez csak rávilágít valami olyasmire, hogy a crontab mégsem olyan jogosultságokkal futtatja a scriptjeimet mint én magam, vagy ahogy szeretném ?
* html {display: none}
- A hozzászóláshoz be kell jelentkezni
Nem lehet hogy alias-od van az mv -re? Azért működik máshogy kézzel, mint cron-ból?
- A hozzászóláshoz be kell jelentkezni
nem
* html {display: none}
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
Ez a beállítás okozhatja azt,hogy néha csinálja, néha nem ?
Ugyanis megcsinálja cronból is nem csak manuálból, csak néha nem :S
* html {display: none}
- A hozzászóláshoz be kell jelentkezni
Na kipróbáltam az általad leírtakat, de sajnos nem tudom dekódolni. Mintha a kapcsolat létrejött volna, de a file nem került át.
Jul 18 01:07:01 *hoszt* sshd[4669]: debug1: Forked child 9185.
Jul 18 01:07:01 *hoszt* sshd[9185]: Set /proc/self/oom_adj to 0
Jul 18 01:07:01 *hoszt* sshd[9185]: debug1: rexec start in 5 out 5 newsock 5 pipe 7 sock 8
Jul 18 01:07:01 *hoszt* sshd[9185]: debug1: inetd sockets after dupping: 3, 3
Jul 18 01:07:01 *hoszt* sshd[9185]: Connection from ***.***.***.*** port 40884
Jul 18 01:07:01 *hoszt* sshd[9185]: debug1: Client protocol version 2.0; client software version OpenSSH_5.1p1 Debian-6ubuntu2
Jul 18 01:07:01 *hoszt* sshd[9185]: debug1: match: OpenSSH_5.1p1 Debian-6ubuntu2 pat OpenSSH*
Jul 18 01:07:01 *hoszt* sshd[9185]: debug1: Enabling compatibility mode for protocol 2.0
Jul 18 01:07:01 *hoszt* sshd[9185]: debug1: Local version string SSH-2.0-OpenSSH_5.5p1 Debian-4ubuntu4
Jul 18 01:07:01 *hoszt* sshd[9185]: debug1: PAM: initializing for "*user*"
Jul 18 01:07:01 *hoszt* sshd[9185]: debug1: PAM: setting PAM_RHOST to "tempobit.hu"
Jul 18 01:07:01 *hoszt* sshd[9185]: debug1: PAM: setting PAM_TTY to "ssh"
Jul 18 01:07:01 *hoszt* sshd[9185]: Failed none for *user* from ***.***.***.*** port 40884 ssh2
Jul 18 01:07:01 *hoszt* sshd[9185]: debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
Jul 18 01:07:01 *hoszt* sshd[9185]: debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
Jul 18 01:07:01 *hoszt* sshd[9185]: debug1: temporarily_use_uid: 1000/1000 (e=0/0)
Jul 18 01:07:01 *hoszt* sshd[9185]: debug1: trying public key file /home/*user*/.ssh/authorized_keys
Jul 18 01:07:01 *hoszt* sshd[9185]: debug1: fd 4 clearing O_NONBLOCK
Jul 18 01:07:01 *hoszt* sshd[9185]: debug1: matching key found: file /home/*user*/.ssh/authorized_keys, line 1
Jul 18 01:07:01 *hoszt* sshd[9185]: Found matching RSA key: **:**:**:43:e9:f9:8b:d2:bd:96:b6:31:**:**:**:**
Jul 18 01:07:01 *hoszt* sshd[9185]: debug1: restore_uid: 0/0
Jul 18 01:07:01 *hoszt* sshd[9185]: debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
Jul 18 01:07:01 *hoszt* sshd[9185]: debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
Jul 18 01:07:01 *hoszt* sshd[9185]: debug1: temporarily_use_uid: 1000/1000 (e=0/0)
Jul 18 01:07:01 *hoszt* sshd[9185]: debug1: trying public key file /home/*user*/.ssh/authorized_keys
Jul 18 01:07:01 *hoszt* sshd[9185]: debug1: fd 4 clearing O_NONBLOCK
Jul 18 01:07:01 *hoszt* sshd[9185]: debug1: matching key found: file /home/*user*/.ssh/authorized_keys, line 1
Jul 18 01:07:01 *hoszt* sshd[9185]: Found matching RSA key: **:**:**:43:e9:f9:8b:d2:bd:96:b6:31:**:**:**:**
Jul 18 01:07:01 *hoszt* sshd[9185]: debug1: restore_uid: 0/0
Jul 18 01:07:01 *hoszt* sshd[9185]: debug1: ssh_rsa_verify: signature correct
Jul 18 01:07:01 *hoszt* sshd[9185]: debug1: do_pam_account: called
Jul 18 01:07:01 *hoszt* sshd[9185]: Accepted publickey for *user* from ***.***.***.*** port 40884 ssh2
Jul 18 01:07:01 *hoszt* sshd[9185]: debug1: monitor_child_preauth: *user* has been authenticated by privileged process
Jul 18 01:07:01 *hoszt* sshd[9185]: debug1: PAM: establishing credentials
Jul 18 01:07:01 *hoszt* sshd[9185]: pam_unix(sshd:session): session opened for user *user* by (uid=0)
Jul 18 01:07:01 *hoszt* sshd[9185]: User child is on pid 9198
Jul 18 01:07:01 *hoszt* sshd[9198]: debug1: SELinux support disabled
Jul 18 01:07:01 *hoszt* sshd[9198]: debug1: PAM: establishing credentials
Jul 18 01:07:01 *hoszt* sshd[9198]: debug1: permanently_set_uid: 1000/1000
Jul 18 01:07:01 *hoszt* sshd[9198]: debug1: Entering interactive session for SSH2.
Jul 18 01:07:01 *hoszt* sshd[9198]: debug1: server_init_dispatch_20
Jul 18 01:07:01 *hoszt* sshd[9198]: debug1: server_input_channel_open: ctype session rchan 0 win 2097152 max 32768
Jul 18 01:07:01 *hoszt* sshd[9198]: debug1: input_session_request
Jul 18 01:07:01 *hoszt* sshd[9198]: debug1: channel 0: new [server-session]
Jul 18 01:07:01 *hoszt* sshd[9198]: debug1: session_new: session 0
Jul 18 01:07:01 *hoszt* sshd[9198]: debug1: session_open: channel 0
Jul 18 01:07:01 *hoszt* sshd[9198]: debug1: session_open: session 0: link with channel 0
Jul 18 01:07:01 *hoszt* sshd[9198]: debug1: server_input_channel_open: confirm session
Jul 18 01:07:01 *hoszt* sshd[9198]: debug1: server_input_global_request: rtype no-more-sessions@openssh.com want_reply 0
Jul 18 01:07:01 *hoszt* sshd[9198]: debug1: server_input_channel_req: channel 0 request exec reply 1
Jul 18 01:07:01 *hoszt* sshd[9198]: debug1: session_by_channel: session 0 channel 0
Jul 18 01:07:01 *hoszt* sshd[9198]: debug1: session_input_channel_req: session 0 req exec
- A hozzászóláshoz be kell jelentkezni
Nagyon úgy tűnik a logokból, hogy az autentikáció sikeres.
Érdemes lenne megnézni, hogy ugyanez hogyan néz ki, amikor sikeres a másolás és összehasonlítani a kettőt.
Érdemes még az scp-nek is egy pár darab '-v' -t átadni, hogy lásd kliensoldalon pontosan mi a panasza az scp-nek.
Nincs véletlen a kettő között valami IPS vagy IDS vagy valami hasonló? Azok tudnak még érdekes dolgokat művelni. Olyasmit tüneteket is produkálhatnak akár, amik nem állandóak. Volt már olyannal dolgom (SSL kapcsolatnál), hogy az IDS valami TCP szintű támadást észlelt és össze-vissza eldobált csomagokat.
Magánál a másoló scriptnél egy 'set -x' -et is érdemes betenni és beleirányítani a fájl stderr -jét meg stdout -ját egy logba és nézegetni pontosan mi is történik ott.
- A hozzászóláshoz be kell jelentkezni
Na az nem hülyeség, hogy a tűzfal gépen szétnézzek. Holnap belei kukkantok.
* html {display: none}
- A hozzászóláshoz be kell jelentkezni
scp helyett rsync+ssh.
- A hozzászóláshoz be kell jelentkezni