FastNetMon
Показаны сообщения с ярлыком SSH. Показать все сообщения
Показаны сообщения с ярлыком SSH. Показать все сообщения
воскресенье, 18 марта 2012 г.
среда, 27 апреля 2011 г.
Как ограничить ssh пользователя, входящего в систему по сертификатам лишь заданным диапазоном IP?
Итак, у нас есть Linux пользователь, который входит в систему по ssh с использованием ключей - парольная аутентификация запрещена. Задача - как ограничить пользователю возможный диапазон IP, с которых он входит в систему.
Вариант 1.
Задать диапазон хостов, с которых может входить юзер можно посредством директивы AlloUsers в /etc/ssh/sshd_config.
Вот цитата из официальной документации (man sshd_config):
Но, очевидно, каждый раз дергать конфиги такого важного демона как ssh для изменения IP крайне неправильно.
Вариант 2.
Использовать поле options в файле authorized_keys: from "ip_addr".
Выглядеть это будет так:
Подробное описание из документации (man 8 sshd):
Вариант 1.
Задать диапазон хостов, с которых может входить юзер можно посредством директивы AlloUsers в /etc/ssh/sshd_config.
Вот цитата из официальной документации (man sshd_config):
AllowUsers This keyword can be followed by a list of user name patterns, separated by spaces. If specified, login is allowed only for user names that match one of the patterns. ‘*’ and ‘?’ can be used as wildcards in the patterns. Only user names are valid; a numerical user ID is not recognized. By default, login is allowed for all users. If the pattern takes the form USER@HOST then USER and HOST are separately checked, restricting logins to particular users from particular hosts.
Но, очевидно, каждый раз дергать конфиги такого важного демона как ssh для изменения IP крайне неправильно.
Вариант 2.
Использовать поле options в файле authorized_keys: from "ip_addr".
Выглядеть это будет так:
from "ip_addr" ssh-rsa AAAABтут_много_букв_которые_представляю_собой_ключ_в_base64== test@yandex.ru
Подробное описание из документации (man 8 sshd):
from="pattern-list"
Specifies that in addition to public key authentication, the canonical name of the remote host must be present in the comma-separated list of patterns (‘*’ and ‘?’ serve as wildcards). The list may also contain patterns negated by prefixing them with ‘!’; if the canonical host name matches a negated pattern, the key is not accepted. The purpose of this option is to optionally increase security: public key authentication by itself does not trust the network or name servers or anything (but the key); however, if somebody somehow steals the key, the key permits an intruder to log in from anywhere in the world. This additional option makes using a stolen key more difficult (name servers and/or routers would have to be compromised in addition to just the key).
Как запретить логин в ssh по паролю для определенного юзера?
Match User someuser
PasswordAuthentication no
Работает только для Debian/Ubuntu, на CentOS поддержки Match нету!
http://serverfault.com/questions/84199/disable-ssh-password-authentication-by-user
SSH, pseudo-tty -t: Connection to some.host.com closed.
При использовании интерактивного ssh:
Часто выдается ошибка Connection to some.host.com closed. Чтобы от нее избавится нужно рядом с -t добавить ключ -q.
Источник: http://fixunix.com/ssh/73970-how-avoid-connection-host-closed-t.html
ssh -t ....
Часто выдается ошибка Connection to some.host.com closed. Чтобы от нее избавится нужно рядом с -t добавить ключ -q.
Источник: http://fixunix.com/ssh/73970-how-avoid-connection-host-closed-t.html
Запуск интерактивных команд по ssh: TERM environment variable not set.
При попытке запустить удаленно интерактивную команду получаем облом:
Чтобы все заработало, делаем так:
ssh test@node1.domain.ru top
TERM environment variable not set.
Чтобы все заработало, делаем так:
ssh test@node1.domain.ru -t top
вторник, 26 апреля 2011 г.
понедельник, 25 апреля 2011 г.
Логин на ssh по одноразовым паролям - ssh + WiKID
Вот такая вот очень умная штука: http://www.wikidsystems.com/support/wikid-support-center/how-to/how-to-secure-ssh-with-two-factor-authentication-from-wikid
Всем, кому нужно делегировать доступ к серверам посвящается :)
Всем, кому нужно делегировать доступ к серверам посвящается :)
четверг, 10 марта 2011 г.
суббота, 5 февраля 2011 г.
/dev/null is not a character device!.
ОС: Gentoo, OpenVZ CT.
Ошибка:
Почему-то /dev/null оказался обычным файлом:
Создал его заново:
После этого sshd заработал:
Ошибка:
/etc/init.d/ssh start
/dev/null is not a character device!.
Почему-то /dev/null оказался обычным файлом:
root@pini-pini:/# stat /dev/null
File: `/dev/null'
Size: 0 Blocks: 0 IO Block: 4096 regular empty file
Device: 37h/55d Inode: 475137 Links: 1
Access: (0600/-rw-------) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2011-02-05 23:21:15.000000000 +0300
Modify: 2011-02-05 23:51:55.000000000 +0300
Change: 2011-02-05 23:51:55.000000000 +0300
Создал его заново:
rm /dev/null
mknod /dev/null c 1 3
После этого sshd заработал:
/etc/init.d/ssh start
Starting OpenBSD Secure Shell server: sshd.
понедельник, 1 ноября 2010 г.
Как выкинуть определенного пользователя из ssh?
Иногда нужно выбросить определенного пользователя из ssh, допустим, на время выполнения тех работ. Есть ряд нестандартных решений (ps aux + kill -9), но оказывается есть вполне стандартное решение задачи.
Итак, имеем двух пользователей root одновременно работающих на сервере (это разные люди):
Нам нужно выкинуть пользователя с IP yy.yy.yy.yy, смотрим, какой tty (терминал) ему соответствует, это pts/1 и отключаем его:
Вуаля, мы остались в гордом одиночестве:
А выброшенный пользователь увидел примерно следующее:
Далее возникает вопрос - как избежать того, чтобы пользователь вошел снова. Можно сделать это вот так, просто сгенерировав новый пароль для пользователя и установив его:
После смены еще раз убеждаем, не переподключился ли второй пользователь снова командой:
После этого можно смело продолжать работать с машиной не беспокоясь, что кто-либо помешает.
Источник: http://www.cyberciti.biz/tips/howto-linux-kill-and-logout-users.html
Итак, имеем двух пользователей root одновременно работающих на сервере (это разные люди):
w
18:08:13 up 17:03, 2 users, load average: 0.00, 0.00, 0.00
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
root pts/0 xx.xx.xx.xx 18:07 0.00s 0.00s 0.00s w
root pts/1 yy.yy.yy.yy 18:08 9.00s 0.00s 0.00s -bash
Нам нужно выкинуть пользователя с IP yy.yy.yy.yy, смотрим, какой tty (терминал) ему соответствует, это pts/1 и отключаем его:
skill -KILL -t pts/1
Вуаля, мы остались в гордом одиночестве:
w
18:08:36 up 17:03, 1 user, load average: 0.00, 0.00, 0.00
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
root pts/0 xx.xx.xx.xx 18:07 0.00s 0.00s 0.00s w
А выброшенный пользователь увидел примерно следующее:
Connection to xx.yy.zz.kk closed.
Далее возникает вопрос - как избежать того, чтобы пользователь вошел снова. Можно сделать это вот так, просто сгенерировав новый пароль для пользователя и установив его:
apt-get install -y pwgen # ставим генератор паролей
pwgen 16 1
passwd
После смены еще раз убеждаем, не переподключился ли второй пользователь снова командой:
w
После этого можно смело продолжать работать с машиной не беспокоясь, что кто-либо помешает.
Источник: http://www.cyberciti.biz/tips/howto-linux-kill-and-logout-users.html
вторник, 19 октября 2010 г.
Проброс портов посредством SSH
Итак, допустим, у нас есть удаленный сервер, доступ к которому возможен лишь по ssh. А нам непременно нужно достучаться до MySQL сервера, установленного на той же машине (или внутри сети, в которой имеет доступ только удаленная машина), то что делать? Очень просто - сделать ssh туннель.
Сделать его проще простого, на клиентской машине делаем следующее:
Где -L 3306:127.0.0.1:3306 - это порт на локальной машине, к которому будет подключен удаленный сервис; адрес удаленного сервера (либо это может быть 127.0.0.1 в случае подключения к локальному сервису машины, к которой у нас имеется ssh доступ), к которому нужно подключиться и порт на нем; -f означает переход в фоновый режим сразу после выполнения заданной команды; -N отключает требование выполнять какую-либо команду на удаленной машине; ssh-server.ru - машина, к которой мы имеем доступ по ssh, а login - логин на этой машине.
После выполнения команды она запросит пароль, его нужно ввести (либо настроить вход на сертификатах).
Далее убеждаемся, что ssh слушает необходимый нам порт:
Все, теперь пробуем подключиться к MySQL:
В реальности же мы подключились к удаленной машине!
Теперь можно поставить MySQL клиент и проверить его работу:
И, вуаля:
Остановка туннеля:
А как сделать тоже самое без ssh и шифрования? Вот этим софтом:
Сделать его проще простого, на клиентской машине делаем следующее:
ssh -L 3306:remote-server.ru:3306 -f -N login@ssh-server.ru sleep 10
Где -L 3306:127.0.0.1:3306 - это порт на локальной машине, к которому будет подключен удаленный сервис; адрес удаленного сервера (либо это может быть 127.0.0.1 в случае подключения к локальному сервису машины, к которой у нас имеется ssh доступ), к которому нужно подключиться и порт на нем; -f означает переход в фоновый режим сразу после выполнения заданной команды; -N отключает требование выполнять какую-либо команду на удаленной машине; ssh-server.ru - машина, к которой мы имеем доступ по ssh, а login - логин на этой машине.
После выполнения команды она запросит пароль, его нужно ввести (либо настроить вход на сертификатах).
Далее убеждаемся, что ssh слушает необходимый нам порт:
netstat -lnpt | grep 3306
tcp 0 0 127.0.0.1:3306 0.0.0.0:* LISTEN 4578/ssh
tcp6 0 0 ::1:3306 :::* LISTEN 4578/ssh
Все, теперь пробуем подключиться к MySQL:
telnet 127.0.0.1 3306
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
?
5.0.51a-24+lenny4J)+;)[n8,j/KhL#hd;;Tt
В реальности же мы подключились к удаленной машине!
Теперь можно поставить MySQL клиент и проверить его работу:
apt-get install mysql-client -y
И, вуаля:
mysql --host=127.0.0.1 -uroot -p -e 'show databases;'
Enter password:
+--------------------+
| Database |
+--------------------+
| information_schema |
| mysql |
+--------------------+
Остановка туннеля:
ps aux | grep 'ssh -L'
kill пид_нашего_процесса
А как сделать тоже самое без ssh и шифрования? Вот этим софтом:
rinetd - Internet TCP redirection server
socat - multipurpose relay for bidirectional data transfer
воскресенье, 17 октября 2010 г.
sshproxy - безопасный доступ к ssh
Так как офсайт лежит, выкладываю сссылку на Debian:
http://packages.debian.org/lenny/sshproxy
http://packages.debian.org/lenny/sshproxy
Утилита для не интерактивного логина на ssh сервера
http://sourceforge.net/projects/sshpass/
Обращаю внимание, что этот вариант использования ssh крайне небезопасен!
Обращаю внимание, что этот вариант использования ssh крайне небезопасен!
воскресенье, 3 октября 2010 г.
Ограничить доступ юзера к SSH по ключу только определенным IP
man 8 sshd
from="pattern-list"
Specifies that in addition to public key authentication, the canonical name of the
remote host must be present in the comma-separated list of patterns (‘*’ and ‘?’ serve
as wildcards). The list may also contain patterns negated by prefixing them with ‘!’;
if the canonical host name matches a negated pattern, the key is not accepted. The pur-
pose of this option is to optionally increase security: public key authentication by
itself does not trust the network or name servers or anything (but the key); however, if
somebody somehow steals the key, the key permits an intruder to log in from anywhere in
the world. This additional option makes using a stolen key more difficult (name servers
and/or routers would have to be compromised in addition to just the key).
четверг, 20 мая 2010 г.
Как скрыть версию ядра в Debian Lenny SSH Welcome screen?
Открываем конфиг:
Накладываем вот такой патч (убираем -r, который как раз и печатает версию ядра):
Применяем изменения:
Все, версия ядра скрыта :)
vi /etc/init.d/bootmisc.sh
Накладываем вот такой патч (убираем -r, который как раз и печатает версию ядра):
- uname -snrvm > /var/run/motd
+ uname -snvm > /var/run/motd
Применяем изменения:
uname -snvm > /var/run/motd
[ -f /etc/motd.tail ] && cat /etc/motd.tail >> /var/run/motd
Все, версия ядра скрыта :)
воскресенье, 18 апреля 2010 г.
sshd[*]: error writing /proc/self/oom_adj: Operation not permitted
И таких записей на OpenVZ VPS куча в логе: /var/log/auth.log
Что это и зачем?
Эта ошибка связана с тем, что SSH корректирует работу механизма ядра Linux называемого OOM killer. Этот механизм призван любыми средствами сохранять работоспособность системы в случае исчерпанная памяти. Когда память кончается, он по довольно сложному алгоритму ищет ненужный, на его взгляд процесс, и убивает его. К сожалению, под действие этого механизма может попасть и процесс SSH сервера, что крайне нежелательно. Поэтому демон SSH передает ядру команду, чтобы его не убивало OOM killer ом в случае недостатка памяти (если быть точным, то его тоже убьет, но самым самым последним).
На VPS же этот механизм не работает по причине, что OpenVZ не дает доступ к файловой системе /proc, которая как раз и используется для управления OOM Killerом. Поэтому, данные записи в логах являются нормальным явлением на VPS и Вам не стоит о них беспокоиться.
А вот бы такой патчик пропихнуть в OpenVZ апстрим....
Что это и зачем?
Эта ошибка связана с тем, что SSH корректирует работу механизма ядра Linux называемого OOM killer. Этот механизм призван любыми средствами сохранять работоспособность системы в случае исчерпанная памяти. Когда память кончается, он по довольно сложному алгоритму ищет ненужный, на его взгляд процесс, и убивает его. К сожалению, под действие этого механизма может попасть и процесс SSH сервера, что крайне нежелательно. Поэтому демон SSH передает ядру команду, чтобы его не убивало OOM killer ом в случае недостатка памяти (если быть точным, то его тоже убьет, но самым самым последним).
На VPS же этот механизм не работает по причине, что OpenVZ не дает доступ к файловой системе /proc, которая как раз и используется для управления OOM Killerом. Поэтому, данные записи в логах являются нормальным явлением на VPS и Вам не стоит о них беспокоиться.
А вот бы такой патчик пропихнуть в OpenVZ апстрим....
Подписаться на:
Сообщения
(
Atom
)