Является ли использование публичных ключей в ssh

Угадай с одного раза.

нет ?

Слишком толсто.

Если бы это не было намного безопаснее и удобнее, этот способ аутентификации не получил бы такого распостранения.

я бы сказал что более удобным, особенно в скриптах.

более секурным чем ввод каждый раз пароля ?

Если к тому же на сервере запрещены PasswordAuthentication и ChallengeResponseAuthentication, то да, является: злоумышленник в принципе не сможет подобрать пароль ввиду отсутствия запросов такового.

подпишусь на комменты в таком эпике

Нет, не является. Достаточно спереть у тебя ключ - и ты даже не узнаешь, что у кого-то появились привилегии в системе. Только аутентификация по паролю в сочетании с аутентификацией обеих сторон сертификатами и (а не «или») двухфакторной аутентификацией по альтернативному каналу дают некоторый минимальный шанс что твоя домашняя садо-мазо порнушка с мёртвыми несовершеннолетними останется секретом для представителей исполнительной власти.

секьюрнее ещё и ключ запароленным держать и вводить пароль каждый раз, но к ключу, а не удалённому серверу

Он и так запароленный. Вот только... Ты уже застраховал свою клиентскую машину от кейлоггиря?

А как вообщем можно, отписываться сдесь анонимно ?.. вроде когда я регистрировался то нельзя было оставлять коментарии от анонимных пользователей.

На счет темы, да я тоже использую ключи аутентификации. Ключи желательно хранить на внешнем носителе но лучше запомнить.

у тебя отличное воображение, в сценаристы срочно беги =))

Ключи <…> лучше запомнить.

Завидую твоей феноменальной памяти и скорости слепого набора.

Внезапно - да

Ключи

лучше запомнить

Лол. Может, ты ещё и HEX-коды бинарников запоминаешь?

Доброе утро.

В зависимости от ситуации же.

Вот у меня на работе был сервер, на который не имел доступ только ленивый. Плюс там постоянно было несколько пользователей сидящих от рута.

Мне необходимо было частенько с этого сервера ходить по ssh на другой сервер, но использование ключей я не мог себе позволить. Потому что руту можно было бы сделать:

root@server:~# su mylogin
mylogin@server:/root/$ ssh mylogin@newserver

Поэтому, в данном случае, приходилось использовать пароль.

Ходить на тот сервер со своего компа, используя ForwardAgent — не вариант? А пароль в данном случае не безопаснее — рут может и кейлоггер задействовать.

Хороший вопрос. Когда шла дискуссии в этой теме, я подумал а нельзя ли в OpenSSH подписывание ключей реализовать как в OpenVPN.
А правда, а нельзя ли чтобы сервер использовал не любые открытые ключи, что присутствуют в authorized_keys, а только подписанные?

Инфраструктура для этого нужна. PKCS, например. А там, где инфраструктура , там всегда всё сразу на порядок сложнее.

Ходить на тот сервер со своего компа, используя ForwardAgent — не вариант?

А что помешает руту подцепиться к сокету ssh-агента? Только что проверил - ничего. Да, сокет создается в tmp с рандомным именем и владельцем его является пользователь, подключенный к серверу. Но это никак не отменяет того факта что root может сделать вручную export SSH_AUTH_SOCK и поиметь доступ к ключу - на то он и root.

Тут отца русской демократии даже kerberos не спасёт - по тем же самым причинам.

Единственный вариант - ограничивать действия рута через SELinux.

Но я очень мало видел систем, где рут и администратор безопасности(в терминологии того же GrSecurity_ - разные люди. И вопрос доверия «администратору безопасности» опять же остаётся открытым.

А правда, а нельзя ли чтобы сервер использовал не любые открытые ключи, что присутствуют в authorized_keys, а только подписанные?

Можно

читая это создаётся впечатление что грамотно настроенная винда с групповыми политиками куда секьюрние любого никса... но есть и обратный пример, у меня при ssh ключах недоступен становиться доступ virt-manager'у к серваку, постоянно жалуется на то, что либвирт не запущен, а с паролем таких проблем нет.... но самый смех был про то, что ssh ключи должны быть в директории с правами 700 а сам файл именно 600.... с 700 уже авторизация по ключу не пашет ....

SElinux будем реалистами нормально пашет только в gentoo да rhel/centos 7, вчера конфиг готовый и работающих в федоре и rhel destop, centos 7 всунул в минт, меня минт послал у тестера далеко и надолго.

А что помешает руту подцепиться к сокету ssh-агента?

Да ничего не помешает, конечно. Просто меня удивил отказ от ключа в пользу пароля из тех соображений, что рут может увести ключ — пароль-то он тоже при желании уведет.

А вот использовать RemoteForward и ProxyCommand — вариант.

грамотно настроенная винда с групповыми политиками куда секьюрние любого никса...

Если к этому никсу, цитирую, «не имел доступ только ленивый. Плюс там постоянно было несколько пользователей сидящих от рута», то да, грамотно настроенная винда (редкая зверюга, кстати сказать) побезопаснее будет.

у меня при ssh ключах недоступен становиться доступ virt-manager'у к серваку, постоянно жалуется на то, что либвирт не запущен

Чини руки - я на работе использую virt-manager через ssh по ключу - никаких проблем

читая это создаётся впечатление что грамотно настроенная винда с групповыми политиками куда секьюрние любого никса

Концепция root = система. Пролюбил доступ рута - ССЗБ.

грамотно настроить групповые политики для 12 категорий людей это месяц работы для 2 админов(работа+ проверка работоспособности после этого рабочей станции). Я вот например судо не перевариваю, и потому у меня пользователь имеет можно сказать права рута, в плане установки софта и тд,и посему моя рабочая станция крайне не секьюрна... к примеру.

при ssh ключах недоступен становиться доступ virt-manager'у к серваку

Ты что-то делаешь не так.

а что чинить? через konsole5 захожу без проблем просто набрав пароль от своего ключа(образно говоря, не знаю как правильно сказать, к файлу с ключём....), а вот через вирт манеджер не хочет, говорит либвирт не доступен, хотя подключаюсь к своему пользователю на сервере, даже не к руту...

а что чинить?

Тебе виднее что ты сломал. Я только хочу сказать, что virt-manager прекрасно умеет работать с ssh, в том числе и авторизуясь по ключу. А если он где-то не работает - значит на этой системе что-то сломано

грамотно настроить групповые политики для 12 категорий людей это месяц работы для 2 админов(работа+ проверка работоспособности после этого рабочей станции).

А угробить их («не имел доступ только ленивый») — дело пяти минут.

Я вот например судо не перевариваю

А я не перевариваю AD+GPO (хотя когда-то умел их готовить). Чьи это проблемы?

может вирт манагер не может правильно обработать пароль от ключа? при подключении надо ввести пароль от rsa key, может в этом дело?

Либвирт не может в запароленный ключ без ssh-agent (естественно, ключ-то запаролен). Лечится использованием ssh-agent.

Update: не либвирт, а virt-manager, разумеется.

ну у меня fedora, так что сломано может быть вполне, хотя есть вероятность, что вирт манегер не переваривает если стоит пароль на .ssh/id_rsa... Ничего более я не делал, в остальном сплошной стандарт, если не брать 5 кеды вместо гнома.

печально тогда, придётся ставить, с ним много гемора с этим агентом?

у меня fedora, так что сломано может быть вполне

У меня тоже, и я ответственно заявляю — ничего там не сломано.

с ним много гемора с этим агентом?

Вообще никакого: ssh-agent входит в openssh-clients, поэтому он уже установлен, осталось установить openssh-askpass, перелогиниться и наслаждаться.

Update: возможно, для KDE нужен ksshaskpass.

в понедельник попробую, отпишусь, кстати на счёт вирт манагера/ovirt, как они с xen дружит?у меня сейчас пока в основном citrix, вот думаю поставить попробовать овирт, чтобы не держать виртуалку с виндой.

на счёт вирт манагера/ovirt, как они с xen дружит?

AFAIR, поддержка заявлена, но не знаю, насколько она полна — уже лет 7 не видел xen, только kvm либо virtualbox.

я пока побоялся поднимать 4 терминальных сервера(2 основа 2 реплика) на kvm, тем более 2012r2 не очень любит kvm.

тем более 2012r2 не очень любит kvm

В чём это выражается? Просто у меня 2012 R2 крутится в кластере на KVM, каких-либо проблем не замечено. Драйвера в системе virtio стоят.

терминальник не зависает если там 1с?

у меня у бухов 1С зависала причём намертво, приходилось сессию закрывать.

конечно да.

Достаточно спереть у тебя ключ

о да. Это так просто…

Ты уже застраховал свою клиентскую машину от кейлоггиря?

как он туда попадёт, если я ставлю только из офф реп?

Поэтому, в данном случае, приходилось использовать пароль.

надо было зашифровать ключ пассфразой.

но самый смех был про то, что ssh ключи должны быть в директории с правами 700 а сам файл именно 600....

почему твоя религия не позволяет поставить права 0700 и 0600?

мне было бы проще если бы там были одинаковые права на файл и директорию, а то гуглить когда то пришлось....

мне было бы проще если бы там были одинаковые права на файл и директорию

тогда и угнать твой ключ можно было-бы очень просто. Но с такими правами необходимо залогинится под твоим именем (или под рутом). Иначе прочитать файл с ключом невозможно. Т.к. админы все балбесы, сделано вот такое напоминание: пока права нормальные не поставишь, работать не будет.

оба стоят, но всё равно не пашет....