MaxSessions, MaxStartups или регистрация: кой SSH лимит да изберем

Тунелните услуги, които обещават едно устройство на абонат, рядко получават това обещание от MaxSessions и първият тест обикновено го доказва. Абонатът отваря втори процес ssh, първата сесия продължава да работи и двата тунела пренасят трафик. Всяка опция за конфигурация брои различно нещо и нито една от тях не брои устройства. Именуването на обещанието първо прави избора между тях очевиден.

Какво всъщност брои всяка опция

MaxSessions ограничава броя на отворените сесии, пренасяни от една удостоверена мрежова връзка. Сесия тук означава шел, заявка exec, подсистема като SFTP или подобен канал, мултиплексиран в един SSH транспорт. Второ извикване на ssh отваря втори транспорт, удостоверява се отново и получава собствено разрешение. Броят сесии на първата връзка е без значение за него.

MaxStartups ограничава едновременните връзки, които още не са удостоверени, изразени като начален праг, скорост и пълен праг. Съществува, за да не може взрив от полуотворени ръкостискания да изчерпи ресурсите на демона преди удостоверяване. Щом клиентът се удостовери, тази връзка спира да се брои срещу MaxStartups и става нечия сесия. Той никога не е бил квота за потребител и вдигането му не позволява на абоната да прави повече.

Правилото за регистрация на устройство изобщо не е опция на sshd. То принадлежи на онази система, която издава удостоверения и следи кое устройство ги държи, което означава, че се нуждае от регистрация, инвентар и отзоваване, а не от брояч. Смесването на това изискване в конфигурацията на sshd е мястото, където повечето такива проекти зациклят.

Къде MaxSessions престава да бъде квота

Блокът Match User променя кои конфигурационни стойности се прилагат към този потребител, затова е естественото място за по-строг MaxSessions за служебен акаунт. Това, което не може да направи, е да агрегира през връзки, защото опцията се оценява за всеки транспорт. Двата транспорта получават собствени лимити и потребителят в крайна сметка има двойно повече от разрешеното от блока.

Препращането е отделна изненада. TCP препращането не се нуждае от канал за сесия, така че MaxSessions 0 може да забрани шелове и подсистеми, като същевременно разрешава тунели -L и -R. Услуга, която само препраща и приема броя сесии за своя тунелна квота, не измерва нищо. Това поведение е документирано в справочника за конфигурация на сървъра OpenSSH и си струва да се прочете, преди да се проектира около име на опция.

Изведете ефективната конфигурация, а не файла, който мислите, че е зареден. Включванията и drop-in директориите обикновено означават, че действащата стойност не е стойността, която сте редактирали.

MaxStartups пази демона, а не абоната

Триделната форма на MaxStartups описва колко неудостоверени връзки могат да съществуват, преди демонът да започне да изпуска процент от новите. Формата му по подразбиране съществува, защото неудостоверена SSH връзка е евтина за отваряне и скъпа за поддържане. Това е контрол за защита на ресурсите на сървъра и се прилага за всички наведнъж.

Вдигането му по време на буря от влизания разменя защитата на демона срещу допускане, което понякога е правилната размяна и винаги е съзнателна. Не прави нищо за абоната, който иска втори тунел, защото първият тунел вече е удостоверен. Объркването на двете води до промяна, която поправя грешния симптом и едновременно отслабва сървъра.

Когато влизанията се отказват на пристъпи, погледнете в журнала на демона съобщението преди удостоверяване, преди да пипате която и да е от двете опции. Съобщението назовава коя защита е задействана и защитите не са взаимозаменяеми.

Слотът за потребител изисква споделено състояние

Истинска политика за един активен транспорт изисква резервация, държана някъде извън sshd. Стъпката на допускане трябва атомарно да заеме слота на акаунта, да го освободи при затваряне на връзката, да го изтече, когато клиент изчезне без затваряне, и да реши дали нов опит се отхвърля или заменя стария. Последното решение е продуктово решение, а не техническа подробност, защото замяната на активен тунел прекъсва някого.

Резервацията трябва да се споделя и от всеки сървър, който приема акаунта. Два хоста с независими локални броячи налагат два отделни лимита и абонат, който се свърже отново през другия шлюз, получава втори слот безплатно. Това, което съхранява състоянието, се нуждае от собствено поведение при отказ, тъй като недостъпно хранилище не бива да заключа всички абонати.

За обещание за едно устройство издайте отделно удостоверение за всяко регистрирано устройство и контролирайте регистрацията и отзоваването на това ниво. Копиран частен ключ все още се удостоверява от всякъде, така че издаването на един ключ на потребител не е доказателство колко машини го държат.

Проверете политиката с две реални връзки

Напишете приемните тестове като команди, преди да напишете политиката. Петте случая са втори транспорт, отворен докато първият е активен, множество канали в един транспорт, клиент, който само препраща портове, повторно свързване след прекъсната връзка и същият акаунт, пристигащ на друг шлюз.

Първо прочетете ефективните лимити, после отворете връзките, които политиката трябва да откаже. И двете половини на този тест са важни и нито една не замества другата.

sshd -T | grep -iE "maxsessions|maxstartups|allowtcpforwarding|permitopen"
ss -tn state established '( sport = :22 )' | head
ssh -N -L 8080:127.0.0.1:80 [email protected]

Стартирайте тунелната команда два пъти в два терминала и пребройте установените връзки на порт 22. Ако и двете пренасят трафик, докато политиката ви твърди един активен транспорт, политиката е документация, а не прилагане. Поправете тази пропуск в слоя за допускане, а не като намалите MaxSessions и се надявате вторият транспорт да го забележи.