Один знакомый патриот подарил наклейку. Я шокирован.
Как чинить проблемы SSHD
Если ваша Путти внезапнно вместо логина на сервер по паре ключей пишет в консоли:
Using username "root".
Server refused our key
root@8.8.8.8's password:
А в логе путти вы видите:
2014-12-10 12:17:15 Offered public key
2014-12-10 12:17:15 Server refused our key
2014-12-10 12:17:15 Using SSPI from SECUR32.DLL
2014-12-10 12:17:15 Attempting GSSAPI authentication
2014-12-10 12:17:16 GSSAPI authentication request refused
Это значит, что: караул, меня взломали, я разорен или что настала пора что-то полечить.
1. если вы раньше отключали ведение логов для экономии ресурсов, то нужно убедиться в том, что сейчас работает демон rsyslogd, без него не пишется /var/log/secure и следовательно не работает fail2ban между прочим
# ps axfu
где-то есть такое /sbin/rsyslogd -i /var/run/syslogd.pid -c 5
service rsyslog start
chkconfig rsyslog on
2. включить дебаг лога SSHD
\etc\ssh\sshd_config
разремить или добавить
LogLevel DEBUG3
в районе
#LogLevel INFO
3. За одно проверить
#AuthorizedKeysFile .ssh/authorized_keys
обратите внимание, что путь будет строиться от домашнего каталога юзера! Вам тут исправлять вот так
AuthorizedKeysFile /root/.ssh_t/authorized_keys
не нужно!
4. читать логи, если там есть
key_type_from_name: unknown key type 'ssh-dsa'
key_read: missing keytype
то внимательно проверить файл с публичным ключем, в моем случае было ssh-dsa.... вместо ssh-dss....
а если бы я выбрал ключик попроще RSA, то такой проблемы не было бы :)
желательно в конце ключа через пробел после == дописать что-то типа john@example.net
5. Вывод - выбирайте тип RSA и генерируйте ключи на сервере, потому что при переносе ключа из Putty в \root\.ssh\authorized_keys больше шансов ошибиться, чем при скачивании приватного ключа с сервера на локальный комп.
5. Инструкция
Создаем папку
$ mkdir ~/.ssh
$ chmod 700 ~/.ssh
Генерируем ключи
$ ssh-keygen -t rsa
и три раза Энтер
Создаст
~/.ssh/id_rsa приватный ключ
~/.ssh/id_rsa.pub публичный ключ
$ cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
$ chmod 600 ~/.ssh/authorized_keys
Теперь нужно стащить ~/.ssh/id_rsa (приватный ключ) в программу puttygen.exe и сохранить в формате Путти. Потом подключить к Путти...
Проверим права и владельцев по всему пути
namei -om /root/.ssh
SSHD строго следит за минимально необходимыми правами. Ставить везде 777 и 666 нельзя.
Если это ВДС под OpenVZ, то потребуется восстановить владельца:
restorecon -Rv /root/.ssh
Припрячем ключ на будущее
$ chmod 600 ~/.ssh/id_rsa
Или уберем за собой, смотря кому как нужно
rm ~/.ssh/id_rsa
rm ~/.ssh/id_rsa.pub
Полезное чтиво http://wiki.centos.org/HowTos/Network/SecuringSSH
Прочитать полностью...
Для борьбы с крякозаблами вместо псевдографики в mc обычно делают так
/etc/sysconfig/i18n
LANG="en_US.UTF-8" --> LANG="ru_RU.koi8r"
ИЛИ
LANG="en_US.UTF-8" --> LANG="ru_RU.UTF-8"
но тогда гадостным обазом половина сообщений операционной системы Centos становятся на русском языке, что сильно затрудняет обращение в нерусский саппорт :)
Оказалось, что эту псевдографику в mc можно победить одной командой:
unicode_start
И никакого русского языка :)
Это ещё не всё...
Прочитать полностью...
Арендовал я месяц назад выделенный сервер потому что ВДС мне уже не хватает по производительности. Вроде всё так же, но какие-то гадости вылазят. Напишу их тут, чтобы потом легче искать было.
Гадость 1.
Midnight Commander, он же mc, после запуска и закрытия оставляет сообщение
Cannot open master side of pty: ▒▒ ▒▒▒▒▒▒▒▒▒▒ ▒▒▒▒▒▒▒▒▒ ▒▒▒▒▒ (28)
Решетки это из-за сломавшегося \etc\sysconfig\i18n - это ещё одна гадость от mc
Под решетками имеется в виду так:
Cannot open master side of pty: No space left on device (28)
Решение простое:
#mkdir /dev/pts
#mount /dev/pts
ну и дописать в автозагрузку в /etc/rc.d/rc в самое начало или в /etc/rc.d/rc.local куда угодно
mkdir /dev/pts
mount /dev/pts
----------------------------
другие рецепты не помогали:
«Cannot open master side of pty: No such file or directory (2)
Прежде всего убедитесь, что в /etc/fstab присутствует запись вида:
none /dev/pts devpts mode=0620 0 0
Если нет - добавляем и выполняем под пользователем root:
#mount -a
Если нет идем дальше: Можно запустить strace и посмотреть, что идет не так. Но вероятнее всего ошибка возникает при обращении к /dev/urandom и/или /dev/ptmx.
бла бла бла про OpenVZ.
И это не помогло
Если devpts все же примонтирована, а ошибка сохраняется, возможно отсутствует файл /dev/ptmx
создадим его:
mknod /dev/ptmx c 5 2
chmod 0666 /dev/ptmx
chown root.tty /dev/ptmx
Это ещё не всё...
Прочитать полностью...
До войны я бегал по беговой дорожке и ездил на велотренажере.
Всё это осталось на временно оккупированной территории. А бендеровцы кроме двух рабов ничего не выдают. А покупать чтобы после войны выбросить не логично.
Но мне повезло, я сейчас живу на восьмом этаже. Можно сказать, я всегда об этом мечтал. С каждым днем скорость подъёма вверх увеличиваю, дыхание строго носом. На лифте только с очень тяжелым грузом, типа колес для автомобиля :) Вниз тоже только пешком, с ужасом заметил, что я разучился быстро сбегать по лестнице не держась за перила. Старость :(
Будьте здоровы все, кроме хуйла.
Прочитать полностью...
"На локальном компьютере все работает нормально, а на сервере не работает."
Пост лютой ненависти сука к Микрософт Виндовсу.
Сделал сайт, протестировал на локальном компьютере - всё работает, залил на сервер - не работает кусок яваскриптов. Ну там сепермегакруто и красиво на JQuery.ajax и все дела, кроссбраузерность, адаптивный дизвйн, красота охуительная и для людей и для роботов. Такое дело даже дором не удобно называть, хотя это дор :)
Так вот, на сервере не работает. А я в этих ваших яваскриптах и аяксах джейКваери (так это по-русски читается?) разбираюсь чуть лучше чем нихуя никак. В общем половину дня потратил, инет начал читать, пока не нашел пост такого же оболдуя как и я.
Итого.
Для винды jquery.prettyPhoto.js и jquery.prettyphoto.js одно и то же, а вот для никсов - нихуя. Блядь, я же знал, я помнил, я всегда именовал всё сам нормально, но тут пизженый код и не взлетело - вот и наказание, карма блеать.
Удалить из ридера
никого, а вот добавить свежего надо http://lime.black/ - читайте пока он пишет и не упекли его в пироженницу :)
Прочитать полностью...
Если вдруг на вашем любимом сервере NGINX + PHP-FPM после безобидных на первый взгляд действий перестали открываться все сайты с ошибкой 403 "HTTP/1.1 403 Forbidden", а в логе nginx пишет примерно такое даже при обращении к серверу по IP:
2014/11/15 13:46:58 [error] 25908#0: *27341 open() "/home/pupkin/www/5.6.7.8/index.html" failed (13: Permission denied), client: 1.1.1.1, server: 5.6.7.8, request: "GET /index.html HTTP/1.0", host: "5.6.7.8"
И вы уже проверили владельца папки и права доступа ко всему, что только можно, то пришло время проверить прова на переход по папкам сверху вниз командой namei -om ( owner + mode ), примерно так:
namei -om /home/pupkin/www/5.6.7.8/index.html
получите:
f: /home/pupkin/www/5.6.7.8/index.html
drw-r--r-- root root /
drwxr-xr-x root root home
drwx-----x pupkin users pupkin
drwxr-xr-x pupkin users www
drwxr-xr-x pupkin pupkin 5.6.7.8
-rw-rw-r-- pupkin pupkin index.html
Обратите внимание на первую строку. Если в процессе ваших настроек вы случайно дали команду
chmod 644 /
т.е. хотели какому-то файлу поставить права 644, но путь к файлу куда-то пропал и остался только путь к корню.
Лечится очевидно:
chmod 755 /
или более умно, мне помогло так.
Удалить из ридера
http://dmxo.blogspot.com/ - был блог и пропал автор навсега в 2012 году
Прочитать полностью...
