Старые добрые шоткаты
Sunday, 13 Jan 2013Странная тема- в процессе работы в текстовом редакторе VI через SSH почему то отвалился переход в командный режим редактора через ESC. Работал- работал и вдруг хрясь и уже не работает.
Инкапсуляция сессии в SSH канал
Sunday, 23 Dec 2012Не даром говорят о том, что лень является двигателем прогресса. В прекрасный субботний день мне надо было ехать к клиенту, у которого на площадке я установил новый NAS сервер от Synology, для того чтобы настроить его.
Но в какой то момент меня дико заломало туда ехать, и я стал раздумывать, как бы мне так все настроить, не отрывая задницу от стула. При том, что в офисе никого не было, и как следствие все компьютеры были выключены, то есть Teamviewer был недоступен, а пароль от VPN, откровенно говоря, я забыл.
Передача файлов через SSH
Friday, 21 Dec 2012Для администрирования удаленных серверов всем хорош ssh- и быстрый и безопасный и удобный. Но иногда бывает необходимо залить какой нибудь файл с или на администрируемый сервер, и тогда начинаешь ломать голову, как это сделать, то ли втыкать флешочку, то ли поднимать на коленке ftp сервер, который все таки является небезопасным соединением.
Естественно, что под SSH сервером можно поднять так называемый безопасный FTP сервер- SFTP, являющийся частью сервера SSH, но опять же это все требует некоторых перенастроек системы.
Ограничение доступа ssh по IP в CentOS
Thursday, 17 May 2012Как говорится век живи – век учиcь. Оказалось, что CentOS’вский ssh не в курсе того, что на нормальных операционках ограничение подключений по IP осуществляется путем директивы AllowHosts в конфиге sshd_config. И посему эти ограничения следует прописывать в двух файлах:
/etc/hosts.allow
/etc/hosts.deny
Причем смысл в том, что прописываются в них ограничения для всех пакетов относящихся к INET сервисам. В принципе это конечно довольно удобно, то что не надо лазить по разным конфигам, а настраивается в одном файле, но имхо- все же в конфиге софта было бы понятнее.
Забавный глюк работы связки named и ssh
Wednesday, 24 Aug 2011Столкнулся тут с довольно забавным глюком связки ssh + named, в процессе прикручивания сервера доменных имен на работающем фаерволе. Брандмауэр был настроен уже какое то время назад, практически по мануалу который я напостил недавно, и вот на днях возникла необходимость сделать его еще и сервером доменных имен.
Хотя это конечно не безопасно, особенно исходя из концепции параноидальности на сетевом экране, тем более что не далее как в этом феврале была найдена уязвимость BIND 9 ветки, приводившая к DoS севера имен, при трансфере зоны или динамическом обновлении, но тем не менее пропатчив BIND и открыв его только вовнутрь сетки, решил что пользовать можно.
И вот в процессе настройки, когда вроде бы named резолвился для localhost но почему то не хотел стартовать на внутреннем интерфейсе, я решил раскомментировать строку в named.conf содержащую следующее выражение:
query-source address * port 53;
после чего решил добавить страку разрешающую обращение к фаерволу из внутренней сетки по 53 порту, и перегрузил сервак. После чего ssh у сервера интеллигентно отпал. Точнее сервер крутился и при обращении к нему выдавал запрос имени пользователя, но после его ввода, вместо ожидаемого в ответ запроса пароля, просто отключал пользователя. Поскольку сервер был удаленный, я звякнул тамошнему админу, и попытался его руками все вернуть обратно, но замена новых правил фаервола на новые- ничего не дала. Так что пришлось пилить в контору.
Изначально я полагал, что допустил в синтаксисе правил какую то ошибку, из-за которой правила не догружались до конца, но оказалось что таблица правил фаервола была загружена полностью. Да и ssh висел на порту, а вот named почему то отсутствовал. Попытка его стартануть не увенчалась успехом, так что я полез в логи, где обнаружил что прописал в named.conf фалы для зоны “.” дважды, точнее я то прописал один раз, не заметив, что они уже были обозначены. Что и приводило к падению демона named. Но что еще более поразительно- это же и приводило к нестабильной работе сервера ssh, отрубавшего логин к серверу.
Судя по всему, в случае падения демона named, резолвить имена подключений не получалось, так как в /etc/resolv.conf стоял только 127.0.0.1, и по этой самой причине соединение и рубилось на корню.
Так что на всякий случай добавил в /etc/ssh/sshd_config строчку отрубающую резолв имен: UseDNS no , хотя, в принципе, можно было бы и добавить дополнительных DNS серверов в resolv.conf
Смена стандартного пароля пользователя root на iPhone
Friday, 25 Dec 2009Как я уже писал ниже, в ноябре этого года, многочисленные пользователи iPhone в Европе, совершившие процедуру джейлбрейка своего телефона, подверглись атаке вируса iKee.B (duh) Apple iPhone, делавшего коммуникатор участником литовского ботнета. Использованная этим бот вирусом уязвимость, был стандартный пароль ‘alpine’ для пользователя root, и удаленный доступ к iPhone который злоумышленник получал через дополнительно установленный на iPhone ssh сервер.
