Strona 1 z 1

Na jednym serwerze nie działają skrypty przez ssh

: 29 czerwca 2010, 11:45
autor: garnus
Witam.
Nie wiem, czy dobrze zidentyfikowałem problem ale sprawa ma się tak:
Mam z 20 serwerów z Debianem 5.0. Na wszystkich takie same konfigi sshd i ssh. Uruchamiam z jednego z nich w cronie skrypty przez ssh wykonujące się na każdym z 20 serwerów. Coś tam robią i trwa to ogólnie na każdym ~6minut. Skrypt wywołujący czeka na odpowiedź zwrotną. 19 serwerów jest w porządku, a na jednym wykonuje się i nic nie zwraca, wisi i w końcu się wyłącza. Podejrzewam jakiś ,,timeout'' ale w sshd_config nic takiego nie ma no i czemu działa na pozostałych. Gdzie jeszcze mogę szukać?

sshd_config

Kod: Zaznacz cały

Port 22
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes

# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 768

# Logging
SyslogFacility AUTH
LogLevel INFO

# Authentication:
LoginGraceTime 120
PermitRootLogin no
StrictModes yes

RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile	%h/.ssh/authorized_keys

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

# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no

# Change to no to disable tunnelled clear text passwords
#PasswordAuthentication yes

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

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
#UseLogin no

#MaxStartups 10:30:60
#Banner /etc/issue.net

# Allow client to pass locale environment variables
AcceptEnv LANG LC_*

Subsystem sftp /usr/lib/openssh/sftp-server

UsePAM yes
ssh_config

Kod: Zaznacz cały

Host *
#   ForwardAgent no
#   ForwardX11 no
#   ForwardX11Trusted yes
#   RhostsRSAAuthentication no
#   RSAAuthentication yes
#   PasswordAuthentication yes
#   HostbasedAuthentication no
#   GSSAPIAuthentication no
#   GSSAPIDelegateCredentials no
#   GSSAPIKeyExchange no
#   GSSAPITrustDNS 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,umac-64@openssh.com,hmac-ripemd160
#   EscapeChar ~
#   Tunnel no
#   TunnelDevice any:any
#   PermitLocalCommand no
    SendEnv LANG LC_*
    HashKnownHosts yes
    GSSAPIAuthentication yes
    GSSAPIDelegateCredentials no

: 29 czerwca 2010, 16:00
autor: adasiek_j
A uruchomione z ręki to coś na owym serwerze co zwraca? Może jakiś komunikat?

Adam

: 30 czerwca 2010, 09:43
autor: Bastian
Popatrz w logi na tamtym serwerze, mogą pomóc.

: 01 lipca 2010, 09:57
autor: garnus
Skrypt uruchomiony na serwerze z ręki działa bez problemu.
Co do logów, to nic nie ma ciekawego.
Szukam jakiś ,,timeout'', które mogą zrywać połączenie ssh i to raczej jakiś w systemie niż w ssh.

: 01 lipca 2010, 13:21
autor: Bastian
Rozumiem, że patrzysz w te logi na serwerze gdzie jest odpalany skrypt ?

Pokaż wynik:

Kod: Zaznacz cały

cat /etc/crontab
oraz na serwerze na którym mają się wykonywać te skrypty:

Kod: Zaznacz cały

cat /etc/syslog.conf