Gate One: ssh в браузере средствами html 5

http://www.opennet.ru/opennews/art.shtml?num=33333

Как ограничить ssh пользователя, входящего в систему по сертификатам лишь заданным диапазоном IP?

Итак, у нас есть Linux пользователь, который входит в систему по ssh с использованием ключей - парольная аутентификация запрещена. Задача - как ограничить пользователю возможный диапазон IP, с которых он входит в систему.

Вариант 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 без перезапуска демона?

/usr/sbin/sshd -t

Использование KeyChain для работы с ssh

http://www.cyberciti.biz/faq/ssh-passwordless-login-with-keychain-for-scripts/

Как запретить логин в 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:

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

Вход в SSH по Public Keys из LDAP

http://blog.fupps.com/2006/03/02/ssh-public-keys-from-ldap/

Логин на ssh по одноразовым паролям - ssh + WiKID

Вот такая вот очень умная штука: http://www.wikidsystems.com/support/wikid-support-center/how-to/how-to-secure-ssh-with-two-factor-authentication-from-wikid

Всем, кому нужно делегировать доступ к серверам посвящается :)

Авторизация на сертификатах с MacOS на Linux

http://www.howtoforge.com/setting-up-an-ssh-certificate-for-ubuntu-from-a-mac

SSH2 клиент на Java

http://www.cryptzone.com/products/agmindterm/

/dev/null is not a character device!.

ОС: Gentoo, OpenVZ CT.

Ошибка:

/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.

Как выкинуть определенного пользователя из ssh?

Иногда нужно выбросить определенного пользователя из ssh, допустим, на время выполнения тех работ. Есть ряд нестандартных решений (ps aux + kill -9), но оказывается есть вполне стандартное решение задачи.

Итак, имеем двух пользователей 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

Проброс портов посредством SSH

Итак, допустим, у нас есть удаленный сервер, доступ к которому возможен лишь по ssh. А нам непременно нужно достучаться до 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

sshproxy - безопасный доступ к ssh

Так как офсайт лежит, выкладываю сссылку на Debian:
http://packages.debian.org/lenny/sshproxy

Утилита для не интерактивного логина на ssh сервера

http://sourceforge.net/projects/sshpass/

Обращаю внимание, что этот вариант использования ssh крайне небезопасен!

Использование DNS для публикации отпечатков публичных SSH ключей

http://tools.ietf.org/search/rfc4255

Ограничить доступ юзера к 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).

Как скрыть версию ядра в Debian Lenny SSH Welcome screen?

Открываем конфиг:

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

Все, версия ядра скрыта :)

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 апстрим....