Коли стали широко використовуватися алгоритми шифрування при передачі даних в мережі, однією з перших завдань стала організація безпечної оболонки. До цього існувала система rsh, яка дозволяла певним користувачам з певних машин (між ними повинні були бути довірчі відносини) працювати на сервері з його оболонкою. Це практично те ж саме, що і telnet-доступ. Але з розвитком мереж стали видні кричущі дірки rsh:
Дані, що передаються через мережу, ніяк не шифруються, включаючи паролі.
Дані, що передаються через мережу, можуть бути без проблем отримані або модифіковані третьою стороною.
Зловмисник міг спокійно підмінити ip клієнта і, використавши отриманий раніше хеш пароля, пройти автентифікацію на сервері зі всіма витікаючими наслідками.

Тому зараз rsh застосовується у надзвичайно рідкісних випадках, наприклад, при перенесенні даних між двома попарно сполученими машинами (мені довелося працювати з двома машинами в різних кімнатах). В основному стандартом де-факто став ssh. Перша буква «s» означає безпечний (secure), що означає, що всі дані, предаваемые через ssh шифруються, а отже, захищені від перегляду. Існує кілька версій протоколу ssh, що відрізняються використовуваними алгоритмами шифрування і загальними схемами роботи. В даний час повсюдно використовується протокол ssh версії два. Протокол молодших версій є за сучасними мірками небезпечним (там є кілька дуже небезпечних дірок). Взагалі-то зараз ssh є комерційним продуктом (що саме по собі суперечить вимогам безпеки для всіх повинен бути відомий вихідний код системи захисту інформації, щоб переконатися у відсутності всяких backdoors), але тим не менш доступна вільна реалізація ssh OpenSSH, яка може бути знайдена на www.openssh.com. Найкращим документом по ssh є, по-моєму, банальний man ssh, тому в деяких місцях я не посоромлюся його просто перекладати.

Отже, почнемо, як завжди, з теорії. SSH надає 3 способи аутентифікації клієнта: за ip-адресою клієнта (небезпечно), по публічного ключа клієнта і стандартний парольний метод. Ось як працює ssh версії 2: при запиті клієнта сервер повідомляє йому, які методи аутентифікації він підтримує (це визначається в опції PreferredAuthentications sshd.conf) і клієнт по черзі намагається перевірити їх. За замовчуванням клієнт спочатку намагається аутентифицироваться своєю адресою, потім публічним ключем і, якщо нічого не спрацювало, передає пароль, введений з клавіатури (при цьому пароль шифрується асиметричним шифруванням). Після проходження аутентифікації одним з методів з наявних у клієнта і сервера пар ключів генерується ключ симетричного шифрування, який, як я описував у введенні, генерується на підставі свого секретного і віддаленого публічного ключів. Після чого всі дані, що передаються через ssh, шифрування цим ключем (зазвичай використовується алгоритм aes з довжиною ключа 128 біт). Зазначу, що протокол ssh версії 1 мав деякі баги в шифрації переданого трафіку і був по суті методом безпечної аутентифікації, тому за сучасними мірками даний протокол вважається небезпечним. Протокол версії 2 підтримує більш сучасні методи шифрування тарфика, також разом з даними надсилаються контрольні суми формату sha або md5, що виключає підміну або іншу модифікацію переданого трафіку (чого не було у ssh версії 1).

Тепер пару слів про способи аутентифікації користувачів через ssh:

1) За адресою клієнта.

При даному способі аутентифікації відбувається наступне: кожен клієнт і сервер мають свої пари ключів RSA, які називаються ключі хоста. При цьому існує кілька методів перевірки адреси клієнта. Сервер дивиться файли $HOME/.rhosts, $HOME/.shosts, /etc/hosts.equiv або /etc/ssh/shosts.equiv, якщо ж сервер налаштований на перевірку ключів клієнтів (а це потрібно в міркуваннях безпеки, т. к. інакше зловмисник може підмінити ip клієнта на свій), то він додатково перевіряє /etc/ssh/ssh_known_hosts і $HOME/.ssh/known_hosts. Природно, що файли, розташовані в домашніх каталогах сервера, діють на користувача, в чиєму каталозі вони розміщені, а файли, розташовані у /etc мають глобальний ефект. Для початку розповім про синтаксис вищеперелічених файлів:
.rhosts визначає адресу машини та ім’я користувача, з якою користувачу відкритий доступ (файл розташований у домашньому каталозі користувача).
.shosts аналогічний .rhosts, але призначений виключно для ssh, тому краще використовувати саме цей файл. Приклад .shhosts:
user1.test.ru user1
userstend.test.ru user1
null.test.ru user1
/etc/hosts.equiv також містить пари ім’я машини/ім’я користувача, але має ефект на всіх користувачів.
/etc/shosts.equiv аналог hosts.equiv, але застосовується тільки ssh, що також більш переважно. Приклад файлу /etc/shhosts.equiv:
+ user1.test.ru user1
— server.test.ru xakep
Знак “+” означає дозвіл користувачеві працювати з сервером з цієї адреси, знак “-” забороняє подібну дію.
/etc/ssh/ssh_known_hosts і $HOME/.ssh/known_hosts дані файли містять список адрес і відповідних їм публічних ключів. При запиті клієнта сервер генерує рандомную рядок і шифрує її публічним ключем віддаленого хоста. Клієнт, отримавши цю рядок, розшифровує її своїм секретним ключем (який є тільки у нього) і зашифровує отриманий рядок ключем сервера. Сервер отримує зашифроване повідомлення, розшифровує своїм секретним ключем і порівнює з вихідною. Якщо рядки співпали, то клієнт має дійсний таємний ключ, що дає йому право заходження на цей сервер. Але для початку клієнт повинен мати правильну адресу, якому відповідає публічний ключ на сервері у файлі ssh_known_hosts. Файл складається з 3-х полів: адреса, розділені комою), публічний ключ для нього одного (!) рядком і додаткове поле коментарів(необов’язково). Приклад файлу known_hosts:
user1.test.ru {SOME_VERY_LONG_PUBLIC_KEY}

Адреса клієнта повинен бути в повному форматі(name.domain), інакше можуть бути проблеми. Крім цього, в адресі можна використовувати шаблони * і?.. Публічні ключі вставляються в даний файл самим адміністратором з генерованих клієнтом ssh(identity.pub) публічних ключів. Взагалі створення ssh_known_hosts це прерогатива адміністратора (aka root).

І ще додам: при аутентифікації по хосту краще використовувати ssh_known_hosts, оскільки цей метод досить безпечний, якщо публічні ключі клієнтів були отримані з надійного джерела. Інші методи аутентифікації не виключають підміну адреси, і тому вважаються небезпечними.

2) Аутентифікація користувача за його публічного ключа.

Аутентифікація вилученого користувача по ключу ідентична перевірки ключа хоста (з посилкою рандомно рядка) за тим винятком, що перевіряється не адресу клієнтської машини, а ключ клієнта та ім’я користувача. Користувачу на сервері може відповідати його публічний ключ, тоді клієнт, маючи секретний ключ зможе заходити на сервер без пароля. Механізм роботи я тільки що описав, тому відразу ж розповім, яким чином аутентифікувати користувачів по ключу (передбачається, що використовується клієнт і сервер openssh):

Для генерації пари ключів використовуйте програму ssh-keygen. Для вказівки типу ключа вкажіть ssh-keygen -t {RSA DSA}, наприклад, ssh-keygen -t rsa створить пару ключів RSA довжиною 1024 біт. Для вказівки файлу, у якому слід зберегти ключі, можна використовувати опцію -f (традиційно використовуються файли $HOME/.ssh/id_rsa і $HOME/.ssh/id_dsa для ключів rsa і dsa відповідно), для зазначення довжини ключа в бітах використовуйте опцію -b:
ssh-keygen -t rsa -b 2048 -f $HOME/.ssh/id_rsa

В результаті роботи програма попросить ввести пароль секретного ключа шифрування, щоб виключити використання його при попаданні до стороннім особам, які не знають пароля пароль бажано вибирати не коротше 10 символів). Після цього вам буде необхідно ввести цей пароль щоразу при використанні секретного ключа (далі я розповім, як уникнути цього за допомогою програми ssh-agent). Після роботи ssh-keygen створюється пара ключів: один секретний (зашифрований введеним паролем), а інший публічний з розширенням .pub (id_rsa.pub). Публічний ключ вам необхідно буде скопіювати в домашню директорію сервера $HOME/.ssh/authorized_keys. Після цього сервер буде знати ключ даного користувача і зможе аутентифікувати вас без пароля. Файл authorized_keys може містити кілька публічних ключів, допустимих для даного користувача: просто помістіть їх у файл по порядку. Після цих операцій ви зможете входити, маючи секретний ключ на сервер, де розміщений ваш публічний ключ, причому під тим користувачем, у чиєму домашньому каталозі даний ключ знаходиться. Пароль віддаленого користувача не потрібно, необхідно лише знати пароль розшифровки секретного ключа. Для перенесення свого публічного ключа на сервер треба використовувати тільки безпечні джерела, інакше ваш ключ можуть підмінити. Для перенесення публічного ключа клієнта служить програма ssh-copy-id. Для початку необхідно зробити наступне:
# ssh-copy-id -i public_key_file [email protected]

Після з’єднання з північчю machine і передачею імені користувача user (необхідно вказувати, якщо віддалене ім’я відрізняється від локального) відбувається парольна аутентифікація заданого користувача(або поточного) на віддаленій машині, потім відбувається копіювання ключа public_key_file (або $HOME/.ssh/identity.pub, якщо ім’я файлу не зазначено) на сервер у $HOME/.ssh/authorized_keys. Після цього можна входити на сервер, не використовуючи пароль користувача. При виконанні даної операції врахуйте, що ви повинні скопіювати на віддалену машину ПУБЛІЧНИЙ ключ, інакше все буде дуже сумно (думаю, зрозуміло чому).

3) Звичайна парольна аутентифікація.

Тут можна зауважити лише одне: в будь-якому випадку спочатку йде обмін асимметрическими ключами, і хеш пароля передається в зашифрованому вигляді. Парольна аутентифікація використовується найбільш часто, але, чесно кажучи, ssh пропонує більш зручні методи аутентифікації, і користуватися ними IMHO можна, якщо до ssh є всі латки. І, звичайно ж, протокол версії 1 необхідно вирубати взагалі. Отже, починаємо налаштування

Я помітив, що більшість адміністраторів просто залишає конфіги клієнта і сервера за замовчуванням, щоб не бруднити руки. Але це неправильно: у різних системах ці конфіги відрізняються дуже суттєво, і це призводить до плутанини і нерозуміння роботи сервера, що створює додаткову загрозу безпеки (свій сервак сутінки). Для цього я вирішив описати файли конфігурації ssh на прикладах ssh_config і sshd.conf для клієнта і сервера відповідно. Для конфігурації клієнта використовується файл $HOME/.ssh/config або /etc/ssh/ssh_config (для всієї системи). Файл має такий формат: визначення адреси хоста і параметри для нього. В адресі можна використовувати звичайні шаблони * і ?, всі імена параметрів і їх значення повинні бути набрані в тому ж регістрі, що і в прикладі (інакше параметр сприйнятий не буде). Ось приклад ssh_config, який містить найбільш корисні опції (насправді описувати деякі параметри конфігурації ssh не має сенсу, оскільки вони вживаються дуже рідко):

# Визначення хоста, в даному випадку включає всі хости домену test.ru можна
# використовувати одиночний символ * щоб вказати параметри доступу до будь-якого хосту
Host *.test.ru
# Ця опція визначає, чи ssh використовувати передачу даних від віддаленого
# X сервера через свій безпечний канал. Далі буде описано, яким чином
# організовуються безпечні тунелі через ssh. Дана можливість дозволяє
# захищати по ідеї небезпечні протоколи(X, pop, smtp, ftp) шифруванням ssh. За
# замовчуванням ця опція no
ForwardX11 yes
# Список бажаних методів аутентифікації через ssh версії 2. Першим
# варто найкращий протокол, думаю, значення даного параметра ясні
PreferredAuthentications hostbased,publickey,keyboard-interactive
# Цей параметр визначає, чи буде проводиться стандартна перевірка парольний
# За замовчуванням yes
PasswordAuthentication yes
# Число спроб введення пароля перед тим, як клієнт від’єднується від сервера. За
# замовчуванням пароль можна вводити тричі
NumberOfPasswordPrompts 3
# Список допустимих користувачів для даного сервера. Можна застосовувати два
# формату: список користувачів, розділених пробілом, і список користувачів
# хостів, розділених пробілом([email protected] — дозволяє користувачу доступ
# тільки з цієї адреси). Можна використовувати вирази * і?.. Подібне ж
# призначення мають опції AllowGroups, DenyUsers і DenyGroups(для груп не можна
# вказувати адресу клієнта)
AllowUsers *@*.test.ru
DenyUsers xakep lamer
DenyGroups x*
# Використання ssh(2 версія) аутентифікації через rhosts і ключі RSA. За
# замовчуванням no.
HostbasedAuthentication yes
# Чи буде клієнт намагатися працювати за rsh, якщо ssh недоступний або з якихось
# причин працює неправильно. За замовчуванням no
FallBackToRsh no
# Використовуємо чи rsh. За замовчуванням no
UseRsh no
# Режим скрипта, коли не запитуються паролі з терміналу. За замовчуванням no
BatchMode no
# Додатково перевіряється ключ хоста віддаленої машини в
# known_hosts, що виключає підміну ip. За замовчуванням yes.
CheckHostIP yes
# Даний параметр означає, чи буде клієнт довіряти отриманим від серверів
# ключів. Параметр може приймати такі значення: yes — ключі ніколи
# автоматично не поміщаються в known_hosts, ask — ключ може бути поміщено у
# known_hosts тільки після підтвердження користувача, no — всі ключі
# автоматично розміщуються у known_hosts(небезпечно). За замовчуванням ask.
StrictHostKeyChecking ask
# Наступні параметри визначають секретні ключі ssh різних форматів:
# rsa і dsa
IdentityFile $HOME/.ssh/id_rsa
IdentityFile $HOME/.ssh/id_dsa
# Порт, на віддаленій машині використовується ssh. За замовчуванням 22
Port 22
# Версії протоколів, які використовуються клієнтом в порядку спадання пріоритету.
Protocol 2
# Протокол шифрування для версії 1 протоколу ssh
Cipher 3des
# Можливі протоколи шифрування в порядку убування пріоритету для протоколу
# версії 2
Ciphers aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc
# Значення escape-символи, що сигналізує, що йдуть за ним символи
# необхідно сприймати спеціальним чином(наприклад ~. викличе негайне
# відключення клієнта від сервера) при передачі двійкових даних необхідно
# встановити цей параметр none, що вимикає escape послідовності. За
# замовчуванням ~
EscapeChar ~
# Керування роботою компресії зашифрованнного трафіку. Корисний параметр для
# повільних мереж, т. к. зашифровані дані зазвичай збільшуються в розмірі за
# рахунок фіксованої довжини ключа. Компресія дозволяє зменшити кількість
# даних, переданих через мережу, але збільшить час роботи самого протоколу.
# Так що вмикати цей параметр бажано на повільних з’єднаннях. За
# замовчуванням no.
Compression yes
# Управляє посилкою повідомлень про доступність клієнта серверу, що дозволяє
# нормально розірвати з’єднання, якщо неполадка в мережі або інша,
# призвела до розриву з’єднання. Якщо зв’язок поганий, то краще цю опцію
# відключити, щоб дисконект не відбувався після кожної помилки мережі. За
# замовчуванням yes.
KeepAlive yes

Я думаю, що в даному прикладі всі пояснено досить докладно і скажу тільки ось що: в більшості випадків опції за умовчанням працюють непогано, необхідно тільки відключити підтримку ssh версії 1 і налаштувати необхідні методи аутентифікації (крім захищений) і вказати шляхи доступу до ключів. На цьому закінчимо з налаштуванням клієнта і налаштуємо сервер. Файл конфігурації сервера sshd знаходиться в /etc/ssh/sshd_config, і багато його параметри збігаються з аналогічними в ssh_config, але тут немає визначень хостів, як це було в ssh_config. Я все-таки наведу приклад sshd_config, щоб далі не виникало питань:

# Номер порту і версія протоколу
Port 22
Protocol 2

# Адреси, на яких слухає сервер, можна також вказувати
# порт (server.test.ua:2022), але призначення ssh нестандартного порту
# недоцільно, оскільки зацікавить потенційних зломщиків(«А чого це там
# вони ховають?»)
ListenAddress server.test.ru

# Ключ сервера протоколу версії 1
HostKey /etc/ssh/ssh_host_key
# Ключі rsa і dsa для ssh версії 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key

# Дані значення визначають довжину ключа сервера і його час життя для
# використання ssh версії 1(цей ключ буде заново генеруватися через
# заданий час)
#KeyRegenerationInterval 3600
#ServerKeyBits 768

# Далі визначаємо методи аутентифікації для даного сервера та її параметри

# Сервер від’єднується за подію даного часу в секундах, якщо клієнт
# не проходить аутентифікацію
LoginGraceTime 600
# Дозволяємо заходити по ssh руту. Довгий час ця тема обговорювалася на форумі,
# але я думаю все ж, що з внутрішньої мережі рут може заходити і по ssh (для
# цього треба налаштувати належним чином iptables). Також можна заборонити руту
# входити за паролем: without-password, дозволяючи вхід тільки по публічного ключа
PermitRootLogin yes
# Перевірка sshd прав доступу і власників домашніх каталогів. Корисно для тих
# користувачів, що дають право всьому 0777. Хоча таких бовдурів краще тримати на
# відстані від сервера(найкраще це робити колодою, підвішеним у серверній
# до стелі, щоб надати нежеланному гостю належне прискорення, і не забудьте
# оббити кінець колоди якоюсь залізякою, інакше колоди доведеться міняти
# занадто часто 😉
StrictModes yes

# Аутентифікація через RSA (версія 1)
RSAAuthentication yes
# Аутентифікація користувача за ключем (версія 2)
PubkeyAuthentication yes
# Визначає публічний ключ користувача для аутентифікації по ключу. Можна
# застосовувати шаблони: %u — ім’я користувача, %h — домашній каталог користувача.
AuthorizedKeysFile .ssh/authorized_keys

# Не використовуємо аутентифікацію rhosts
RhostsAuthentication no
# Можна також ігнорувати rhosts і shosts при hostbased autentification,
# використовуючи тільки known_hosts файл.
#IgnoreRhosts yes
# Використовуємо чи аутентифікацію через known_hosts спільно с .rhosts або
# .shosts. Опція дійсна тільки для протоколу версії 1.
RhostsRSAAuthentication no
# Те ж саме, що і попереднє тільки для версії 2
HostbasedAuthentication yes
# Якщо немає довіри до known_hosts, то їх можна не використовувати при hostbased
# autentification. За замовчуванням no
IgnoreUserKnownHosts no

# Щоб заборонити посилку хешів паролів через тунель ssh задайте значення
# даної опції no. За замовчуванням аутентифікація по паролю дозволено
PasswordAuthentication yes
# Можна також дозволити порожні паролі, але це повний відстій, т. к. це величезна
# діра на сервері, через яку можна наробити багато гидот! Тому має
# no бути (за замовчуванням)
PermitEmptyPasswords no

# Аутентифікація через механізм PAM.
PAMAuthenticationViaKbdInt no

# Передача протоколу іксів через тунель ssh
X11Forwarding yes
# Використовуємо в якості x-сервера, тобто клієнт, запускаючи в себе x-клієнта
# фактично використовувати наш сервер, але всі дані від сервера до клієнта
# будуть шифруватися, що є добре!
X11UseLocalhost yes
# При логін користувача виводимо /etc/motd: в деяких системах це скасовано
# цілях безпеки
PrintMotd yes
# Повідомляємо користувачеві час і місце останнього логіна, ситуація, аналогічна
# попередньої
PrintLastLog yes
# Посилати клієнту повідомлення про доступність
KeepAlive yes
# Максимальне число можливих з’єднань, де не відбулося аутентифікації. Якщо
# клієнтів, які не пройшли аутентифікацію більше, то нові сполуки не будуть
# оброблятися
MaxStartups 10
# Шлях до файлу, який буде відображатися при вході клієнта ДО аутентифікації
Banner /etc/ssh_message
# Перевірка відповідності ip адреси клієнта і його символічного імені в backzone,
# потім знову порівняння імені з ip-адресою. Таким чином (збоченим)
# перевіряється справжність ip, але метод цей досить гальмівний і за замовчуванням
# вимкнено
VerifyReverseMapping no

# Нові системи, що працюють через ssh. В даному прикладі визначається
# «безпечний» ftp сервер — sftp, аналогічний доступ користувача, але з
# можливістю передачі файлів(тобто користувач отримує доступ до всіх своїм
# файлів і немає можливості налаштування дозволів і віртуальних користувачів,
# як, наприклад в proftpd). По суті справи підсистеми ssh можуть забезпечувати
# проходження інших протоколів по мережі, але під «крильцем» ssh. Наприклад, для
# sftp сервера є однойменний sftp клієнт. Його інтерфейс повністю ідентичний
# оригінальному ftp, але з однією відмінністю: відбувається та ж сама аутентифікація
# користувача на віддаленому сервері(методами ssh), але замість оболонки з
# користувачем взаємодіє підсистема, у даному випадку sftp.
Subsystem sftp /usr/lib/ssh/sftp-сервер

Ну от, начебто все налаштовано! Тепер я б хотів поговорити про деякі фичах, що працюють в ssh. Для початку я б хотів розповісти про тунелях. SSH має вбудовану можливість передавати дані з локального порту на віддалений, використовуючи мережевий тунель, причому дані, що передаються через цей тунель будуть шифруватися. Тобто відбувається аутентифікація на віддаленій системі, а потім починається перенаправлення трафіку через тунель. Таким чином, можна передавати будь-який трафік, а протокол іксів може працювати в інтерактивному режимі, для цього необхідно включити відповідні опції у файлах конфігурації сервера і клієнта(це було описано раніше). Для інших портів необхідно викликати ssh з параметром L{LOCAL_PORT}:{LOCAL_ADDRESS}:{REMOTE_PORT}:
# ssh -L10101:localhost:101 server.test.ru

Такий тунель досить швидко вмирає, т. к. сервер автоматично вбиває «ледачих» клієнтів. Тому можна застосувати метод, який дозволяє встановлювати довільний час утримання тунелю: виконати sleep на віддаленому сервері:
# ssh -f -L10101:loclahost:101 server.test.ru sleep 100

Дана команда тримає тунель 100 секунд, чого достатньо для будь-якого з’єднання. І ще одна річ: коли по тунелю передаються дані, то він не знищується, що добре для реалізації безпечного ftp, smtp і pop3-протоколів (втім, sftp-сервер є вже і в постачанні openssh, застосування його не повинно викликати труднощів sftp [[email protected]]hostname, т. к. фактично це особлива реалізація ssh протоколу і механізм роботи sftp абсолютно ідентичний механізму ssh). Щоб вимкнути перенаправлення портів, необхідно встановити опцію sshd AllowTcpForwarding в no. Використання тривалої затримки ssh-тунель кілька зменшує безпеку, оскільки під час очікування зловмисник має більше шансів на атаку (але механізм ssh версії 2 дозволяє уникнути подібної ситуації підписування повідомлень).

От що зробив би я для безпечного ssh. Для початку створив би rsa-ключ довжиною 4096 біт:
# ssh-keygen -t rsa -b 4096

Потім скопіював б цей ключ з допомогою дискети або ssh-copy-id на віддалений сервер(а):
# ssh-copy-id -i $HOME/.ssh/id_rsa remote_host

Після цього заборонив би парольну і всяку hostbased аутентифікацію в sshd_config:
IgnoreHosts yes
RhostsAuthentication no
RhostsRSAAuthentication no
RSAAuthentication yes
HostbasedAutentification no
PasswordAuthentication no
PermitEmptyPasswords no
UseLogin no
PermitRootLogin without-password

І відключимо потокол версії 1 (за замовчуванням Protocol 2,1 і сервер падає до ssh 1, при невдачі ssh 2):
Protocol 2

Ну, ось, тепер, щоб зайти на сервак по ssh треба ввести некволий (а він повинен бути добрячий!) пароль секретного ключа. Трошки незручно, чи не правда? Можна зберігати пароль секретного ключа в пам’яті протягом роботи певної програми (наприклад, bash) і при запиті його клієнтом ssh діставати з пам’яті. Для цієї мети служить програма ssh-agent (агент автентифікації ssh). Агент запускає необхідну програму і чекає додавання нових секретних ключів (ssh-agent зберігає розшифровані таємні ключі). Для цієї мети є інша програма ssh-add, яке додає в агент ключі $HOME/.ssh/id_rsa, id_dsa, identity. Якщо необхідно додати інші ключі, то треба запустити ssh-add з ім’ям файлу: ssh-add filename. Врахуйте, що при додаванні ключа агент ssh-add вам все одно необхідно ввести пароль для його розшифровки, але поки агент знаходиться в пам’яті (поки викликана ним програма не завершилася), вводити пароль секретного ключа не треба: ключ береться з ssh-agent. Причому контакт з ssh-agent може встановлювати тільки програма, запущена їм (і всі її дочірні процеси), т. к. встановлюються змінні оточення. Звичайний метод запуску ssh-agent:
# ssh-agent bash
# ssh-add
Enter passphrase for ‘.ssh/id_rsa’:
Enter passphrase for ‘.ssh/id_dsa’:
.ssh/identity: No such file or directory

Після завершення роботи оболонки ssh-agent завершується, а ключі видаляються з пам’яті.

Ну, і нарешті можна дозволити доступ для визначених користувачів до певних машин. Це робиться полем AllowUsers в sshd_config або правил iptables. Думаю, цього достатньо для нормальної і безпечної роботи на віддаленому сервері через ssh. Особливо недовірливі можуть заборонити доступ рута по ssh (PermitRootLogin no) та делегувати частину його прав з допомогою sudo. Ну, і використовувати протокол версії 2 (такі плюси, як алгоритм обчислення симетричного ключа на підставі пари асиметричних, і підписування повідомлень, переданих по мережі, а також 2 версія протоколу ssh швидше першою). Існує безліч клієнтів ssh, що працюють на різних ОС:

Windows:
putty (IMHO кращий віндовий клієнт): www.chiark.greenend.org.uk/~sgtatham/putty.html
raju: ftp://ftp.franken.de/pub/win32/develop/gnuwin32/cygwin32/porters/mathur_raju
cigaly: www.doc.ic.ac.uk/~ci2/ssh/
f-secure: www.datafellows.com/f-secure/fclintp.htm
secure crt: www.vandyke.com/products/securecrt/
ttssh: www.zip.com.au/~roca/ttssh.html
therapy: guardian.htu.tuwien.ac.at/therapy/ssh/
chaffee: bmrc.berkeley.edu/people/chaffee/winntutil.html
sergey okhapkin: www.lexa.ru/sos/
fissh: www.massconfusion.com/ssh/
Mac:
niftytelnet+ssh: www.lysator.liu.se/~jonasw/freeware.html
f-secure: www.datafellows.com/f-secure/fclintp.htm