SCP & Public Key néha nem megy

UNIX haladó

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

  • 4221 megtekintés

( calamari | 2011. 07. 16., szo – 11:51 )

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.

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}

Esetleg eltérő környezeti változó beállítások a direkt root login
és a cron-os futtatás esetében? Lásd a manuál vonatkozó része:

ENVIRONMENT
ssh will normally set the following environment variables:

DISPLAY The DISPLAY variable indicates the location of the X11 server. It is auto‐
matically set by ssh to point to a value of the form “hostname:n”, where
“hostname” indicates the host where the shell runs, and ‘n’ is an integer ≥
1. ssh uses this special value to forward X11 connections over the secure
channel. The user should normally not set DISPLAY explicitly, as that will
render the X11 connection insecure (and will require the user to manually
copy any required authorization cookies).

HOME Set to the path of the user's home directory.

LOGNAME Synonym for USER; set for compatibility with systems that use this variable.

MAIL Set to the path of the user's mailbox.

PATH Set to the default PATH, as specified when compiling ssh.

SSH_ASKPASS If ssh needs a passphrase, it will read the passphrase from the current ter‐
minal if it was run from a terminal. If ssh does not have a terminal associ‐
ated with it but DISPLAY and SSH_ASKPASS are set, it will execute the program
specified by SSH_ASKPASS and open an X11 window to read the passphrase. This
is particularly useful when calling ssh from a .xsession or related script.
(Note that on some machines it may be necessary to redirect the input from
/dev/null to make this work.)

SSH_AUTH_SOCK Identifies the path of a UNIX-domain socket used to communicate with the
agent.

SSH_CONNECTION Identifies the client and server ends of the connection. The variable con‐
tains four space-separated values: client IP address, client port number,
server IP address, and server port number.

SSH_ORIGINAL_COMMAND This variable contains the original command line if a forced command is exe‐
cuted. It can be used to extract the original arguments.

SSH_TTY This is set to the name of the tty (path to the device) associated with the
current shell or command. If the current session has no tty, this variable
is not set.

TZ This variable is set to indicate the present time zone if it was set when the
daemon was started (i.e. the daemon passes the value on to new connections).

USER Set to the name of the user logging in.

Additionally, ssh reads ~/.ssh/environment, and adds lines of the format “VARNAME=value” to the
environment if the file exists and users are allowed to change their environment. For more infor‐
mation, see the PermitUserEnvironment option in sshd_config(5).

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

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.