Вопрос вдогонку. Какой может теоретически сущестовать оверхед от SSH по сравнению с просто SSL? Ведь если будет шифрование, то по любому какой-то LibreSSL, GnuTLS, etc. А SSH содержит какую-то толстоту поверх уже после установки соединения?

Почему же не используется, в доках «The world's most advanced open source database» так и сказано:

SSL connections encrypt all data sent across the network: the password, the queries, and the data returned. The pg_hba.conf file allows administrators to specify which hosts can use non-encrypted connections (host) and which require SSL-encrypted connections (hostssl). Also, clients can specify that they connect to servers only via SSL. Stunnel or SSH can also be used to encrypt transmissions.

Ну вот, городят кучу фич всяких. Но может ли какая-то новая СУБД сказать «SSH и все, обычные unix юзеры и все»

К базе могут быть и сотни подключений, с сотней подключений будет сотня лишних sshd процессов на сервере.

SSH и все, обычные unix юзеры и все

А если RDBMS используется в изолированной внутренней сети(как часто и бывает) начёрта оверхед от шифрования? Так или иначе придётся делать TCP, а прикрутить туда SSL не так уж сложно

К базе могут быть и сотни подключений, с сотней подключений будет сотня лишних sshd процессов на сервере.

Мелочи же, любой сервак не заметит. Сейчас например в большинства СУБД вместо процессов много потоков, разница по памяти есть, но на планировщик задач - особенно никакого влияния.

А если RDBMS используется в изолированной внутренней сети(как часто и бывает) начёрта оверхед от шифрования? Так или иначе придётся делать TCP, а прикрутить туда SSL не так уж сложно

Ну я к тому что вместо сложной подсистемы работы с пользователями можно просто напросто оставить один тумблер localhost_only и отключать его в защищенных сетях и включать в незащищенных и подключаться через туннель

в большинства СУБД вместо процессов много потоков

В postgresql «Each connection gets its own process» - на планировщик задач - особенно никакого влияния, а изоляция и устойчивость к падениям.

можно просто напросто оставить один тумблер localhost_only

То есть так и пришлось бы разрабатывать сетевую часть, протокол, обработку ситуаций и всё связанное. А прикрутить шифрование к уже готовому TCP не так уж сложно.

А тумблер такой в pg есть, pg_hba.conf, прямо так и работает + ограничение по IP/пользователям

И еще момент: а если клиенты недоверенные, например программы на пользовательских ПК, всем им ssh дать?

То есть так и пришлось бы разрабатывать сетевую часть, протокол, обработку ситуаций и всё связанное

Нету heartbeat столько-то десятков секунд - все, отключение

Если есть недоверенные клиенты, то они обычно работают через отдельное приложение и взаимодействуют с ним по какому-то другому протоколу, HTTP например

> Почему не используется широко?

Почему не используется широко?

Под «окошки» оно не очень развито. Это не библиотека а командная утилита предназначеная в основном для запуска вручную и в этом смысле малопригодна к интеграции. SSL легко маскируется под HTTPS который не закроют, а вот левый ssh всегда будет кандидатом на прибитие без суда и следствия. SSH в общем используется только там где почти или совем админ.

Просто наличие SSH часто вообще единственный способ достучаться до машины. Цеплять клавиатуру к серваку - моветон. Сейчас все в амазонах и тд, а там SSH есть

на серверах отличных от linux это точно хороший вариант?

Зачем сервера отличные от Linux?

Ну я к тому что вместо сложной подсистемы работы с пользователями можно просто напросто оставить один тумблер localhost_only

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

Ну я к тому что вместо сложной подсистемы работы с пользователями можно просто напросто оставить один тумблер localhost_only

Без системы работы с пользоватлями ты получишь однопользовательское приложение.