У дома интернет Свързване към ubuntu чрез ssh putty. Използване на SSH за свързване към отдалечен Ubuntu сървър. Настройки на SSH клиент

Свързване към ubuntu чрез ssh putty. Използване на SSH за свързване към отдалечен Ubuntu сървър. Настройки на SSH клиент

Така че в интернет, разбира се, има голяма сумапримери за инсталиране на SSH, но това е лош късмет 🙂 не всички подробности са описани навсякъде и понякога не е лесно за начинаещ в тази ситуация, аз го изпитах сам ... И така, ето пълно и подробно описание на инсталирането на великият и могъщ SSH.

Първо, нека инсталираме SSH на машината, към която планираме да се свържем. За да направите това, в конзолата (командния ред, терминал) въведете командата:

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

След тази команда SSH автоматично ще бъде намерен и инсталиран (разбира се, трябва да се свържете с великия и могъщ Интернет). След това трябва да конфигурирате. Цялата конфигурация на нашия сървър се извършва чрез промяна на файла /etc/ssh/sshd_config. Но първо бих препоръчал да направите резервно копие на оригиналния конфигурационен файл. За това пишем:

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.original

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

sudo nano /etc/ssh/sshd_config

Ще видите следните директиви:

Порт 22 - указва порта, на който сървърът ще слуша за входяща връзка. Например, порт 1234 означава, че ще бъде възможно да се свържете към сървъра на порт 1234. Но стандартният е порт 22, въпреки че бих препоръчал да го промените, тъй като именно от този порт „недружелюбните личности на интернет просторите“ започнете да хакнете сървъра.
PermitRootLogin не - по-добре е да се зададе стойност не. Това ще ви попречи да влезете като root.
ListenAddress указва кой протокол/интерфейс ще слуша ssh.
Протокол - позволява ви да изберете протокол версия 1 или 2. Препоръчва се протокол 2.
HostKey - ключови файлове за втората версия на SSH протокола
PermitEmptyPasswords не - забранете празните пароли, надеждността не вреди.
UsePrivilegeSeparation - най-добре е да оставите включено за сигурност.
AllowUsers Goodboy - този параметър го няма в конфигурацията, съветвам ви да го добавите. Goodboy - името на вашия потребител (всеки има свое, разбира се, това е само пример). Този параметър задава разрешение за влизане само и само с това име, ssh се пробива не само за парола, но и за системни или стандартни имена. Например apache, www, който по някаква причина може да се окаже без парола, или andy, bobby, anna и т.н. Можете да добавите ip адрес към името на Goodboy - [имейл защитен]- ако сте сигурни, че на клиентската машина винаги е този непроменен адрес. Тази опция ще позволи само на потребител Goodboy да влезе в системата и само ако неговият хост съвпада с посочения. По принцип това, разбира се, не е необходимо, но пет, допълнителната защита няма да навреди.

Ние преконфигурираме тези настройки, от които се нуждаете допълнително, след това натиснете бутона F3, за да запазите и след това Enter, за да потвърдите и F2, за да излезете обратно от конзолата.

След това рестартирайте SSH демона:

sudo /etc/init.d/ssh рестартирайте

Тогава можем да се свържем с него. По правило сървърът е на Linux, а работещите машини обикновено са на Windows, след което ще се свържем със сървъра през операционната система Windows. За да направите това, на машината, с която планираме да се свържем, инсталираме 2 програми: Замазка— за достъп до командния ред на сървъра, WinSCP- за по-удобни стандартни операции за копиране, изтриване, преместване, създаване на папки на сървъра и т.н. Последната програма с интерфейса си прилича на аналог тотален командир, Far manager и подобни програми. Всъщност можете да използвате не само WinSCP, но и горните програми, както и FileZilla и други, но е по-лесно, по-удобно и по-малко проблематично да настроите и да работите, според мен, текущата програма. Така че, за да се свържете, просто трябва да посочите порта, към който искате да се свържете, по подразбиране 22, ако не сте го променили, и след това името на хоста или неговия IP адрес. Тъй като сървърите обикновено се поставят на статични IP адреси, това не е проблем.

Благодарим ви за проявения интерес към нашия сайт. Компанията за ИТ специалисти съществува от 2006 г. и предоставя ИТ аутсорсинг услуги. Аутсорсингът е прехвърляне на необходима, но неосновна за компанията работа на друга организация. В нашия случай това са: създаване, поддръжка и поддръжка на сайтове, популяризиране на сайтове в търсачките, поддръжка и администриране на сървъри, работещи под Debian GNU/Linux.

Сайтове на Joomla

В сегашната ера на информация, сайтът де факто се превръща най-малкото в отличителен белег на организацията, а често и в един от бизнес инструментите. Вече се създават уебсайтове не само за организации и лица, но и за отделни стоки, услуги и дори събития. Днес сайтът е не само източник на реклама за огромна аудитория, но и инструмент за продажби и създаване на нови контакти. Създаваме уебсайтове с помощта на CMS Joomla! Тази система за управление на съдържанието е проста и интуитивна. Той е много разпространен и затова има много информация за него в интернет. Намирането на специалист, работещ с Joomla също е лесно. И не е нужно да ходите далеч! Нашият ИТ специалист се занимава с поддръжка и поддръжка на сайтове на Joomla! Ние ще извършим цялата техническа работа, ще се погрижим за цялата кореспонденция с хостера и регистратора на домейни, ще попълним сайта и ще актуализираме информацията в него. И въпреки че Joomla е лесна за управление, тя е интуитивна. Но вие сами ще извършвате редовно необходимата работа на сайта? Колко време ще ви вземат? Ако искате да се концентрирате върху бизнеса си, тогава поверете поддръжката на вашия сайт на нас. Ние ще направим всичко по силите си, за да поддържаме сайта жив и полезен на собственика си.
Ако сте търговска организация, която рекламира или продава своите стоки, услуги в Интернет, тогава просто трябва да популяризирате сайта си в търсачките. В крайна сметка, за да продадеш нещо, трябва поне да те видят, да те разберат. И ние ще ви помогнем с това, ще популяризираме вашия Joomla сайт в търсачките. В зависимост от конкуренцията и бюджета, отделен за промоция, вашият сайт ще заеме достойна позиция в Резултати от търсенето. Сайтът ще увеличи печалбите ви!

Debian сървъри

Рано или късно, стремейки се към откритост и прозрачност на своя бизнес, много компании се сблъскват с необходимостта да гарантират чистотата на лицензираните софтуер. Разходите за лицензионни такси обаче далеч не винаги са приемливи, особено за малкия и среден бизнес. Изходът от тази трудна ситуация е решението за преминаване към технологията с отворен код. Едно от направленията на Open Source е операционната Linux система(Linux). Служителите на нашата компания са специализирани в Debian Linux (Debian Linux). Това е най-старата и най-стабилна дистрибуция операционна система Linux. Ние ви предлагаме услуги за внедряване на Debian Linux във вашето предприятие, конфигурация, поддръжка и поддръжка на сървъри.

Информация и реклама

Тази статия е относно настройките за отдалечен достъп за Ubuntu Server. Принципът на свързване е много прост: от страна на клиента използваме програма за отдалечен достъп (например Putty), от страна на сървъра инсталираме и конфигурираме пакета OpenSSH. При свързване клиентът преминава през процедурата за авторизация на сървъра и между тях се установява криптирана връзка. По-подробно принципът на работа на SSH протокола беше разгледан в статията за.

Диаграмата на мрежата е показана по-долу. Дистанционна връзкакъм сървъра ще се извършва от клиентския компютър.

Инсталирахме Ubuntu Server на празен твърд диск. След инсталирането трябва да конфигурирате мрежовия интерфейс на сървъра за достъп до мрежата. А именно, задайте IP адрес, мрежова маска, шлюз по подразбиране. Ако вашият интерфейс вече е конфигуриран, можете да пропуснете тази стъпка. Настройките на мрежовия интерфейс са посочени във файла /etc/network/interfaces. Използвайте текстов редактор за редактиране нано.

Влизаме в режим на редактиране на файла с интерфейси. Интересуваме се от всичко по-долу # Основният мрежов интерфейс. AT този моментсървърът получава IP адрес чрез DHCP, което не е съвсем правилно. Сървърът трябва да има статичен IP, така че всички възли в мрежата да знаят точния му адрес. Нека напишем мрежовите настройки ръчно.

Моят сървър е в локалната подмрежа 192.168.1.0/24. На сървъра е присвоен IP 192.168.1.2, маска 255.255.255.0, шлюз по подразбиране 192.168.1.1, адрес на DNS сървър 192.168.0.1

За да запазите файла, натиснете Ctrl + X –> Y –> Enter. За да приложите настройките, трябва да рестартирате мрежовия процес. Можете също така просто да рестартирате сървъра с командата sudo reboot.

проверка (команда ifconfig -a) – приложени настройки

Всичко е готово за OpenSS, който може да се инсталира от терминала с командите

$ sudo apt-get инсталирайте openssh-клиент

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

Можете да контролирате стартирането, спирането и рестартирането на SSH сървъра с помощта на командите

$ sudo обслужване ssh спирам | начало | рестартирам

Всъщност вече имате SSH достъп до сървъра. Но за повече фина настройкаима конфигурационен файл в /etc/ssh/sshd_config. Достъпът до конфигурациите се осъществява само от root.

От страна на клиента изтегляме всяка програма за свързване чрез SSH, препоръчвам Putty. Програмата ще трябва само да въведе IP адреса на сървъра и да се свърже с него. Когато се свързвате, въведете потребителско име и парола.

Абонирайте се за нашия

Благодаря MadKox

Пример за конфигурационен файл

# Конвенции: #
# Под "по подразбиране" се има предвид поведението на sshd, когато #
# към неопределена директива. Струва си да се отбележи, че в Ubuntu #
# файлът sshd_config вече съдържа редица настройки, които #
# са настройките по подразбиране специално за Ubuntu. #
# Такива настройки са посочени в този файл. #
# #

################# Настройки на адрес/порт и др. ###########
############################################################
# #
## Порт ################################################# #####
# #
# Портът за използване. Можете да посочите няколко, например: #
# Порт 22 #
# Порт 23 #
# Порт 24 #
# Препоръчително е да използвате нестандартен порт, т.к #
# стандартът често се сканира от ботове за #
# потенциални "дупки". Може да се пропусне, ако е даден #
# чрез адрес. Вижте също параметъра ListenAddress. #
# #
Порт 8022
# #
## ListenAddress #############################################
# #
# Мрежовият адрес, на който сървърът "слуша". Адресът може да бъде #
# пишете така: #
# ListenAddress host|IPv4_addr|IPv6_addr #
# ListenAddress host|IPv4_addr:port #
# ListenAddress :порт #
# Ако портът не е зададен, sshd ще слуша този адрес и #
# на порта, посочен в опцията Port. Ако ще бъдеш #
# използвайте ListenAddress без да посочвате порт, след това опция #
# Портът трябва да предхожда опцията ListenAddress. Ако не #
# посочете, след това слуша всички локални по подразбиране #
# адреса. Можете да посочите няколко адреса. #
# #
## АдресСемейство ###############################################
# #
# Указва кое семейство IP адреси трябва да бъде #
# използван sshd. Възможни опции: #
# "всички" всякакви #
# "inet" (само IPv4) #
# "inet6" (само IPv6) #
# По подразбиране е "всеки". #
Адрес Семейство инет
# #
## Използвайте DNS ################################################## ##
# #
# Указва дали sshd трябва да проверява името на хоста и #
# използвайте това име, за да проверите IP адреса, даден от клиента срещу #
# получено от DNS. #

# #
############################################################
############## Настройки за потребителски достъп ###############
############################################################
# #
# Разрешаване/не допускане на потребителя се определя от директиви #
# DenyUsers, AllowUsers, DenyGroups и AllowGroups. #
# в същото време проверката върви отгоре надолу по веригата: #
# ## DenyUsers ## #
# || #
# ## AllowUsers ## #
# || #
# ## DenyGroups ## #
# || #
# ## AllowGroups ## #
# Приемат се само имена на потребители и групи, цифрови #
# идентификатора (UserID) не са разпознати. правилен #
# записване на множество потребители/групи на свой ред, чрез #
# интервал. Ако е написано като user@host тогава #
# потребител и хост се проверяват отделно, това позволява #
# ограничаване на достъпа до определени потребители с #
# конкретни хоста. Струва си да се помни, че директивите #
# DenyUsers и AllowUsers приемат като параметър #
# потребителско име и име на DenyGroups и AllowGroups #
# групи. Вижте ШАБЛОНИ в man ssh_config за повече #
# информация за формите на писане на потребителски имена и групи. #
# #
## DenyUsers #################################################
# #
# Списък с ПОТРЕБИТЕЛИ, които НЕ ТРЯБВА да се използват от sshd. #
# По подразбиране не е посочено = никой не е забранен. Тези. ако #
# тук е посочен потребител, достъпът ще бъде отказан #
# към ssh сървъра. #
# #
## AllowUsers ################################################
# #
# Списък на ПОТРЕБИТЕЛИТЕ, които sshd МОЖЕ да използва, #

# поне един указан потребител, ssh достъп до сървъра #
# е достъпен само за него. #
# #
## DenyGroups ################################################
# #
# Списък с ГРУПИ, които НЕ ТРЯБВА да се използват от sshd. #
# Не е посочено по подразбиране = няма забранени групи. #
# т.е. ако е посочена поне една група, тогава потребители, #
На # членове на тази група ще бъде отказан достъп до ssh #
# сървър. #
# #
## AllowGroups ################################################
# #
# Списък от ГРУПИ, които sshd МОЖЕ да използва. #
# Не е посочено по подразбиране = всички са разрешени. Тези. ако #
# посочена е поне една група, след това само тези потребители#
# които съдържа, ще бъде разрешен достъп до ssh сървъра.#
# #
############################################################
######### Опции за откриване на състоянието на връзката ###########
############################################################
# #
## TCPKeepAlive #############################################
# #
# Показва дали системата трябва да изпраща TCP съобщения до клиента #
# за поддържане на връзката. Ако изпратите тези пакети, #
# можете да дефинирате прекъсване на връзката. Това обаче също е #
# означава, че връзката може да бъде прекъсната, ако #
# моментно прекъсване на маршрутизирането и #
# Някои хора намират това за много досадно. От друга страна, ако #
# сесии на сървъра не могат да изпращат такива съобщения #
# последно за неопределено време, раждайки "призрачни" потребители,#
# и поглъщане на сървърни ресурси. Стойност по подразбиране „да“, #
# т.е. изпращайте такива съобщения. За да деактивирате изпращането на #
# от такива съобщения трябва да бъде зададено на „не“. По-рано този #
# опцията беше наречена KeepAlive. Струва си да се отбележи, че #
# има по-сигурни начини за проверка на състоянието #
# връзки (вижте по-долу). #
# #
TCPKeepAlive да
# #
## ClientAliveCountMax ########################################
# #
# Задава броя на съобщенията до клиенти, които sshd #
# изпраща последователно, без да получава отговор от #
# клиент. Ако прагът е достигнат и #
# клиентът никога не е отговорил sshd ще прекъсне връзката с клиента чрез прекъсване #
# ssh сесия. Струва си да се отбележи, че използването на такъв #
# messages е фундаментално различен от директивата TCPKeepAlive. #
# Съобщенията до/от клиенти се изпращат през криптирани #
# канал и следователно не са подправени. Същите съобщения #
# TCPKeepAlive е подправен. Клиентът на механизма е жив #
# особено ценно в случаите, когато сървърът и клиентът трябва #
# знам кога връзката е станала неактивна. По подразбиране #
# стойността е 3. В случай, че ClientAliveInterval #
# е зададено на
5 и ClientAliveCountMax напусна с #
# по подразбиране неотговарящите клиенти ще бъдат прекъснати приблизително #
# след 45 секунди. Тази директива работи само за #
# ssh2 протокол. #
# #
## ClientAliveInterval ########################################
# #
# Задава времевия интервал в секунди. Ако в рамките на #
# този интервал не е имало комуникация с клиента, sshd #
# изпраща съобщение през криптиран канал, #
# искане на отговор от клиента. По подразбиране е 0, т.е. #
# не изпращайте такива съобщения. Тази директива работи #
# само за ssh2 протокол. #
# #
############################################################
################ Общи опции за удостоверяване #################
############################################################
# #
## AuthorizedKeysFile ########################################
# #
# Указва файла, който съдържа публичните ключове, #
# се използва за удостоверяване на потребителите. Директива №
# може да съдържа маркери от формата %M, които са заместени в #
# процесът на установяване на връзка. #
# Дефинирани са следните маркери: #

# Така ключовият файл може да бъде определен като #
# абсолютен път (т.е. един общ файл с ключове) и #
# динамично в зависимост от потребителя (т.е. според #
# файл на потребител). #
# По подразбиране е “.ssh/authorized_keys”. #
# Пример за ключов файл в домашната папка на потребителя: #
# AuthorizedKeysFile %h/.ssh/authorized_key #
# Пример за общ файл: #
# AuthorizedKeysFile /etc/ssh/authorized_keys #
# Вижте описанието на файла authorized_keys за повече #
# информация. #
# #
## ChallengeResponseAuthentication ############################
# #
# Показва дали да се разреши удостоверяване с въпроси и отговори #
# (удостоверяване на предизвикателство-отговор). Всички поддържани #
# типове удостоверяване от login.conf По подразбиране "yes", #
# т.е. позволява. #
# Деактивирано в Ubuntu от съображения за сигурност. #
# #
ChallengeResponseAuthentication no
# #
## HostbasedUsesNameFromPacketOnly ############################
# #
# Указва как сървърът трябва да получи името на хоста на клиента #
# със схема за удостоверяване, базирана на проверка на хост. #
# Ако е зададено на "yes" при проверка за последователност във файлове #
# ~/.shosts, ~/.rhosts или /etc/hosts.equiv sshd ще бъде #
# използвайте името на хоста, предоставено от клиента. #
# (извършване на обратна DNS резолюция) Ако е зададено на "не"#
# sshd ще разреши името от самата TCP връзка. #
# По подразбиране е "не". #
# #
## IgnoreRhosts ##############################################
# #
# Деактивира използването на .rhosts и .shosts файлове #
# по време на базирано на хост удостоверяване. #

# Файловете /etc/hosts.equiv и /etc/ssh/shosts.equiv са все още #
# са използвани. #
# По подразбиране е "да". #
# #
IgnoreRhosts да
# #
## IgnoreUserKnownHosts ########################################
# #
# Указва дали sshd трябва да игнорира потребителските имена #
# "познати хостове" файл ~/.ssh/known_hosts в процес #
# удостоверяване въз основа на проверка на хост #
# (RhostsRSAAuthentication или HostbasedAuthentication). #
# По подразбиране е "не". #
# #
## Разрешаване на ключове в черния списък ######################################
# #
# Показва дали sshd трябва да приема ключове, изброени в #
# черен списък като компрометиран (известен-компрометиран #
# ключове (вижте ssh-vulnkey)). Ако е зададено на "да" #
# опити за удостоверяване с такива ключове ще бъдат регистрирани #
# регистриране и прието, ако стойността е „не“ опити #
# удостоверявания ще бъдат отхвърлени. #
# По подразбиране е "не". #
# #
## PermitEmptyPasswords ######################################
# #
# Ако е разрешено удостоверяване с парола, #
# показва дали е възможно влизане с празна парола. #
# По подразбиране е "не". #
# #
PermitEmptyPasswords бр
# #
## PermitRootLogin ############################################
# #
# Показва дали ssh влизането като суперпотребител е разрешено #
# (корен). Може да приема стойности: #
# "да" суперпотребител може да влезе. Прилага #
# текуща глобална схема за удостоверяване. #
# #
# суперпотребител "без парола" може да влезе. #
# Удостоверяването с парола за него ще бъде деактивирано. #
# #
# „само за принудителни команди“ суперпотребител ще може да влиза, #
# използване на удостоверяване с публичен ключ и #
# само ако предава команда за изпълнение. #
# Това е полезно за архивиране, #
# дори когато е нормално (т.е. не чрез ssh) #
Влизането на # суперпотребител е отказано. Всички други методи #
# Удостоверяванията за суперпотребител ще бъдат деактивирани.#
# #
# „не“ суперпотребител не може да използва ssh за #
# Влизам. #
# #
# Стойността по подразбиране е "да". #
# #
PermitRootLogin №
# #
## Протокол ################################################## #
# #
# Указва кой протокол трябва да използва sshd. #
# Възможни стойности'1' и '2' ssh1 и ssh2 #
# съответно. Възможен е едновременен запис с #
# които трябва да бъдат разделени със запетаи. #
# По подразбиране е “2.1”. #
# Обърнете внимание, че редът на протокола в #
# запис не задава приоритет, защото клиентът избира кой #
# от няколко протокола, предложени му от сървъра #
# използване. Нотацията "2,1" е точно същата #
# записа "1,2". #
# #
Протокол 2
# #
## UsePAM ################################################## ##
# #
# Активира PAM (Pluggable Authentication Module) интерфейс #
# интерфейс). Ако е зададено на "да" за всички типове #
# удостоверяване в допълнение към обработката на модула за сесия и акаунт #
# PAM ще използва удостоверяване въз основа на #
# заявка-отговор (ChallengeResponseAuthentication и #
# PasswordAuthentication) удостоверяване #
# заявка-отговор в PAM обикновено изпълнява същата роля като #
# същото като удостоверяването с парола, трябва да деактивирате #
# или PasswordAuthentication или #
# ChallengeResponseAuthentication. Струва си да се отбележи, че #
# ако директивата UsePAM е активирана, няма да можете да стартирате #
# sshd като потребител, различен от root. #
# Стойността по подразбиране е "не". #
# #
Използвайте PAM да
# #
## Удостоверяване на парола ####################################
# #
# Показва дали е разрешено удостоверяване чрез #
# парола. #
# По подразбиране е "да". #
# #
PasswordAuthentication да
#
## HostKey ################################################## #
# #
# Указва файла, съдържащ частния хост ключ, #
# SSH за използване. По подразбиране /etc/ssh/ssh_host_key #
# за ssh протокол
и /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
# #
## RhostsRSAAудостоверяване ###################################
# #
# Показва дали е необходимо удостоверяване на базата на файлове #
# rhosts или /etc/hosts.equiv заедно с успешно #
# хост удостоверяване чрез RSA. #

# По подразбиране е "не". #
# #
RhostsRSAAутентификационен номер
# #
## RSAAудостоверяване #########################################
# #
# Показва дали е разрешено "чисто" RSA удостоверяване. #
# Приложимо само за ssh1 протокол. #
# По подразбиране е "да". #
# #
RSAAудостоверяване №
# #
## ServerKeyBits ###############################################
# #
# Указва броя на битовете във временния ключ на сървъра за #
# ssh1 протокол. Минимална стойност 512. #
# Стойността по подразбиране е 1024. #
ServerKeyBits 1024
# #
############################################################
########### Опции за протокол SSH версия 2 (ssh2) #############
############################################################
# #
## Шифрове ################################################# #
# #
# Указва разрешените алгоритми за криптиране за #
# 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, #
# aes192-ctr, aes256-ctr #
# #
## Базирано на хост удостоверяване ###################################
# #
# Показва дали е позволено удостоверяване въз основа на #
# проверка на хоста. Проверка на rhosts или /etc/hosts.equiv, #
# и ако е успешно, съвместно с успешно валидиране #
# публичен ключ, достъпът е разрешен. Тази директива #
# е същото като RhostsRSAAuthentication директивата и #
# валидно само за ssh2 протокол. #
# По подразбиране е "не". #
# #
Базирано на хост удостоверяване №
# #
## MACs ################################################## ####
# #
# Показва валиден MAC алгоритъм (съобщение #
# код за удостоверяване). Използван MAC алгоритъм #
# ssh2 за защита на целостта на данните. Няколко #
# от алгоритмите трябва да бъдат разделени със запетаи. #
# По подразбиране са: #
# hmac-md5,hmac-sha1, [имейл защитен],hmac-ripemd160, #
# hmac-sha1-96,hmac-md5-96 #
# #
## PubkeyAuthentication ######################################
# #
# Показва дали удостоверяването е разрешено въз основа на #
# публичен ключ. От значение само за протокола ssh2. #
# По подразбиране е "да". #
# #
PubkeyAuthentication да
############################################################
#################### Опции на GSSAPI ###########################
############################################################
# #
############# Приложимо само за ssh2 протокол ############
# #
## GSSAPIAудостоверяване #####################################
# #
# Показва дали удостоверяването на потребителя е разрешено на #
# базиран на GSSAPI. По подразбиране е "не", т.е. забранено. #
# #
## GSSAPIKeyExchange ##########################################
# #
# Показва дали обменът на ключове въз основа на # е разрешен
#GSSAPI. Обменът на GSSAPI ключове не разчита на #
# ssh ключове при проверка на самоличността на хоста. #
# По подразбиране "не", т.е. замяната е забранена. #
# #
## GSSAPICleanupCredentials ##################################
# #
# Показва дали да се унищожи автоматично #
# персонализиран кеш за идентификационни данни за удостоверяване, когато #
# край на сесията. #
# По подразбиране "да", т.е. трябва да бъдат унищожени. #
# #
## GSSAPIStrictAcceptorCheck #################################
# #
# Показва колко строга трябва да бъде проверката #
# самоличност на клиента при удостоверяване чрез GSSAPI. #
# Стойност "yes" кара клиента да се удостовери в #
# приемащата хост услуга на текущия хост. Значение "не" #
# позволява на клиента да се удостовери с всеки #
# от ключа за услуги. #
# Стойността по подразбиране е "да". #
# Обърнете внимание, че задаването на стойността на "не" може #
# работи само с редки Kerberos GSSAPI библиотеки. #
# #
############################################################
################### Опции за Kerberos #########################
############################################################
# #
## KerberosAuthentication ####################################
# #
# Показва дали предоставената парола # изисква
# потребител за удостоверяване #
# (PasswordAuthentication) валидации в Kerberos KDC. #
# За да използвате тази опция, сървърът се нуждае от #
# уверете се, че KDC е верен. (Сървърът се нуждае от #
# Kerberos servtab, който позволява проверката на #
# Самоличността на KDC) #
# По подразбиране е "не". #
# #
## KerberosGetAFSToken #######################################
# #
# Ако AFS е активен и потребителят е получил Kerberos 5 TGT, #
# дали да опитате да получите AFS токен преди потребителя #
# ще има достъп до началната си папка. #
# По подразбиране е "не". #
# #
## KerberosOrLocalPasswd #####################################
# #
# Указва какво да се направи, ако удостоверяването #
# неуспешно чрез Kerberos. Ако #
# стойност = "да" паролата ще бъде потвърдена с #
# всеки допълнителен локален механизъм за оторизация, #
# например /etc/passwd. #
# По подразбиране е "да". #
# #
## KerberosTicketCleanup #####################################
# #
# Указва дали файлът да се унищожи автоматично с #
# кеша за билети на потребителя, когато сесията приключи. #
# По подразбиране е "да". #
# #
############################################################
################## Опции за пренасочване #####################
############################################################
# #
## AllowAgentForwarding #######################################
# #
# Указва дали да разрешите или откажете пренасочването #
# ssh-agent"a. По подразбиране е "да", т.е. позволява. #
# Обърнете внимание, че деактивирането на пренасочванията не #
# увеличете сигурността, докато потребителите също #
# достъпът до обвивката е отказан, защото винаги могат да зададат #
# вашите собствени агенти. #
# #
AllowAgentForwarding №
# #
## AllowTcpForwarding #######################################
# #
# Указва дали да разреши или забрани TCP пренасочване. #
# По подразбиране е „да“, т.е. позволява. Струва си да се отбележи, #
# какво като в случая с AllowAgentForwarding деактивиране #
# пренасочванията няма да повишат сигурността, освен ако #
# потребители ще имат конзолен достъп, защото те могат #
# инсталирайте вашите колеги. #
# #
# #
AllowTcpForwarding №
# #
## GatewayPorts ###############################################
# #
# Указва дали да се разреши достъп на отдалечени хостове до #
# пренасочени порта. По подразбиране sshd слуша #
# връзки към пренасочени портове само на localhost #
# интерфейс (loopback). Не дава друго дистанционно #
# хостове се свързват с пренасочени портове. Мога #
# използвайте GatewayPorts, за да позволите на sshd да направи това #
# направи. Директивата може да приема 3 стойности: #
# само "не" обратна връзка. #
# "да" - всякакви адреси. #
# "клиентски" адреси, посочени от клиента. #
# #
Портове на шлюза №
# #
## PermitOpen #################################################
# #
# Указва къде е разрешено препращането на TCP порт. #
# Подсказката за пренасочване трябва да вземе един от #
# от следните форми: #
# PermitOpen host:port #
# PermitOpen IPv4_addr:port #
# Разрешение за отваряне: порт #
# Могат да бъдат посочени множество записи, като се разделят с интервали. #
# Аргументът “any” може да се използва за премахване на всички #
# забрани за пренасочване на портове. По подразбиране е всеки #
# разрешено пренасочване. #
# #
## PermitTunnel ###############################################
# #
# Показва дали пренасочването на tun устройство е разрешено. #
# Може да приема стойности: #
# "да" #
# „точка до точка“ (3-то мрежов слой) #
# “ethernet” (втори мрежов слой) #
# "не" #
# Стойността "да" позволява едновременно "точка до точка" #
# и "ethernet". По подразбиране е "не". #
# #
############################################################
################## Опции за регистриране #####################
############################################################
# #
## SyslogFacility ############################################
# #
# Указва обектния код на журнала за писане на съобщения до #
# syslogот sshd. Възможни стойности: #
#ДЕМОН#
#ПОТРЕБИТЕЛ#
#AUTH#
#МЕСТЕН0#
#МЕСТЕН1#
#МЕСТЕН2#
#МЕСТЕН3#
#МЕСТЕН4#
#МЕСТЕН5#
#МЕСТЕН6#
#МЕСТЕН7#
# По подразбиране е AUTH. #
# #
SyslogFacility AUTH
# #
## LogLevel #################################################
# #
# Задава нивото на подробност на sshd журнала. #
# Възможни опции: #
#ТИХА#
#ТИХО#
#ФАТАЛЕН#
# ГРЕШКА #
#ИНФО#
#ГОЛОВНО#
#DEBUG#
#DEBUG1#
#DEBUG2#
#DEBUG3#
# По подразбиране е INFO. #
# DEBUG и DEBUG
са еквивалентни един на друг. #
# DEBUG2 и DEBUG3 задават най-високите нива на отстраняване на грешки #
# изход. Регистрирането с ниво на DEBUG заплашва #
# поверителност на потребителя и не се препоръчва. #
# #
LogLevel INFO
# #
############################################################
##################### Пренасочване на X

####################
############################################################
# #
## X11 Препращане #############################################
# #
# Показва дали е разрешено графично пренасочване #
# X11 подсистеми. Може да приема стойностите "да" или "не". #
# По подразбиране е "не". #
# Внимание, позволяващо просто пренасочване на X11 #
# голям риск както за сървъра, така и за клиентите, т.к в #
# в случай на такова пренасочване на прокси показва sshd #
# приема връзки от всеки адрес. Използвайте #
# директива X11UseLocalhost за ограничаване на достъпа до #
# към сървъра за пренасочване "x". Струва си да се отбележи, че #
# деактивирането на пренасочването няма да гарантира, че #
# потребители няма да могат да пренасочат X11, защото имам #
# конзолен достъп те винаги задават свой собствен #
# пренасочващ. Пренасочването на X11 ще бъде #
# автоматично деактивирано, ако е активирано #
# UseLogin директива. #
# #
X11 Препращане №
# #
## X11UseLocalhost ###########################################
# #
# Показва дали sshd трябва да ограничи обхвата #
# пренасочете X11 към локален loopback адрес или #
# трябва да позволява всякакви адреси. Sshd по подразбиране #
# "засажда" сървъра за пренасочване на X11 към локален адрес #
# и задава частта от променливата на средата DISPLAY, съответстваща на #
# за име на хост като "localhost". Струва си да се отбележи, че #
# някои стари X11 клиенти може да не работят с тези #
# настройки. По подразбиране е "да", т.е. пренасочване #
# ограничено до localhost, "не" деактивира #
# ограничения. #
# #
## XAuthLocation ############################################
# #
# Указва пълния път до програмата xauth. #
# По подразбиране /usr/bin/X11/xauth. #
# #
## X11DisplayOffset ##########################################
# #
# Указва номера на първия дисплей, достъпен за sshd в #
# като X11 пренасочване. Това се прави с цел #
# така че пренасочените x да не се пресичат с #
# истински. По подразбиране е 10. #
# #
X11Отместване на дисплея10
# #
############################################################
################### Различни опции #########################
############################################################
# #
## LoginGraceTime #############################################
# #
# Време, след което сървърът прекъсва #
# на потребителя, ако не са успели да направят задоволително #
# Влизам. Стойност 0 позволява на потребителя да #
# влизане за неопределено време. По подразбиране е 120 (секунди). #
# #
LoginGraceTime 120
# #
## MaxAuthTries ##############################################
# #
# Указва максималния брой опити за удостоверяване, #
# разрешени за връзка. #
# Веднага след като броят на неуспешните опити надхвърли половината #
# дадена стойност, всички последващи опити ще бъдат #
# бъдете регистрирани. Стойността по подразбиране е 6. #
# #
MaxAuth опити 4
# #
## MaxSessions ##############################################
# #
# Указва максималния брой едновременни връзки #
# за всяка мрежова връзка. По подразбиране е 10. #
# #
Макс.сесии1
# #
## MaxStartups ##############################################
# #
# Указва максималния брой едновременни #
# неоторизирани връзки към sshd. Ако #
# броят на връзките ще надхвърли ограничението за всички допълнителни #
# връзки ще бъдат нулирани до текущия #
# връзките няма да бъдат завършени или успешна авторизация, #
# или изтичането на срока, посочен в директивата #
# LoginGraceTime. Стойността по подразбиране е 10. #
# Освен това можете да зададете ранно нулиране на връзката, #
# посочване като параметър на три стойности, разделени с #
# двоеточие “start:rate:full” (например: "10:30:60"). #
# sshd ще отхвърли опита за свързване с вероятност, равна на #
# “rate/100” (т.е. 30% в нашия пример), ако вече #
# има „старт“ (10) на неоторизирани връзки. #
# Вероятността нараства линейно и всички опити #
# връзки ще бъдат отхвърлени, ако броят на неупълномощените #
Броят на връзките ще достигне „пълен“ (60). #
# #
## Компресия #################################################
# #
# Показва дали компресирането на данни е разрешено. Може би #
# "да" компресиране е разрешено. #
# "отложеното" компресиране се забавя до #
# потребителят не е удостоверен успешно. #
# "без" деактивирана компресия. #
# По подразбиране е "отложено". #
# #
## UseLogin ##################################################
# #
# Показва дали трябва да се използва вход за #
# интерактивна сесия. Стойността по подразбиране е "не". #
# Обърнете внимание, че данните за вход никога не са били използвани за #
# изпълнява дистанционни команди. Също така имайте предвид, че #
# използването на вход ще направи невъзможно използването #
# X11 Директиви за препращане, защото влизането не знае какво #
# той трябва да направи с xauth. Ако директивата # е включена
# UsePrivilegeSeparation ще бъде деактивиран след #
# упълномощаване. #
# #
## UsePrivilegeSeparation #####################################
# #
# Указва дали sshd трябва да споделя привилегии. Ако отговорът е да #
# тогава първо ще бъде създадено дете без привилегии #
# процес за входящ мрежов трафик. След успешно #
# оторизацията ще създаде друг процес с привилегии #
# от влезлия потребител. Основната цел на разделянето #
# привилегии за предотвратяване на нарушения на достъпа. #
# Стойността по подразбиране е "да". #
# #
UsePrivilegeSeparation да
# #
## Строги режими ###############################################
# #
# Указва дали sshd трябва да проверява режимите на достъп и #
# собственост върху потребителски папки и файлове преди #
# позволете на потребителя да влезе. Това обикновено е защото #
# начинаещите често правят своите файлове достъпни за запис #
# всички подред По подразбиране е „да“. #
# #
StrictModes да
# #
## AcceptEnv #################################################
# #
# Показва кои променливи на средата се предават #
# ще бъдат приети от клиента. Вижте опцията SendEnv в клиента. #
# Трябва да се отбележи, че предаването на променливи е възможно само #
# за ssh2 протокол. Променливите са посочени по име, #
Могат да се използват # заместващи знаци ('*' и '?'). Можете да посочите #
# множество променливи, разделени с интервал или разделени на #
# няколко реда AcceptEnv. Внимавайте малко #
# променливите на средата могат да се използват за заобикаляне #
# забранени потребителски среди. Използвай това #
# директива внимателно. Няма по подразбиране #
# дефинирани от потребителя променливи на средата не се приемат. #
# #
AcceptEnv LANG LC_*
# #
## PermitUserEnvironment ######################################
# #
# Показва дали sshd трябва да приема #
# ~/.ssh/среда и опцията за среда= в #
# ~/.ssh/authorized_keys. По подразбиране е "не". Разходи #
# забележете, че разрешение за обработка на средата може да даде #
# потребителите възможността да заобикалят ограниченията в някои #
# конфигурации, използващи механизми като #
# LD_ПРЕДВАРИТЕЛНО ЗАРЕЖДАНЕ. #
# #
# #
## PidFile ################################################# #
# #
# Указва файла, съдържащ ID на процеса #
# (ИД на процес, PID) на SSH демона. #
# По подразбиране /var/run/sshd.pid #
# #
# #
## PrintLastLog ###############################################
# #
# Указва дали sshd трябва да показва датата и часа #
# последна сесия, когато потребителят е интерактивно влязъл. #
# По подразбиране е "да". #
# #
PrintLastLog да
# #
## PrintMotd #################################################
# #
# Указва дали sshd трябва да отпечата /etc/motd #
# когато потребителят е влязъл интерактивно. На няколко #
# системи (напр. Ubuntu) тази информация също е #
# отпечатан на екрана от черупката. #
# Стойността по подразбиране е "да". #
# #
PrintMotd №
# #
## Банер ################################################# ###
# #
# Показва кой файл съдържа текстовия банер, който #
# ще се покаже на потребителя ПРЕДИ процедурата #
# удостоверяване. Опцията е достъпна само за протокола ssh2.#
# Не показва нищо по подразбиране. #
# В Ubuntu, issue.net съдържа фразата Ubuntu (версия), #
# например за кармичен е "Ubuntu 9.10". Мога #
# използвани за дезориентиране на възможни нападатели, #
# пишейки там например "Моят D-Link Internet Router" =) #
# #
Банер /etc/issue.net
# #
## ChrootDirectory ###########################################
# #
# Ако е указано, предоставя пътя, който ще #
# chroot след удостоверяване. Пътят и всичко това #
# съдържанието трябва да съответства на притежаваното #
# папки на суперпотребител и не са достъпни за #
# публикации от други потребители. #
# Пътят може да съдържа етикети, които са заменени в #
# процес на удостоверяване: #
# %% се заменя с литерала "%" #
# %h се заменя с домашна директория #
# удостоверяване на потребител #
# %u се заменя с името на потребителя, който се удостоверява #
# папката chroot трябва да съдържа всички необходими файлове и #
# папки за потребителската сесия. За интерактивни #
Необходими са поне # сесии: #
# shell, обикновено sh #
# основни устройства в /dev, като например: #
# нула, нула, stdin, stdout, stderr, arandom и tty #
# за сесия с данни, използваща sftp none #
# разширени настройкине е необходимо, ако се използва #
# вътрешен процес на sftp сървъра. Вижте подсистема за #
# повече информация. По подразбиране chroot не се изпълнява. #
# #
## ForceCommand ##############################################
# #
# Причинява изпълнението на посочената команда. Игнорира #
# всички команди, дадени от клиента или написани на #
# ~/.ssh/rc. Командата се извиква от потребител #
# черупки с опцията -c. Подходящ за изстрелване на черупка, #
# команди или подсистеми. Най-полезен в блок #
# съвпада. Първоначално изпратената от клиента команда се съхранява #
# в променливата на средата SSH_ORIGINAL_COMMAND. Ако #
# посочете командата "internal-sftp", тя ще се изпълни #
# вътрешен sftp сървър, който не се нуждае от допълнителен #
# файлове и папки, описани в директивата ChrootDirectory. #
# #
## Подсистема ################################################
# #
# Дефинира и конфигурира външна подсистема (напр. #
# демон за прехвърляне файлдемон за прехвърляне). #
# Аргументите са име и команда (с незадължителен #
# аргументи), които ще бъдат изпълнени по време на заявката #
# към подсистеми. Командата sftp-сървър стартира "sftp" #
# подсистема за прехвърляне на файлове. Освен това можете да посочите #
# като подсистема "internal-sftp", която ще работи #
# вътрешен sftp сървър. Това може значително да опрости #
# настройка в случай на използване на директивата #
# ChrootDirectory Няма подсистеми по подразбиране #
# не е извикан. От значение само за протокола ssh2. #
# #
#Подсистема sftp /usr/lib/openssh/sftp-сървър #
# #
############################################################
###################### Съвпадение блок ############################
############################################################
# #
# Специално преместен в края на файла, за да го направи по-удобен #
# напишете правила за съвпадение. #
#MadKox. #
# #
# Директивата за съвпадение е началото на условното #
# блок. Ако всички критерии, посочени в ред #, са изпълнени
# Съвпадение, директивите на следващите редове на блока се изпълняват,#
# което ви позволява да заобиколите стойностите на глобалните файлови директиви #
# sshd_config за случая, който е директивен критерий #
# съвпада. Всички редове след ред # се считат за блокове.
# с критерия (ред за съвпадение) до следващия ред за съвпадение #
# или до края на файла. Съвпадение на директивен аргумент едно или #
# множество двойки записи на критерии. Възможни типове записи: #
#потребител#
#Група#
#домакин#
#Адрес#
# Записите могат да съдържат и двете единични стойности #
# (напр. Потребител=потребител) и множество стойности, #
# разделени със запетаи (Потребител=потребител1,потребител2). Те също могат да #
# да се използват регулярни изрази, описани в #
# Секция PATTERNS на ssh_config. Записи в критерии #
# Адресът може да съдържа адреси в CIDR нотация #
# (Дължина на адреса/маската, напр. „192.0.2.0/24“ или #
# "3ffe:ffff::/32"). Заслужава да се отбележи, че представеният #
# дължината на маската трябва да съответства на адреса и също #
# дълго/късо за адрес няма да работи. #
# Директивите за съвпадение могат да използват само #
# специфичен набор от директиви: #
# AllowTcpForwarding #
#банер#
#ChrootDirectory#
#ForceCommand#
#GatewayPorts#
# GSSAPIAудостоверяване #
# Базирано на хост удостоверяване #
#KbdInteractiveAuthentication#
#KerberosAuthentication#
#MaxAuthTries#
#MaxSessions#
#Удостоверяване на парола#
# Отворете разрешение #
# PermitRootLogin #
#RhostsRSAAuthentication#
# RSAAудостоверяване #
#X11DisplayOffset#
#X11Препращане#
#X11UseLocalHost#

Веднага малка забележка към конфигурацията, тя деактивира възможността за влизане чрез ssh като root потребител, така че ако " любителски„Променете настройката PermitRootLogin на да

За да копирате горната конфигурация на вашата Unix машина
Отидете в директорията, където се съхранява конфигурационният файл sshd_config

Sudo cd /etc/ssh

Тъй като направихме резервно копие на файла sshd_config, ще го изтрием

sudo rm sshd_config

Все още в директорията /etc/ssh, копирайте горния ssh конфигурационен файл от сайта itautsors,

sudo wget http://website/sshd_config

Рестартирайте демона

sudo service ssh рестартиране

Уверете се, че SSH демонът работи

Ps-A | grep sshd

Ще видим нещо подобно.

<какой то номер>? 00:00:00 sshd

Ако няма ред, тогава SSH демонът не работи,

Проверете дали входящите връзки слушат:

Sudo ss -lnp | grep sshd

В отговор получаваме

0 128:::22:::* потребители:(("sshd",16893,4)) 0 128 *:22 *:* потребители:(("sshd",16893,3))

Ако има повече от един ред, тогава SSH демонът слуша повече от един порт, ако не един, трябва да бъде посочен поне един порт, и в двата случая е необходимо да се върнете и да редактирате конфигурационния файл

Нека се опитаме да влезем с локален компютър(т.е. отиваме от същия компютър, на който сме настроили ssh сървъра, така да се каже, първоначалната проверка), (не забравяйте, че нашият порт не е стандартен 8022):

ssh -v localhost -p 8022

Ще се покаже информация за отстраняване на грешки и подкана за въвеждане на парола.
След успешно свързване, за да излезете, въведете:

Настройте достъп до OpenSSH сървър с OpenSSH клиент с оторизация на ключ

Дадено: Хостът на OpenSSH сървъра, към който искаме да влезем чрез ssh в бъдеще под потребителя NameUserOnOpenSSHServer от хоста OpenSSH Client. Нека генерираме двойка ключове на хоста, от който искаме да се свържем (OpenSSH Client). Проверете дали двойката ключове вече е генерирана.
След като се съгласите с мястото, където е записан ключът (/home/NameUserOnOpenSSHClient/.ssh/id_rsa), паролата може да остане празна, тогава при удостоверяване със сертификат няма внимателно да въведе паролата, което е по-малко сигурно, но много по-удобно (в нашия пример няма да въвеждаме паролата):

ssh-keygen -t rsa -b 4096

В домашната папка ~/.ssh на потребителя, под който е стартирано генерирането (в нашия пример ИмеUserOnOpenSSHClient) файловете ще се появят на хоста на клиента OpenSSH:

~/.ssh/id_rsa.pubпубличен
~/.ssh/id_rsaчастен

Задайте разрешенията за папката и файловете
Няма значение под кой потребител ще започнем генерирането на OpenSSH Client, единственото влизане в отдалечената OpenSSH Server машина ще трябва да бъде под този потребител, тъй като ще бъдат зададени следните права (такива права трябва да бъдат зададени така, че частният ключ не е компрометиран):

$ chmod 0700 ~/.ssh/ $ chmod 0600 ~/.ssh/id*

Нека прехвърлим публичния ключ от клиента към сървъра за потребителя, под който използваме командата ssh-copy-id към файла ~/.ssh/authorized_keys, ако портът, на който сървърът слуша, не е стандартен, вие трябва да го регистрирате с помощта на ключа -p и да го оградите в кавички. Ключът може да се прехвърля по всякакъв начин, защото е публичен.

ssh-copy-id "-p 8022 [имейл защитен]"

NameUserOnOpenSSHServer - това е потребителят, под който ще влезем в отдалечената машина в бъдеще.
След това трябва да въведете паролата на потребителя NameUserONOpenSSHServer и след успешна авторизация ще видим подсказка:

Сега опитайте да влезете в машината с "ssh" [имейл защитен]"", и проверете: ~/.ssh/authorized_keys, за да се уверите, че не сме добавили допълнителни ключове, които не сте очаквали.

Влизаме в хоста чрез ssh и проверяваме съдържанието на файла (други ключове могат да бъдат регистрирани в този файл, ние търсим нашия.) ИмеUserONOpenSSHServer/.ssh/authorized_keys:

sudo ssh" [имейл защитен]" sudo cat /home/NameUserONOpenSSHServer/.ssh/authorized_keys

Трябва да съответства на съдържанието на файла. ИмеUserONOpenSSHClient/.ssh/id_rsa.pub

Sudo cat /home/NameUserONOpenSSHClient/.ssh/id_rsa.pub

sudo mcedit /etc/ssh/sshd_config

Натиснете F7, потърсете PubkeyAuthentication, RSAAuthentication, AuthorizedKeysFile
редовете трябва да бъдат без коментари / зададени параметри (проверете):

# разрешите използването на RSA ключове RSAAuthentication да # ако използвате SSH1 не е желателно # разрешите оторизация с помощта на ключове PubkeyAuthentication да # Пътят, където ще бъдат разположени ключовете, с които всеки потребител може да свърже собствен файл в своята директория. AuthorizedKeysFile %h/.ssh/authorized_keys

Рестартирайте SSH сървъра

sudo service ssh рестартиране

Задаваме правата на файла /home/NameUserOnOpenSSHServer/.ssh/authorized_keys

Chmod 0600 ~/.ssh/authorized_keys

Излизаме от конзолата на OpenSSHServer, опитваме се да влезем от клиента към сървъра с помощта на сертификат, влизаме в реда и трябва да влезем в конзолата на OpenSSHServer, без да въвеждаме парола (ако не сте въвели парола при генериране на ключове)

ssh [имейл защитен]

Част 2.

Преди да започнем, нека създадем нов потребител с root права.

Посочете правата за тестовия потребител с командата

usermod -a -G sudo тест

За да проверите дали тестовият потребител е добавен към sudo групата, можете да изпълните следната команда:

Сега ще конфигурираме отдалечен достъп до сървъра чрез ssh (комаден ред), както в локална мрежа, както и през Интернет

Инсталирайте ssh

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

След инсталирането трябва да конфигурираме сигурността на връзката и директния достъп. Да отидем на файла с настройки

sudo nano /etc/ssh/sshd_config

По подразбиране ssh използва порт 22. Нека го променим на нестандартен, това ще повиши сигурността на нашия достъп. Нека сменим порта например на 2200

Когато се свързва чрез ssh, нашият сървър ще изисква RSA ключ вместо парола, а не парола. За да предотвратите това да се случи, въведете „НЕ“ в параметрите RSAAuthentication и PubkeyAuthentication. Също така отказваме достъп на ROOT потребителя, за това трябва да премахнете коментара от параметъра Authetication: и да въведете „НЕ“ в параметъра PermitRootLogin

Сега ще регистрираме достъп на потребителите

В реда AllowUsers посочваме потребители, разделени с интервал във формата user@host, т.е. посочваме кой потребител откъде може да се свързва. Можете да използвате *

Нека зададем права за достъп на тестовия потребител и да ги разгледаме.

[имейл защитен]

Можете също да откажете достъп. определени потребители(например потребител test2), за това трябва да въведете по-долу

Ние стартираме

sudo /etc/init.d/ssh стартиране

Конфигурирахме ssh. Сега нека отворим достъп до него. За да направим това, ще отворим достъп до порт 2200.

В последната част инсталирахме защитната стена с командата arno-iptables-firewall, сега трябва да направим промени там. Според това ще го преконфигурираме.

sudo dpkg-reconfigure arno-iptables-firewall

Настройката започна

Въведете порта, който ще отворите. Можете също да въведете други портове в този прозорец, ако трябва да бъдат отворени.

В следващия прозорец въвеждаме и порт 2200.

След като въведете портовете, можете да натиснете ENTER навсякъде и да рестартирате защитната стена.

След това ssh портът ще бъде достъпен от мрежата

За да увеличим сигурността на ssh връзката, можем да конфигурираме помощната програма denyhosts. Помощната програма е скрипт на Python, който анализира файла /var/log/auth.log за записи на неоторизирани опити за влизане в сървъра чрез ssh и добавя IP адресите, от които са направени тези опити, към файла /etc/hosts.deny , където ssh влизането е отказано.

Инсталиране от екип

sudo aptitude инсталира denyhosts

Веднага след инсталирането помощната програма ще сканира файла /var/log/auth.log и ще добави ip-адресите, от които са познати паролите, към /etc/hosts.deny. Ще отнеме време за сканиране, ако вече има много такива записи във файла /var/log/auth.log.

След инсталирането трябва да коригирате конфигурационния файл

sudo nano /etc/denyhosts.conf

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

Също така, за контрол, трябва да посочите адреса електронна пощаза изпращане на известия за неуспешни опити за достъп до сървъра:

ADMIN_EMAIL= [имейл защитен]вместо [имейл защитен]посочете пощата си

За да влязат в сила новите настройки, трябва да рестартирате услугата denyhosts:

sudo service denyhosts рестартиране

P.S. Ако трябва да промените паролата си на сметка. Въведете команда

passwd user - където user е потребителското име

P.S.S. Ако имате проблеми с кодирането, тогава се задълбочете в настройките клиентска програмаШшт

Повечето популярна програмаза работа чрез ssh, програмата PuttY.