Комментарии 14
Простите, а Дока 2 когда будет?
Почитал https://doka.guide/tools/ssh/
scp ~/.ssh/id_rsa.pub root@100.110.120.130:/tmp
После введения пароля нужно будет зайти на сервер. Для соединения с сервером нужно выполнить команду и ввести пароль ещё раз:Затем нужно настроить службу sshd. Для этого необходимо зайти в конфигурационный файл /etc/ssh/sshd_config (например, с помощью редактора vi или nano) и отредактировать настройку для доступа по паролю так:
Authentication: PermitRootLogin no
После этого нужно скопировать файл ключа в директорию .ssh в домашней директории пользователя. Для пользователя root:
mkdir /root/.ssh
mv /tmp/id_rsa.pub /root/.ssh/authorized_keys
Простите, но у вас действительно проводится техническое ревью?
Например, зачем сперва копировать ключ в /tmp а потом в authorized_keys, если есть правильная команда ssh-copy-id, которая вдобавок не перепишет authorized_keys (который может быть уже существует и в нем могут быть другие ВАЖНЫЕ ключи), а добавит в него ваш ключ?
Зачем нужно сразу после копирования ключа настраивать службу sshd, отключая логин по паролю (это отдельный разговор почему он там в принципе был включен, а не настроен доступ к суперюзеру через sudo) до того, как вы проверили, что можете действительно подключиться по ssh-ключу? (Тем более что вы даже не проверили, а вдруг в данном sshd используется, например, authorized_keys2 и таким образом вы просто поломаете себе доступ к хосту вообще)
Просто не совсем понятно - описан довольно сложная процедура внесения правок, и при этом, на мой взгляд, допущены очень грубые ошибки...
Часто используемые длинные ключи также имеют короткий аналог (псевдоним, alias) из одного символа, например
-hдля той же справки.
Это из другой статьи на Doka. Ну посмотрите пожалуйста по короткому алиасу (-h) справку на команду shutdown, желательно на продакшене от рута...очень поучительно будет.
Привет! Спасибо за уточнение. Мы хотели показать пример как это работает без необходимости глубоко вникать в суть, поэтому в статье есть упрощения и допущения. В жизни вряд ли фронтендер будет поднимать ssh на сервере, это админская задача, но высокоуровнево понимать что происходит по ту сторону может быть полезно для диалога.
Ты описал классный пример, как правильно, и он будет отличным блоком «В работе». Приходи его писать!
Ну мой основной посыл был в том, что в статье допущены серьезные ошибки, которые могут привести к поломке. Я не против упрощений и допущений - это правильно, википедия зачастую страдает от чрезмерно академического подхода. Но подобные ошибки недопустимы даже при желании что-либо упростить.
Забавное кому-то будет утешение.
Т.е. вашу доку воспринимать всерьёз нельзя.
То есть у вас есть проект с кучей людей, аппруверов, дизайнеров, но если вам указать явную техническую ошибку, вы говорите "приходи бесплатно поработать на нашу knowledge base", но не просто поправь, а изучи нашу инструкцию из кучи шагов, зарегистрируйся и предложи изменение в указанном формуляре, а мы подумаем принять его или нет.
Серьезно, ребята. Википедия с пост-модерацией в этом плане гораздо привлекательнее...
В категории инструментов шапка ну совсем "вырви глаз". Особенно со смартфона.
<Удалено>
Как говорится: сам себя не похвалишь - никто не похвалит. Дока - проект для самопиара, не более. Теперь каждый контрибьютор проекта может написать по бесполезной статье о проекте, в котором никто не нуждался, на хабре и прочих ресурсах, чтобы почувствовать себя важнее, так держать!
Зачем вы пишите очередной велосипед?
История следующая: группа людей решили сделать очередной велосипед которых в интернете пруд пруди. Раструбили о нем, а дальше общество пускай допиливает.
Дизайн - ужасен.
Логотип - ни о чем.
Материал - не полноценный, статьи не полные.
Гордиться нечем! Единственное, что на отечественном ресурсе такого (ужасного) справочника нет.
Дока классная, сделано с душой!
Как устроена Дока — опенсорсный справочник с документацией, который сообщество пишет для сообщества