частный и публичный ключ надо сравнивать скорее с двумя ключами, которые предназначены для необычного замка - у него два отверстия для двух ключей, и, будучи вставлены одновременно, они и только они открывают этот замок
У вас замечательные уроки, пожалуй лучшие среди русского комьюнити. С криптографией неплохо знаком, о на деле особо не применял, теперь буду реализовывать)
Спасибо, узнал что то новое, про файлик ssh_known_hosts раньше не знал)) Жду новых видео, обратил внимание что у вас 16 версия сервера, надеюсь что все дальнейшие уроки будут именно на ней.
Кирилл, спасибо вам огромное. Скажите не планируете рассказать в подробностях об управлении netfiltr, в частности об iptables? Мало подробной информации, в основном галопом по европам. Так вроде в общем понятно, но вот дело дошло до балансировки нагрузки(в частности в Mikrotik, там же Linux) или просто разделить два провайдера по разным подсетям так мучился....! Вроде сделал. Разделил два провайдера, по разным подсетям. Но вот проблема повисла, при маркировки пакетов. В одной из подсетей был ipsec tunnel, он перестает работать когда произвел маркеровку пакетов. Соединение PPPoE от двух провайдеров. Много наговорил.....))))
В папке /etc/ssh уже существует набор пар публичных и приватных ключей для rsa, dsa, ecdsa и др. Для чего они нужны? Можно ли их как-то использовать? Можно на локальном хосте создать пару открытый/закрытый ключ и затем передать открытый на удаленный сервер, но также можно создать эту пару на сервере и передать публичный ключ на локальный хост. Какой вариант правильный и можно ли в качестве открытого ключа использовать тот, что уже лежит в каталоге /etc/ssh ? Например, rsa. При самом первом заходе на сервер вы получили хэш публичного ключа ecdsa. Это тот самый ключ, что лежит в означенной директории /etc/ssh ? Почему именно ecdsa?
по порядку: 1) в /etc/ssh лежат ключи самого сервера, в домашних директориях ключи пользователей. Ключу сервера вы доверяете при подключении к нему, если он изменится (например ваш трафик переправят на поддельный хост) - вам будет выведено предупреждение.
2) Когда вы передаете свой публичный ключ на систему - система начинает узнавать вас. Когда вы сохраняете у себя публичный ключ удалено системы - ее начинаете узнавать вы. Вопрос только в том кто куда подключается и кому надо кому доверять.
Хорошо, а что если вася с ноутбуком подключится по ssh к серверу, получит публичный ключ, а затем забежит в серверную и воткнет кабель в ноутбук? Я так понимаю что шифрование между 2мя узлами основывается на том, что узлы друг другу выдают свои публичные ключи, и затем информация от узла1 до узла2 шифруется ключем, выданным узлом2, а от узла2 до узла1 - ключем, выданным узлом1, и таким образом не возможно расшифровать инфу, проходящуюю по каналу
Второй абзац - все так. Не понимаю первый. Пусть что хочет Вася делает, пока у него нет частного ключа сервера, он не сможет расшифровать информацию, предназначенную серверу, куда бы он себе кабель не втыкал)
Kirill Semaev а, ну да, действительно, спасибо, все понял) А если есть 2 узла - скажем А и Б А отправляет публичный ключ узлу Б. Провайдер ворует ключ и подменяет на свой. Б принимает измененный ключ, и отправляет свой узлу А. Провайдер подменяет ключ, и А подучает измененный ключ. А затем в процессе передачи данных провайдер расшифровывает данные с обоих сторон своими ключами, читает, сохраняет, а потом шифрует верными ключами и отправляет дальше? эксплойт???)))) или я бред несу?)))
если вы так определение даете, то нет) Отпечаток можно создавать например не MD5 а SHA-1, алгоритмы тоже разные можно. А в данном конкретном случае - наверное да, я в подробности не вдавался)
Кирилл, большое тебе спасибо, что делишься знаниями!
Пусть всё у тебя будет всегда отлично 🐻❄️
Спасибо тебе дружище! Дай бог тебе здоровья
частный и публичный ключ надо сравнивать скорее с двумя ключами, которые предназначены для необычного замка - у него два отверстия для двух ключей, и, будучи вставлены одновременно, они и только они открывают этот замок
Парень, ты класс! Продолжай в том же духе. Было бы еще интересны лекции для centos/rhel админов или начинающих, с чего начать и т.п.
Думаю и до них доберусь
ждём с нетерпением!!@@KirillSemaev
У вас замечательные уроки, пожалуй лучшие среди русского комьюнити. С криптографией неплохо знаком, о на деле особо не применял, теперь буду реализовывать)
Спасибо, стараюсь держать уровень)
откуда владелец получает частный ключ таким образом, чтобы его не узнал кто то другой???
бро, красавчик, спасибо большое, подписался на тебя! Единственное замечание, можешь чуть медленнее говорить))
Спасибо, узнал что то новое, про файлик ssh_known_hosts раньше не знал)) Жду новых видео, обратил внимание что у вас 16 версия сервера, надеюсь что все дальнейшие уроки будут именно на ней.
Да, я уже решил закончить на 15, а практику начнем с 16. Ну и я во все видео вставлю правки, если там сильная разница будет.
Спасибо!!!
Спасибо, хорошее видео, с 4 просмотра чем отличается публичный ключ от приватного :)
С четвертого это хороший показатель)) Я помню как по 10-15 раз перечитывал и ничего не понятно)) В следующих частях закрепим
Пока только начинаю изучать тему ssh. В данный момент ещё не понятно, хоть и хорошо объясняешь
откуда владелец получает частный ключ таким образом, чтобы его не узнал кто то другой???
кстати для выхода из сеанса , чтобы не набирать exit, можно просто нажать Ctrl+d
Спасибо за объяснение!
А будет ли идти речь про port forwarding в этой серии уроков про SSH?
Вот буквально сейчас записываю
+Kirill Semaev ура! спасибо!
Не советую открывать этот22 наружу, или тогда уже сразу 5900 отx11vnc и с паролём password
Кирилл, спасибо вам огромное. Скажите не планируете рассказать в подробностях об управлении netfiltr, в частности об iptables? Мало подробной информации, в основном галопом по европам. Так вроде в общем понятно, но вот дело дошло до балансировки нагрузки(в частности в Mikrotik, там же Linux) или просто разделить два провайдера по разным подсетям так мучился....! Вроде сделал. Разделил два провайдера, по разным подсетям. Но вот проблема повисла, при маркировки пакетов. В одной из подсетей был ipsec tunnel, он перестает работать когда произвел маркеровку пакетов. Соединение PPPoE от двух провайдеров. Много наговорил.....))))
Вот как раз сейчас планирую разобрать нефильтр подробно в видео)
Спасибо Вам, очень жду!)
огонь контент
откуда владелец получает частный ключ таким образом, чтобы его не узнал кто то другой???
@@axelvermontov6607 Сам себе генерит, а "серверу" пересылает публичный (открытый) ключ.
В папке /etc/ssh уже существует набор пар публичных и приватных ключей для rsa, dsa, ecdsa и др. Для чего они нужны? Можно ли их как-то использовать?
Можно на локальном хосте создать пару открытый/закрытый ключ и затем передать открытый на удаленный сервер, но также можно создать эту пару на сервере и передать публичный ключ на локальный хост. Какой вариант правильный и можно ли в качестве открытого ключа использовать тот, что уже лежит в каталоге /etc/ssh ? Например, rsa.
При самом первом заходе на сервер вы получили хэш публичного ключа ecdsa. Это тот самый ключ, что лежит в означенной директории /etc/ssh ? Почему именно ecdsa?
по порядку:
1) в /etc/ssh лежат ключи самого сервера, в домашних директориях ключи пользователей. Ключу сервера вы доверяете при подключении к нему, если он изменится (например ваш трафик переправят на поддельный хост) - вам будет выведено предупреждение.
2) Когда вы передаете свой публичный ключ на систему - система начинает узнавать вас. Когда вы сохраняете у себя публичный ключ удалено системы - ее начинаете узнавать вы. Вопрос только в том кто куда подключается и кому надо кому доверять.
ну а вообще я буду дольше пересказывать) Вот хорошая статья: habrahabr.ru/post/122445/. если по ней останутся вопросы: пишите
Хорошо, а что если вася с ноутбуком подключится по ssh к серверу, получит публичный ключ, а затем забежит в серверную и воткнет кабель в ноутбук?
Я так понимаю что шифрование между 2мя узлами основывается на том, что узлы друг другу выдают свои публичные ключи, и затем информация от узла1 до узла2 шифруется ключем, выданным узлом2, а от узла2 до узла1 - ключем, выданным узлом1, и таким образом не возможно расшифровать инфу, проходящуюю по каналу
Второй абзац - все так. Не понимаю первый. Пусть что хочет Вася делает, пока у него нет частного ключа сервера, он не сможет расшифровать информацию, предназначенную серверу, куда бы он себе кабель не втыкал)
Kirill Semaev а, ну да, действительно, спасибо, все понял)
А если есть 2 узла - скажем А и Б
А отправляет публичный ключ узлу Б.
Провайдер ворует ключ и подменяет на свой.
Б принимает измененный ключ, и отправляет свой узлу А.
Провайдер подменяет ключ, и А подучает измененный ключ. А затем в процессе передачи данных провайдер расшифровывает данные с обоих сторон своими ключами, читает, сохраняет, а потом шифрует верными ключами и отправляет дальше? эксплойт???)))) или я бред несу?)))
Все так, именно поэтому в ключи советуют изначально передавать только в оффлайне, на флэшках.
а что мешает хаккеру перед тем как выдернуть шнур получить публичный ключ и подменить на своем ноутбуке?
отпечаток/fingerprint - это MD5-хэш открытого ключа, закодированного алгоритмом Base64
если вы так определение даете, то нет) Отпечаток можно создавать например не MD5 а SHA-1, алгоритмы тоже разные можно. А в данном конкретном случае - наверное да, я в подробности не вдавался)
Kirill Semaev Ну само собой, я про данный конкретный случай говорил
Один дислайк, найдите этого человека ;\
уже 2. мб какие-то забредшие замкнутые гномы-безопасники)
откуда владелец получает частный ключ таким образом, чтобы его не узнал кто то другой???
Secure aSHell
Я так понимаю, уже ему не напишешь ибо не ответит
Админ - собака