Підключення до віртуального сервера за SSH та SFTP. Підключення до сервера з SSH і SFTP Підключення до ssh через putty
Що таке і для чого потрібний SSH
Безпечний шелл (SSH) - це мережевий протокол, що забезпечує функції шелла на віддаленій машині через безпечний канал. SSH несе в собі різні покращення безпеки, серед них автентифікація користувача/хоста, шифрування даних та цілісність даних, завдяки чому неможливі популярні атаки на кшталт підслуховування (eavesdropping), DNS/IP spoofing, підробка даних (data forgery), перехоплення з'єднання (connection hijacking) і т. д. Користувачам ftp, telnet або rlogin, які використовують протокол, що передає дані у вигляді відкритого тексту, рекомендується переключитися на SSH.
OpenSSH – це реалізація з відкритим вихідним кодомпротокол SSH, що дозволяє шифрувати з'єднання в мережі за допомогою набору програм. Якщо ви хочете мати SSH на Linux, ви можете встановити OpenSSH, який складається з сервера OpenSSH і клієнтських пакетів.
OpenSSH серверні/клієнтські пакети поставляються з такими утилітами:
- OpenSSH сервер: sshd (SSH daemon)
- OpenSSH клієнт: scp (безпечне віддалене копіювання), sftp (безпечна передача файлів), slogin/ssh (безпечний віддалений вхід), ssh-add (додаток закритого ключа), ssh-agent (агент аутентифікації), ssh-keygen (управління ключами аутентифікації) ).
Якщо ви хочете встановити сервер/клієнт OpenSSH і настроїти автоматичний запуск сервера OpenSSH, дотримуйтесь наступних інструкцій, які відрізняються залежно від дистрибутива.
Debian, Ubuntu або Linux Mint
$ sudo apt-get install openssh-server openssh-client
У системах, заснованих на Debian, відразу після встановлення, OpenSSH буде запускатися автоматично під час завантаження. Якщо з будь-яких причин сервер OpenSSH не запускається автоматично під час запуску системи, ви можете виконати наступну команду для однозначного додавання ssh у завантаження під час старту системи.
$ sudo update-rc.d ssh defaults
Fedora або CentOS/RHEL 7$ sudo yum -y install openssh-server openssh-clients $ sudo systemctl start sshd service $ sudo systemctl enable sshd.service
CentOS/RHEL 6$ sudo yum -y install openssh-server openssh-clients $ sudo service sshd start $ sudo chkconfig sshd on
Arch Linux$ sudo pacman -Sy openssh $ sudo systemctl start sshd service $ sudo systemctl enable sshd.service
Налаштування сервера OpenSSHЯкщо ви бажаєте налаштувати сервер OpenSSH, ви можете редагувати загальносистемний файл конфігурації, розміщений в /etc/ssh/sshd_config.
Є кілька опцій OpenSSH, які можуть зацікавити:
За замовчуванням sshd прослуховує порт 22 і очікує вхідні з'єднання ssh. Змінивши порт за замовчуванням для ssh, ви можете запобігти різним автоматизованим атакам хакерів.
Якщо ваша машина має більш ніж один фізичний мережевий інтерфейс, можливо, ви заходите уточнити, який з них пов'язаний з sshd, для цього ви можете використовувати опцію ListenAddress. Ця опція допомагає покращити безпеку за допомогою обмеження вхідних SSH лише через особливий інтерфейс.
HostKey /etc/ssh/ssh_host_key
Оція HostKey визначає, де розміщений персональний хост ключ.
PermitRootLogin no
PermitRootLogin – чи може root входити в систему за допомогою ssh.
AllowUsers alice bob
Використовуючи опцію AllowUsers, можна вибірково відключити службу ssh для певних користувачів Linux. Можна встановити безліч користувачів, розділяючи їх пробілами.
Після зміни /etc/ssh/sshd_config , переконайтеся, що перезапустили службу ssh.
Для перезапуску OpenSSH на Debian, Ubuntu або Linux Mint:
$ sudo /etc/init.d/ssh restart
Для перезапуску OpenSSH на Fedora, CentOS/RHEL 7 або Arch Linux:$ sudo systemctl restart sshd.service
Для перезапуску OpenSSH на CentOS/RHEL 6:$ sudo service sshd restart
Як підключитися до SSHПідключення до SSH з Linux
Користувачам Linux не потрібно встановлювати додаткові програми.
Підключення до SSH із Windows
Приховано від гостей
.Cygwin це не просто клієнт SSH. Це потужний комбайн, в якому підтримується багато команд Linux. Наприклад, у Cygwin дуже легко створювати SSL-сертифікати (так само, як і в Linux). У Windows для створення самопідписаних сертифікатів потрібно потанцювати з бубном. Cygwin дуже зручно користуватися cURL (не потрібно нічого встановлювати окремо) і т. д. Ті, кому не вистачає на Windows командного рядката програм Linux, в особі Cygwin знайдуть собі віддушину.
Установка Cygwin проста. Переходимо на
Приховано від гостей
І скачуємо
Приховано від гостей
Приховано від гостей
Скачається крихітний файл – це установник. Установник графічний. Хоча він і містить велику кількість опцій, всі вони досить прості і багато хто знайомий з інших графічних установників. Якщо щось незрозуміло, просто натискайте "Далі". Мабуть, тільки наступне вікно може збентежити:
Тут представлені всі доступні для встановлення елементи. Нам не потрібно прямо зараз розбиратися в них. Оскільки найзатребуваніші вже позначені для встановлення. А якщо чогось у майбутньому не вистачатиме, то легко можна доустановити потрібне.
З'єднання SSH (загальне для Linux та Windows)
Користувачі Linux відкривають консоль, користувачі Windows друкують у Cygwin.
SSH потрібна наступна інформація для підключення:
- IP або ім'я хоста
- номер порту
- Ім'я користувача
- пароль користувача
Ssh 192.168.1.36
Я бачу наступне
Alex@MiAl-PC ~ $ ssh 192.168.1.36 Автентифікація host "192.168.1.36 (192.168.1.36)" може бути встановлений. e you sure you want to continue connecting ( yes/no)?
Оскільки я підключаюся до хоста вперше, це незнайомий хост. У мене запитують, чи я хочу продовжити. Я набираю yes:
Warning: Permanently added "192.168.1.36" (ECDSA) to the list of known hosts. [email protected]"s password:
Добре, хост 192.168.1.36 додано до списку знайомих хостів. У мене запитується пароль для користувача Alex. Оскільки на сервері з SSH немає такого користувача, але я натискаю Ctrl+C(Для розриву) і вводжу команду разом з ім'ям користувача віддаленої системи. Користувач вводиться перед адресою віддаленої машини та відокремлюється від адреси символом @. Символ @ англійською читається як і можна перекласти як «в». Тобто. запис [email protected]можна витлумачити як "користувач mial в машині 192.168.1.36".
Запрошення Alex@MiAl-PC змінилося запрошенням mial@mint. Це означає, що ми вже на віддаленій машині, тобто у нас відбулося з'єднання. Якщо потрібно вказати порт (якщо він відрізняється від стандартного), порт потрібно вказувати після ключа -p. Наприклад так:
Ssh [email protected]-p 10456
Після підключення нас зустрічає приблизно таке привітання:
Linux mint 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1 (2015-05-24) x86_64 Програми включають в себе Debian GNU/Linux system є free software; Розширені терміни розповсюдження для кожного програмного забезпечення будуть описані в окремих файлах в /usr/share/doc/*/copyright. Debian GNU/Linux використовується з ABSOLUTELY NO WARRANTY, до виключеного розміру застосовуваного права. Last login: Tue Jun 16 15:32:25 2015 від 192.168.1.35
З нього випливає, що віддалена машина – це Linux Mint, з ядром 3.16, 64-бітна версія. Також важлива інформаціяпро час останнього входу та IP адресу з якого відбулося з'єднання. Якщо час та IP вам незнайомі, а ви є єдиним користувачем, то ваша система скомпрометована і потрібно вживати відповідних заходів.
Наберемо кілька команд, щоб переконатися, де ми і хто ми: pwd, [B]uname -aі т.д.:
Щоб закінчити сесію (вимкнутись), наберіть
Або натисніть Ctrl+D.
Вхід до SSH без введення пароля
По-перше, це просто зручніше. По-друге, це безпечніше.
По-перше, нам потрібно створити rsa ключі. Якщо ви користувач Linux, то у вас все гаразд. Якщо ви є користувачем Windows, але ви не послухали мою пораду і вибрали PuTTY, то у вас проблема і думайте самі, як її вирішувати. Якщо у вас Cygwin, то все гаразд.
Якщо ви встигли залогінитись на віддаленій системі, розлогіться. Після цього наберіть
Ssh-keygen -t rsa
У нас запитують ім'я файлу, не потрібно нічого вводити, буде використано стандартне ім'я. Також запитується пароль. Я пароль не вводжу.
Тепер на дистанційній машині нам потрібно створити каталог.ssh. Про виконання команди на віддаленій машині ще буде розказано нижче. Поки що просто копіюєте команду, не забуваючи поміняти IP адресу та ім'я користувача на свої:
Ssh [email protected] mkdir .ssh
Тепер нам потрібно скопіювати вміст файлу id_rsa.pub на віддалену машину. Зробити це дуже просто (не забуваємо міняти дані на свої):
Cat .ssh/id_rsa.pub | ssh [email protected]"cat >> .ssh/authorized_keys"
Тепер просто логінімся і більше жодного пароля у нас не запитують. І так тепер завжди буде.
Виконання команд на віддаленому сервері без створення сесії Шелла
Крім відкриття сесії шелла на віддаленій системі, ssh також дозволяє виконувати окремі команди на віддаленій системі. Наприклад, для виконання команди tree на віддаленому хості з ім'ям remote-sys та відображенням результатів на локальній системі, потрібно зробити так:
Ssh remote-sys tree
Мій реальний приклад:
Ssh [email protected] tree
Використовуючи цю техніку, можна робити цікаві речі, такі як виконання команди ls на віддаленій системі і перенаправлення виведення в файл на локальній системі:
Ssh remote-sys "ls *" > dirlist.txt
Реальний приклад:
Ssh [email protected]"ls *" > dirlist.txt cat dirlist.txt
Зверніть увагу на одиночні лапки у вищенаведеній команді. Це зроблено тому, що ми не хочемо, щоб розкриття шляху було виконано на локальній машині; оскільки нам потрібне це виконання на віддаленій системі. Також якщо ми хочемо стандартний висновок перенаправити файл на віддаленій машині, ми можемо помістити оператор редиректу та ім'я файлу всередині одиночних лапок:
Ssh remote-sys "ls*> dirlist.txt"
Передача стандартного виведення з локальної машини на віддалену по sshНе менш цікавий варіант виконання команд наведено трохи вище:
Cat .ssh/id_rsa.pub | ssh [email protected]"cat >> .ssh/authorized_keys"
- Команда cat терміново зчитує та відображає вміст файлу.ssh/id_rsa.pub, розташованого на локальній машині.
- | (труба) передає те, що мало б з'явитися у стандартному висновку, іншій команді.
- Замість команди, яка мала б обробляти рядки, що передаються їй, відбувається з'єднання до віддаленої системи (ssh [email protected]).
- на віддалену системуприходять рядки, для яких передбачено команду cat >> .ssh/authorized_keys . Тобто. вміст стандартного виводу записується в файл.ssh/authorized_keys, що знаходиться на віддаленій машині.
Для наступного фокусу потрібно два комп'ютери із системою Linux. На жаль, навіть Cygwin із цим трюком не справляється. Причому обидва Linux"а повинні бути з графічним інтерфейсом користувача.
Тунелювання з SSH
Серед іншого, що відбувається коли встановлюється з'єднання з віддаленим хостом через SSH, це створення зашифрованого тунелю, який утворюється між локальною та віддаленою системами. Зазвичай цей тунель використовується для того, щоб набрані на локальній машині команди безпечно були передані дистанційній машині, а результат, також безпечно, надісланий назад.
На додаток до цієї базової функції, протокол SSH дозволяє переправляти більшість типів трафіку зашифрованим тунелем, створюючи деякого роду VPN (віртуальну приватну мережу) між локальною та віддаленою системами.
Мабуть, найчастіше використовувана з цих функцій - це можливість транслювати трафік систем X Window. На системі з запущеним X сервером (це машини, які мають графічний інтерфейс користувача) можливо запустити програму X клієнта (графічний додаток) на віддаленій системі і бачити результати її роботи на локальній системі. Зробити це легко. Наприклад, я хочу підключитися до дистанційного хоста remote-sys і на ньому хочу запустити програму xload. При цьому бачити графічне виведення цієї програми я зможу на локальному комп'ютері. Робиться це так:
Ssh-X remote-sys xload
Реальний приклад:
Ssh-X [email protected] gedit
Тобто. SSH запускається із ключем -X. А потім просто запускається програма. Подивіться на скріншот.
Я знаходжусь у Kali Linux. Я успішно логінюся до віддаленого комп'ютера SSH. Після цього я запустив програму gedit. Цієї програми, можливо, навіть немає на Kali Linux, але вона точно є в Linux Mint, до якої я підключився. Результат роботи цієї програми я можу бачити на екрані так, ніби програма запущена локально. Але, повторюся, я хочу, щоб ви це зрозуміли, запущеної програми gedit на локальному комп'ютері немає. Якщо я захочу зберегти результат роботи gedit (або будь-якої іншої програми, відкритої таким чином), то виявиться, що вона працює в оточенні віддаленого комп'ютера, бачить його файлову систему і т.д. .
Про те, як передати зображення з усього робочого столу ви дізнаєтеся в цій статті далі, в секції «Як налаштувати VNC через SSH».
На деяких системах для цього "фокусу" потрібно використовувати опцію "-Y" замість опції "-X".
Копіювання з/на віддалений комп'ютер (scp та sftp)
scp
Пакет OpenSSH також включає дві програми, які використовує зашифрований тунель SSH для копіювання файлів через мережу. Перша програма – scp(«Безпечне копіювання») – використовується частіше, як і схожа з нею програма cp для копіювання файлів. Найбільш помітна різниця в тому, що джерелом файлу може бути віддалений хост після якого слідує двокрапка і розташування файлу. Наприклад, якщо ми хочемо скопіювати документ, названий document.txt з нашої домашньої директорії на віддалену систему remote-sys у поточній робочій директорії на нашій локальній системі, ми можемо зробити так:
Scp remote-sys:document.txt . document.txt 100% 177 0.2KB/s 00:00
Реальний приклад:
# видалимо файл на локальній машині, якщо він є rm dirlist.txt # створимо файл на віддаленій машині ssh [email protected]"ls * > dirlist.txt" # перевіримо його наявність ssh [email protected]"ls -l" # скопіюємо його на локальну машину scp [email protected]: dirlist.txt . # перевіримо його вміст cat dirlist.txt
sftpДля копіювання файлу з B на A, коли залогінені в B:
scp /path/to/file username@a:/path/to/destination
Копіювання файлу з B на A, коли залогінені в A:
scp username@b:/path/to/file /path/to/destination
Друга програма для копіювання файлів через SSH – це sftp. Як випливає з її імені, вона є безпечним замінником ftp програм. sftp працює як і оригінальна ftp програма. Проте замість відправлення чистим текстом вона використовує зашифрований тунель SSH. Важливою перевагою sftp перед ftp є те, що для неї не потрібний запущений сервер FTP на віддаленому хості. Для неї потрібний лише SSH сервер. Це означає, що будь-яка віддалена машина, яка підключена через SSH клієнт може також бути використана як FTP-подібний сервер. Ось приклад сесії:
Alex@MiAl-PC ~ $ sftp [email protected] Connected to 192.168.1.36. sftp> ls dirlist.txt newfile.txt nfile.txt temp Відео Документи Завантаження Зображення Музика Загальнодоступні робочий стіл /mial/temp/TakeMeHome to TakeMeHome sftp> bye
SFTP протокол підтримується багатьма графічними файловими менеджерами, які можна знайти у дистрибутивах Linux. Використовуючи як Nautilus (GNOME), так і Konqueror (KDE), ми можемо вводити URI (посилання), що починаються на sftp:// у рядок переходу і працювати з файлами, розташованими на віддаленій системі із запущеним SSH сервером.
Вітаю! Цікавить питання: як підключитися SSH до домашнього комп'ютера через інтернет. Вдома встановлено FreeSSHd сервер. Я так розумію, треба якось відкрити порт 22 на зовнішньому IP?
Так, часто виникає потреба. Я в тій статті багато про що розповідав, а тут ми говоритимемо виключно про SSH, якщо Alex люб'язно надав нам цю можливість. До того ж, мені самому дуже цікавий SSH, а тут ще й на Windows ... ммм.
Що таке SSH і навіщо він потрібний?
Справа в тому, що SSH - це S ecure SH ell. Протокол для безпечного доступу до оболонки керування. Тому воно надає доступ саме до командного рядка, бо Shell - перекладається як оболонкаі тут у значенні текстова оболонка управління. Але взагалі, цей протокол примітний тим, що він дозволяє пропускати в собі будь-який інший трафік, причому в зашифрованому вигляді. Так, протокол безпечного підключення до файловій системіназивається SFTP і працює поверх SSH. Але може тунелювати абсолютно будь-які інші з'єднання — чи то HTTP, чи навіть RDP. По суті виходить VPN на коліні.
Тут Алекс уже зробив півсправи, він встановив та запустив на домашньому комп'ютері FreeSSHd. Це дозволяє підключитися до Windows через SSH. В даному випадку – «дозволяє» – це сказано дуже сильно. Тому що це рішення працює на Віндовсі абияк. По-перше, вона не має пристойного текстового інтерфейсу — командного рядка, для управління.
Принаймні штатний cmd мало що дозволяє зробити з віддаленою машиною. Є ще Powershell - це вже більш сучасне та потужне рішення. Freesshd дозволяє змінити консоль на PowerShell, але я до неї так і не зміг підключитися. До CMD підключився - але це абсолютно неюзабельно:
По-друге, у випадку з FreeSSHd мені не вдалося підключитися до комп'ютера з Windows навіть по локальній мережі, не кажучи вже про підключення через інтернет. Вірніше, підключитися виходить, але сервіс зависає і вилітає, керувати Windows-хостом таким чином не вийде.
Тому, я припускаю, що Алексу знадобився ssh-сервер на Windows для підключення до файлової системи або використання її як VPN, проксіювання чогось поверх SSH. Хоча я й маю сумнів, що FreeSSHd дозволить це робити. Бо по-третє: він навіть не зберігає налаштувань, при перезапуску сервісу все збивається. Загалом, я сподіваюся, що Алекс розповість нам у коментарях про те, навіщо це йому знадобилося.
Як ще можна запустити SSH на Windows?
Є більш працездатне рішення – Powershelserver. Хоча в ньому також є баги, але воно хоча б не вилітає. Тому я б рекомендував використовувати саме його для підключення SSH до віндових серверів.
По-перше, він стабільно працює без вильотів. І через нього дійсно можна керувати windows через powershell.
Усі налаштування нормально зберігаються. Доступні ті ж функції, що і в FreeSSHd і навіть більше - можна використовувати SCP - це копіювання файлів поверх SSH.
Але найшикіший — це консоль! Вона працює, панове!
Я легко підключився, без жодних танців з додаванням користувачів (це потрібно робити у freesshd). І та найпростіша командана перегляд таблиці маршрутизації чудово відпрацювала та видала потрібну інфу. Фріссш у мене «упав» саме при спробі перегляду netstat -rn
Тут правда видно, що не відображаються російські символи. Так у нас це легко налаштувати, просто виставляю потрібне мені кодування на powershellserver, перезапускаю, перепідключаюсь.
Налаштування кодування у Powershellserver
Тепер у нас є повноцінний SSH і можемо повністю керувати Windows через консоль.
Microsoft створить власне рішення для SSH
До речі, Microsoft ще влітку оголосила про те, що має намір розробити нативнупідтримку SSH для Powershell у нових версіях Windows. Є новини новини на хабрі та на pcweek (і ще). Тому нам тільки залишається чекати з нетерпінням цієї знакової події, оскільки це справді буде проривом для роботи в гетерогенних мережах.
Я не став перевіряти решту функцій — sftp і scp, але чомусь впевнений, що вони теж будуть чудово працювати.
Як відкрити зовні SSH-порт?
Отже, ми підібралися до того потаємного, заради чого взагалі й затіялася ця стаття. Відповіді питання читача.
Перекидання порту на роутері або модемі
Для підключення до комп'ютера ззовні, дійсно потрібно зробити NAT, або, в окремому випадку. Як це зробити залежить від пристрою, який використовується як шлюз. Це може бути ADSL модем або . У більшості випадків докладні інструкції для вашого девайсу легко знайти за запитами типу «прокидання порту модель_пристрою» або «port forwarding модель_пристрою»
Ось так це виглядає на моєму домашньому роутері Zyxel Keenetic Lite:
А ось так це виглядає на ADSL-модемі з функціоналом роутера Linksys WAG200G, який опинився під рукою:
Крім того, у деяких провайдерів це може бути неможливо зробити технічно, оскільки вони не надають "білий".
Перекидання порту на віддалений сервер за допомогою SSH-тунелю
У такому випадку, для підключення SSH може бути доступний єдиний спосіб— з локальної Windows-машини (та сама, до якої хочемо підключитися по SSH) на віддалений сервер. У цьому випадку у вас має бути SSH-доступ до якогось сервера в інтернеті.
Налаштування «зворотного» тунелю SSH
Таке прокидання легко зробити за допомогою простого SSH-клієнта Putty (є і ) Потім можна буде підключитися на цьому самому віддаленому сервері через прокинутий порт.
Ну якщо вам потрібно розшарити SSH-порт вінди у світ, достатньо в налаштуваннях зворотного тунелю як destination вказати не localhost:3322, а ip_server:3322. Зможете підключатися до вінди SSH звідусіль, де є доступ до цього сервера.
Як перевірити чи правильно прокинуто порт?
Дуже просто. Потрібно перевірити, чи він відкритий. У випадку з SSH відкритий портвідповідатиме повідомленням про свою версію. Самий найпростіший спосібперевірки порту – утиліта telnet.
Просто наберіть у командному рядку через пробіл:
telnet домен_або_IP порт
Якщо порт доступний, то ви побачите щось на кшталт такого:
Відповідь SSH якщо порт доступний
Якщо порт з якихось причин недоступний — ви побачите або «connection refused» чи «connection timeout». У першому випадку це буде миттєво, і означає, що порт закритий файрволом.
У другому випадку це буде схоже на «зависання» і може тривати кілька хвилин — телнет-клиент намагатиметься встановити з'єднання. Це може означати блокування файрволлом, але вже іншого типу. Або просто що цей хост недоступний або порт на ньому закритий.
Якщо ви змогли підключитися телнетом, натисніть комбінацію клавіш Ctrl+] і введіть quit,потім Enter. Інакше не вдасться перервати сесію і доведеться відкривати нове вікно консолі, якщо вона вам ще потрібна.
Ця стаття позначена як незакінчена. Див. нотатку в кінці статті.
Ця стаття присвячена клієнту та серверу захищеного терміналу (secure shell) в Ubuntu, їх налаштуванню та використанню. SSH - це спеціальний мережевий протокол, що дозволяє отримувати віддалений доступ до комп'ютера з великим ступенем безпеки з'єднання. Докладніше про протокол ssh можна прочитати.
Опис принципів роботи та використовуваних додатків
В основному, SSH реалізований у вигляді двох додатків - SSH-сервера та SSH-клієнта У Ubuntu використовується вільна реалізація клієнта та сервера SSH-OpenSSH. При підключенні клієнт проходить процедуру авторизації у сервера та між ними встановлюється зашифроване з'єднання. OpenSSH сервер може працювати з протоколом ssh1, і з протоколом ssh2. В даний час протокол ssh1 вважається небезпечним, тому його використання не рекомендується. Я навмисно опускаю різні технічні подробиці роботи протоколу, тому що основною метою цього посібника є опис його налаштування та використання. Про сам протокол, принципи його роботи, алгоритми шифрування тощо існує безліч статей в інтернеті, наприклад докладно про це можна почитати.
Встановлення
Встановити OpenSSHможна з терміналу командою:
sudo apt-get install sshУ метапакеті ssh міститься як клієнт, так і сервер, але при цьому, швидше за все, буде встановлений тільки сервер, тому що клієнт вже є в Ubuntu за замовчуванням.
Налаштування сервера
При установці SSH-Сервер автоматично прописується в автозавантаження. Керувати його запуском, зупинкою або перезапуском можна за допомогою команд:
sudo service ssh stop| start| restartОсновний файл конфігурації SSH-сервера - файл /etc/ssh/sshd_config, доступний для читання або редагування лише суперкористувачу. Після кожної зміни цього файлу необхідно перезапустити ssh-сервер для застосування таких змін.
Приклад конфігурації SSH-сервера в Ubuntu за промовчанням:
# Приклад конфігурації open-ssh сервера з російськими # # коментарями..2010. # # # # # # # Умовні позначення : # # Під "за замовчуванням" - мається на увазі поведінка sshd при # # невказаній явно директиві. Варто зауважити, що в Ubuntu # # файл sshd_config вже містить ряд налаштувань, які # # є налаштуваннями за замовчуванням саме для Ubuntu. # # Такі параметри вказані в цьому файлі. # # # ################################################ ############# ################ Налаштування адрес/портів і т.д. ########### ######################################## ###################### # # ## Port ######################### ############################ # # # # Використовуваний порт. Можна вказувати кілька, наприклад: # # Port 22 # # Port 23 # # Port 24 # # Рекомендується використовувати нестандартний порт, т.к. # # Стандартний часто сканується ботами на предмет # # Потенційних "дірок". Може бути опущений, якщо задано # # через адресу. Див. також параметр ListenAddress. # # # Port 22 # # ## ListenAddress ######################################## ### # # # Мережева адреса, на якій "слухає" сервер. Адреса можна # # записувати так: # # ListenAddress host | IPv4_addr | IPv6_addr # # ListenAddress host | Port. Якщо ви # # використовувати ListenAddress не вказуючи порт, то опція # # Port повинна передувати опції ListenAddress. Якщо не # # вказувати, то за промовчанням слухає на всіх локальних # # адресах. Можна вказати кілька адрес. # # # ## AddressFamily ############################################ # # Вказує, яке сімейство IP адрес має бути # # використане sshd. Можливі варіанти: # # "any" - будь-які # # "inet" (тільки IPv4) # # "inet6" (тільки IPv6) # # За замовчуванням - "any". # AddressFamily inet # # ## UseDNS ########################################## ######## # # # Вказує, чи повинен sshd перевіряти ім'я хоста і # # використовуючи це ім'я звіряти IP адреса передана клієнтом з # # отриманим від DNS. # # Значення за промовчанням - "yes". # # # ################################################ ############# ############# Налаштування доступу користувачів ############## ####### ################################################## ### # # # Пустить/не пустити користувача визначається директивами # # DenyUsers, AllowUsers, DenyGroups, і AllowGroups. # # при цьому, перевірка проходить зверху - вниз по ланцюжку: # # ## DenyUsers ## # # || # # ## AllowUsers ## # # || # # ## DenyGroups ## # # || # # ## AllowGroups ## # # Приймаються лише імена користувачів та груп, числові # # ідентифікатори (UserID) - не розпізнаються. Коректна # # запис кількох користувачів/груп по черзі, через # # пробіл. Якщо записано як користувач@хост - то # # користувач і хост перевіряються окремо, це дозволяє # # розмежувати доступ певних користувачів з # # певних хостів. Варто пам'ятати, що директиви ## DenyUsers та AllowUsers приймають як параметр ## ім'я користувача, а DenyGroups та AllowGroups - ім'я ## групи. Див. PATTERNS у man ssh_config для додаткової # # інформації про форми запису імен користувачів та груп. # # # ## DenyUsers ############################################ ### # # # Список КОРИСТУВАЧІВ, яким НЕ МОЖНА користуватися sshd. # # За замовчуванням - не вказано = ніхто не заборонено. Тобто. якщо # # тут вказаний користувач, йому буде відмовлено в доступі # # до ssh серверу. # # # ## AllowUsers ############################################ ## # # # Список КОРИСТУВАЧІВ, яким МОЖНА користуватися sshd, # # За замовчуванням - не вказано = дозволено всім. Тобто. якщо # # вказано хоча б одного користувача, ssh доступ до сервера # # доступний лише йому. # # # ## DenyGroups ############################################ ## # # # Список ГРУП, яким НЕ МОЖНА користуватися sshd. # # За замовчуванням - не вказано = жодна група не заборонена. # # Тобто. якщо вказана хоча б одна група, то користувачам, що # # входять до цієї групи буде відмовлено в доступі до ssh # # серверу. # # # ## AllowGroups ############################################ # # # # Список ГРУП, яким МОЖНА користуватися sshd. # # За замовчуванням - не вказано = дозволено всім. Тобто. якщо # # вказана хоча б одна група, то тільки тим користувачам, # # які до неї входять буде дозволено доступ до ssh серверу. # # # #################### ################################################# Опції визначення стану з'єднання ################################################ ######################## # # ## TCPKeepAlive ###################### ####################### # # # # Вказує, потрібно системі посилати TCP повідомлення клієнту # # з метою підтримки з'єднання. Якщо надсилати ці пакети, можна визначити розрив з'єднання. Однак це також # # означає, що з'єднання може бути розірвано у разі # # короткочасного перебою в роботі маршрутизації і # # деяких це сильно дратує. З іншого боку, якщо # # таких повідомлень не надсилати - сеанси на сервері можуть # # тривати нескінченно, породжуючи користувачів - "привидів", # # і пожираючи ресурси сервера. Значення за умовчанням - "yes", # # тобто. надсилати такі повідомлення. Для відключення надсилання # # таких повідомлень потрібно задати значення "no". Раніше ця ## опція називалася KeepAlive. Варто зауважити, що # # існують більш захищені способи перевірки стану # з'єднання (див. нижче). # # # TCPKeepAlive yes # # ## ClientAliveCountMax ##################################### # # # Задає кількість повідомлень до клієнтів, які sshd # # посилає поспіль, не отримуючи жодної відповіді від # # клієнта. Якщо граничне значення буде досягнуто, а # # клієнт так і не відповів - sshd відключить клієнта, перервавши # # ssh сесію. Варто відзначити, що використання таких # # повідомлень докорінно відрізняється від директиви TCPKeepAlive. # # Повідомлення до/від клієнтів надсилаються зашифрованим # # каналом і тому не схильні до спуфінгу. Повідомлення ж # # TCPKeepAlive спуфінгу схильні. Механізм client alive # # особливо цінний у тих випадках, коли серверу і клієнту потрібно # # знати коли з'єднання стало неактивним. За замовчуванням # # значення дорівнює 3. У випадку, якщо ClientAliveInterval # # заданий рівним 15 і ClientAliveCountMax залишений за # # замовчуванням, клієнти, що не відповідають, будуть відключені приблизно # # через 45 секунд. Ця директива працює тільки для # # протоколу ssh2. # # # ## ClientAliveInterval ##################################### # # # Задає тимчасовий інтервал в секундах. Якщо протягом # # цього інтервалу не було обміну даними з клієнтом, sshd # # посилає повідомлення зашифрованим каналом, # # запитує відповідь від клієнта. За замовчуванням – 0, тобто. # # не надсилати таких повідомлень. Ця директива працює # # тільки для протоколу ssh2. # # # ################################################ ############# ################ Загальні опції автентифікації #################### ################################################## ######## # # ## AuthorizedKeysFile ##################################### # # # # Вказує файл, у якому містяться публічні ключі, # # використовувані для автентифікації користувачів. Директива # # може містити маркери виду %М, які підставляються в # # процесі встановлення з'єднання. # # Визначено наступні маркери: # # %% - замінюється літералом "%" # # %h - замінюється домашньою директорією # # аутентифікується користувача # # %u - замінюється ім'ям користувача, що аутентифікується # # Таким чином, файл з ключами може бути заданий як # абсолютним шляхом (тобто один спільний файл з ключами), так і динамічно - в залежності від користувача (тобто по файлу на кожного користувача). # # За замовчуванням - ".ssh/authorized_keys". # # Приклад для файлу ключа в домашній папці користувача: # # AuthorizedKeysFile %h/.ssh/authorized_key # # Приклад для спільного файлу: # # AuthorizedKeysFile /etc/ssh/authorized_keys # # Див. опис файлу authorized_keys для більшої інформації # #. # # # ## ChallengeResponseAuthentication ######################### # # # Вказує, чи дозволити аутентифікацію виду питання-відповідь # # (challenge-response authentication ). Підтримуються всі # # види аутентифікації з login.conf За замовчуванням - "yes", # # тобто. дозволити. # # У Ubuntu - вимкнена з міркувань безпеки. # # # ChallengeResponseAuthentication no # # ## HostbasedUsesNameFromPacketOnly ######################### # # # Вказує, як сервер повинен отримувати ім'я хоста клієнта # # при схему аутентифікації, що ґрунтується на перевірці хоста. # # Якщо задати "yes" - при перевірці відповідності у файлах # # ~/.shosts, ~/.rhosts або /etc/hosts.equiv sshd буде # # використовувати ім'я хоста, надане клієнтом. # # (виконуючи реверсивне DNS розпізнавання) Якщо вказати "no"# # - sshd буде ресолвить ім'я з самого TCP з'єднання. # # За замовчуванням - "no". # # # ## IgnoreRhosts ############################################ # # # Забороняє використання файлів .rhosts і .shosts # # в процесі автентифікації, заснованої на перевірці хоста. # # (RhostsRSAAuthentication або HostbasedAuthentication). # # Файли /etc/hosts.equiv та /etc/ssh/shosts.equiv досі # # використовуються. # # За замовчуванням – “yes”. # # # IgnoreRhosts yes # # ## IgnoreUserKnownHosts #################################### # # # Вказує чи повинен sshd ігнорувати # # "відомі хости" - файл ~/.ssh/known_hosts в процесі # # аутентифікації, заснованої на перевірці хоста # # (RhostsRSAAuthentication або HostbasedAuthentication). # # За замовчуванням - "no". # # # ## PermitBlacklistedKeys ################################### # # # Вказує, чи варто sshd приймати ключі, занесені до # # чорний список як скомпрометовані (known-compromised # # keys (див. ssh-vulnkey)). Якщо значення "yes" - # # спроби автентифікації з такими ключами будуть занесені в # # журнал і прийняті, якщо значення "no" - спроби # # автентифікації будуть відкинуті. # # За замовчуванням - "no". # # # ## PermitEmptyPasswords #################################### # # # У разі дозволеної аутентифікації з допомогою пароля , # # вказує, чи можливий вхід із порожнім паролем. # # За замовчуванням - "no". # # # PermitEmptyPasswords no # # ## PermitRootLogin ######################################## # # # # Вказує, чи можливий ssh-вхід під суперкористувачем # # (root). Може приймати значення: # # "yes" - суперкористувач може зайти. Застосовується # поточна глобальна схема аутентифікації. # # # # "without-password" - суперкористувач може зайти. # # Парольна автентифікація для нього буде вимкнена. # # # # "forced-commands-only" - суперкористувач зможе зайти, # # користуючись автентифікацією на основі публічного ключа і # # тільки якщо передасть необхідну до виконання кімнату. # # Це зручно для здійснення резервного копіювання, # # навіть у тому випадку, коли нормальний (тобто не через ssh) # # вхід суперкористувача заборонено. Всі інші методи # # аутентифікації для суперкористувача будуть заблоковані. # # # # "no" - суперкористувач не може використовувати ssh для # # входу в систему. # # # # Значення за промовчанням - "yes". # # # PermitRootLogin yes # # ## Protocol ######################################## ######## # # # Вказує, який протокол повинен використовувати sshd. # # Можливі значення '1' та '2' - ssh1 і ssh2 # # відповідно. Можливий одночасний запис, при якому значення # слід розділяти комами. # # За замовчуванням - "2,1". # # Варто відзначити, що порядок проходження протоколів в # # запису не ставить пріоритет, т.к. клієнт вибирає який # # з кількох запропонованих сервером протоколів йому # # використовувати. Запис "2,1" абсолютно ідентична # # запису "1,2". # # # Protocol 2 # # ## UsePAM ######################################## ########## # # # Включає інтерфейс PAM (Pluggable Authentication Module # # interface). на основі ## запиту-відповіді (ChallengeResponseAuthentication та ##PasswordAuthentication) Т.к. аутентифікація # # запитів-відповідей у PAM зазвичай виконує ту ж роль, # # що і парольна автентифікація, вам слід відключити # # або PasswordAuthentication, або # # ChallengeResponseAuthentication. Варто зазначити, що # # якщо директива UsePAM включена - ви не зможете запустити # # sshd від імені користувача, відмінного від root. # # Значення за промовчанням - "no". # # # UsePAM yes # # ## PasswordAuthentication ################################## # # # Вказує, дозволена чи аутентифікація з використанням # # пароля. # # За замовчуванням – “yes”. # # # ## HostKey ############################################ ##### # # # Вказує файл, що містить закритий хост-ключ, # # використовується SSH. За замовчуванням - /etc/ssh/ssh_host_key # # для протоколу ssh1 та /etc/ssh/ssh_host_rsa_key та # # /etc/ssh/ssh_host_dsa_key для протоколу ssh2. Варто відзначити, що sshd не буде користуватися файлом, який доступний комусь, крім користувача. Можна використовувати # # кілька файлів з ключами, ключі “rsa1” - # # для протоколу ssh1 та “dsa”/“rsa” для протоколу ssh2. # # # HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh/ssh_host_dsa_key # # ############################### ############################# ########## Опції протоколу SSH версії 1 (ssh1) ### ########## ######################################## #################### # Настійно НЕ РЕКОМЕНДУЄТЬСЯ використовувати протокол ssh1.# # Протокол ssh2 набагато безпечніший, ніж ssh1 # ########### ################################################### # ## KeyRegenerationInterval ################################## # # # Для протоколу ssh1 - раз у визначений час # # автоматично генерується новий тимчасовий ключ сервера # # (якщо він був використаний). Це зроблено для # # запобігання розшифровці перехоплених сеансів, з метою # # пізніше зайти з параметрами цих сеансів на машину і # # вкрасти ключі. Такий ключ ніде не зберігається (зберігається в оперативній пам'яті). Ця директива вказує період # # "життя" ключа в секундах, після якого він буде # # згенерований заново. Якщо значення встановити 0 - # # ключ не буде генеруватися заново. # # За промовчанням значення - 3600 (секунд). # # # KeyRegenerationInterval 3600 # # ## RhostsRSAAuthentication ################################# # # # Вказує, чи потрібна автентифікація на основі файлів # # rhosts або /etc/hosts.equiv спільно з успішною # # автентифікацією хоста через RSA. # # Актуально лише для протоколу ssh1. # # За замовчуванням - "no". # # # RhostsRSAAuthentication no # # ## RSAAuthentication ######################################## # # Вказує, чи "чиста" RSA-автентифікація дозволена. # # Актуально лише для протоколу ssh1. # # За замовчуванням – “yes”. # # # RSAAuthentication yes # # ## ServerKeyBits ######################################## ### # # # Визначає число біт у тимчасовому ключі сервера для # # протоколу ssh1. Мінімальне значення 512. # # Значення за замовчуванням - 1024. # ServerKeyBits 768 # # ################################# ########################### ########### Опції протоколу SSH версії 2 (ssh2) #### ######## ########################################### ###################### Ciphers ########################### ###################### # # # # Вказує алгоритми шифрування, дозволені для # # протоколу ssh2. Декілька алгоритмів повинні бути # # розділені комами. Підтримувані алгоритми: # # "3des-cbc", "aes128-cbc", "aes192-cbc", "aes256-cbc", # # "aes128-ctr", "aes192-ctr", "aes256-ctr", " arcfour128”, # # “arcfour256”, “arcfour”, “blowfish-cbc”, “cast128-cbc”. # # За замовчуванням використовуються: # # aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128, # # arcfour256,arcfour,aes192-cbc,aes256-cbc,aes128-ctr, aes256-ctr # # # ## HostbasedAuthentication ################################## # # # Вказує, чи дозволена аутентифікація , Заснована на # # перевірці хоста. Перевіряється rhosts або /etc/hosts.equiv, # # і в разі успіху, спільного з успішною перевіркою # # публічного ключа, доступ дозволяється. Ця директива # # однакова з директивою RhostsRSAAuthentication і # # підходить лише протоколу ssh2. # # За замовчуванням - "no". # # # HostbasedAuthentication no # # ## MACs ######################################## ############ # # # Вказує допустимий алгоритм MAC (message # # authentication code). Алгоритм MAC використовується # # протоколом ssh2 для захисту цілісності даних. Кілька алгоритмів # # повинні бути розділені комами. # # За замовчуванням використовуються: # # hmac-md5, hmac-sha1, [email protected], hmac-ripemd160, # # hmac-sha1-96, hmac-md5-96 # # # ## PubkeyAuthentication ########################## ########## # # # Вказує, чи дозволена автентифікація на основі # # публічного ключа. Актуально лише для протоколу ssh2. # # За замовчуванням – “yes”. # # # PubkeyAuthentication yes ############################################# ############### ##################### Опції GSSAPI ############## ################################################### ####################### # # ############ # Застосовується тільки для протоколу ssh2 ######## ### # # ## GSSAPIAuthentication #################################### # # # Вказує, дозволена Чи автентифікація користувача на # # основі GSSAPI. За замовчуванням – "no", тобто. заборонено. # # # ## GSSAPIKeyExchange ####################################### # # # Вказує, дозволено обмін ключами, заснований на # # GSSAPI. Обмін ключів за допомогою GSSAPI не покладається на ## ssh ключі під час верифікації ідентичності хоста. # # За замовчуванням – "no" – тобто. обмін заборонено. # # # ## GSSAPICleanupCredentials ################################ # # # Вказує, чи потрібно автоматично знищувати # # Користувальницький кеш автентифікаційних повноважень при завершенні # # # сеансу. # # За замовчуванням – "yes" – тобто. потрібно знищувати. # # # ## GSSAPIStrictAcceptorCheck ############################### # # # Вказує, наскільки суворою повинна бути перевірка # # ідентичності клієнта під час аутентифікації через GSSAPI. # # Значення "yes" змушує клієнта аутентифікуватися в # # приймаючої хост-службі на поточному хості. Значення "no" # # дозволяє клієнту аутентифікуватися за допомогою будь-якого ключа служб # #. # # Значення за промовчанням - "yes". Варто зауважити, що завдання значення "no" може # спрацювати тільки з рідкісними бібліотеками Kerberos GSSAPI. # # # ################################################ ################################ Опції Kerberos ################# ######### ########################################## ################### # # ## KerberosAuthentication ########################## ######## # # # Вказує, чи вимагає пароль, наданий # # користувачем для аутентифікації # # (PasswordAuthentication) валідації в Kerberos KDC. # # Для використання цієї опції серверу потрібно # # переконатися в істинності KDC. (Те server needs a # # Kerberos servtab , які дозволяють здійснити # # KDC's identity) # # За замовчуванням - "no". # # # ## KerberosGetAFSToken ##################################### # # # Якщо активовано AFS і користувач отримав Kerberos 5 TGT, # # чи намагатися отримати AFS токен до того, як користувач # # отримає доступ до своєї домашньої папки. # # За замовчуванням - "no". # # # ## KerberosOrLocalPasswd ################################### # # # Вказує, як чинити у випадку , якщо автентифікація # # через Kerberos завершилася невдачею. Якщо # # значення = "yes" - пароль буде перевірено за допомогою # # будь-якого додаткового локального механізму авторизації, # # наприклад - /etc/passwd. # # За замовчуванням – “yes”. # # # ## KerberosTicketCleanup ################################### # # # Вказує, чи потрібно автоматично знищувати файл з # # кешем тикету користувача після завершення сеансу. # # За замовчуванням – “yes”. # # # ################################################ ############################## Опції перенаправлення ################### ## ################################################ ############# # ## AllowAgentForwarding ################################# ### # # # Вказує, дозволити або заборонити перенаправлення # # ssh-agent"а. За замовчуванням – “yes”, тобто. дозволити. # # Варто зауважити, що відключення перенаправлення не # # збільшить безпеки поки користувачам також не буде # # заборонено доступ до shell, т.к. вони завжди зможуть встановити # # свої власні аналоги агента. # # # ## AllowTcpForwarding ###################################### # # # Вказує, дозволити або заборонити перенаправлення TCP. # # За замовчуванням – “yes”, тобто. дозволити. Варто зауважити, що як і у випадку з AllowAgentForwarding відключення перенаправлення не збільшить безпеки, поки у користувачів буде консольний доступ, т.к. вони зможуть # # встановити свої аналоги. # # # # # # # GatewayPorts ########################################### ## # # # Вказує, чи дозволяти віддаленим хостам доступ до # # перенаправлених портів. За замовчуванням sshd слухає # # з'єднання до перенаправлених портів тільки на локальному # # інтерфейсі (loopback). Це не дає іншим віддаленим хостам # приєднуватися до перенаправлених портів. Можна # # використовувати GatewayPorts, щоб дозволити sshd це # # робити. Директива може приймати 3 значення: # # "No" - тільки loopback. # # "yes" - будь-які адреси. # # "clientspecified" - адреси, вказані клієнтом. # # # ## PermitOpen ############################################ ## # # # Вказує куди дозволено перенаправлення TCP портів. # # Вказівка перенаправлення повинна приймати одну з # # наступних форм: # # PermitOpen host:port # # PermitOpen IPv4_addr:port # # PermitOpen :port # # Кілька записів можна задати, розділяючи їх пробілами. # # Аргумент "any" можна використовувати для зняття всіх # # заборон на перенаправлення портів. За замовчуванням будь-яке # # перенаправлення дозволено. # # # ## PermitTunnel ############################################# # # # Вказує, чи дозволено перенаправлення tun-пристроїв. # # Може приймати значення: # # “yes” # # “point-to-point” (3-й мережевий рівень) # # "ethernet" (2-й мережевий рівень) # # "no" # # Значення "yes" дозволяє одночасно і "point-to-point" # # і "ethernet". За замовчуванням – “no”. # # # ################################################ ############# ################## Опції журналування ################# ### ################################################ ############## # ### SyslogFacility ################################ ########## # # # # Задає код об'єкта журналу для запису повідомлень в # # системний журнал від sshd. Можливі значення: # # DAEMON # # USER # # AUTH # # LOCAL0 # # LOCAL1 # # LOCAL2 # # LOCAL3 # # LOCAL4 # # LOCAL5 # # LOCAL6 # # LOCAL7 # # За замовчуванням використовується AUTH. # # # SyslogFacility AUTH # # ## LogLevel ####################################### ######## # # # # Задає рівень детальності журналу sshd. # # Можливі варіанти: # # SILENT # # QUIET # # FATAL # # ERROR # # INFO # # VERBOSE # # DEBUG # # DEBUG1 # # DEBUG2 # # DEBUG3 # # За замовчуванням - INFO. # # DEBUG та DEBUG1 еквівалентні один одному. # # DEBUG2 і DEBUG3 задають найвищі рівні налагоджувального # # виведення. Запис логів з рівнем DEBUG загрожує приватності користувачів і не рекомендований. # # # LogLevel INFO # # ########################################### #################################### Перенаправлення X11 ############ ######## ########################################### ################## # # ## X11Forwarding ############################ ################ # # # Вказує, чи дозволено перенаправлення графічної # # підсистеми X11. Може набувати значення “yes” або “no”. # # За замовчуванням - "no". # # Увага - включення простого перенаправлення Х11 - # # Великий ризик як сервера, так клієнтів, т.к. у випадку такого перенаправлення проксі-дисплей sshd приймає з'єднання з будь-яких адрес. Використовуйте # # директиву X11UseLocalhost для обмеження доступу до # # серверу перенаправлення "іксів". Варто зазначити, що # # відключення перенаправлення не дасть гарантії, що користувачі не зможуть перенаправляти Х11, т.к. маючи # # консольний доступ вони завжди встановити свій # # перенаправник. Перенаправлення X11 буде # # автоматично вимкнено, якщо буде задіяна # # директива UseLogin. # # # X11Forwarding yes # # ## X11UseLocalhost ######################################## # # # # Вказує, чи повинен sshd обмежити область # # перенаправлення Х11 локальною loopback адресою, або # # повинен дозволити будь-які адреси. За замовчуванням - sshd # # "садить" сервер перенаправлення Х11 на локальна адреса # # і задає частину змінної оточення DISPLAY, що відповідає # # за ім'я хоста як “localhost”. Варто зауважити, що деякі старі клієнти Х11 можуть не працювати з такими налаштуваннями. За умовчанням – "yes", тобто. перенаправлення # # обмежене локалхостом, значення - "no" - відключає # # обмеження. # # # ## XAuthLocation ############################################ # # Вказує повний шлях до програми xauth. # # За замовчуванням - /usr/bin/X11/xauth. # # # ## X11DisplayOffset ######################################## # # # Вказує номер першого дисплея, доступного sshd в # # як перенаправлення X11. Це зроблено для того, щоб перенаправлені "ікси" не перетиналися з реальними. За замовчуванням - 10. # # # X11DisplayOffset 10 # # ###################################### ######################################### Різні опції ####### ################################################### ########################### # ### LoginGraceTime ################### ######################## # # # Час, після якого сервер відключає # # користувача, якщо той не зміг задовільно # # залогінитися. Значення 0 - дозволяє користувачеві # # логінитися нескінченно. За замовчуванням – 120 (секунд). # # # LoginGraceTime 120 # # ## MaxAuthTries ######################################## #### # # # Вказує максимальну кількість спроб аутентифікації, # # дозволене для одного з'єднання. # # Як тільки число невдалих спроб перевищить половину заданого значення # #, всі наступні спроби будуть # # заноситися в журнал. Значення за замовчуванням - 6. # # # ## MaxSessions ##################################### ####### # # # Вказує максимальну кількість одночасних підключень # # для кожного мережного з'єднання. За замовчуванням - 10. # # # ## MaxStartups ####################################### ###### # # # Вказує максимальну кількість одночасних # # неавторизованих підключень до sshd. У випадку, якщо # # число підключень перевищить ліміт - всі додаткові # # підключення будуть скинуті до тих пір, поки поточні підключення # # не завершаться або успішною авторизацією, # # або закінченням періоду часу вказаного в директиві # # LoginGraceTime. Значення за замовчуванням - 10. # # Додатково, можна встановити раннє скидання з'єднань, # # вказавши в якості параметра три значення, розділені # # двокрапкою “start:rate:full” (наприклад: "10:30:60"). # # sshd відхиляє спробу з'єднання з ймовірністю рівною # # "rate/100" (тобто в нашому прикладі - 30%), якщо вже # # є "start" (10) неавторизованих з'єднань. # # Імовірність збільшується лінійно і будь-які спроби # # з'єднання будуть відхилені, якщо кількість неавторизованих # # з'єднань досягне значення "full" (60). # # # ## Compression ############################################# # # # # Вказує, чи дозволено стиснення даних. Можливо # # "yes" - стиск дозволено. # # "delayed" - стиснення відкладено доти, доки # # користувач успішно не аутентифікується. # # "no" - стиск заборонено. # # За замовчуванням – "delayed". # # # ## UseLogin ############################################ #### # # # Вказує, чи повинен використовуватися login для # # інтерактивного сеансу. Значення за промовчанням - "no". # # Варто відзначити, що login ніколи не використовувався для виконання віддалених команд. Також зауважимо, що # # використання login унеможливить використання # # директиви X11Forwarding, тому що login не знає, що # # йому робити з xauth. Якщо включена директива # # UsePrivilegeSeparation - вона буде відключена після # # авторизації. # # # ## UsePrivilegeSeparation ################################## # # # Вказує, чи повинен sshd розділяти привілеї . Якщо так # # - спочатку буде створено непривілейований дочірній # # процес для вхідного мережного трафіку. Після успішної # # авторизації буде створено інший процес з привілеями # # користувача, що увійшов. Основна мета поділу # # привілеїв - запобігання перевищенню прав доступу. # # Значення за промовчанням - "yes". # # # UsePrivilegeSeparation yes # # ## StrictModes ######################################## ##### # # # Вказує чи повинен sshd перевірити режими доступу і # # володіння користувацьких папок і файлів перед тим, як # # дати користувачеві увійти. Зазвичай це пояснюється тим, що # # новачки часто роблять свої файли доступними для запису # # всім підряд. За умовчанням - "yes". # # # StrictModes yes # # ## AcceptEnv ######################################## ####### # # # Вказує, які змінні оточення, передані # # клієнтом будуть прийняті. Див. опцію SendEnv у клієнті. # # Варто зауважити, що передача змінних можлива лише # # для протоколу ssh2. Змінні вказуються на ім'я, # # можна використовувати маски ('*' і '?'). Можна вказати # # кілька змінних через пробіл, або розбити на # # кілька рядків AcceptEnv. Будьте обережні - деякі # # змінні оточення можуть бути використані для обходу # # заборонених користувальницьких оточень. Використовуйте цю # # директиву акуратно. За замовчуванням ніякі # # користувача змінні оточення не приймаються. # # # AcceptEnv LANG LC_* # # ## PermitUserEnvironment ################################### # # # # Вказує, чи sshd повинен сприймати # # ~/.ssh/environment і опцію environment= в # # ~/.ssh/authorized_keys. За замовчуванням – “no”. Варто помітити, що дозвіл обробки оточення може дати користувачам можливість обійти обмеження в деяких конфігураціях, які використовують такі механізми, як # LD_PRELOAD. # # # # # # # # PidFile ########################################## ####### # # # Вказує файл, що містить ідентифікатор процесу # # (process ID, PID) демона SSH. # # За замовчуванням - /var/run/sshd.pid # # # # # # ## PrintLastLog ############################## ############### # # # Вказує, чи повинен sshd виводити на екран дату і час # # останнього севнса при інтерактивному вході користувача. # # За замовчуванням – “yes”. # # # PrintLastLog yes # # ## PrintMotd ######################################## ####### # # # Вказує, чи повинен sshd виводити на екран /etc/motd # # при інтерактивному вході користувача. На деяких системах # # (наприклад в Ubuntu) ця інформація так само # # виводиться на екран оболонкою. # # Значення за промовчанням - "yes". # # # PrintMotd no # # ## Banner ######################################## ########## # # # Вказує який файл містить текстовий банер, який # # буде показаний користувачеві ПЕРЕД процедурою # # аутентифікації. Опція доступна тільки для протоколу ssh2. # # За замовчуванням - нічого не відображає. # # У Ubuntu файл issue.net містить фразу Ubuntu (version), # # наприклад, для karmic це "Ubuntu 9.10". Можна # # використовувати для дезорієнтації можливих атакуючих, # # написавши туди наприклад "My D-Link Interet Router" =) # # # Banner /etc/issue.net # # ## ChrootDirectory ########### ############################## # # # Якщо вказано - надає шлях, яким буде # # виконаний chroot після аутентифікації. Шлях і весь його # # вміст повинні відповідати належним # # суперкористувачу папкам і бути не доступними для # # запису іншими користувачами. # # У дорозі можуть бути вказані мітки, що підставляються в # # процесі аутентифікації: # # %% - замінюється літералом "%" # # %h - замінюється домашньою директорією # # аутентифікується користувача # # %u - замінюється ім'ям користувача, що аутентифікується # # chroot -папка повинна містити всі необхідні файли і # # папки для сеансу користувача. Для інтерактивного # # сеансу потрібні як мінімум: # # оболонка, зазвичай - sh # # базові пристрої в /dev, такі як: # # null, zero, stdin, stdout, stderr, arandom і tty # # для сеансу передачі даних за допомогою sftp ніяких # # додаткових налаштувань не потрібно, якщо використовується # # внутрішній процес sftp сервера. Див. Subsystem для # # більшої інформації. За замовчуванням chroot не виконується. # # # ## ForceCommand ############################################ # # # Примушує виконувати вказану команду. Ігнорує # # будь-які команди, передані клієнтом або записані в # # ~/.ssh/rc. Команда викликається з # оболонки з опцією -с. Підходить для запуску оболонки, команди # або підсистеми. Найбільш корисна всередині блоку # # Match. Команда, спочатку передана клієнтом, зберігається # # в змінному оточенні SSH_ORIGINAL_COMMAND. Якщо # # вказати команду "internal-sftp", буде запущено # # внутрішній sftp сервер, якому не потрібні додаткові # # файли та папки, описані в директиві ChrootDirectory. # # # ## Subsystem ############################################ ### # # # Визначає та налаштовує зовнішню підсистему (наприклад # # демона передачі файлів - file transfer daemon). # # Аргументами служать ім'я та команда (з можливими # # аргументами), яка буде виконана під час запиту # # на підсистеми. Команда sftp-server запускає "sftp" - # # підсистему передачі файлів. Додатково можна вказати # # як підсистему "internal-sftp" - що запустить # # внутрішній sftp сервер. Це може значно спростити # # налаштування у разі використання директиви # # ChrootDirectory За замовчуванням жодних підсистем # # не викликається. Актуально лише для протоколу ssh2. # # # Subsystem sftp /usr/lib/openssh/sftp-server # # ################################# ########################### ##################### Блок Match ################################################### ##################################### # # # Спеціально виніс в кінець файлу, щоб було зручніше # # писати Match правила. # # MadKox. # # # # Директива Match є початок умовного # # блоку. Якщо виконані всі критерії, вказані в рядку # # Match, директиви в наступних рядках блоку виконуються, # # дозволяючи обійти значення глобальних директив файлу # # sshd_config для випадку, що є критерієм директиви # # Match. Блоком вважаються всі рядки, що йдуть після рядка ## з критерієм (Match - рядки) до наступного match-рядка ## або до кінця файлу. Аргумент директиви Match - одна або # кілька пар записів критеріїв. Можливі види записів: # # User # # Group # # Host # # Address # # Записи можуть містити як одиночні значення # # (наприклад User=user), так і кілька значень, # # розділені комами (User=user1,user2). Також можуть # # бути використані регулярні вирази, описані в # # секції PATTERNS файлу ssh_config. Записи в критерії # # Address можуть містити адреси в нотації CIDR # # (Адреса/Довжина маски, наприклад “192.0.2.0/24” або # # “3ffe:ffff::/32”). Варто зауважити, що представлена ## довжина маски повинна відповідати адресі, і надто ## довгі/короткі для адреси не працюватимуть. # # Як директив Match може використовувати тільки # # певний набір директив: # # AllowTcpForwarding # # Banner # # ChrootDirectory # # ForceCommand # # GatewayPorts # # GSSAPIAuthentication # # HostbasedAuthentication # # KbdInteractiveAuthentication # # KerberosAut PasswordAuthentication # # PermitOpen # # PermitRootLogin # # RhostsRSAAuthentication # # RSAAuthentication # # X11DisplayOffset # # X11Forwarding # # X11UseLocalHost #
Можна скопіювати наведений вище текст у власний sshd_config і використовувати в подальшому для налаштування.
Сам по собі, неправильно налаштований SSH-сервер – величезна вразливість у безпеці системи, тому що у можливого зловмисника є можливість отримати практично необмежений доступ до системи. Крім цього, у sshd є багато додаткових корисних опцій, які бажано включити для підвищення зручності роботи та безпеки.
Port, ListenAddress та AddressFamily
Ці три параметри визначають, на яких портах та адресах ваш сервер чекатиме вхідні з'єднання. По-перше, має сенс наскільки можна обмежити сімейство оброблюваних адрес реально використовуваними, т. е. якщо ви використовуєте лише IPv4 - відключіть IРv6, і навпаки. Зробити це можна за допомогою параметра AddressFamily, наприклад (для дозволу IPv4 та заборони IPv6):
AddressFamily inet
По-друге, бажано змінити стандартний порт (22), на якому слухає sshd. Це пов'язано з тим, що численні мережеві сканерипостійно намагаються з'єднатися з 22-м портом та як мінімум отримати доступ шляхом перебору логінів/паролів зі своєї бази. Навіть якщо у вас і відключено парольну автентифікацію - ці спроби сильно засмічують журнали і (у великій кількості) можуть негативно вплинути на швидкість роботи сервера ssh. Якщо ж ви з якоїсь причини не бажаєте змінити стандартний порт, ви можете використовувати як різні зовнішні утиліти для боротьби брутфорсерами, наприклад fail2ban, так і вбудовані, такі як MaxStartups.
Задати порт можна як абсолютним значенням всім інтерфейсів з допомогою директиви Port , і конкретним значенням кожному за інтерфейсу, з допомогою директиви ListenAddress . Наприклад:
Port 2002
ListenAddress 192.168.0.1:2003 ListenAddress 192.168.1.1:2004
Заборона віддаленого доступу для суперкористувача
За промовчанням root-доступ заборонено за паролем (за ключом - можна) - опція PermitRootLogin встановлена в without-password . Але за умови, що за замовчуванням в Ubuntu користувач, доданий при встановленні системи, має можливість вирішувати всі адміністративні завдання через sudo, створювати можливість. root доступудо системи через ssh - виглядає нерозумно (навіть за аутентифікації по ключу). Рекомендується зовсім вимкнути. цю опцію або застосовувати її тільки в режимі forced-commands-only . Відключити root-доступ можна так:
PermitRootLogin no
Парольна автентифікація
Дозволена за замовчуванням парольна автентифікація є практично найпримітивнішим способом авторизації в sshd. З одного боку це спрощує конфігурацію та підключення нових користувачів (користувачеві достатньо знати свій системний логін/пароль), з іншого боку пароль завжди можна підібрати, а користувачі часто нехтують створенням складних та довгих паролів. Спеціальні боти постійно сканують доступні з інтернету ssh сервери та намагаються авторизуватися на них шляхом перебору логінів/паролів зі своєї бази. Настійно не рекомендується використовувати парольну автентифікацію. Вимкнути її можна так:
PasswordAuthentication no
Якщо з якихось причин вам все ж таки хочеться використовувати парольну автентифікацію - подбайте про те, щоб ніхто не міг авторизуватися з порожнім паролем. Для цього задайте директиву PermitEmptyPasswords:
PermitEmptyPasswords no
Протоколи SSH1 та SSH2
Як було зазначено, sshd може працювати з протоколами SSH1 і SSH2. При цьому використання небезпечного SSH1 не рекомендується. Змусити sshd працювати лише з протоколом SSH2 можна так:
Аутентифікація на основі SSH2 RSA-ключів
Найкращим способом авторизації є автентифікація на основі SSH2 RSA-ключів. При такому способі користувач генерує на своєму боці пару ключів, з яких один ключ є секретним, а інший публічним. Публічний ключ копіюється на сервер і використовується для перевірки ідентичності користувача. Докладніше про створення пари ключів та способи розміщення їх на сервері див. в описі SSH-клієнта. Включити аутентифікацію за публічним ключем можна так:
PubkeyAuthentication yes
Сервер повинен знати, де слід шукати публічний ключ користувача. Для цього використовується спеціальний файл authorized_keys . Синтаксис може бути наступним:
# Коментарі записуються тільки з нового рядка # загальний вигляд записів у файлі authorized_keys # [опції] тип_ключа(ssh-rsa або ssh-dss) дуже_довга_рядок_незрозуміла_простій_людині [логін@хост] [email protected] from="*.sales.example.net,!pc.sales.example.net" ssh-rsa AAAAB2...19Q== [email protected] command="dump /home",no-pty,no-port-forwarding ssh-dss AAAAC3...51R== example.net permitopen="192.0.2.1:80",permitopen="192.0.2.2:25" ssh -dss AAAAB5...21S== tunnel="0",command="sh /etc/netstart tun0" ssh-rsa AAAA...== [email protected]
Можна вказати як один спільний файл із ключами, так і за файлом на кожного користувача. Останній спосіб є зручнішим і безпечнішим, тому що можна по-перше вказувати різні комбінації ключів для кожного користувача, а по-друге обмежити доступ до публічного ключа користувача. Задати файл із ключами можна за допомогою директиви AuthorizedKeysFile:
AuthorizedKeysFile %h/.ssh/my_keys
для схеми користувач - файл
або
AuthorizedKeysFile /etc/ssh/authorized_keys
для схеми із загальним файлом. За замовчуванням SSH-клієнт шукає ключі у файлі ~/.ssh/authorized_keys.
Ще про безпеку
Додаткові налаштування
Користувачі та групи.
Якщо у вас на сервері «живе» багато користувачів, а доступ через ssh ви хочете дозволити лише декільком з них - ви можете використовувати директиви DenyUsers, AllowUsers, DenyGroups і AllowGroups. Докладніше про ці директиви див. коментарі на прикладі sshd_config .
Опції визначення стану з'єднання
За замовчуванням із способів визначення стану з'єднання включений тільки спосіб перевірки TCP з'єднання - TCPKeepAlive , проте, sshd вміє визначати стан з'єднання і зручнішими та безпечнішими способами. Докладніше див. відповідний розділ у прикладі sshd_config.
Продуктивність. MaxStartups
Перенаправлення портів
Перенаправлення X11
На сервері у файлі /etc/ssh/sshd_config виставити параметр (за замовчуванням увімкнено):
ForwardX11 yes
На клієнті у файлі /etc/ssh/ssh_config виставити параметри (за замовчуванням вимкнено):
ForwardAgent yes ForwardX11 yes
Запускати на клієнті можна так ssh yurauname@serverip firefox. Або спочатку заходимо ssh yurauname@serverip потім запускаємо, наприклад sudo synaptic.
SFTP
За замовчуванням в sshd вбудований SFTP-сервер. Протокол SFTP (SSH File Transfer Protocol) - SSH-протокол передачі файлів. Він призначений для копіювання та виконання інших операцій із файлами поверх надійного та безпечного з'єднання. Як правило, як базовий протокол, що забезпечує з'єднання, і використовується протокол SSH2. Щоб увімкнути підтримку SFTP, додайте в sshd_config рядок
Subsystem sftp /usr/lib/openssh/sftp-server
За промовчанням підтримка SFTP увімкнена.
Використання критеріїв. Директива Match
Налаштування SSH-клієнта
Найбільш безпечним вважається вхід по ключу, і в більшості випадків на стороні сервера така можливість включена, так що для використання ніяких прав суперкористувача не потрібно. На клієнтській машині генеруємо ключ:
ssh-keygen -t rsaОтримуємо пропозицію ввести пароль для захисту файлу ключа (виявляється корисним при попаданні файла в чужі руки). Якщо ми збираємося по SSH виконувати скрипти, залишаємо порожнім. Передаємо публічний ключ на сервер командою
Ssh-copy-id -i ~/ .ssh/ id_rsa.pub user@ server
Все можна заходити.
Коли ssh працює на нестандартному порту:
Ssh-copy-id -i ~/ .ssh/ id_rsa.pub "-p port user@server"
Якщо виникає помилка: Bad port "umask 077; test -d .ssh || mkdir .ssh ; cat >> .ssh/authorized_keys"
спробуйте взяти параметри в лапки:
Ssh-copy-id "-i /home/user/.ssh/id_rsa.pub "-p port user@server""
Зручно при підключенні на віддаленій системі користуватися утилітою screen.
Налаштування віддаленої ssh-директорії в Nautilus
Монтування віддаленої директорії за допомогою sshfs
Монтування віддаленого каталогу до локального каталогу
sshfs user@ hostingserver.ru:/ home/ userdir ~/ sshfsdirРозмонтування
Fusermount -u ~/ sshsfdir
SSH aliases
При використанні кількох серверів з різними параметрами доступу (нестандартний порт, довге ім'я хоста, логін відмінний від локального, тощо) інколи втомливо вводити всі налаштування підключення щоразу заново. Для полегшення цього можна використовувати або.
Установки зберігаються в ~/.ssh/config для одного користувача та /etc/ssh/ssh_config глобально для всіх користувачів.
Приклад конфіг. Описано може бути безліч серверів. Детальніше у man ssh_config(не плутати з sshd_config)
Host AliasName # Довільне ім'я хоста HostName 1.2.3.4 # Можна вказувати як IP, так і hostname (якщо працює DNS) User YourUserName # Якщо користувач не збігається з локальним користувачем Port YourSSHPort # Якщо нестандартний порт
Після цього можна підключатися до сервера командою
ssh AliasNamessh-agent
Діагностика проблем підключення
Аналіз лога підключення:
Аналіз конфігураційних файлів клієнта та сервера.
Розташування конфігураційних файлів можна дізнатися з
man ssh man sshd
Використання смарт-карток
1. Створення сертифіката та експорт відкритого ключа, а також клієнтська частина на Windows + Putty SC описано на сайті: http://habrahabr.ru/post/88540/ Описане доповнення Key Manager доступне тільки в старих версіях Firefox. Перевірено на версії 3.5 для Windows. Пряме посилання на додаток: https://addons.mozilla.org/ru/firefox/addon/key-manager/
2. Підготовка сервера. Вам необхідно переконатися, що у конфігурації sshd дозволена аутентифікація за допомогою публічних ключів. Для цього необхідно у файлі "sshd_config" вказати значення параметра "PubkeyAuthentication" у "yes". Потім у файл "~/.ssh/authorized_keys" додаємо наш публічний ключ отриманий раніше (одним рядком). Зверніть увагу, файл ".ssh/authorized_keys" знаходиться в домашньому каталозі того користувача, який потім буде логінуватися за публічним ключем.
3. Клієнтська частина на Linux. Потрібно перескладання пакета OpenSSH без параметрів. Рекомендується вказати лише префікси каталогів, наприклад –prefix=/usr. Також слід врахувати, що файли конфігів будуть у /usr/etc. Перед початком необхідні пакети: opensc-lite-devel, zlib-devel, openssl-devel. Встановлюємо драйвер смарт-картки. Для зручності в конфізі ssh_config (не плутати з sshd_config) вказати шлях до бібліотеки pkcs: PKCS11Provider=<путь к библиотеке>
4. На клієнті запускаємо ssh user@host Якщо смарт-карта (токен) підключена, буде запитаний пароль та виконано вхід до сесії SSH .
Можливі проблемипри використанні
Звична комбінація клавіш Ctrl + S , що використовується в багатьох редакторах для збереження виправлень, при роботі в терміналі з ssh-сервером призведе до виконання команди XOFF, що зовні нагадує зависання сесії. Однак, це не так. Сервер продовжує приймати символи та команди, що вводяться, але не виводить це на екран. Щоб вийти з такого скрутного становища досить застосувати комбінацію Ctrl + Q, тим самим включивши режим XON назад.
Посилання
Т. е. user1 може бути прописаний як у себе - у файлі /home/user1/.ssh/keys) так і в іншого користувача, що дозволить йому виконувати зі свого комп'ютера вхід як «під собою», так і під «іншим»
SSH (Secure Shell) — це мережевий протокол, призначений для віддаленого керування сервером та передачі даних зашифрованим TCP з'єднанням. Більшість хостингів, навіть віртуальних, сьогодні надає доступ як по FTP, так і SSH. На мій погляд, це здорово, SSH набагато зручніше та безпечніше у використанні.
Налаштування SSH
Налаштування відбуватимуться під виділений сервер, VDS, VPS на Debian, Ubuntu. Конфігураційний файл розміщується тут: /etc/ssh/sshd_config.
Якщо у вас звичайний хостинг, все і так має бути налаштовано як слід, переходьте до розділу .
За замовчуванням, демон SSHD (саме в нього ми вносимо зміни) не потребує будь-яких налаштувань і працює нормально. Ми внесемо лише кілька невеликих змін, щоб обмежити доступ небажаних осіб до сервера.
В результаті внесення неправильних змін до конфігураційного файлу ви можете втратити доступ до сервера по ssh, тому переконайтеся, що у вас є альтернативні варіантидля доступу до нього, наприклад, за допомогою панелі керування ISPManager.
Як обмежити доступ по SSH
Всі зміни вносяться до /etc/ssh/sshd_config
Щоб зміни набули чинності, необхідно
Змінити порт
Port 9724Тепер при авторизації вам потрібно замість стандартного порту 22 вказувати 9724 .
Спосіб дуже простий і дієвий проти більшості простих роботів хакерів, які стукають у стандартні порти. Тут головне не створити конфлікт з іншими службами і підібрати явно не використовується число.
Заборонити зв'язок по старому протоколу
Тут ми визначаємо, що зв'язок можливий лише за протоколом v2
Якщо ви авторизовані не під root, перед усіма консольними командами потрібно додавати sudo - розшифровується як Substitute User and DO- Заміни користувача і роби (під ним). Наприклад, дозволяє виконувати команди від імені суперкористувача root.
Зменшити кількість спроб авторизації
MaxAuthTries 2Кількість спроб введення пароля. 6. При невдалому переборі сеанс зв'язку обривається.
Зменшити час очікування на авторизацію
LoginGraceTime 30sЗа промовчанням 120 секунд може тривати сеанс авторизації. Після цього часу він обривається. 2 хвилини на авторизацію - це перебір, весь цей час сервер тримає зв'язок відкритим, що дуже нераціонально. Півхвилини за очі вистачить.
Закрити доступ до IP
Перш ніж налаштовувати обмеження по IP, переконайтеся, що у разі помилки в налаштуванні та наступного бана власного IP у вас залишиться альтернативний спосіб повернути доступ до сервера
Якщо доступ потрібен тільки вам, найпростішим і надійнішим буде закрити доступ звідусіль, крім вашого IP або, якщо він динамічний, то діапазону IP.
- Відкриваємо /etc/hosts.allow та додаємо туди SSHD: 192.168.1.1
де 192.168.1.1 - ваш IP. Якщо у вас динамічний IP, визначте IP з маскою підмережі та запишіть Вашу підсіть замість IP, наприклад:
SSHD: 192.168.0.0/16
- Відкриваємо /etc/hosts.deny та додаємо туди: SSHD: ALL
Ще один спосіб обмеження доступу по IP
Можна скористатися такою директивою:
AllowUsers = *@1.2.3.4
Тут ми дозволяємо доступ лише для IP 1.2.3.4
Авторизація SSH за ключами
Набагато безпечніше, зручніше та правильніше буде налаштувати ssh авторизацію без пароля. Для цього використовуватиметься авторизація за ключом.
Отже, ось інструкція.
Ви придбали свій перший VPS, а може навіть одразу сервер. Напевно, у вас є веб-панель для його адміністрування. Але тру адміни, завжди ходять через консоль 😉 Тому треба навчитися це робити. У цьому уроці ми встановимо програму PuTTY, підключимося до сервера за протоколом SSH, і навчимося визначати зайнятий і вільний простір на сервері.
Програма Putty для з'єднання з сервером за протоколом SSH
Завантажуємо Putty із сайту putty.org Для себе я завантажую версію « For Windows on Intel x86 - PuTTY: putty.exe»
Розпаковуємо архів, запускаємо програму.
Ось так виглядає вікно програми після запуску. Я вже ввів IP-адресу свого сервера в полі «Host Name (or IP address)»:
Вводимо домен або IP-адресу свого сервера і натискаємо кнопку «Open». Відкриється вікно командного рядка. Воно запитує у нас логін та пароль користувача. Спочатку вводимо логін, потім пароль. Увага, під час води пароля — символи на екрані не друкуються, не друкуються навіть зірочки ***. Тому пароль вводимо як би наосліп. Вводимо та натискаємо Enter. Якщо пароль ввели правильно, відбувається вхід у консоль управління сервером. Виводиться рядок з часом останнього входу та інформація про операційну систему.
Команди у консолі
pwd
df
Команда df показує розмір вільного та зайнятого простору на сервері, у всіх змонтованих файлових системах
du
Команда du показує, скільки місця займає папка або файл.
Приклад команди:
Du -h /home/
Ця команда покаже, скільки місця займає директорія /home/
На цьому все. Перше знайомство з підключенням до сервера SSH і програмою putty закінчено. Використовуючи цю інформацію можна зайти на сервер, і подивитися, скільки місця займають дані на ньому.
