Faq по OpenSSH в російській редакції

Українська редакція: Андрій Лаврентьєв ( [email protected] ) Date: 2001/05/30

1.0 - Що таке OpenSSH і Де Я можу його взяти?

2.0 - Основні Питання.

3.0 - Питання пов'язані з Портабельная версіями OpenSSH.

OpenSSH це ВІЛЬНА версія відомого набору мережевого інструментарію SSH, кількість шанувальників і користувачів якого в Internet істотно зросла і продовжує зростати. Більшість користувачів таких програм як telnet, rlogin, ftp, та інших подібних програм не знають або усвідомлюють що ці програми передають по мережі призначені для користувача паролі в нешифрованому вигляді на відміну від OpenSSH. OpenSSH шифрує весь переданий трафік (включаючи паролі) і ефективно запобігає підслуховування, похіщеніе.перехват з'єднань та інші види мережевих атак.

Пакет OpenSSH включає в себе ssh (1) програму для заміни таких засобів як rlogin і telnet, програму scp (1) яка замінює такі кошти як rcp (1) і ftp (1) . Нещодавно в OpenSSH були реалізовані і додані sftp (1) і sftp-server (8) які реалізують просту передачу файлів.

OpenSSH consists of a number of programs.

• sshd (8) - Серверна програма для запуску на серверній машині. Ця програма слухає мережеві запити від віддалених - клієнтських машин, і при отриманні запиту на з'єднання проводить необхідні дії, авторизацію віддаленого клієнта і в разі її проходження запускає необхідну службу для віддаленого клієнта.
• ssh (1) - Це клієнтська програма, яка використовується для входу на іншу машину мережі або виконання команд на віддаленому комп'ютері. slogin це інше ім'я цієї ж програми.
• scp (1) - Безпечне копіювання файлів з однієї машини на іншу.
• ssh-keygen (1) - Використовується для створення Публічних авторизаційної ключів (RSA or DSA) як для хостів (комп'ютерів), так і для користувача.
• ssh-agent (1) - Авторизаційний Агент, який використовується для зберігання особистих RSA ключів в пам'яті, для подальшої авторизації з використанням публічних ключів.
• ssh-add (1) - Використовується для додавання нових особистих ключів авторизаційному агенту ssh-agent.
• sftp-server (8) - Підсистема SFTP сервер.
• sftp (1) - програма безпечної передачі файлів.
• ssh-keyscan (1) - програма для збору ssh публічних ключів в мережі.

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

• Сувора авторизація. Виправлено велику кількість дірок в безпеці. (Наприклад IP, routing, і DNS spoofing).
• Посилено безпеку. Всі з'єднання автоматично і прозоро шифруються.
• Безпечна робота X11 сесій. Програми автоматично встановлюють змінну DISPLAY на віддаленому сервері, і перенаправляють будь-які з'єднання X11 за захищеними шифрованих каналах.
• Довільні TCP / IP порти можуть бути перенаправлені через шифровані канали в обох напрямках (наприклад, для e-cash транзакцій).
• Немає необхідності перепідготовки звичайних користувачів.
• Ніколи не довіряти мережі. Мінімальна довіру з'єднанню з віддаленої сторони. Мінімальна довіру серверів доменних імен. Чистий RSA авторизація не довіряє нічому крім особистих ключів.
• Клієнт авторизує сервер по RSA на початку кожного з'єднання для захисту від трянскіх коней (routing або DNS spoofing) і man-in-the-middle атак, і сервер в свою чергу авторизує по RSA клієнта, до прийняття авторизації через .rhosts або / etc / hosts.equiv щоб в свою чергу захистити себе від атак (DNS, routing, або IP-spoofing).
• Поширення публічних ключів хостів може проводитися централізовано адміністраторами мережі або автоматично при встановленні з цим хостом першого з'єднання.
• Будь-який користувач може створити будь-яку необхідну для своїх потреб кількість авторизаційних ключів RSA.
• Програма сервер має свій власний RSA ключ сервера який автоматично змінюється, за замовчуванням кожну годину.
• На додаток можна використовувати авторизаційний агент щоб зберігати в пам'яті RSA авторизовані ключі користувача лаптопа, нотбука або робочої станції.
• OpenSSH може бути встановлений і використаний (з деякими обмеженнями) навіть без привілеїв суперюзера root.
• Конфігурація клієнтська частина може бути змінена як у відповідних системних конфігураційних файлах, так і в конфігураційних файлах самих користувачів.
• У разі якщо на віддаленому сервері не використовується або не працює серверна програма sshd, клієнт автоматично спробує перейти на роботу через rsh якщо він підтримується сервером і при цьому буде видано відповідне повідомлення.
• При роботі може бути використана компресія всіх даних за допомогою використання gzip (включаючи форвардірованіе з'єднань X11 і перенаправлення TCP / IP портів), причому компресія може значно підвищити швидкість роботи, особливо на повільних з'єднаннях / каналах.
• Повна заміна засобів rlogin, rsh, і rcp.

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

Коли ви здійснює візит на віддалений комп'ютер в мережі, ваш пароль передається в мережі відкритим текстом. Тому будь-який підслуховує ваш login і пароль в мережі, зможе ним скористатися щоб зробити будь-яку мерзенність яку він побажає. Більшість подібних инцендентов спостерігалося на тих комп'ютерах в мережі, які залишилися без компетентного адміністрування і на них були встановлені програми прослуховування мережі і збору паролів. Подібні програми вільно доступні в мережі Internet або можуть бути написані компетентним програмістом за кілька годин.

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

Багато компаній не уявляють що інформація так легко може бути залучена при наявності доступу в мережу. Вони вважають що їх дані в безпеці бо нікому не відомо що інформація в мережі може бути підслухана або тому що кількість переданих в мережі даних занадто велике. Це не безпечна політика.

Незважаючи на те що OpenSSH розроблений в рамках проекту OpenBSD проте існує маса його портів для інших операційних систем. Проект портирования версій OpenSSH очолює Damien Miller . Для швидкого огляду портірованних версій OpenSSH дивіться: http://www.openssh.com/portable.html . Короткий список інших OS's які підтримують OpenSSH, наведено нижче.

• OpenBSD
• NetBSD
• FreeBSD
• AIX
• HP-UX
• IRIX
• Linux
• NeXT
• SCO
• SNI / Reliant Unix
• Solaris
• Digital Unix / Tru64 / OSF
• MacOS X

Список виробників які включають OpenSSH в свої дистрибутиви можна знайти на сторінці www.openssh.com/users.html .

Розробники OpenSSH доклали багато праці і зусиль щоб зберегти цей проект вільним від будь-яких патентів або проблем з copyright. Щоб реалізувати це довелося накласти обмеження для деяких опцій, а саме, для запатентованих алгоритмів.

OpenSSH не підтримує запатентовані транспортні алгоритми. У режимі роботи SSH1, підтримуються опції для 3DES і Blowfish. У режимі роботи SSH2, можна використовувати лише алгоритми 3DES, Blowfish, CAST128, Arcfour і AES. Запатентований алгоритм IDEA не підтримується.

OpenSSH забезпечує підтримку обох протоколів і SSH1, і SSH2.

З тих пір як минув час обмеження на використання патенту RSA, більше не існує обмежень на використання алгоритму RSA в програмних продуктах, включаючи OpenBSD.

Існує маса місць в Internet де можна отримати допомогу або консультації, на додаток до основного вебсайту OpenSSH: http://www.openssh.com , Існує багато списків розсилки, можете скористатися ними. Однак перед тим як поставити запитання в ці списки, попередньо поіщіті необхідну вам інформацію через пошук по архівах цих списків розсилки, щоб не повторювати питання на які вже відомий і була дана відповідь. Один зі списків і архів можна знайти за посиланням: theaimsgroup.com .

Більш детальну інформацію по підписці на OpenSSH і пов'язані з ним списки розсилок можна знайти на сторінці: www.openssh.com/list.html .

Клієнт OpenSSH використовує номера портів з нижньої частини, ті ssh_config або ~ / .ssh / config файли.

Або ви можете скористатися зазначеним вище сервісом через командний рядок, використовуючи -o опцію ssh (1) команди.

$ Ssh -o "UsePrivilegedPort no" host.com

В продовження попереднього питання, ( 2.1 ) OpenSSH повинен іметьroot привілеї щоб відкрити нижні порти

У SSH версій 2.3 і молодше є недолік в реалізціі HMAC. Замість того, щоб посилати повний блок даних дайджесту, код цих версій завжди обмежується 128 бітами. При використанні більш довгих дайджестів SSH 2.3 несумісний з OpenSSH.

OpenSSH 2.2.0 розпізнає цей дефект SSH 2.3. Ця помилка буде виправлена ​​в нових версіях SSH. Уникнути цю ситуацію в SSH 2.3 допоможе додавання рядка в / etc / sshd2_config такого вигляду:

Крім дефектної (кривої) реалізації HMAC, була помічена наступна проблема: OpenSSH не підтримує функцію рекеінга (rekeying). SSH 2.3 намагається істользовать цю функціональність. В результаті ви можете отримати зависла сесію або повідомлення про помилку "Dispatch protocol error: type 20". Для вирішення цієї проблеми або використовуйте SSH версії 2.4 і вище, або додайте наступний рядок в файл конфігурації SSH версії 2.3 sshd_config для відключення рекеінга:

Більш ранні версії SSH використовували патентований алгоритм для шифрування своїх / etc / ssh / ssh_host_key. Ця проблема ясно показує що sshd (8) не зможе прочитати власні ключі. Для вирішення цієї проблеми скористайтеся нижче наведеної командою для перетворення вашого ssh_host_key з використанням методу 3DES. Примітка: Скористайтеся ssh-keygen (1) програмою від Комерційної версії продукту SSH першої версії, * НЕ * від OpenSSH, приклад наведено нижче.

# Ssh-keygen -u -f / etc / ssh / ssh_host_key

програма ssh-keygen (1) з комерційного пакету SSH містила помилки при генерації Публічних ключів (RSA або DSA) в яких був відсутній Most Significant Bit (MSB). Такі ключі представлялися як повноцінні, в той час як це насправді було не так, ті їх довжина була меншою на один біт.

OpenSSH в таких випадках буде видавати попередження, якщо зустріне такі ключі. Щоб позбутися від подібних повідомлень, відредагуйте ваш файл known_hosts і замініть ключі з некоректним розміром (зазвичай "1 024") на їх реальну довжину (зазвичай "1023"). Слід зауважити, що ці ключі менш безпечні і тому краще замінити їх створивши нові.

Перевірте ваші файли ssh_config і sshd_config. За замовчуванням, в конфігураційних файлах заборонена авторизація та форвардірованіе з'єднань X11. Щоб активувати цих можливостей, помістіть зазначену нижче рядок в конфігураційний файл сервера sshd_config:

і наступні рядки в конфігураційний файл клієнта ssh_config:

Примітка: Для користувачів системи Linux Mandrake 7.2, Mandrake змінює значення змінної середовища XAUTHORITY в файлі /etc/skel/.bashrc, і можливо в стартових файлах домашньої директорії користувачів у Кото як SHELL встановлений BASH. Оскільки цю змінну встановлює OpenSSH, закоментуйте рядок в /etc/skel/.bashrc як показано нижче і в інших подібних настройках теж:

# Export XAUTHORITY = $ HOME / .Xauthority

Від версії до версії в конфігураційних файлах OpenSSH sshd_config або ssh_config відбуваються зміни. Будьте уважні і після заміни старої версії на нову завжди перевіряйте які зміни були внесені в конфігурацію нової версії. Наприклад, при переході з версії OpenSSH 2.3.0 до 2.5.1 вам необхідно додати наступний рядок в файл sshd_config

HostKey / etc / ssh_host_dsa_key

sftp і / або scp можуть розривати з'єднання в тому випадку якщо ваші настройки SHELL (.profile, .bashrc, .chsrc, etc) такі, що після ініціалізації середовища відбувається спроба зробити висновок в НЕ інтерактивних сесіях. Цей висновок збиває роботу sftp / scp клієнта і призводить до збою. Перевірити настройки власного shell'а можна виконавши команду:

ssh yourhost / usr / bin / true

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

Портований версії OpenSSH можуть виробляти паразитні повідомлення в лог-файли при кожному вході, подібно до наведеного нижче:

Ці повідомлення видаються бо OpenSSH спершу намагається визначити який метод авторизації використовує користувач при вході (наприклад empty password). На жаль PAM реєструє будь-які спроби авторизації, включаючи зазначені і записує їх в логи.

Якщо це дратує або заважає вам, встановіть "PermitEmptyPasswords no" в sshd_config. Це захистить вас від подібних повідомлень і заборонить вхід по беспарольному акаунтів. Ця опція використовується за умовчанням в разі конфігураційного файлу sshd_config з поставки OpenSSH.

Щоб дозволити використовувати порожні паролі в OpenSSH, зібраним з підтримкою PAM вам необхідно додати прапор nullok в рядку відповідного модуля перевірки пароля в файлі конфігурації PAM /etc/pam.d/sshd. наприклад:

auth required / lib / security / pam_unix.so shadow nodelay nullok

Це необхідно зробити доповнення до установок "PermitEmptyPasswords yes" в sshd_config файлі.

Існує одне важливе зауваження щодо використання порожніх паролів з PAM авторизацією: PAM буде дозволяти ставити будь-які паролі при авторизації через вхід з порожнім паролем. І це порушує перевірку яку sshd (8) використовує для визначення що даний аккаунт без пароля і гарантованого доступу користувачеві незважаючи на значення вказане в PermitEmptyPasswords. Ось чому в цілях безпеки не рекомендується додавати директиву nullok вашу конфігурацію PAM до тих пір поки у вас не залишилося іншого варіанту як дозволити роботу з порожніми паролями.

Версія бібліотеки glibc поставляється з Redhat 6.1 дійсно займає багато часу для вирішення "IPv6 або IPv4" адрес з доменних імен. Цю проблему можна обійти використовую опцію configure --with-ipv4-default при автоконфігурації OpenSSH перед компіляцією. У той разі OpenSSH буде використовувати тільки IPv4 схему дозволу адрес. (IPv6 метод може бути заданий зазначенням опції -6).

Ядро Linux намагається знайти (через modprobe) і довантажити протокол сімейства 10 (IPv6). Або вручну довантажити в ядро відповідний модуль, або задайте правильний алиас в файлі підвантажуваних модулів /etc/modules.conf або вимкніть підтримку IPv6 в /etc/modules.conf.

Іноді з метою дурень-стійкості файл /etc/modules.conf в Linux може мати ім'я /etc/conf.modules.

В Slackware 7.0, OpenSSH необхідно збирати з крипто-бібліотекою libcrypt.

LIBS = -lcrypt ./configure [options]

Переконайтеся в тому що ваші бібліотеки OpenSSL були зібрані з внутрішньою підтримкою RSA або DSA або через RSAref. Реалізація RSA і DSA включені в OpenSSL і їх використання в OpenSSH залежить від того як були зібрані бібліотеки OpenSSL які використовує OpenSSH.

програма scp (1) повинна знаходиться в директорії яка знаходиться в дорозі / PATH як у клієнта, так і сервера. Якщо ви хочете розмістити цю програму в спеціальній директорії, вам необхідно поставити її в опції --with-default-path в відпо із заданим вами маршрутом програма розшукуватиметься в цьому шляху на сервері. Ця опція замінює пошук в дорозі за замовчуванням, тому вам необхідно вказати всі необхідні директорії для пошуку в дорозі, включаючи ту де знаходиться програма scp. наприклад:

$ ./Configure --with-default-path = / bin: / usr / bin: / usr / local / bin: / path / to / scp Або просто вкажіть всі необхідні директорії в змінній оточення PATH в налаштуваннях ініціалізації вашого SHELL, включаючи директорію де знаходиться scp.

У деяких операційних системах пристрій / dev / tty має некоректно встановлені права, в результаті чого неможливо прочитати пароль зі свого пристрою, про що і видається помилка:

You have no controlling tty. Can not read passphrase.

Для вирішення цієї проблеми встановіть для пристрою / dev / tty права 0666 і повідомте про цю помилку продавцеві вашої OS.

Якщо у вашому дистрибутиві відсутній файл 'configure' або процес складання `make` завершився з повідомленнями про помилки виду" missing separator ", ймовірно ви завантажили або скачали версію OpenSSH для дистрибутива OpenBSD, а намагаєтеся відкомпілювати на іншій платформі. Будь ласка прочитайте інформацію про портірованних версіях на сторінці portable version візьміть необхідний вам дистрибутив OpenSSH відповідно з посиланнями для вашої OS.

Поточна версія OpenSSH може подвисать при виході. Це зустрічається коли ще залишилися активні фонові процеси. Таке зазвичай зустрічається в системах Linux і HP-UX. Наявність цієї проблеми можна перевірити в такий спосіб: sleep 20 & exit.

Користувачі у яких в якості shell'а встановлений bash, для вирішення цієї проблеми можуть помістити "shopt -s huponexit" в файл / etc / bashrc або в файл ~ / .bashrc. В інших випадках, читайте керівництва по вашому SHELL як вирішити послати сигнал HUP активним процесам при виході.

$ OpenBSD: faq.html, v 1.37 2001/05/22 8:03:24 kevlo Exp $
Українська редакція: Андрій Лаврентьєв ( [email protected] ) Date: 2001/05/30

Спонсори:

Хостинг: