SSH - запретить конфиги в ~/.ssh

Права поставь чтоб ничего не могло читать и писать, что не должно.

Глобально, AFAIK никак. Разве что chattr +i, но это тоже грязно и мерзко.

ничто не помешает пользователю дать свои настройки через опцию -о

ограничения должны быть на сервере, «урезать» клиента – бред

Что ты хочешь этим добиться? На всякий случай сообщаю, что даже если ты каким-то образом запретишь ~/.ssh, никакой безопасности это само по себе не добавит. И даже запрет -o (про который выше пишут) тоже не добавит безопасности.

chattr +i тоже в целом не поможет.

Бессмысленно, если пользователь имеет доступ к оболочке, и сам выполняет команды. Для ssh наивысший приоритет имеют аргументы командной строки, а уже затем конфиги. Так, даже если запретить изменение конфигов, пользователь при запуске может задать любые аргументы непосредственно, или создав и указав новый конфиг.

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

Можно ли глобально запретить домашнюю директорию (для клиента)? Чтобы все конфиги определялись через /etc/ssh/ssh_config и пользователь не мог сам ничего добавлять.

Где предполагается запрещать? На каждом клиенте отдельно? На сервере запретить это невозможно потому что на уровне протокола SSH нет никаких директорий .ssh и пользователь гипотетически может использовать любой кастомный клиент, читающий конфиги откуда угодно в каком угодно формате.

ну может ты уже пояснишь? А то уже третьим постом умнячка давишь и тайну нагоняешь

Да вроде понятно всё. Если юзеру запретить запись в ~/.ssh, он передаст нужные опции через -o, если запретить -o — пересоберёт клиент с нужными ему опциями по умолчанию, или другим расположением конфига. И так как снежный ком получается, что придётся юзера прям совсем в песочницу загонять, а это сложно, часто ненужно или вредно, и очень легко что-то упустить. Единственным правильным решением будет на стороне сервера делать ограничения.

Что поясню? Пусть автор поясняет зачем ему конфиг клиента выключать.

Разве что chattr +i, но это тоже грязно и мерзко.

«грязно и мерзко» это отдельно монтировать эту директорию, а chattr эт нормально.

а ты хорош!

я вспомнил - я примерно из-за такой темы в своё время пачил OpenSSH и ProFTPd на тему magic_chroot когда желаемый chroot не совпадал с хомяком.там «волшебство» было в /./ в пути до хомяке ЕМНИП - удобно было

Ну как так не добавит. Если ты всякую каку от юзера ждёшь, то может и добавит, главное понимать от чего именно ты защищаешься. Смотри, простой пример - есть у тебя юзеры, юзеры тупые, могут скрипты на питоне запускать или баше (да запрет на запуск бинарей в линуксах не влияет на скрипты, их можно запускать если прям совсем-совсем не огораживать, даже астралинукс смоленск эдишн ручками надо допиливать и донастраивать и то я не уверен что юзер не найдёт способа как запустить скриптоту). А папка ssh очень вкусная, там можно и свои ключики положить, чтоб бекдор был в систему и чужие забрать и про сеть информацию наковырять. Понятно что /etc/ssh/sshd_config надо крутить и можно (и даже нужно) выключить/выпилить ssh из системы у тех юзеров, которым он не нужен. Но ведь есть и те которым он нужен. А с ними как быть?

А как ограничить сервер от валидного ключа который лежит себе в .ssh и используется для входа?

Я бы вообще подумал над монтированием разных директорий в .ssh по требованию. И сброс ОС тонкого клиента до дефолта после каждого запуска компьютра, с которого предполагается удалённый доступ к критически важным серверам.

Ты серьёзно предлагаешь защищаться от запущеного трояна методом защиты от записи в ~/.ssh ?

там можно и свои ключики положить

sshd_config

Да, я забыл про то что туда и sshd смотрит, но автора sshd не интересует, у него тема про ssh-клиент.

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

И защитить он хочет от записи а не от чтения.

Ты серьёзно предлагаешь защищаться от запущеного трояна методом защиты от записи в ~/.ssh ?

Против запущенной гадости надо защищаться комплексно. Зачем облегчать пацанам жизнь? Пусть думают как права повысить и пароль рута утянуть. И куда в автозапуск прописаться (да его тоже надо у юзера отнимать), имея только права юзера. Конечно мы говорим сейчас не о дырявых по дефолту убунтах, рассчитанных на домашнее использование, чтоб чисто в доту играть и видосики про котиков с сети смотреть. А так, на самом деле вся твоя работа как ИБ-шника (не того который бумажки перекладывает, а который реально за ИБ отвечает, пусть даже должность у него сисадмин будет), заключается в том, чтоб запретить всё, кроме того что действительно необходимо. Т.е. зарезать автозапуск, зарезать лишний софт который куда-то в инет лезет, зарезать все порты кроме нужных, зарезать права у юзеров на всё, кроме того что им нужно (но тут надо понимать что им реально нужно, а не по бумажке которую идиот начальник придумал и конечно не то что тебе в голову пришло, иначе может стать хуже, юзеры тоже люди и могут саботаж устроить гораздо хуже, например, начав работать с секретными данными на своих домашних убунтах, потому что у тебя всё огорожено так, что работать неудобно), обновлять софт по мере исправления уязвимостей, возможно сделать хонипот для взломщиков (пусть ломают и радуются туфте которую ты им подсунешь). И у автора троянов резко начнёт болеть попа, трояны в лучшем случае пишутся под домашние убунты с дефолтными настройками (а ещё лучше под оффтопик там юзеров глупых в техническом плане куда больше), на массового юзера. Т.е. случайно у тебя уже ничего не сопрут. Останутся только те ребятки, которые будут ломать именно тебя. Но делать это будет очень неприятно, долго и дорого. А дальше экономика порешает - если ты так нужен что ради тебя готовы лярд баксов потратить то взломают, может даже терморектально, если другие варианты не помогут или будут дороже. А если всего-то 300 000 рублей конкурент готов заплатить, то те ребятки которые на это согласятся нужного навыка иметь не будут, проплюются и уйдут не солона хлебавши.

Интересный опыт. Но вопрос: Зачем?

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

PS: давно было, 25 лет прошло. я толком уже не помню причину

вот причина: https://askubuntu.com/questions/134425/how-can-i-chroot-sftp-only-ssh-users-into-their-homes

Очень правильно описали! По моему опыту всё именно так и есть!

вот причина: https://askubuntu.com/questions/134425/how-can-i-chroot-sftp-only-ssh-users-i...

Ну там же в ответах и есть ответ.

Чтобы не давать юзерам прописывать свои ключи для удалённого входа в систему достаточно в sshd_config прописать другую директорию authorized_keys, такую, куда у юзера нет доступа. Ну и вообще дважды думать на каких машинах поднимать вообще sshd, а где не надо. А ещё можно ограничить какие юзеры вообще могут логинится по SSH, через тот же sshd_config. Если юзеру нельзя прописывать свои ключи для входа, возможно, ему вообще должен быть запрещён этот самый вход.

Чужие ключи из .ssh можно взять только если их кто-то туда положил. Ну и если они там уже лежат, то можно просто сделать cat/cp этого файла и скопировать ключ куда тебе хочется. Тут какая-то проблема высосанная из пальца. Либо ты кладёшь в домашней директории (где-угодно) юзера ssh ключи и он может ими пользоваться, либо не кладёшь.

Зайти на удалённый сервер папка .ssh вообще не нужна. Во-первых, существует вход по паролю, во-вторых, команда ssh имеет опцию -i позволяющую указать произвольный путь приватного ключа для входа на желаемый сервер. Он вообще не обязан быть в .ssh.

Проблема не в .ssh, а либо в конфиге sshd_config, либо в том что ты кладёшь какие попало файлы в домашний каталог юзера, к которым он не должен иметь доступ.

ничто не помешает пользователю дать свои настройки через опцию -о

Ничто не мешает написать обёртку над ssh и вызывать её, а она уже будет вызывать ssh с нужными опциями через sudo от отдельного пользователя, у которого будет право на запуск бинарника ssh. Заодно и с ~/.ssh проблем не будет. Может и без обёртки получится справиться, у sudo есть ограниченная возможность проверять передаваемые программе аргументы, тогда достаточно будет просто запускать ssh через sudo.

ограничения должны быть на сервере, «урезать» клиента – бред

Я тоже теряюсь в догадках, какую задачу хочет решить товарищ, но если сильно хочется - пуркуа бы и не па.

неужели нельзя выключить или только имутабельной директорию делать?

Ну запретишь, а он переложит их в ~/.ssh1, тебе легче станет?

Я тоже теряюсь в догадках, какую задачу хочет решить товарищ

Ну и не надо выдумывать

но если сильно хочется

не надо, особенно когда ТС даже не удосужился хотя бы один комментарий написать

чё за поколение прокладок ?? то электроном всё засирают, то элементарну програмку поменять не могут :)

мусъё !! пропатчить код и скопилировать версию с вкомпилированными изменениями. мы ж с линухой работаем а не костыли в окно кидаем.

Это не поддерживаемо.

патч меняющий параметр, предположу ибо не видел сырцов, вынесенный в отдельную строку с дефолтным путем хранения данных пользователя ??

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

сам-то пробовал? а слышал что при этом тебе пользователи говорят?

ещё раз - magic chroot позволял решить специфичную проблему, автоматически поставить при входе в хомяк, при этом автоматически сделав чрут на уровень выше (или больше, тоже применялось).

и да - internal-sftp не всегда был в openssh

плюс там был полноценный доступ по ssh. и полноценный хомяк на полном автомате
а «sshd won’t chroot into user-owned directory», корневая причина в этом.

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

ЯННП.

сам-то пробовал? а слышал что при этом тебе пользователи говорят?

Сам пробовал, пользователей не слышал.

ещё раз - magic chroot позволял решить специфичную проблему, автоматически поставить при входе в хомяк, при этом автоматически сделав чрут на уровень выше (или больше, тоже применялось).

Это зачем?

и да - internal-sftp не всегда был в openssh

Это да, тут спору нет.

плюс там был полноценный доступ по ssh. и полноценный хомяк на полном автомате
на полном автомате

Вот с этого и надо было начинать!

Погоди, погоди. sshd это для сервера. А если атака идёт на/через юзера? Вот сайты ваша фирма делает и разраб заливает код через ssh на сервера. Злоумышленнику может быть очень полезно почитать ваш код который ты туда залил. Сервер может и не ломаться, попробуй сначала найди какой именно ломать надо, интернет большой и всё за клаудфларами от которых не только РКН плачет, но и куча кулхацкеров. А так сломал админа который с сайтом что-то делает по ssh, открыл файлик ~/.ssh/known_hosts и вот и всё, знаем что ломать, а может даже и ключик у юзера уведём.

Не, патчить плохо — на хомяка куда ты получил доступ могут поставить noexec и бинарики работать не будут, чтоб бинарик засунуть свой это надо рута иметь, а рута если заимел, то можно куда интереснее штуки делать. А вот скрипт обёртка с нужным названием засунутая куда-то в PATH (это можно сделать имея права юзера и срать ему на noexec, он скрипт а интерпритаторы многие срут на noexec, у них свой механизм запуска) это как раз то, как тебя будут ломать, повышая права или перехватывая твою работу в консольке.

Ты ничего с этим не можешь сделать. Вирус может прописать себя и в код проекта (прецеденты есть) и быть задеплоенным вообще добровольно. Плюс SSH ключи имеют характерную сигнатуру и вообще не проблема просканировать весь хомяк на них и найти в любой папке.

Единственное, что может защитить - ключи защищённые паролем. Но это на усмотрение разработчика.

Может, но какова цена разработки? Вирус который пропишет себя в автозапуск или PATH и подменит собой sudo условное стоит копейки, его можно силами половины людей в этом треде сделать за пару часов вместе с отладкой и тестированием. Чтоб незаметно прописать вирус в код надо либо ИИ-шку в вирус встраивать, либо знать код заранее (а это значит что придётся коннектится человечку к вам и код смотреть, что и палевно и долго и дорого), чтоб понимать куда и как встраивать.

А так сломал админа который с сайтом что-то делает по ssh, открыл файлик ~/.ssh/known_hosts и вот и всё, знаем что ломать, а может даже и ключик у юзера уведём.

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

Может, но какова цена разработки? Вирус который пропишет себя в автозапуск или PATH и подменит собой sudo условное стоит копейки, его можно силами половины людей в этом треде сделать за пару часов вместе с отладкой и тестированием.

В чём проблема подменить не sudo, а ssh и точно так же сделать всё что угодно при следующей попытке админа подключиться по ssh? Без всякой необходимости что-то сохранять в ~/.ssh? Можно так, чтобы он заметил, что у него почему-то не спросили про хост, а можно и заэмулировть это, чтобы он даже ничего не заметил.

Если пользователь имеет какой-то доступ, и этого пользователя жёстко взломали (с доступом к ФС и т.д.) — считай, что злоумышленик имеет доступ ко всему, к чему имеет пользователь. Это работает только так, обезопасить за счёт каких-то странных манипуляций с конкретным каталогом, не получится — это иллюзия безопасности.

Да, можно юзера загнать совсем в песочницу, сделать ему на хомяк, на /tmp, на /run и прочее везде строго noexec, также запретить автозапуск любых скриптов, запретить cron, запретить at, и т.д. Чтобы он сам толком ничего сделать не мог, только по ssh подключиться и всё. Тогда да, наверное возможно добиться какой-то безопасности. Но судя по идеям и вопросам, ты не справишься с таким — где-нибудь какую-нибудь «дырку» да забудешь заткнуть. Это не в обиду, если что, я и сам не уверен, что справился бы, особенно если у юзера физический доступ есть.

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

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

Да, какой-нибудь любитель писать веб-сервисы на C++ (и обязательно на самописном фреймворке) не пострадает, но большинство проектов написаны на Python/JS/PHP/Java и там много чего стандартизировано.

Собирая вместе вышесказанное, просто берёшь топ языков и фреймворков из всяких рейтингов типа «самый популярный язык для бекэнд разработки в 2026», качаешь пару десятков OpenSource проектов на этих стеках, запускаешь ИИ агента в корне с задачей «мне нужно написать автопатчер для добавления библиотеки foo в каждый из этих проектов, сделай патчер максимально надёжным, чтобы он смог патчить проекты с похожей, но другой структурой». ИИ справится.

неужели нельзя выключить

конечно можно!

1. форкнуть репозиторий https://github.com/openssh/openssh-portable

2. сделать в форке нужные вам изменения

3. собрать для своей системы пакет

4. установить пакет на все необходимые хосты

5. …

6. PROFIT!

Проблем много. Начиная от ребута компа админа (только то что в PATH есть переживёт, а если ещё и хомяк (по крайней мере важные файлы, вроде .bashrc) сбрасывается после каждого включения, то не переживёт)

Но судя по идеям и вопросам, ты не справишься с таким

ТС вероятно не сможет, но ты не с ТС-ом споришь, а со мной (сорян что с анона — запускать шумную пекарню не могу так рано). А я, поверь, знаю как такое делать.

Но судя по идеям и вопросам, ты не справишься с таким

Это да какая-нибудь дырка останется даже если всё АНБ напрячь, но не забывай, чтоб эту дырку найти взломщик должен знать пекичи лучше меня, а это значит что от половины злоумышленников ЛОР-а можно спать спокойно. И да, всё что ты написал про то что юзеру надо всё запретить что ему не нужно это я полностью поддерживаю. Ни крона ни автозапуска у него быть не должно от прав юзера.

Если ты вообще чайничек в ИБ, то я бы взял виртуальную машину и разрешил бы работать тебе только в ней (если ты админ лучше, то есть другие варианты, вроде загрузки ОС по сети, монтирования каталогов по сети и так далее), а с неё пробросил бы на хост пару каталогов (загрузки и документы), всё остальное откатывать после выключения к дефолтному образу. Это гарантия того что мало что сможет выжить между загрузками (только то что сломает сам хост или если есть уязвимость, вроде той, что запускала файл с определённым названием в долфине при попытке отрисовать миниатюры, т.е. в случае загрузок сразу при открытии долфина). Ну или конечно вредный файл, но его надо запустить ручками или открыть и опять надо zero day уязвимость знать к софту который на машинке есть, а это очень сильно отсекает круг взломщиков.

По-хорошему, скрипты сборки и системы сборки должны проверять целостность того что они собирают (включая патчинг библиотек, хотя бы по хешам, прежде чем деплоить всё это добро в продакшн). Думаю даже спрос на готовое решение будет, как раз потому что наступил век ИИ. Потому как подобные атаки были.