آموزش اسکریپت نویسی

آموزش اسکریپت نویسی پوسته گنو-لینوکس

آموزش اسکریپت نویسی

آموزش اسکریپت نویسی پوسته گنو-لینوکس

ssh keys

کلیدهای اعتبار سنجی در پوسته امن

این صفحه روشهایی را که در آنها اعتبار سنجی مبتنی بر کلید SSH ممکن است ناموفق گردد، و برخی اقداماتی را که شما می‌توانید برای حل آنها به عمل آورید، تشریح می‌کند. شکست تصدیق اعتبارِ کلید، احتمالاً رایج‌ترین مشکل برای کاربران جدید در آزمودن SSH است، و پاسخگویی مکرر به این پرسشها خسته کننده است....

نگاه کلی

این نظر اجمالی، مفاهیم اصلی تصدیق اعتبار کلید عمومی را برای آنهایی که هنوز چیز زیادی در مورد آن نمی‌دانند، شرح می‌دهد.

کلید عمومی اعتبار سنجی، به کار بردن رمزنگاری برای اثبات آنکه شما مالک مطمئن اعتبارنامه می‌باشید را شامل می‌گردد، بدون آنکه واقعاً آن اعتبارنامه را برای طرف دیگر آشکار سازد. مخصوصاً، سرویس‌گیرنده یک کلید خصوصی را نگهداری می‌کند، که ممکن است با یک عبارت عبور رمزی شده یا نشده باشد. سرویس‌دهنده یک کلید عمومی را نگهداری می‌کند. سرویس‌دهنده و گیرنده یک روش Zero-knowledge proof ‎ [1] ‎  را به کار می‌برند، که در این روش سرویس‌گیرنده ثابت می‌کند که نگهدارنده کلید خصوصی است، اما در عمل کلید محرمانه را انتقال نمی‌دهد.

تنظیم نمودن آن مستلزم چند مرحله است. نخست، یک جفت کلید (کلیدهای خصوصی و عمومی) در سیستم سرویس‌گیرنده تولید می‌شوند. سپس، کلید عمومی به سرویس‌دهنده کپی می‌گردد، (افزوده می‌شود) به فایل ‎~username/.ssh/authorized_keys‎ (یک فایل ساده متنی). این فایل به برنامه sshd روی سرویس‌گیرنده می‌گوید که به نگهدارنده کلید خصوصی که با کلید عمومی منطبق گردد اجازه داده می‌شود به عنوان «username» به سیستم متصل گردد.

کلید عمومی اطلاعات مخفیانه نیست، و نیازی به محافظت شدن ندارد. اگر اشخاصی کلید عمومی شما را به فایل authorized_keys خودشان کپی کنند، این تنها به آنها آسیب می‌رساند، نه به شما -- این به شما اجازه می‌دهد به سیستم آنها متصل شوید.

کلید خصوصی اطلاعات محرمانه است، و از اینرو باید محافظت گردد. کلید خصوصی معمولاً با استفاده از یک عبارت عبور رمزی شده است، که باید قبل از اینکه کلید خصوصی بتواند به کار برود در سیستم سرویس‌گیرنده وارد شده باشد. عبارت عبور کلید خصوصی ربطی به کلمه عبور سرویس‌دهنده ندارد (اگر سرویس‌دهنده چنین موردی دارد). این دو نباید باهم اشتباه شوند.

تنظیم

اکثر فرمانهای نشان داده شده در این صفحه فرض می‌کنند که شما در حال استفاده از OpenSSH می‌باشید. معادل‌هایی در سایر پیاده‌سازی‌ها وجود دارد، ممکن است آنها گاهی اوقات نامهای متفاوتی داشته باشند (برای مثال، ssh-keygen2 یا puttygen). وقتی مردد هستید، مستندات خودتان را کنکاش کنید.

برای آغازگران، لطفاً ‎man ssh-keygen‎ (یا معادل آن) در سیستم خود را بخوانید. این صفحه پردازش اصلی تولید یک جفت کلید، و سپس قرار دادن کلید عمومی در سرویس‌گیرنده را شرح می‌دهد.

SSH دارای دو قرارداد برای ارتباطات است، که ‎"protocol 1"‎ و ‎"protocol 2"‎ نامیده می‌شوند. پروتکل 1 فرسوده در نظر گرفته می‌شود، و نباید به کار برود. با وجود این، تا همین اواخر تنظیم پیش‌فرضِ ssh-keygen در OpenSSH برای تولید یک جفت کلید هنوز پروتکل-1 بود. بنابراین، شما همواره باید به طور صریح مشخص نمایید که کدام نوعِ جفت کلید را می‌خواهید تولید کنید.

پروتکل 2 دو الگوریتم متفاوت برای کلید عمومی اعتبارسنجی ارایه می‌کند: RSA‎[2]‎ و DSA. الگوریتم RSA بواسطه حقوق انحصاری ثبت شده‌(patent) چند سال قبل انحصاری شده بود (آن حقوق اکنون منقضی گردیده است). DSA در هنگامیکه RSA گرفتار شده بود به عنوان یک جایگزین ایجاد شد. هردو «مطمئن» به شمار می‌روند، و شما می‌توانید یکی از آنها را به کار ببرید: 

   ssh-keygen -t rsa    # or
   ssh-keygen -t dsa

توجه نمایید برای اینکه هرگز نیازی نباشد که کلید خصوصی به جایی انتقال داده شود، تولید جفت کلید معمولاً روی سرویس‌گیرنده انجام می‌شود.

برای محل جفت کلید و عبارت عبور به شما اعلان داده خواهد شد (برای پذیرش پیش فرض‌ها فقط کلید اینتر را بزنید). اگر یک عبارت عبور به کار ببرید، کلید خصوصی رمزبندی خواهد شد. هر زمان که سرویس‌گیرنده SSH به خواندن کلید خصوصی احتیاج داشته باشد، لازم خواهد بود که عبارت عبور شما را برای باز کردن آن استفاده کند -- یا بواسطه اعلان به شما برای آن، یا از طریق به دست آوردن آن از ssh-agent. این مطلب مقداری امنیت در برابر سرقت کلید خصوصی برای شما فراهم می‌کند. اگر از یک عبارت عبور استفاده نکنید، آنوقت هر شخصی که کلید خصوصی شما را به دست آورد (به عنوان مثال، از یک پشتیبانِ دایرکتوری خانگی شما) قادر به استفاده از آن خواهد بود. (تنظیم ssh-agent در اینجا پوشش داده نمی‌شود.)

موقعی که ssh-keygen انجام می‌شود، شما دو فایل خواهید داشت: 

   $HOME/.ssh/id_rsa       # کلید خصوصی‎
   $HOME/.ssh/id_rsa.pub   # کلید عمومی‎

اگر یک جفت کلید DSA تولید کردید، یا اگر از یک پیاده‌سازی متفاوت استفاده می‌کنید، نامها تفاوت خواهند داشت. کلید خصوصی شما باید محرمانه نگهداری شود. اگر یک عبارت عبور به کار برده‌اید، آن نیز رمزبندی می‌شود. کلید عمومی باید به سرویس‌دهنده جایی که sshd بتواند آن را بخواند کپی گردد.

اکنون، قبل از انجام آن، لازم است شما بدانید که دو قالب متفاوت وجود دارد که کلید عمومی ممکن است در آنها ذخیره شود: قالب OpenSSH، یا قالب SECSH. ممکن است لازم باشد شما کلید عمومی را به هر کدام از قالب‌ها که پیاده‌سازی sshd روی سرویس‌دهنده شما می‌داند چطور آن را بخواند، تبدیل نمایید. اگر جفت کلید را با استفاده از OpenSSH تولید کرده‌اید، آنوقت (آشکارا) کلید عمومی شما در قالب OpenSSH خواهد بود. اگر sshd در سرویس‌دهنده شما OpenSSH (که می‌توانید با کاربرد ‎telnet server.hostname 22‎ و خواندن banner تعیین کنید) ‌باشد، آنوقت کلید شما نیازی به تبدیل ندارد.

اگر سرویس‌دهنده شما در یک پیاده‌سازی اجرا می‌شود که از قالب SECSH استفاده می‌کند، پس شما احتیاج خواهید داشت که کلید عمومی را به آن قالب تبدیل کنید. ssh-keygen گزینه‌هایی برای انجام آن دارد، برای دیدن چگونگی انجام آن، صفحه man مربوط را بخوانید. به همچنین، اگر شما جفت کلیدتان را با استفاده از PuTTY (یا مورد دیگری که قالب SECSH را به کار می‌برد) تولید کرده‌اید، و سرویس‌دهنده شما OpenSSH را اجرا می‌کند، آنوقت لازم است کلید عمومی شما به قالب OpenSSH تبدیل شود.

هر وقت کلید در قالب صحیح باشد، باید در فایلی (نه دایرکتوری) به نام ‎$HOME/.ssh/authorized_keys‎ روی سرویس‌دهنده قرار داده شود. اگر شما قبلاً به این سرویس‌دهنده متصل شده‌اید، یا در صورتیکه قبلاً از سرویس‌گیرنده ssh روی این سرور استفاده نموده‌اید، آنوقت دایرکتوری ‎$HOME/.ssh‎ باید از قبل موجود باشد، و سپس تمام آنچه شما نیاز به انجام آن خواهید داشت، الحاق کلید عمومی‌تان به انتهای فایل authorized_keys است.

(برخی افراد مایل هستند از برنامه ssh-copy-id برای کپی کلید عمومی‌شان به فایل authorized_keys روی سرویس‌دهنده استفاده نمایند. اگر نگارش SSH شما دارای آن هست، برای دستورالعمل‌ها ‎man ssh-copy-id‎ را ببینید.)

رفع نقص

اگر شما سعی در ارتباط با سرویس‌دهنده می‌نمایید، و اگر هنوز اعلان برای کلمه عبور به شما داده می‌شود، پس ممکن است سرویس‌دهنده پذیرش کلید شما را رد کرده است. اگر این حالت است، چند مورد وجود دارد که باید کنترل کنید.

اول حصول اطمینان از آنکه شما فهمیده‌اید که آیا واقعاً برای یک کلمه عبور (توسط سرویس‌دهنده)، یا یک عبارت عبور (توسط سرویس‌گیرنده) به شما اعلان داده شده است. اگر سرویس‌گیرنده نیاز به یک عبارت عبور برای رمزگشایی کلید خصوصی دارد، موردِ کاملاً متفاوتی با قبول نکردن کلید توسط سرور و برگشت به عقب برای کلمه عبور اعتبارسنجی است.

این یک مثال از پرسش سرویس‌گیرنده برای عبارت عبور است: 

cyclops:~$ ssh golem
Enter passphrase for key '/home/greg/.ssh/id_rsa':

این یک مثال از پرسش سرویس‌دهنده برای یک کلمه عبور می‌باشد: 

imadev:~$ ssh vandev
wooledg@vandev's password:

دوم، لطفاً توجه کنید که فایل authorized_keys از املای آمریکایی استفاده می‌کند، نه املای بریتانیایی. اگر شما کلید را در فایل authorised_keys قرار بدهید کار نخواهد کرد.

سوم، اطمینان حاصل نمایید که کلید عمومی را به سرویس‌گیرنده کپی نموده‌اید، نه کلید خصوصی را.

اگر یکی از این موارد نیست، آنوقت شما نیاز دارید مجوزهای همه چیز را کنترل کنید. اگر کلید عمومی در جایی باشد که سایر کاربران قادر به نوشتن کلیدهای عمومی‌شان باشند، OpenSSH از پذیرش کلید عمومی شما امتناع خواهد نمود. (اگر یک کاربر دیگر بتواند در فایل authorized_keys شما بنویسد، آنوقت او می‌تواند کلید خودش را آنجا قرار بدهد، و سپس به عنوان شما لاگین کند.)

این بخشی است که اکثر افراد اشتباه می‌کنند. نه تنها باید تضمین نمایید که خود فایل authorized_keys مجوزهای نوشتن گروه و دیگران را نداشته باشد، بلکه همچنین باید اطمینان حاصل نمایید که هر دایرکتوری در مسیر کامل رسیدن به آن فایل به طور مشابهی فاقد مجوزهای نوشتن گروه و دیگران ‌باشد. برای مثال: 

   wooledg@hostname:~$ echo $HOME
   /home/wooledg
   wooledg@hostname:~$ ls -ld / /home /home/wooledg /home/wooledg/.ssh
   drwxr-xr-x 21 root    root    4096 2007-07-03 08:57 /
   drwxrwsr-x  3 root    staff   4096 2006-07-20 14:32 /home
   drwxr-sr-x 25 wooledg wooledg 4096 2007-07-17 17:00 /home/wooledg
   drwx--S---  2 wooledg wooledg 4096 2006-07-20 14:40 /home/wooledg/.ssh
        ^
        |
        +-- .مجوز نوشتن گروه‎

در بسیاری از پیاده‌سازی‌ها، وجود بیت مجوز نوشتنِِ گروه در دایرکتوری ‎/home‎ سبب خواهد شد sshd یک فایل authorized_keys در این دایرکتوری ‎.ssh‎ کاربر را نپذیرد. (برخی تنظیمات پیکربندی وجود دارد که می‌تواند آن را تغییر بدهد، اما معمولاً به جای حذف اقدامات پیشگیرانه حفاظتی، اصلاح مجوز دایرکتوری‌های خیلی بی قید و بند، آسانتر و بهتر است.)

(جایی حول و حوش ‎OpenSSH 3.0‎ -- شماره نگارش دقیق نامشخص -- کنترل شدن مجوزها روی دایرکتوری‌های «فوق» دایرکتوری خانه کاربر متوقف شد. بنابراین، آزادی مجوزها روی دایرکتوری ‎/home‎ در نگارش‌های به اندازه کافی جدید OpenSSH موجب مشکل نخواهد بود. بازهم، اصلاح آنها آسیب نمی‌رساند.)

اشکالزدایی بیشتر

اگر هیچ یک از نکات بخش رفع نقص مشکل را برطرف نکرد، آنوقت شاید موقع کاوش عمیق‌تر باشد. اول از همه، توجه به اینکه سرویس‌دهنده به سرویس‌گیرنده نخواهد گفت که چرا یک کلید پذیرفته نمی‌شود ناگزیر است. این مطلب تعمدی است، برای ممانعت از فاش شدن اطلاعات برای یک مهاجم. بنابراین، هیچ مقداری از ‎ssh -vvvv‎ به هیچ نحوی [3] سودمند نخواهد بود. عدم پذیرش کلید ابداً نمی‌تواند در طرف سرویس‌گیرنده تشخیص داده شود.

به هر حال، گاهی اوقات یک عدم پذیرش کلید از طرف سرویس‌دهنده، می‌تواند عیب‌شناسی گردد. به احتمال بسیار زیاد برای تشخیص آن نیاز به مزایای کاربر ارشد ‎(root)‎ دارید. شروع جستجو برای جایی که sshd از قبل اطلاعات را در آنجا وقایع‌نگاری نموده، غالباً، این فایل ممکن است فایل ‎/var/log/auth.log‎، یا فایلی مشابه آن باشد. ببینید آیا در آنجا دلیلی برای عدم پذیرش قید گردیده. اگر نشده، یا اگر هنوز چنین فایلی موجود نیست، آنوقت ممکن است بخواهید یک نمونه دوم از sshd را روی یک درگاه جایگزین راه‌اندازی کنید: 

server# sshd -p 2200 -d

آن پنجره را باز نگاه دارید، چون اطلاعات اشکالزدایی در خروجی استاندارد نوشته می‌شود. سپس در سرویس‌گیرنده، با آن پورت جایگزین ارتباط بگیرید: 

client$ ssh -p 2200 username@server

اگر کلید پذیرفته نمی‌شود، باید یک دلیل برای عدم پذیرش در سرویس‌دهنده آشکار گردد.

tl;dr ‎[4]‎

اجازه بدهید برای شخص ناشکیبایی که مطلب را فقط به طور سطحی تا پایین خوانده است، رئوس مطالب را تکرار کنیم:

  1. کلید خصوصی روی سرویس‌گیرنده به سر می‌برد. کلید عمومی روی سرویس‌گیرنده تولید می‌شود و به سرویس‌دهنده کپی می‌شود. مطمئن شوید که این دو را با هم اشتباه نمی‌کنید.

  2. فایل authorized_keys روی سرویس‌دهنده باید دارای املای صحیح باشد.

  3. مجوزها روی هر دایرکتوری داخلِ مسیر به سمت authorized_keys با شروع از ریشه نباید قابل نوشتن برای گروه و دیگران باشد.

CategorySsh CategoryUnix

کلیدهای ssh (آخرین ویرایش ‎2012-10-15 21:05:11‎ توسط GreyCat)

  1. مترجم: در رمزنگاری، یک zero-knowledge proof یا zero-knowledge protocol عبارت است از یک روش تعامل برای یک گروه جهت اثبات به گروه دیگر که یک گزاره (معمولاً ریاضی) صحیح است، اما بدون فاش کردن هر مورد دیگری غیر از صحت آن گزاره. یک zero-knowledge proof باید سه خصوصیت را احراز نماید:
    تمامیت: اگر گزاره صحیح باشد، تصدیق‌کننده راستین (یعنی آنکه ضوابط را به طور صحیح پیروی می‌کند) به وسیله اثبات‌کننده درستکار از این امر مجاب خواهد شد.
    صحت: اگر گزاره غلط باشد، اثبات کننده متقلب نمی‌تواند تصدیق‌کننده راستین را به صحت آن متقاعد نماید، با استثنای احتمال ضعیف.
    کمترین شناسایی: اگر گزاره صحیح باشد، تصدیق‌کننده دروغین چیزی بیش از این حقیقت را نمی‌آموزد. این امر نشان دهنده آن است که هر تصدیق کننده دروغین که فقط دارای یک شبیه‌ساز گزاره‌ای است که باید اثبات شود (بدون دسترسی به اثبات کننده) فقط می‌تواند یک رونوشت تولید کند که همانند‌سازیِ یک تعامل میان اثبات‌کننده واقعی و تصدیق‌کننده متقلب است. (منبع: ویکی‌پدیا)     (بازگشت)

  2. RSA نام متداولترین الگوریتم تهیه کلید عمومی و کلید خصوصی رمزنگاری می‌باشد، که از حروف اول نام ابداع کنندگان این روش اخذ گردیده است که سه نفر به نام‌های ‎Ron Rivest , Adi Shamir , Leonard Adleman‎ می‌باشند، ایشان در سال 1977 این شیوه رمزنگاری را ابداع نمودند، امنیت RSA به دشواری یافتن عوامل مؤثر در تولید اعداد خیلی بزرگ متکی است. در حال حاضر این دشواری، امنیت لازم را تامین می‌نماید اما ممکن است در آینده هکرها بتوانند روش آسانی برای غلبه بر آن ابداع کنند! شایان ذکر است که حق امتیاز RSA متعلق به شرکت امنیتی با همین نام بود که در سپتامبر سال 2000 منقضی گردیده است.
    روش DSA نیز که سرنام Digital Signature Algorithm است، یک استاندارد ‎U.S. federal‎ است که در سال 1991 توسط موسسه ملی تکنولوژی و استانداردها در امریکا تهیه گردیده است. (بازگشت)

  3. مترجم: گزینه ‎-v‎ برای وضعیت verbose (درازنویس) است. این گزینه باعث می‌گردد ssh پیغام‌های اشکال‌یابی در باره جریان پیشروی‌اش را چاپ نماید که برای اشکالزدایی اتصال و تصدیق اعتبار و مشکل پیکربندی سودمند است. به کاربردن چندگانه این گزینه درازنویسی را افزایش می‌دهد و حداکثر تعداد آن ۳ عدد است. شاید نویسنده برای تاکید بر هیچ مقدار در اینجا vvvv ‏(۴ عدد) به کار برده است. (بازگشت)

  4. مترجم: اصطلاحی است با مفهوم آنکه خیلی طولانی است شاید به طور سطحی خوانده‌ای . (4)