Ръководство за SSH на Secure Shell

Урок за този великолепен протокол, започнал своите приключения през 1997 г., предлагащ голямо разнообразие от инструменти, които се открояват със сигурността си, като е много обширен, ще го разделя на няколко статии, опитвайки се да обхване най -важното, както на ниво клиент, така и на ниво сървър.

Какво представлява протоколът Secure Shell?Secure Shell или SSH е мрежов протокол, който позволява обмен на данни по защитен канал между два компютъра. SSH използва техники за криптиране, които правят информацията, която преминава през комуникационния носител, нечетлива и никое трето лице не може да открие потребителското име и паролата на връзката или написаното по време на цялата сесия. SSH използва криптография с публичен ключ за удостоверяване на отдалечения компютър и му позволява да удостовери потребителя, ако е необходимо.

SSH обикновено се използва за стартиране на сесия на отдалечена машина, където можете да изпълнявате команди, но също така позволява тунелиране, произволно препращане на TCP портове и X11 връзки; Прехвърлянето на файлове може да се извърши и с помощта на свързани SFTP или SCP протоколи.

Можем да видим, че голямата му привлекателност е неговата характеристика повече от достатъчна, за да измести стария протокол TELNET, в който липсва криптиране на информация, компрометиране на данни, включително идентификационни данни за достъп.

The SSH сървър, по подразбиране предлага TCP порт 22. SSH клиент обикновено се използва за установяване на връзки към sshd сървър, който приема отдалечени връзки. И двете често се срещат в повечето съвременни операционни системи, включително Mac, Linux, Solaris и OpenVMS.

Поддръжката на Windows за версията на сървъра се очаква да бъде официално пусната тази година, докато на ниво клиенти предлага голямо разнообразие от опции, подчертаващи PuTTY пред останалите.

Научете се да използвате шпакловка

OpenSSHOpenSSH (Open Secure Shell) е набор от приложения, които позволяват шифровани комуникации през мрежа, използвайки SSH протокол. Той е създаден като безплатна и отворена алтернатива на SSH протокола, той е най -използваният в Linux и ще бъде този, който ще използваме в записите.

1. Инсталирайте Secure Shell SSH

В почти всички дистрибуции клиентската му версия е предварително инсталирана, докато сървърната версия е достъпна от хранилището, инсталацията й трябва да бъде много проста.

Debian, Ubuntu, Linux Mint и производни

 sudo apt-get инсталирайте openssh-сървър

Centos, Rhel, Fedora

 sudo yum инсталирайте openssh-сървър

Arch-Linux

 pacman -Syu openssh

Проверяваме дали работи с:

 curl localhost: 22

В случай, че работи правилно, той трябва да върне:

[color = # 696969] [/Цвят]

Свързване към сървъра
С помощта на клиента можем да се свържем със сървъра, който може да бъде отдалечен, дори ако имаме и двете версии за вътрешно свързване чрез localhost.

Най -основният начин за свързване би бил:

 ssh потребител @ hostaddress

В случай на вътрешно свързване би било:

 ssh потребител @ localhost

Имаме голямо разнообразие от опции при свързване, ще обясня някои много полезни, можете да изброите всичките си опции с:

 човек сш

Тук им показваме:

Man SSH опции
-° СИскайте компресиране на данни, спестявайки честотна лента или данни в случай, че сте в мобилна мрежа.

-лПосочете потребителя, с когото ще се свържем.

-ИСъздайте лог файл, в който стандартната грешка ще бъде отклонена.

-FИзбираме друг конфигурационен файл, полезен за сървъри с необичайни опции.

-gИзисква се за тунелиране на пристанища.

-iИзбираме папката, която ще използваме за алтернативен частен ключ.

-КАктивирайте, когато използвате идентификационни данни на GSSAPI.

-нИзползвайки го заедно с X11 по този начин, целият дневник, генериран от приложението, се пренасочва към / dev / null.

-илиИзисква се за използване на по -разширени опции като ServerAliveInterval 30.

-стрИзберете порт, различен от 22, за да се свържете с хоста.

-vТой показва всички стъпки, необходими за установяване на връзката. Можете да получите още повече информация с -vv -vvv.

-ХНеобходимо е, ако искаме да използваме X11 Forwarding.

-ДАктивира защитено препращане на X11.

Ще се свържем със сървъра test.solvetic.com с потребителя на jcarrillo, използвайки различен личен ключ, намиращ се в нашата / home / jcarrillo / keys-aws папка, използвайки порт 8022 на нашия екземпляр на AWS.

 Пример → ssh -C -i “~ / keys -aws /” -p 8022 -l jcarrillo test.solvetic.com

Както виждаме, това е обширен, но много пълен инструмент, който заслужава повече записи, за да може да покрие необходимите си функции за всеки Sysadmin на средно или професионално ниво.

Сега преминаваме към неговата конфигурация на ниво клиент-сървър, генериране на публични и частни ключове, използване на пренасочване на портове в реални ситуации, пренасочване на X сървъра чрез пренасочване X11, използване на scp, sftp, ssh-agent и др. .

2. Защитете SSH сървъра

Продължаваме с OpenSSH съсредоточаване върху защита на нашия SSH сървър, за да се избегнат всички видове атаки, които биха могли да компрометират нашия сървър. Всички тези конфигурации ще бъдат направени във файла sshd_config, намиращ се в / etc / ssh /, който можем да променим с всеки текстов редактор в моя случай vim:

 sudo vim / etc / ssh / sshd_config

Сега виждаме как да го променим.

Променете sshd_config
Вътре ще видим типичен конфигурационен файл, базиран на „Опция за стойност“ Ако някоя от опциите не е намерена по подразбиране, трябва да поставим реда изцяло, в други случаи това ще бъде само промяна от 0 на 1 от Не на Да или разкоментиране на ред.

Промяна на порт 22
От съществено значение е променете порта по подразбиране на произволен много скриптове са конфигурирани да атакуват този порт, препоръчително е да го промените в варират от 1000 до 23000 гарантира, че портът не се използва от друга услуга.

Също така не трябва да използваме портове като 2222, 8022 или 1022, те са също толкова често срещани, колкото 22 и много скриптове са конфигурирани да ги атакуват.

порт 2345

Ако имаме SELINUX активиран, трябва да използваме допълнителна команда, за да разрешим достъп отвън до новия порт.

Semanage порт -a -t ssh_port_t -p tcp 2345 #Промяна на порт 22 за сигурност

Използвайте протокол 2 по подразбиране
Трябва да се уверим, че всичките ни връзки са направени съгласно Протокол 2, тъй като 1 има много уязвимости.

Протокол 2

Време е да въведете идентификационни данни
Раздел за търсене „Удостоверяване“. Вашите първи две опции също са важни. Първият е броят секунди, които отдалеченият потребител ще трябва да влезе във вашата машина. Задайте тази стойност на няколко секунди, няма да отнеме много време за влизане, ако знаем акаунта и паролата.

По този начин избягваме определени скриптове, които се възползват от това време. Типичната стойност по отношение на сигурността е 30, въпреки че може да бъде дори по -малка.

ВходGraceTime 30

Деактивирайте коренния достъп
Това Това е най -важният вариант да бъдеш жертва на нападение, те се нуждаят от 3 неща:

• Потребител
• пристанище
• Парола

Ако деактивираме root, те вече имат такъв, тъй като root е общ потребител във всички системи. В допълнение към това, този потребител може да причини хаос, като има всички разрешения са разрешени.

PermitRootLogin не

Активирайте контролиран достъп
Можем да контролираме кой потребител да влезе чрез SSH и дори да поставим клауза за свързване само от определен IP. Това е подобно на това, което AWS предлага да ни свърже с вашите екземпляри.

AllowUsers [email protected]

Важно е да разрешите достъп само на потребители, които се нуждаят от отдалечен достъп, и ако е възможно да ги ограничите до известен IP.

Конфигурирайте броя на неуспешните опити
Ако поставим грешна парола, сървърът ни дава няколко опита да я въведем отново, това трябва да бъде ограничено или може да сте жертва на скрипт за груба сила, можем да го поставим 2 или 3 пъти.

MaxAuthTries 2

Брой разрешени връзки едновременно
Това може да варира в зависимост от това как използвате сървъра, но идеалното е той да бъде контролиран, просто добавете общия брой потребители, разрешени от SSH.

MaxStartups X

След като направим всички промени в нашия файл, ние трябва рестартирайте нашата sshd услуга, Тя може да варира в зависимост от мениджъра на услуги.

SystemD

 systemctl рестартирайте sshd

Upstart / Sysinit

 рестартиране на услугата sshd

Всички тези промени добавят a допълнително ниво на сигурност но трябва да имаме предвид:

• Използвайте буквено -цифрови пароли.
• Използвайте Удостоверяване чрез публични / частни ключове когато е възможно.
• Допълнете сигурността със SELINUX и защитни стени.
• Контролирайте достъпа, до който потребителите трябва да влизат отдалечено.

Удостоверете публичните / частните ключове на SSH

В момента се използва SSH ключове Това е незаменимо изискване, това удостоверяване се използва широко от администраторите за автоматизиране на задачи между различни сървъри и дори се използва от разработчиците за достъп до SCM като GIT, GITHUB, GITLAB и др.

Той предлага голяма сигурност и възможност за създаване на автоматизирани задачи базиран на скрипт като a обратно или Повторете промените към множество възли едновременно.

При използване на ключ SSH (публичен и частен), те могат лесно да се свързват с един сървър или няколко сървъра, без да се налага всеки път да въвеждат парола. Възможно е да конфигурирате ключовете си без парола, но това би било безразсъдно, ако някой получи вашия ключ, би могъл да го използва. Ще говорим за това как да генерираме ключове, да ги разпространяваме и да използваме ssh-agent, за да получим по-голяма сигурност.

Генериране на ключове без парола
На първо място, уверете се, че имате инсталиран OpenSSH, не е необходимо, сървърът е само клиентът.

Започваме с генериране на ключ тип DSA със защита 1024 бита, повече от достатъчно, въпреки че можете да отидете по -далеч и да генерирате ключ тип RSA с ограничение от 4096.

 ssh -keygen -b 1024 -t dsa

Той ще ни поиска местоположението, където ще запази ключовете по подразбиране ~ / .ssh

 Въведете файл, в който да запазите ключа (/home/test/.ssh/id_dsa)

Тогава той ще поиска фраза за сега няма да използваме нито една и ще я оставим празна и ще ни каже, че ключът е създаден и ни отразява.

Изображението винаги ще бъде различно, то се генерира на случаен принцип, тогава ако отидем в .ssh папката трябва да имаме 2 файла

id_dsa -----> Частен ключ (Не го споделяйте с никого, той е като вашия TDC).
id_dsa.pub ----> Това е този, който споделяме, за да се свържем.

Споделяне на публичен ключ
В случай, че искаме да споделим публичния ключ в SCM или Chef, Puppet, Jenkins, визуализираме файла с публичен ключ, копираме го и го поставяме там, където съответства.

 повече id_dsa.pub SSH-DSS AAAAB3NzaC1kc3MAAACBAN6SEI4Qqzb23pJYRXIAtPmGJHln5hFdthFq43ef + ifR29v2IknXCFwefKK8jorSDiUEY / 1Е / yp0xao mjhFQu1jNXOgF0PAZTfivRVFn6Q9FRsyXU9s + FX + + L22sV7GkCHPxAAAAFQCyF1Gdh3 xQiW3mf3y4IX654O82SLGl7Vhh5UsvG8r8d8pV6R Cap4xr / J44xDDn 0gFArHmFwAxfQAAAIEAmVYjPYAdQ9DCNWP + + + 03anWgyoZqSPPs23djyVQ756U4VitM0GiIQQ89HCdvTFFpSagnfdVpWh4 Hxo4Y5skKihnPMtB bFNbP / 2SmGdPz1AOmb7tvRrTkj5VLtXeDeB3ulowUKarwiBVVvAvxtxmozoZHOADWqrEPizxIAAACAU2DF1ZGTiJMP OhVB7mlsVhhkq53OxKKJbZqsl9hkOiSxaLUfQBNu6Ae441ekIObqolWNCBIvCO3uQYOozyzNGBhqHE7FVq 1oXguj + + + 2GAQ UGNkee96D2by S7daieIKNmFer2hO / SBxzepMrWAiIUnUsP5irmYspkjGlQxP + hxw = тест @ solvetic 

В случай, че искате да го споделите за достъп до сървър, винаги препоръчвам използването на ssh-copy-id е включено в OpenSSH и е много лесно за използване:

 ssh-copy-id потребител @ remote-server-ip -i посочва местоположението на ключа, който да се използва.

Има и други начини като:

 ssh потребител @ remote-server-ip \ 'cat >> .ssh / авторизирани_ключове2' <.ssh / id_dsa.pub

 scp ~ / .ssh / id_dsa.pub потребител @ remote-server-ip

Отсега нататък ключовете са свързани и трябва само да влезете в хоста.

 ssh -l потребител remote-server-ip

Този път той няма да иска парола и можем да използваме скриптове без взаимодействие.

Генерирайте парола и свържете с ssh-агент
The Защита на SSH ключ Той се основава на нашия личен ключ, който работи като карта за достъп, но ако някой открадне нашия ключ, той ще има достъп до всички места, където имаме достъп. Но когато генерираме парола, можем да имаме допълнително ниво, ключът не само е необходим, но и не е нужно да въвеждаме нашата фраза.

Този път ще създадем rsa ключ с по -голяма сигурност чрез конфигуриране на фраза.

 ssh -keygen -b 4096 -t rsa -C "Ключ с паролна фраза" # -C Добавете коментар. 

Като фраза можем да използваме интервали, точки и специални знаци

 пример ---> Това е моят нов ключ с Fr @ S3.

Споделяме новия ключ:

 scp ~ / .ssh / id_rsa.pub потребител @ remote-server-ip

Този път имаме нужда от ключа и паролата, но въвеждането му няколко пъти е досадно, но можем да го допълним с ssh-agent, трябва да го стартираме.

 ssh-агент

Добавяме нашия ключ

 ssh-add Въведете парола за /home/user/.ssh/id_rsa: # Въвеждаме конфигурираната фраза. 

Сега можем да се свържем с всеки сървър, който използва нашия ключ, без да се налага да въвеждаме нашия паролна фраза.

Препоръчвам този метод, ако сте извън интранет, клиент и сървър в различни точки на Интернет и няма да използваме автоматизирани задачи, а по -скоро се свързваме със сървъра за целите на отдалечено администриране, най -добре е да посочите парола или много дълго паролна фраза (15 или повече знака, главни, малки букви, цифри и символи) към публичния ключ.

Насам ще бъде практически невъзможно да бъде хакнат по този метод, тъй като хакерът не само ще трябва да знае паролата, но и ще трябва да има валиден публичен сертификат на сървъра, за да може да бъде удостоверен. (Разбира се, ако приемем, че сървърът никога не е бил компрометиран и е напълно актуален и с възможно най-добрата сигурност).

Хареса ли ви и помогнахте на този урок?Можете да възнаградите автора, като натиснете този бутон, за да му дадете положителна точка