از لحاظ تاریخی، مجوزهای sudo بر اساس محتویات فایلها کنترل میشد /etc/sudoers.d и ویسودوو مجوز کلید با استفاده از آن انجام شد ~/.ssh/authorized_keys. با این حال، با رشد زیرساخت ها، تمایل به مدیریت متمرکز این حقوق وجود دارد. امروزه ممکن است چندین گزینه راه حل وجود داشته باشد:
- سیستم مدیریت پیکربندی - سر اشپز, عروسک خیمه شب بازی, غیر ممکن, نمک
- اکتیو دایرکتوری + ssd
- انحرافات مختلف در قالب اسکریپت و ویرایش دستی فایل
به نظر ذهنی من، بهترین گزینه برای مدیریت متمرکز همچنان ترکیبی است اکتیو دایرکتوری + ssd. مزایای این روش عبارتند از:
- واقعاً یک دایرکتوری متمرکز کاربر.
- تقسیم حقوق کد: sudo به اضافه کردن یک کاربر به یک گروه امنیتی خاص منجر می شود.
- در مورد سیستم های مختلف لینوکس، بررسی های اضافی برای تعیین سیستم عامل هنگام استفاده از سیستم های پیکربندی ضروری است.
مجموعه امروز به طور خاص به اتصال اختصاص داده خواهد شد اکتیو دایرکتوری + ssd برای مدیریت حقوق کد: sudo و ذخیره سازی SSH کلیدها در یک مخزن واحد
بنابراین، سالن در سکوت شدید یخ کرد، رهبر ارکستر باتوم خود را بلند کرد و ارکستر آماده شد.
برو
داده شده:
- دامنه اکتیو دایرکتوری testopf.local در ویندوز سرور 2012 R2.
- هاست لینوکس که Centos 7 را اجرا می کند
- پیکربندی مجوز با استفاده از ssd
هر دو راه حل تغییراتی را در طرحواره ایجاد می کنند اکتیو دایرکتوری، بنابراین همه چیز را در یک محیط آزمایشی بررسی می کنیم و تنها پس از آن تغییراتی در زیرساخت کار ایجاد می کنیم. من می خواهم توجه داشته باشم که تمام تغییرات هدفمند هستند و در واقع فقط ویژگی ها و کلاس های لازم را اضافه می کنند.
اقدام 1: کنترل کد: sudo نقش ها از طریق اکتیو دایرکتوری.
برای گسترش مدار اکتیو دایرکتوری شما باید آخرین نسخه را دانلود کنید
ldifde -i -f schema.ActiveDirectory -c dc=X dc=testopf,dc=local
(فراموش نکنید که ارزش های خود را جایگزین کنید)
باز کن adsiedit.msc و به زمینه پیش فرض متصل شوید:
یک تقسیم در ریشه دامنه ایجاد کنید ژاکت. (بورژوازی سرسختانه ادعا می کند که در این واحد است که شیطان ssd یک مورد را جستجو می کند sudoRole اشیاء. با این حال، پس از روشن کردن اشکالزدایی دقیق و مطالعه گزارشها، مشخص شد که جستجو در کل درخت دایرکتوری انجام شده است.)
ما اولین شی متعلق به کلاس را در بخش ایجاد می کنیم sudoRole. نام را می توان کاملاً خودسرانه انتخاب کرد، زیرا صرفاً برای شناسایی راحت است.
در میان ویژگی های موجود در پسوند طرحواره، اصلی ترین آنها به شرح زیر است:
- sudoCommand - تعیین می کند که کدام دستورات مجاز به اجرا در هاست هستند.
- sudoHost - تعیین می کند که این نقش برای کدام میزبان ها اعمال می شود. می توان به عنوان مشخص کرد همهو برای یک میزبان فردی با نام. امکان استفاده از ماسک نیز وجود دارد.
- sudoUser - مشخص کنید که کدام کاربران مجاز به اجرا هستند کد: sudo.
اگر یک گروه امنیتی را مشخص می کنید، علامت "%" را در ابتدای نام اضافه کنید. اگر در نام گروه فاصله وجود داشته باشد، جای نگرانی نیست. با قضاوت بر اساس سیاهههای مربوط، وظیفه فرار از فضاها توسط مکانیسم انجام می شود ssd.
شکل 1. اشیاء sudoRole در زیربخش sudoers در ریشه دایرکتوری
شکل 2. عضویت در گروه های امنیتی مشخص شده در اشیاء sudoRole.
راه اندازی زیر در سمت لینوکس انجام می شود.
در پرونده /etc/nsswitch.conf خط را به انتهای فایل اضافه کنید:
sudoers: files sss
در پرونده /etc/sssd/sssd.conf در بخش [sssd] به خدمات اضافه کنید کد: sudo
cat /etc/sssd/sssd.conf | grep services
services = nss, pam, sudo
پس از تمام عملیات، باید کش sssd daemon را پاک کنید. بهروزرسانیهای خودکار هر 6 ساعت یکبار اتفاق میافتد، اما چرا وقتی اکنون آن را میخواهیم باید اینقدر صبر کنیم؟
sss_cache -E
اغلب اتفاق می افتد که پاک کردن کش کمکی نمی کند. سپس سرویس را متوقف می کنیم، پایگاه داده را تمیز می کنیم و سرویس را راه اندازی می کنیم.
service sssd stop
rm -rf /var/lib/sss/db/*
service sssd start
ما به عنوان اولین کاربر متصل می شویم و آنچه را که در sudo در دسترس او است بررسی می کنیم:
su user1
[user1@testsshad log]$ id
uid=1109801141(user1) gid=1109800513(domain users) groups=1109800513(domain users),1109801132(admins_)
[user1@testsshad log]$ sudo -l
[sudo] password for user1:
Matching Defaults entries for user1 on testsshad:
!visiblepw, always_set_home, match_group_by_gid, always_query_group_plugin,
env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE KDEDIR LS_COLORS",
env_keep+="MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE",
env_keep+="LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES",
env_keep+="LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE",
env_keep+="LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY",
secure_path=/sbin:/bin:/usr/sbin:/usr/bin
User user1 may run the following commands on testsshad:
(root) /usr/bin/ls, /usr/bin/cat
ما همین کار را با کاربر دوم خود انجام می دهیم:
su user2
[user2@testsshad log]$ id
uid=1109801142(user2) gid=1109800513(domain users) groups=1109800513(domain users),1109801138(sudo_root)
[user2@testsshad log]$ sudo -l
Matching Defaults entries for user2 on testsshad:
!visiblepw, always_set_home, match_group_by_gid, always_query_group_plugin,
env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE KDEDIR LS_COLORS",
env_keep+="MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE",
env_keep+="LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES",
env_keep+="LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE",
env_keep+="LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY",
secure_path=/sbin:/bin:/usr/sbin:/usr/bin
User user2 may run the following commands on testsshad:
(root) ALL
این رویکرد به شما اجازه می دهد تا نقش های sudo را به صورت متمرکز برای گروه های کاربری مختلف تعریف کنید.
ذخیره و استفاده از کلیدهای ssh در اکتیو دایرکتوری
با گسترش جزئی طرح، میتوان کلیدهای ssh را در ویژگیهای کاربر Active Directory ذخیره کرد و از آنها هنگام مجوز در هاستهای لینوکس استفاده کرد.
مجوز از طریق sssd باید پیکربندی شود.
ویژگی مورد نیاز را با استفاده از اسکریپت PowerShell اضافه کنید.
AddsshPublicKeyAttribute.ps1تابع New-AttributeID {
$Prefix="1.2.840.113556.1.8000.2554"
$GUID=[System.Guid]::NewGuid().ToString()
$Parts=@()
$Parts+=[UIint64]::Parse($guid.SubString(0,4)،"AllowHexSpecifier")
$Parts+=[UIint64]::Parse($guid.SubString(4,4)،"AllowHexSpecifier")
$Parts+=[UIint64]::Parse($guid.SubString(9,4)،"AllowHexSpecifier")
$Parts+=[UIint64]::Parse($guid.SubString(14,4)،"AllowHexSpecifier")
$Parts+=[UIint64]::Parse($guid.SubString(19,4)،"AllowHexSpecifier")
$Parts+=[UIint64]::Parse($guid.SubString(24,6)،"AllowHexSpecifier")
$Parts+=[UIint64]::Parse($guid.SubString(30,6)،"AllowHexSpecifier")
$oid=[String]::Format(«{0}.{1}.{2}.{3}.{4}.{5}.{6}.{7}»,$prefix,$Parts[0],
$Parts[1],$Parts[2],$Parts[3],$Parts[4],$Parts[5],$Parts[6])
$oid
}
$schemaPath = (Get-ADRootDSE).schemaNamingContext
$oid = New-AttributeID
$attributes = @{
lDAPDisplayName = 'sshPublicKey';
ویژگیId = $oid;
oMSyntax = 22;
featureSyntax = "2.5.5.5";
isSingleValued = $true;
adminDescription = 'کلید عمومی کاربر برای ورود به سیستم SSH';
}
New-ADObject -Name sshPublicKey -Type featureSchema -Path $schemapath -OtherAttributes $attributes
$userSchema = get-adobject -SearchBase $schemapath -Filter 'name -eq "user"'
$userSchema | Set-ADObject -Add @{mayContain = 'sshPublicKey'}
پس از افزودن ویژگی، باید Active Directory Domain Services را مجددا راه اندازی کنید.
بیایید به سراغ کاربران اکتیو دایرکتوری برویم. ما یک جفت کلید برای اتصال ssh با استفاده از هر روشی که برای شما مناسب است ایجاد می کنیم.
PuttyGen را راه اندازی می کنیم، دکمه "Generate" را فشار می دهیم و دیوانه وار ماوس را در ناحیه خالی حرکت می دهیم.
پس از اتمام فرآیند، میتوانیم کلیدهای عمومی و خصوصی را ذخیره کنیم، کلید عمومی را در ویژگی کاربر Active Directory آپلود کنیم و از فرآیند لذت ببریم. با این حال، کلید عمومی باید از " استفاده شودکلید عمومی برای چسباندن در فایل OpenSSH authorized_keys:".
کلید را به ویژگی کاربر اضافه کنید.
گزینه 1 - رابط کاربری گرافیکی:
گزینه 2 - PowerShell:
get-aduser user1 | set-aduser -add @{sshPublicKey = 'AAAAB...XAVnX9ZRJJ0p/Q=='}
بنابراین، ما در حال حاضر داریم: یک کاربر با ویژگی sshPublicKey پر شده، یک سرویس گیرنده Putty پیکربندی شده برای مجوز با استفاده از کلیدها. یک نکته کوچک باقی می ماند: چگونه دیمون sshd را مجبور کنیم تا کلید عمومی مورد نیاز خود را از ویژگی های کاربر استخراج کند. یک اسکریپت کوچک که در اینترنت بورژوایی یافت می شود می تواند با موفقیت با این موضوع کنار بیاید.
cat /usr/local/bin/fetchSSHKeysFromLDAP
#!/bin/sh
ldapsearch -h testmdt.testopf.local -xb "dc=testopf,dc=local" '(sAMAccountName='"${1%@*}"')' -D [email protected] -w superSecretPassword 'sshPublicKey' | sed -n '/^ /{H;d};/sshPublicKey:/x;$g;s/n *//g;s/sshPublicKey: //gp'
مجوزهای روی آن را روی 0500 برای root قرار دادیم.
chmod 0500 /usr/local/bin/fetchSSHKeysFromLDAP
در این مثال، یک حساب مدیر برای اتصال به دایرکتوری استفاده می شود. در شرایط جنگی باید یک حساب جداگانه با حداقل مجموعه ای از حقوق وجود داشته باشد.
من شخصاً با وجود حقوق تعیین شده، با لحظه رمز عبور به شکل خالص آن در اسکریپت بسیار گیج شدم.
گزینه راه حل:
- رمز عبور را در یک فایل جداگانه ذخیره می کنم:
echo -n Supersecretpassword > /usr/local/etc/secretpass
- من مجوزهای فایل را برای روت روی 0500 تنظیم کردم
chmod 0500 /usr/local/etc/secretpass
- تغییر پارامترهای راه اندازی ldapsearch: پارامتر -w superSecretPassword تغییرش میدم به -y /usr/local/etc/secretpass
آخرین آکورد در مجموعه امروزی ویرایش sshd_config است
cat /etc/ssh/sshd_config | egrep -v -E "#|^$" | grep -E "AuthorizedKeysCommand|PubkeyAuthe"
PubkeyAuthentication yes
AuthorizedKeysCommand /usr/local/bin/fetchSSHKeysFromLDAP
AuthorizedKeysCommandUser root
در نتیجه، دنباله زیر را با مجوز کلید پیکربندی شده در کلاینت ssh دریافت می کنیم:
- کاربر با نشان دادن لاگین خود به سرور متصل می شود.
- دیمون sshd، از طریق یک اسکریپت، مقدار کلید عمومی را از یک ویژگی کاربر در اکتیو دایرکتوری استخراج می کند و با استفاده از کلیدها مجوز را انجام می دهد.
- دیمون sssd بیشتر کاربر را بر اساس عضویت در گروه احراز هویت می کند. توجه! اگر این پیکربندی نشده باشد، هر کاربر دامنه به میزبان دسترسی خواهد داشت.
- وقتی میخواهید sudo کنید، دیمون sssd در Active Directory نقشها را جستجو میکند. اگر نقشها وجود داشته باشند، ویژگیهای کاربر و عضویت در گروه بررسی میشوند (اگر sudoRoles برای استفاده از گروههای کاربر پیکربندی شده باشد)
خلاصه.
بنابراین، کلیدها در ویژگی های کاربر Active Directory، مجوزهای sudo ذخیره می شوند - به طور مشابه، دسترسی به هاست های لینوکس توسط حساب های دامنه با بررسی عضویت در گروه Active Directory انجام می شود.
آخرین موج باتوم رهبر ارکستر - و سالن در سکوتی محترمانه یخ می زند.
منابع مورد استفاده در نوشتن:
منبع: www.habr.com