Comments 85
# who
Либо в ручную, либо в cron, что менее правильно чем в приведоном методе.
Это когда Вы вспомните и решите посмотреть кто сидит уже в системе. А автор предлагает вариант оповещения в случае установления соединения.
Идея, по-моему, интересна.
Идея, по-моему, интересна.
tail -f /var/log/auth.log
Внимательнее читайте статью. "… пока Вы сейчас спокойно читаете хабр, возможно с Вашего компьютера уже передаются конфиденциальные данные..."
Суть в том, что не требуется личного участия — о событии будет извещено.
Суть в том, что не требуется личного участия — о событии будет извещено.
| grep Accept
# last
# w
может проще запретить авторизацию по паролю?
Спасибо! Этого мне не хватало как параноику:)
На сервере у меня стоит отправка сообщение на email.
Наверняка, можно сделать, чтобы с сервера запускался скрипт на десктопе.
Наверняка, можно сделать, чтобы с сервера запускался скрипт на десктопе.
а еще бы кнопку — отрубить соединение :)
Кстати да, мне кажется в этой статье еще кое-чего не хватает. Научите пожалуйста кто-нибудь «выкидывать» пользователя, который на данный момент каким-либо образом залогинен на машину (локально или удаленно). Какой командой это можно сделать?
sudo ifconfig eth0 down
точно помогает ;)находите нужный pid командой ps ax | grep 'sshd: username'
убиваете командой kill
убиваете командой kill
Если вы не против, то сразу поинтересуюсь: А как можно локального пользователя (с запущенными иксами) выгрузить, желательно корректно — что-то вроде «выход из системы», logout. Т.е. идея прибить процесс понятна и для ssh-подключений вполне годится, а как быть с графическим режимом?
reboot -n now
Хоть и велосипед, но идея отличная! Можно как вариант парсить логи, но это лишнии процессы в памяти.
Надо помнить, что notify-send выполняется с правами вошедшего пользователя и может стоять не во всех системах. Ставится в Debian вместе с либой libnotify-bin.
Стоит ли наделять такого пользователя достаточными правами для таких действий? И уж не стоит повторять, что возможность входа под рутом по SSH — моветон.
Стоит ли наделять такого пользователя достаточными правами для таких действий? И уж не стоит повторять, что возможность входа под рутом по SSH — моветон.
Выглядит конечно здорово и устрашающе, вот только сценарий реального использования представить себе не могу, даже для параноиков.
Если есть ssh доступ, значит возможны и легитимные подключения. И для них орать «ужас-ужас, нас ломают!» как-то глупо и будет только мешать. А если ssh только для себя самого, то и предупреждать-то некого :)
Если есть ssh доступ, значит возможны и легитимные подключения. И для них орать «ужас-ужас, нас ломают!» как-то глупо и будет только мешать. А если ssh только для себя самого, то и предупреждать-то некого :)
Есть компьютер дома. Подключаемся сами с работы — пищит, ну и ладно. Подключается злоумышленник, а мы дома — пищит, слышим, волнуемся.
Подключается злоумышленник, а мы вышли за хлебом — не слышим, не волнуемся, все пропустили.
Без пользы это IMHO. Это то, что называют security theater. От кражи данных не спасет, только нервы попортит, может быть.
Без пользы это IMHO. Это то, что называют security theater. От кражи данных не спасет, только нервы попортит, может быть.
Отлично работает, если коннект происходит под текущим юзером. Но при коннекте под другим аккаунтом, например, root(знаю, что плохо разрешать, но всё же) или pupkin, 'notify-send' ничего не показывает, т.к. не имеет доступа к X, только слышена сирена. Система Ubuntu 10.10. Конечно же, помогает команда добавления юзера в список доступа к X:
Но такой вариант неприемлем по причинам безопасности.
xhost local:pupkin
Но такой вариант неприемлем по причинам безопасности.
Так же Вы можете поставить такие оповещения и просто на подключение к порту или запросу к HTTP-серверу.
а какой при этом скрипт срабатывает? или парсить логи на предмет активности?
Спасибо за статью.
P.S. стерёт -> сотрёт
P.S. стерёт -> сотрёт
Проще не включать демон или закрыться фаерволом.
UFO just landed and posted this here
Кстати, интересно, что если $SSH_CONNECTION не установлено, а скрипт запускается (например, по другим причинам), то from и to не выводятся, что не нарушает красоты сообщения и работу скрипта.
для Ubuntu понадобилось ещё поставить пакет sox для проигрывания звука, не стоял по дефолту.
В итоге все дополнительные команды, учитывая упомянутый libnotify:
sudo apt-get install libnotify-bin
sudo apt-get install sox
спасибо автору!
В итоге все дополнительные команды, учитывая упомянутый libnotify:
sudo apt-get install libnotify-bin
sudo apt-get install sox
спасибо автору!
Автор, допишите, пожалуйста, что если есть ~/.ssh/rc, то выполнится он, и /etc/ssh/sshrc выполняться *не будет*, плюс данный скрипт не должен ничего выводить в stdout, но эта часть нужна тем, кто использует x11 forwarding через ssh.
man sshd
/SSHRC
И спасибо за статью :)
man sshd
/SSHRC
И спасибо за статью :)
Сейчас добавлю, только я не понял о чём Вы пытались сказать про stdout?
В man-е пишут, что [данный скрипт, ~/.ssh/rc или /etc/ssh/sshrc ]…
«must not produce any output on stdout; stderr must be used instead. If X11 forwarding is in use, it will receive the „proto cookie“ pair in its standardinput (and DISPLAY in its environment).»
Касается не многих, но у кого-то может поломаться :)
«must not produce any output on stdout; stderr must be used instead. If X11 forwarding is in use, it will receive the „proto cookie“ pair in its standardinput (and DISPLAY in its environment).»
Касается не многих, но у кого-то может поломаться :)
Может, вместо play использовать aplay -q, потому что, например в Ubuntu, play по умолчанию не установлен, зато есть aplay.
1. aptitude install pam-dbus-notify
2. /usr/share/pam_dbus/pam-dbus-notify &
3. sed -i 's/@include common-auth/auth required pam_dbus.so/' /etc/pam.d/sshd
4. ssh localhost
2. /usr/share/pam_dbus/pam-dbus-notify &
3. sed -i 's/@include common-auth/auth required pam_dbus.so/' /etc/pam.d/sshd
4. ssh localhost
Появилась идея повесить в комнате красную лампу и включать ее в подобных случаях.
Автор — молодец, идея интересная, хоть и мне не нужная, но есть замечание.
Вот вы зачем свой скрипт прогоняете через bash? В нём же не используются никакие специфично башевские вещи, ни массивы, ни parameter expansion с pattern substitution. Такие простые скрипты надо начинать с
и на той же бубунте они будут скармливаться dash'у, который использует в 3 раза меньше памяти и стартует в 10 раз быстрее.
Вот вы зачем свой скрипт прогоняете через bash? В нём же не используются никакие специфично башевские вещи, ни массивы, ни parameter expansion с pattern substitution. Такие простые скрипты надо начинать с
#!/bin/sh
и на той же бубунте они будут скармливаться dash'у, который использует в 3 раза меньше памяти и стартует в 10 раз быстрее.
Спасибо, интересный способ.
Правда я настроил conky на показ входящих подключений по 21 и 22 портами, и всегда вижу на десктопе входящие соединения по ftp и ssh, мне этого достаточно.
Правда я настроил conky на показ входящих подключений по 21 и 22 портами, и всегда вижу на десктопе входящие соединения по ftp и ssh, мне этого достаточно.
«export DISPLAY=:0» — по идее это не должно работать, если войти по ssh используя учётную запись отличную от той, которая в данный момент используется в X-ах, т.к. пользователь не сможет в X-ах авторизоваться.
Удивительно, что никто еще не написал про sendxmpp в связи с этим.
echo -e "SSH Login on $(hostname -f)\n\nDate:\t\t$(date +%d.%m.%Y\ %H:%M:%S)\nRemote Host:\t$SSH_CONNECTION\nUser:\t\t$USER\nShell:\t\t$SSH_TTY" |\
sendxmpp -u user -p password -j server -s "SSH Login on $(hostname -f)" -r "$(hostname -f)" my@jabber.id 2>/dev/null
Немного поэкспериментировал. Похоже, уведомление notify-send работает, только если по ssh входит тот же пользователь, от которого запущен X-сервер. Тогда уведомление отображается нормально. Если же по ssh входит, например, root, то notify-send от root ничего не выводит на экран пользователя:
Также если просто запустить из консоли от root:
wiselord ~ # notify-send test
X11 connection rejected because of wrong authentication.
…
Аварийный останов
Можно видеть, что дело не в ssh, а именно в том, что вывод на DISPLAY возможен только от того же пользователя.
По крайней мере, в KDE4 так, а делать `xhost +` для доступа всех — это поступиться одной безопасностью ради другой.
Также если просто запустить из консоли от root:
wiselord ~ # notify-send test
X11 connection rejected because of wrong authentication.
…
Аварийный останов
Можно видеть, что дело не в ssh, а именно в том, что вывод на DISPLAY возможен только от того же пользователя.
По крайней мере, в KDE4 так, а делать `xhost +` для доступа всех — это поступиться одной безопасностью ради другой.
Много написал, но только сейчас заметил комментарий выше: habrahabr.ru/blogs/linux/117834/#comment_3837428
«xhost +» делать не очень хорошо с точки зрения безопасности. Правильнее будет сделать так, как это делается, например, в скриптах ACPI.
см. /usr/share/acpi-support/power-funcs, функция getXuser()
см. /usr/share/acpi-support/power-funcs, функция getXuser()
Спасибо автору за статью. Очень и очень полезно. Только возникает вопрос. В чем смысл запущенного ssh, пока вы читаете хабр? Как показывает горький опыт, данные и функционал лучше разносить по машинам.
А в целях безопасности, можно просматривать весь исходящий трафик на уровне TCP, и закрывать соединение при появлении подозрительных строк. Наверняка это можно сделать с помощью Snord или c tcpdump (ручками). Парсить логи для этого, на мой взгляд вредно, лучше в режиме реального времени. Узнаем, что у нас что-то тащат — рвем соединение и посылаем владельцу sms, как писали выше.
Если мы очень вредные, то при появлении подозрительных строк, можно не рвать соединение, а подменять данные на заведомо ложные. При посылке опасных команд — рвать, ничего эдакого тут не придумаешь.
Главное, самому не попасть в свои же капканы.
Но автору еще раз спасибо за познавательную статью.
А в целях безопасности, можно просматривать весь исходящий трафик на уровне TCP, и закрывать соединение при появлении подозрительных строк. Наверняка это можно сделать с помощью Snord или c tcpdump (ручками). Парсить логи для этого, на мой взгляд вредно, лучше в режиме реального времени. Узнаем, что у нас что-то тащат — рвем соединение и посылаем владельцу sms, как писали выше.
Если мы очень вредные, то при появлении подозрительных строк, можно не рвать соединение, а подменять данные на заведомо ложные. При посылке опасных команд — рвать, ничего эдакого тут не придумаешь.
Главное, самому не попасть в свои же капканы.
Но автору еще раз спасибо за познавательную статью.
>В чем смысл запущенного ssh, пока вы читаете хабр?
Реальный пример: на моей тачке на работе есть пишущий DVD, а у другана рядом нет и он иногда пишет на моем DVD… по ssh.
Реальный пример: на моей тачке на работе есть пишущий DVD, а у другана рядом нет и он иногда пишет на моем DVD… по ssh.
Может я не прав, но это своего рода костыль. Безопаснее\полезнее\удобнее поставить ему еще один DVD, или хотя бы выносной купить, если это вообще возможно в силу инфраструктуры\бюрократических ограничений. Но как реальный пример — очень хорош. Спасибо.
>В чем смысл запущенного ssh, пока вы читаете хабр?
Когда паранойя заставляла включать ssh только когда уезжаю, но пару раз забыл включить и не смог получить доступ когда он очень нужен был, с тех пор работает постоянно.
Когда паранойя заставляла включать ssh только когда уезжаю, но пару раз забыл включить и не смог получить доступ когда он очень нужен был, с тех пор работает постоянно.
А можно ли в Убунте реализовать отправку уведомлений по сети типа как в маковском Growl? Я бы хотел чтобы домашний сервер мог посылать уведомления мне на ноутбук. Для винды есть Growl for Windows, для линукс нету?
Про Grovi не знаю, но сами уведомления по сети сделать довольно просто.
Что-то подобное есть. Подробности тут: goo.gl/mmlX2 :)
UFO just landed and posted this here
А как быть с
> libnotify-Message: Unable to get session bus: /bin/dbus-launch terminated abnormally with the following error: No protocol specified
> Autolaunch error: X11 initialization failed.
При установленных DBUS_SESSION_BUS_ADDRESS и DBUS_SESSION_BUS_PID работает нормально, но их ведь где-то надо взять предварительно…
> libnotify-Message: Unable to get session bus: /bin/dbus-launch terminated abnormally with the following error: No protocol specified
> Autolaunch error: X11 initialization failed.
При установленных DBUS_SESSION_BUS_ADDRESS и DBUS_SESSION_BUS_PID работает нормально, но их ведь где-то надо взять предварительно…
такое ощущение, что про syslog никто и близко не слышал.
Sign up to leave a comment.
Оповещение при подключении к SSH