FastNetMon

Показаны сообщения с ярлыком SSH. Показать все сообщения
Показаны сообщения с ярлыком SSH. Показать все сообщения

среда, 7 апреля 2010 г.

Бэкап MySQL баз по SSH


mkdir /home/back
/usr/bin/mysqldump -u имя -pпароль -f --all-databases | gzip -c > /home/back/allbases`date "+%Y-%m-%d"`.sql.gz


scp -r /home/back user@ip:/root/back

Не выйдет с scp, смотрите команду sftp

http://forum.searchengines.ru/showpost.php?p=6680551&postcount=385

четверг, 18 марта 2010 г.

Выполнение команд на удаленном сервере по SSH2 из Python /Paramiko

Ставим библиотеку Paramiko:
apt-get install -y python-paramiko



#!/usr/bin/python
# -*- coding: utf-8 -*-

import paramiko
import sys

ssh = paramiko.SSHClient()
ssh.set_missing_host_key_policy( paramiko.AutoAddPolicy() )

try:
ssh_connection = ssh.connect('domain.ru', username='xxxx', password='yyyyy')
except paramiko.AuthenticationException:
print "Auth failed"
ssh.close()
sys.exit(0)

( stdin, stdout, stderr ) = ssh.exec_command('cat /proc/mdstat')

for line in stdout.read().splitlines():
print line


ssh.close()



Вот пример запуска команды:

./ssh_command.py
Personalities : [raid1] [raid10] [raid0] [raid6] [raid5] [raid4]
md0 : active raid1 sdb1[1] sda1[0]
4200896 blocks [2/2] [UU]

md1 : active raid1 sdb2[1] sda2[0]
2104448 blocks [2/2] [UU]

md2 : active raid1 sdb3[1] sda3[0]
1458830400 blocks [2/2] [UU]

unused devices:



по материалам: http://jessenoller.com/2009/02/05/ssh-programming-with-paramiko-completely-different/

среда, 24 февраля 2010 г.

Debian: отучить SSH слушать ipv6 интерфейс

Стандартно SSHD на Debian слушает на ipv6 интерфейсе, что далеко не всем нужно:

netstat -lnpt | grep ssh
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 6555/sshd
tcp6 0 0 :::22 :::* LISTEN 6555/sshd


Открываем конфиг:
vi /etc/ssh/sshd_config


Добавляем около закомментированного ListenAddress:
AddressFamily inet


Перезапускаем SSH:
/etc/init.d/ssh restart


Убеждаемся, что слушается только ipv4:
netstat -lnpt | grep ssh
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 7675/sshd


Источник: http://ubuntu-tutorials.com/2008/01/12/disabling-ssh-connections-on-ipv6/

воскресенье, 14 февраля 2010 г.

Запуск SSHD в chroot на Debian 5 Lenny: подготовка дерева каталогов

ЭТО НЕ CHROOTED SSH в папку пользователя!!! Это запуск демона в CHROOT!!!! В 95% случаев ЭТА СТАТЬЯ ВАМ НЕ НУЖНА.

Мы будем использовать makejail, но есть еще ряд аналогов: jailer и jailtool.

Ставим тулзу для сборки chroot среды:
apt-get install -y makejail


В его стандартной поставке есть ряд шаблонов для запуска различных сервисов в chroot:

ls /usr/share/doc/makejail/examples
apache.py global.OpenBSD mysqld.py postgresql.py
bind.py mldonkey.py ntpd.py sshd.py


Теперь создаем папку, куда будет "сложен" комплект файлов для успешного чрута sshd:
mkdir -p /var/chroot/sshd


Но при попытке запуска:
makejail /usr/share/doc/makejail/examples/sshd.py


Нас постигает полный облом:

Loading configuration file /usr/share/doc/makejail/examples/sshd.py
Cannot load configuration file '/usr/share/doc/makejail/examples/sshd.py' as a python module
Executing it with python which should display a syntax error:
File "/usr/share/doc/makejail/examples/sshd.py", line 3
SyntaxError: Non-ASCII character '\xf1' in file /usr/share/doc/makejail/examples/sshd.py on line 3, but no encoding declared; see http://www.python.org/peps/pep-0263.html for details


К счастью, это крайне легко фиксица добавлением в файл:
vi /usr/share/doc/makejail/examples/sshd.py


Следующих строк в самое начало:
# -*- coding: utf-8 -*-


Также добавляем в низ файла подключение стандартных утилит работы с файлами - ls, dir, ln, chown и проч ( в примере конфига опечатка, fileutils теперь зовут coreutils):
packages=["coreutils"]


И повторяем запуск команды.

После того, как программа отработает в нашей chroot папке будет построено дерево каталогов, необходимое sshd для работы:

ls /var/chroot/sshd/
bin dev etc lib lib64 sbin usr var


Причем, занимаемое им пространство крайне скромно:

du -sh /var/chroot/sshd/
16M /var/chroot/sshd/


Теперь пробуем сделать chroot на созданную папку:
chroot /var/chroot/sshd/



Основано на: http://www.debian.org/doc/manuals/securing-debian-howto/ap-chroot-ssh-env.en.html и http://stephan.paukner.cc/syslog/archives/332-SSH-daemon-in-a-chroot-on-Debian-lenny.html

четверг, 7 января 2010 г.

Защита от перебора паролей SSH посредством iptables

Модуль recent дает очень удобный способ защитить sshd от перебора ботами, вот отличная статья по его настройке: http://www.debian-administration.org/articles/187

Для тех, кто не ходит по ссылкам вот пример:

iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --name ssh_secure --set
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --name ssh_secure --update --seconds 60 --hitcount 4 -j DROP


Первое правило добавляет IP нового клиента в таблицу recent. Второе правило проверяет наличие IP в таблице recent, и в случае, если от указанного клиента было более 3 попыток соединения за последние 60 секунд отклонит его последующие попытки.

среда, 23 декабря 2009 г.

Переключение ssh в CentOS на альтернативный порт

Последней стадией стало вот такое наблюдение в логах за последние три дня:

cat /var/log/secure|grep fail|wc -l
54887


Как видите, перебор очень суровый. Задолбало однако :) Есть, конечно, всякие fail2ban, но я уверен, что почти все попытки подобрать прекратятся после переноса ssh эдак на 2000й порт :)

Итак, открываем конфиг:
vi /etc/ssh/sshd_config


Корректируем там следующим образом:
Port 2000


Перезапускаем:

/etc/init.d/sshd restart


Ну вот и все:

netstat -lnpt | grep ssh
tcp 0 0 :::2000 :::* LISTEN 6981/sshd


Теперь при подключении к серверу правда придется явно указывать порт ключом -p, но зато безопасность будет на уровне и никто не будет дергать винт тупыми попытками перебора.

четверг, 17 декабря 2009 г.

Переключение ssh на авторизацию по ключам

1. Создаем для своего аккаунта публичный (уйдет на удаленный сервер) и приватный (останется у нас) сертификаты:

ssh-keygen -t rsa


Стандартно он будет сохранен по пути: /home/<имя_вашего_юзера>/.ssh/id_rsa), при этом строго обязательно указываем passphrase (пароль, который будет спрашиваться при доступе к ключу).

Если же хотите сгенерировать ключи из скрипта, чтобы он не задавал лишних вопросов, используйте такой вызов:

ssh-keygen -t rsa -q -f /root/.ssh/id_rsa -P ""


2. Теперь надо свой ключ разложить по серверам:
ssh-copy-id -i ~/.ssh/id_rsa.pub my_login_on_target_system@target-hostname.ru


или более кратко в случае, если файл лежит по стандартному пути:

ssh-copy-id target-hostname.ru


3. При этом (т.е. при закладывании ключей на удаленную систему) будет запрошен ваш пароль на сервер, но сделано это будет в крайний раз, потом вход на сервер будет осуществляться исключительно по ключам

4. Все, можете входить на удаленную систему по ключам:
ssh target-hostname.ru uname -r

среда, 16 декабря 2009 г.

iptables: разрешить SSH на сервере

iptables -P INPUT DROP # блокируем все соединения, кроме явно разрешенных
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j ACCEPT # разрешаем соединение с ssh портом
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT # разрешаем все установленные и связанные соединения


Итого:

iptables -vL
Chain INPUT (policy DROP 94 packets, 7040 bytes)
pkts bytes target prot opt in out source destination
5 320 ACCEPT tcp -- any any anywhere anywhere tcp dpt:ssh state NEW
88 10745 ACCEPT all -- any any anywhere anywhere state RELATED,ESTABLISHED

Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

Chain OUTPUT (policy ACCEPT 143 packets, 16395 bytes)
pkts bytes target prot opt in out source destination

вторник, 8 декабря 2009 г.

Как избавиться от Are you sure you want to continue connecting (yes/no) ?

При подключении к новому незнакомому SSH узлу выдается сообщение:

ssh linux.org.ru
The authenticity of host 'linux.org.ru (217.76.32.61)' can't be established.
RSA key fingerprint is f4:3c:84:2d:5a:40:d3:d2:9d:67:c4:3d:1a:8f:70:c1.
Are you sure you want to continue connecting (yes/no)?



Когда за день подключаешься к десяткам машин это начинает немного надоедать.

Открываем конфиг SSH (у меня пути для Mac, для других ос они немного отличаются, так что смотрите сами):

sudo vi /etc/ssh_config


И добавляем туда:

StrictHostKeyChecking no


После этого запрос примет вид молчаливого согласия:

ssh linux.org.ru
Warning: Permanently added 'linux.org.ru,217.76.32.61' (RSA) to the list of known hosts.
nrg@linux.org.ru's password:


За решение большое спасибо отличном блогу: http://www.vdomck.org/2009/10/someone-is-doing-something-nasty.html Кстати, в нем же Вы найдете способ, как отучить SSH вопить при смене ключа узла.

понедельник, 27 апреля 2009 г.

понедельник, 16 марта 2009 г.

Причина не запрещать root`у логиница по SSH

Сам всегда работаю под обычным юзером и исполняю команды через sudo, но вот сегодня после долгого редактирования /etc/sudoers я получил вот такое чудо:

sudo vim /etc/sudoers
>>> sudoers file: syntax error, line 85 <<< sudo: parse error in /etc/sudoers near line 85



Как же мне повезло, что логин рута по SSH не был залочен (требование определенной проги, сам бы я залочил). Так что безопасность, безопасностью, а паранойя паранойей, теперь НИКОГДА не буду запрещать логин рута по SSH, буду лишь ставить НУ ОЧЕНЬ длинные пароли. Как раз вот для таких случаев.