Rsync + Ssh + Klucze Nie Działa Z Pod Crona

kain468 · Lipiec 17, 2009

Witam wszystkich Panów i Panie którzy zechcą pomóc w problemie.

Mój problem tkwi w synchronizacji 2 stacji w tej samej sieci. Używam rsync łącznie z ssh i kluczami a do tego wszystkiego mam napisany pliczek xxx.sh i z crona próbuje go wywołać.

Niestety ku mojemu zdziwieniu pliczek działa jak go ręcznie wywołuje ale z crona w żaden sposób. Sam rsync działa klucze działają ssh działa zapora też ponieważ ręcznie działa.

Jak wywołam skrypt z lini komend to też działa. :?: próbowałem i na root i na innym użytkowniku identyczna sytuacja. 2 tygodnie walki i nic. Na redhat 5.3 też tak samo fedorka też się położyła.

borzole · Lipiec 17, 2009

bo cron będzie to robił jako root, czyli potrzebne są kluczyki ssh dla konta roota, a nie usera

kain468 · Lipiec 17, 2009

bo cron będzie to robił jako root, czyli potrzebne są kluczyki ssh dla konta roota, a nie usera

Z tego co wiem składnia crona jest taka

***** "użytkownik" "polecenie"

więc wydaje mi się że użytkownik znaczy tyle co wywołanie polecenia jako ten użytkownik.

Ale dziękuje za uwagę sprawdzę czy jak zrobię wszystko na root to zadziała jeśli tak to kolega ma piwko na wskazany adresik byle nie w Najrobi

kain468 · Lipiec 18, 2009

OK, sprawdziłem kilka możliwości, co prawda Twój post nie dał rozwiązania ale wiem na pewno, że wina stoi po stronie ssh agent, nie przekazuje on hasła dla klucza ssh. Sprawdziłem certyfikat na roocie, bez hasła synchronizacja działa, uruchamiam ssh agent funkcją eval $(ssh-agent). Po czym używam polecenia ssh add, które nast epnie prosi mnie o hasło. Jeśli coś robię źle, proszę odpiszcie. Wszystkie sugestie mile widziane.

borzole · Lipiec 18, 2009

1. może nie widzi ścieżek (np. tu masz o co mi chodzi z PATH itd)

2. "użytkownika" się dodaje jeśli wpisy są w /etc/... a jeśli dodane poleceniem crontab -e to już nie

3. przekieruj wyjście błędu do logu

1 * * * * skrypt.sh 2> /var/log/ale_o_co_chodzi.log

kain468 · Lipiec 20, 2009

1. może nie widzi ścieżek (np. tu masz o co mi chodzi z PATH itd)
2. "użytkownika" się dodaje jeśli wpisy są w /etc/... a jeśli dodane poleceniem crontab -e to już nie

3. przekieruj wyjście błędu do logu
1 * * * * skrypt.sh 2> /var/log/ale_o_co_chodzi.log

Ok zrobiłem testy poniżej wynik

Permission denied, please try again.

Permission denied (publickey,gssapi-with-mic,password).

rsync: connection unexpectedly closed (0 bytes received so far) [receiver]

rsync error: error in rsync protocol data stream (code 12) at io.c(600) [receiver=3.0.5]

coś podobnego widziałem wtedy jak pomyliłem się kiedyś i uruchomiłem agenta z roota a próbowałem się logować z innego usera.

borzole · Lipiec 20, 2009

Czyli generalnie chodzi o kluczyki, poeksperymentuj jeszcze z tym.

Te kluczyki to generowałeś nowe dla root czy skopiowałeś z usera do roota (tak chyba nie można)? Kiedyś mi odrzucił kluczyki, bo przypadkiem przestawiłem prawa dostępu do ~/.ssh i musiałem generować drugie (gdzieś w systemie zapisała się informacja, że te są już "spalone").

kain468 · Lipiec 20, 2009

Czyli generalnie chodzi o kluczyki, poeksperymentuj jeszcze z tym.
Te kluczyki to generowałeś nowe dla root czy skopiowałeś z usera do roota (tak chyba nie można)? Kiedyś mi odrzucił kluczyki, bo przypadkiem przestawiłem prawa dostępu do ~/.ssh i musiałem generować drugie (gdzieś w systemie zapisała się informacja, że te są już "spalone").

1. kluczyki są nowe generowane na root

2. skopiowane ssh-copy-id -i /root/.ssh/id_dsa.pub 192.168.0.10

3. bez hasła działa na haśle nie.

ale kiedyś miałem taki trzask, że jeśli generowałem klucze według standardowego polecenia bez podania długości klucza to ssh wcale tego nie przyjmował.

teraz generuje je tak ssh-keygen -t dsa -b 1024 zastanawiam się czy nie ma to coś wspólnego z protokołem ponieważ wtedy miało była zła długość klucza i dlatego nie działało

kain468 · Lipiec 20, 2009

I tym samym sprawa jasna hasło jest nie podawane

w logach zdalnego servera /var/log/secure wpisy bład hasła ssh

Panowie i Panie proszę o sugestie. Normalnie się zagotowałem :lammer:

borzole · Lipiec 20, 2009

zawsze możesz na chama wpisywać hasło z pliku do skryptu tak.

$(cat plik_z_hasłem.txt)

kain468 · Lipiec 21, 2009

zawsze możesz na chama wpisywać hasło z pliku do skryptu tak.
$(cat plik_z_hasłem.txt)

Wiesz wolał bym nie stosować takich rozwiązań skoro są do tego celu zrobione aplikacje i mają to robić. Zresztą i tak po wywołaniu tego z pliku dostaje błąd że nie ma takiego polecenia. Naprawdę wygląda to tak jak gdyby crontab nie mógł odczytać hasła.

borzole · Lipiec 21, 2009

Wiesz wolał bym nie stosować takich rozwiązań skoro są do tego celu zrobione aplikacje i mają to robić.

kluczyki to przecież pliki z hasłem, leżą w ~/.ssh i nic poza prawami dostępu ich nie strzerze

Zresztą i tak po wywołaniu tego z pliku dostaje błąd że nie ma takiego polecenia.

to coś źle robisz, używaj tego jak parametru i podaj pełną ścieżkę o tak np.:

echo $(/bin/cat ~/.bashrc)

kain468 · Lipiec 21, 2009

Poniżej podaje kilka wpisów w moich plikach.

crontab -e

------------

SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root@fedorka
NICE=15
*/1 * * * * /root/sshtes.sh 2> /var/log/wynik_skrypt.log

skrypt.sh

------------

#!/bin/bash
rsync -av --delete [email protected]:/root/tes /root/tes

ssh_config(stacja prubująca się łączyć)

--------------

# Host *
#   ForwardAgent no
#   ForwardX11 no
#   RhostsRSAAuthentication no
#   RSAAuthentication yes
#   PasswordAuthentication yes
#   HostbasedAuthentication no
#   GSSAPIAuthentication no
#   GSSAPIDelegateCredentials no
#   BatchMode no
#   CheckHostIP yes
#   AddressFamily any
#   ConnectTimeout 0
#   StrictHostKeyChecking ask
#   IdentityFile ~/.ssh/identity
#   IdentityFile ~/.ssh/id_rsa
#   IdentityFile ~/.ssh/id_dsa
#   Port 22
#   Protocol 2,1
#   Cipher 3des
#   Ciphers aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc
#   MACs hmac-md5,hmac-sha1,[email protected],hmac-ripemd160
#   EscapeChar ~
#   Tunnel no
#   TunnelDevice any:any
#   PermitLocalCommand no
Host *
GSSAPIAuthentication yes
# If this option is set to yes then remote X11 clients will have full access
# to the original X11 display. As virtually no X11 client supports the untrusted
# mode correctly we set this to yes.
ForwardX11Trusted yes
# Send locale-related environment variables
SendEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES 
SendEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT 
SendEnv LC_IDENTIFICATION LC_ALL LANGUAGE

sshd_config(stacji zdalnej)

---------------

#Port 22
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

# Disable legacy (protocol version 1) support in the server for new
# installations. In future the default will change to require explicit
# activation of protocol 1
Protocol 2

# HostKey for protocol version 1
#HostKey /etc/ssh/ssh_host_key
# HostKeys for protocol version 2
#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_dsa_key

# Lifetime and size of ephemeral version 1 server key
#KeyRegenerationInterval 1h
#ServerKeyBits 1024

# Logging
# obsoletes QuietMode and FascistLogging
#SyslogFacility AUTH
SyslogFacility AUTHPRIV
LogLevel INFO
#LogLevel DEBUG

# Authentication:

#LoginGraceTime 2m
#PermitRootLogin yes
StrictModes yes
#MaxAuthTries 6
#MaxSessions 10

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile      /root/.ssh/authorized_keys

# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#RhostsRSAAuthentication no
# similar for protocol version 2
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# RhostsRSAAuthentication and HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes

# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication no
#PermitEmptyPasswords no
#PasswordAuthentication yes

# Change to no to disable s/key passwords
ChallengeResponseAuthentication yes
#ChallengeResponseAuthentication no

# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no

# GSSAPI options
GSSAPIAuthentication no
#GSSAPIAuthentication yes
#GSSAPICleanupCredentials yes
GSSAPICleanupCredentials yes
# Set this to 'yes' to enable PAM authentication, account processing, 
# and session processing. If this is enabled, PAM authentication will 
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
#UsePAM no
UsePAM yes

# Accept locale-related environment variables
AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
AcceptEnv LC_IDENTIFICATION LC_ALL LANGUAGE

#AllowAgentForwarding yes
#AllowTcpForwarding yes
#GatewayPorts no
#X11Forwarding no
X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes
#PrintMotd yes
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no
#UsePrivilegeSeparation yes
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#ShowPatchLevel no
#UseDNS yes
#PidFile /var/run/sshd.pid
#MaxStartups 10
#PermitTunnel no
#ChrootDirectory none

# no default banner path
#Banner none

# override default of no subsystems
Subsystem       sftp    /usr/libexec/openssh/sftp-server

# Example of overriding settings on a per-user basis
#Match User anoncvs
#       X11Forwarding no
#       AllowTcpForwarding no
#       ForceCommand cvs server

---------log crontab stacji lokalnej-----------

Jul 18 14:49:01 fedorka CROND[19578]: (root) CMD (/root/sshtes.sh 2> /var/log/wynik_skrypt.log)
Jul 18 14:50:01 fedorka CROND[19595]: (root) CMD (/root/sshtes.sh 2> /var/log/wynik_skrypt.log)
Jul 18 14:51:01 fedorka CROND[19611]: (root) CMD (/root/sshtes.sh 2> /var/log/wynik_skrypt.log)

-----------------logi stacji zdalnej(secure)--------------------

Jul 18 08:39:07 localhost unix_chkpwd[24360]: password check failed for user (root)
Jul 18 08:39:07 localhost sshd[24359]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.0.11  user=root
Jul 18 08:39:10 localhost sshd[24352]: error: PAM: Authentication failure for root from 192.168.0.11

------------------------klucz publiczny------------------------

ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAmGMbuJOSadhhThBAJM/rzJMdoDqK+MWuWQYEHhA9EUXTomSK/FrmGRFMQSLcfiKWz3fIdGUkuDbkPFyG04aJx1R/n5aR+MZLCRaXaGtHyY+aXxyg5En/ANCy12HkKut+lLexG9WZRjQXDvPWlFBEY765A8Mse6Lm2GpaA1dyQr1kJeZ2Bj14z6zvcorHsmBZOM6n
vEFJoiJwYoe++TF10lhuIGba+WiH98QcaMHp3vATa7QZB7Mk1UMJYbAoGlX8OJ4UJXTalsylWHuHVvgn/tBgo4WVmPIKeJhBUiHAk7+DzxwI5KwoMrFvtdZ2YyL+TbeDPw8EGiBfK0FTBk0WzQ== root@fedorka

---------------------klucz prywatny---------------------------

----------------------plik kontrolny skryptu--------------------------------

Permission denied, please try again.

Permission denied, please try again.

Permission denied (publickey,gssapi-with-mic,password).

rsync: connection unexpectedly closed (0 bytes received so far) [receiver]
rsync error: error in rsync protocol data stream (code 12) at io.c(600) [receiver=3.0.5]

Edytowane Lipiec 22, 2009 przez WalDo
znaczniki. Na ortografię nie mam siły :\

kain468 · Lipiec 22, 2009

Witam ponownie.

Poprawiłem wywołanie pliku ze skryptu. Faktycznie wywołanie powinno zawierać całą ścieżkę /bin/cat. Jednak nie zmienia to faktu że skrypt wywoływany spod palca nie działa z hasłem z pliku ponieważ zatrzymuje się w momencie podawania hasła do certyfikatu, a następnie po podaniu hasła wyświetla plik z hasłem.

Hej ludziska bardzo proszę o dołączenie się do tematu. Męczę go już trzy tygodnie i jakoś nie chce mi się wierzyć że wszystkim to śmiga, a wiem że stosuje się to rozwiązanie często i nie tylko mi się to przyda.

pozdrawiam

ps. dzięki Borzole!

@WalDo · Lipiec 22, 2009

Nie dość, że się drzesz, to jeszcze z błędami koszmarnymi <_<

A listingi to ujmujemy w odpowiednie tagi. Poczytaj sobie → http://forum.fedora.pl/index.php?s=&ac...amp;CODE=bbcode

Rsync + Ssh + Klucze Nie Działa Z Pod Crona

Rekomendowane odpowiedzi

Odnośnik do komentarza

Udostępnij na innych stronach

Odnośnik do komentarza

Udostępnij na innych stronach

Odnośnik do komentarza

Udostępnij na innych stronach

Odnośnik do komentarza

Udostępnij na innych stronach

Odnośnik do komentarza

Udostępnij na innych stronach

Odnośnik do komentarza

Udostępnij na innych stronach

Odnośnik do komentarza

Udostępnij na innych stronach

Odnośnik do komentarza

Udostępnij na innych stronach

Odnośnik do komentarza

Udostępnij na innych stronach

Odnośnik do komentarza

Udostępnij na innych stronach

Odnośnik do komentarza

Udostępnij na innych stronach

Odnośnik do komentarza

Udostępnij na innych stronach

Odnośnik do komentarza

Udostępnij na innych stronach

Odnośnik do komentarza

Udostępnij na innych stronach

Odnośnik do komentarza

Udostępnij na innych stronach

Jeśli chcesz dodać odpowiedź, zaloguj się lub zarejestruj nowe konto

Zarejestruj nowe konto

Zaloguj się