SSH прості хитрощі

Інформація здебільшого для новачків, але й у мене руки дійшли до цього тільки зараз.

Є багато засобів захисту SSH від тупих атак "китайських хакерів", найочевидніший – прикрити фаєрволом від "світу", залишивши доступ тільки з відомих довірених мереж/вузлів. Але такий варіант не завжди підходить, наприклад, є машини які використовуються у якості "точок входу" (на випадок коли немає можливості підключитись по VPN). Стійкі паролі досить надійно захищають від грубих атак, але армія роботів все одно спробує переконати сервер що пароль "Мао*Дзедун", їхні спроби засмічують журнали, що в будь-якому разі не є добре.

Найпростіший спосіб направити цю армію по хибному шляху, перенести службу SSH на інший нестандартний порт, наприклад, tcp/227 або будь-який інший не задіяний для стандартних служб.

!!! Будьте обережні, особливо якщо сервер віддалений, при зміні налаштувань не "зарубайте" доступ самому собі. Для цього виконуйте зміни у наступному порядку:

  • до конфігурації фаєрволу додайте правило, яке дозволить з'єднання по новому нестандартному порту;
  • змініть порт у налаштуваннях SSHd;
  • перевірте з'єднання по новому порту;
  • і тільки тепер заберіть правило, яке дозволяло з'єднання по стандартному порту.

Але це тільки пів справи, ви надурили армію роботів, але й собі створили незручності, для підключення до сервера вам доведеться вказувати додаткові параметри:

~$ ssh -p 227 server.example.com

Справжні спеціалісти не люблять дурної роботи, тому ми навчимо ssh-клієнт пам'ятати у якого сервер який порт використовується. Для цього допишіть у файл ~/.ssh/config ось такі рядки:

Host server.example.com

Port 227

Після цього вам не потрібно буде кожного разу вказувати порт вручну.

Це не єдина зручність яку дозволяє організувати конфігураційний файл ssh, ви можете створювати псевдоніми для вузлів, автоматично підставляти нестандартне ім'я користувача, тощо.

Host dev

HostName developer.example.com

User vasyadev

Port 227

IdentityFile developer_key

Почитайте man ssh_config. Що краще ви знаєте свій інструмент, то більш ефективною стає ваша робота.


Mac OS X і зовнішній жорсткий диск

Задача: ефективно/зручно використовувати для резервного копіювання і зберігання всяких даних зовнішній жорсткий диск ємністю 1ТБайт у операційних системах Linux, Mac OS X і опціонально Windows.

Теоретична частина (вибір ФС для диску)

З чого будемо вибирати: рідна для Linux — Ext3, рідна для Mac OS X — HFS+, рідна для Windows — NTFS, на FAT не дивимось бо її обмеження у XXI-у столітті виглядають смішними.

. Ext3 - дуже симпатичний кандидат (OSS4ever!), але вимагає установки

милиць у інші ОС, як виявилося пізніше дуже кривих.

. HFS+ - Apple way, Джобз тріумфує (дай йому Бог здоров'я), для інших

ОС знадобляться додаткові танці, але я сподіваюсь Linux, як завжди, потішить, а на Windows нам начхати (зовсім необов'язково)

. NTFS - "обітєль зла", на Mac треба додатковий софт, на Linux хоч і

коробочний, але теж не дуже рідний. Єдиний незначний плюс - можливість запхати в чужий віндовий комп'ютер, але й це скоріше мінус, бо ще всяких "зловрєдів" налізе.

Добряче почухавши потилицю, вибираємо HFS+, подивимось як заведеться під Linux.

Практична частина (зберігаючи хронологію, але без матюків)

Диск був відформатований у Ext3, оскільки раніше я використовував виключно Linux (Ubuntu). На ньому накопичилась купка даних, які треба тимчасово перенести на Mac (більше ніде немає достатньо місця), попутно пробуємо варіант №1 з теоретичної частини.

Спроба № раз — macfuse і ext2fuse

Взагалі, способів установки ПЗ на Mac забагато; і .dmg, і .pkg, для OSS - macports, а віднедавна ще й AppStore. Я, як новачок, ще й досі гублюся... але для OSS вибрав один єдиний "православний" і "кошерний" спосіб — macports.

Вони ж (ports) мене і підвели, як ти їх не умовляй хоч через variants, хоч через macports.conf, все одно збирали модуль ядра тільки для архітектури i386.

Помордувавшись трохи, подумав, біс із ним, перезавантажив систему у 32-бітному режимі. І тут невдача, щось йому там "connection timed out", вирішив далі не розбиратись. Зніс ext2fuse і macfuse.

Спроба № два — Ext2fsx

Проект дохлий, не оновлюється з 2006-го, але знайшлася пара статей за 2010 «ставте все працює» — дзуськи! На Snow Leopard (10.6.7) воно не працює ні разу. Нічого дивного, йдемо далі.

Спроба № три — Paragon (Бог трійцю любить)

За рекомендацією приятеля ставлю комерційний Paragon ExtFS for Mac OS X, "тик-тик-тик", встановлено — працює. Ура!

Не душила б жаба заплатити $40 (але краще "Deore по кругу" для ровера, а якщо й до комп'ютера то Portal 2 ;)), використовував би на диску Ext3 і горя не знав, але ставлю 10-денну демо-версію, щоб тільки раз переписати файли з Ext3 на Mac.

Фініш

На цьому мої поневіряння закінчились, файли переписано, диск переформатовано у HFS+ (без журналювання). Linux побачив HFS+, хоч і без журналювання, зате «з коробки» на читання/запис, чим вкотре підтвердив свою позитивну репутацію «приспособлєнца».