Каждый месяц застрял ssh (и не только ssh)
Я почти ничего не знаю об этом сервере. Это было настроено до того, как я присоединился к моей компании, и я никогда не использовал до сих пор. Мой коллега сказал мне, что каждый месяц ssh перестает работать. Сервер все еще работает, потому что службы в нем продолжают работать, но ssh. Перезагружаем его с главной панели управления, после перезагрузки ssh возвращается.
Ubuntu Server 12.04.1 LTS.
Если бы вы начали расследовать это, с чего бы вы начали?
РЕДАКТИРОВАТЬ: все, что связано с SSH застрять. Ssh соединение с использованием putty или SecureShell, Sftp [...] просто не отвечает. К сожалению, я новичок в этом сервере, и я точно не знаю, какие другие сервисы зависят от ssh. Что я знаю, так это то, что он просто перестает работать раз в месяц (и я видел это только один раз, около 22 декабря, тогда мой коллега рассказал мне, что эта проблема случается раз в месяц).
OpenSSH_5.9p1 Debian-5ubuntu1, OpenSSL 1.0.1 14 марта 2012 г. (Да, я знаю… обновите это! Я просто лучше не трогать это сейчас, производственная среда).. Мне нужны только советы о том, что проверять первым и последним
Port 22
Protocol 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
UsePrivilegeSeparation yes
KeyRegenerationInterval 3600
ServerKeyBits 768
SyslogFacility AUTH
LogLevel INFO
LoginGraceTime 120
PermitRootLogin yes
StrictModes yes
RSAAuthentication yes
PubkeyAuthentication yes
IgnoreRhosts yes
RhostsRSAAuthentication no
HostbasedAuthentication no
PermitEmptyPasswords no
ChallengeResponseAuthentication no
X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
AcceptEnv LANG LC_*
Subsystem sftp /usr/lib/openssh/sftp-server -f LOCAL5 -l INFO
UsePAM yes
Рутлогин, да я тоже знаю.. но..
РЕДАКТИРОВАТЬ 2 (не ssh на этот раз):
Это случилось снова, но не так, как я ожидал! На этот раз сервер просто завис и не имеет отношения к ssh. Консоль управления увидела, что сервер не отвечает на Ping. Последний журнал, зарегистрированный в системном журнале, ничего не сказал мне в глаза. Я скопировал это в главном вопросе.. Возможно, вы (ребята) видите что-то, чего я не вижу.. Или можете дать мне советы по улучшению системы регистрации, чтобы перехватывать каждый (каждый) [каждый] {каждый} журнал! Я тоже только опытный пользователь, но лучше знаю ОС Windows:/
Jan 10 06:05:01 ns237221 kernel: mdadm: sending ioctl 1261 to a partition!
Jan 10 06:06:01 ns237221 kernel: last message repeated 3 times
Jan 10 06:06:01 ns237221 CRON[11762]: (root) CMD (/usr/local/rtm/bin/rtm 27 > /dev/null 2> /dev/null)
Jan 10 06:06:24 ns237221 kernel: [UFW BLOCK] IN=eth0 OUT= MAC=4c:72:b9:24:c6:b3:e8:ba:70:42:e4:80:08:00 SRC=222.186.34.180 DST=37.59.5.180 LEN=40 TOS=0x00 PREC=0x00 TTL=112 ID=256 PROTO=TCP SPT=21404 DPT=2345 WINDOW=16384 RES=0x00 SYN URGP=0
Jan 10 06:06:36 ns237221 kernel: [UFW BLOCK] IN=eth0 OUT= MAC=4c:72:b9:24:c6:b3:1c:e6:c7:52:af:80:08:00 SRC=81.93.11.86 DST=37.59.5.180 LEN=52 TOS=0x00 PREC=0x00 TTL=52 ID=9496 DF PROTO=TCP SPT=4935 DPT=3389 WINDOW=65535 RES=0x00 SYN URGP=0
Jan 10 06:07:01 ns237221 CRON[11806]: (root) CMD (/usr/local/rtm/bin/rtm 27 > /dev/null 2> /dev/null)
Jan 10 06:08:01 ns237221 CRON[11850]: (root) CMD (/usr/local/rtm/bin/rtm 27 > /dev/null 2> /dev/null)
Jan 10 06:09:01 ns237221 CRON[11897]: (root) CMD ( [ -x /usr/lib/php5/maxlifetime ] && [ -d /var/lib/php5 ] && find /var/lib/php5/ -depth -mindepth 1 -maxdepth 1 -type f -cmin +$(/usr/lib/php5/maxlifetime) ! -execdir fuser -s {} 2>/dev/null \; -delete)
Jan 10 06:09:01 ns237221 CRON[11898]: (root) CMD (/usr/local/rtm/bin/rtm 27 > /dev/null 2> /dev/null)
Jan 10 06:09:39 ns237221 kernel: [UFW BLOCK] IN=eth0 OUT= MAC=4c:72:b9:24:c6:b3:e8:ba:70:42:e4:80:08:00 SRC=107.150.98.130 DST=37.59.5.180 LEN=40 TOS=0x00 PREC=0x00 TTL=243 ID=54321 PROTO=TCP SPT=42075 DPT=84 WINDOW=65535 RES=0x00 SYN URGP=0
Jan 10 07:22:25 ns237221 kernel: imklog 5.8.6, log source = /proc/kmsg started.
Jan 10 07:22:25 ns237221 rsyslogd: [origin software="rsyslogd" swVersion="5.8.6" x-pid="3475" x-info="http://www.rsyslog.com"] start
1 ответ
Я бы начал с этого:
- перед перезагрузкой, если у вас по-прежнему есть доступ к серверу (физическая консоль, com-порт и т. д.): проверьте состояние службы (состояние sshd службы) и посмотрите, прослушивает ли какой-либо процесс ваш порт ssh (netstat -anp)
- проверьте auth.log на наличие необычной активности ssh непосредственно перед сбоем службы
- если проблема возникает в одну и ту же дату каждый месяц, вы можете проверить таблицы cron на предмет того, что запланировано на это время.
Пожалуйста, обратите внимание, что я не опытный системный администратор, я немного опытный пользователь.