SSH-COPY-ID(1) راهنمای دستورات کاربر SSH-COPY-ID(1)

ssh-copy-id - نصب کلید عمومی در کارساز مجاز

ssh-copy-id [-f] [-n] [-s] [-x] [-i [identity_file]] [-t target_path] [-F ssh_config] [-o ssh_option]... [-p port] [user@]hostname
ssh-copy-id -h | -?

ssh-copy-id اسکریپتی است که از ssh(1) برای ورود به یک ماشین راه دور (احتمالاً با استفاده از گذرواژه ورود، بنابراین احراز هویت با گذرواژه باید فعال باشد، مگر اینکه به شیوه هوشمندانه‌ای از چندین شناسه استفاده کرده باشید) استفاده می‌کند. این اسکریپت فهرستی از یک یا چند اثرانگشت (همان‌طور که در ادامه توضیح داده شده است) را گردآوری کرده و تلاش می‌کند با هر کلید وارد شود تا ببیند آیا هیچ‌یک از آن‌ها از پیش نصب شده‌اند یا خیر (البته اگر از ssh-agent(1) استفاده نمی‌کنید، این کار ممکن است منجر به این شود که مکرراً از شما عبارت عبور خواسته شود). سپس فهرستی از مواردی که ورود با آن‌ها ناموفق بوده است را گردآوری کرده و با استفاده از ssh(1)، امکان ورود با آن کلیدها را در کارساز راه دور فراهم می‌سازد. به‌طور پیش‌فرض، این اسکریپت کلیدها را با افزودن آن‌ها به فایل ~/.ssh/authorized_keys کاربر راه دور اضافه می‌کند (و در صورت نیاز، فایل و دایرکتوری را ایجاد می‌کند). این اسکریپت همچنین قادر است تشخیص دهد که آیا سیستم راه دور یک دستگاه NetScreen است یا خیر، و در این صورت به‌جای آن از دستور set ssh pka-dsa key ... استفاده کند.

گزینه‌ها به شرح زیر هستند:

تنها از کلید(های) موجود در identity_file استفاده می‌کند (به‌جای جستجوی شناسه‌ها از طریق ssh-add(1) یا در default_ID_file). اگر نام فایل به .pub ختم نشود، این پسوند به آن اضافه خواهد شد. اگر نام فایل حذف شود، از default_ID_file استفاده می‌شود.
توجه داشته باشید که با اطمینان از اینکه فایل کلید قبل از اقدام به کپی دارای توضیحات و گزینه‌های دلخواه است، می‌توان از این گزینه برای اطمینان از اینکه کلیدهای کپی‌شده دارای توضیحات مورد نظر و/یا گزینه‌های اضافی اعمال‌شده هستند استفاده کرد.
حالت اجباری: بررسی نمی‌کند که آیا کلیدها روی کارساز راه دور وجود دارند یا خیر. این بدان معناست که نیازی به کلید خصوصی ندارد. البته این کار می‌تواند منجر به نصب بیش از یک نسخه از کلید روی سیستم راه دور شود.
اجرای آزمایشی (dry-run). به‌جای نصب کلیدها روی سیستم راه دور، صرفاً کلید(هایی) را که قرار بود نصب شوند چاپ می‌کند.
حالت SFTP: معمولاً کلیدهای عمومی با اجرای دستورات در سمت راه دور نصب می‌شوند. با این گزینه، فایل ~/.ssh/authorized_keys کاربر دانلود شده، به‌طور محلی اصلاح شده و با sftp آپلود می‌شود. این گزینه در صورتی مفید است که کارساز محدودیت‌هایی برای دستوراتی که می‌توانند در سمت راه دور استفاده شوند داشته باشد.
مسیری روی سیستم مقصد که کلیدها باید به آن اضافه شوند (به‌طور پیش‌فرض .ssh/authorized_keys).
درگاهی (پورت) را مشخص می‌کند که باید برای اتصال به میزبان راه دور استفاده شود.
این گزینه‌ها دست‌نخورده (به همراه آرگومان‌هایشان) به ssh/sftp منتقل می‌شوند و به ترتیب امکان تعیین یک فایل پیکربندی جایگزین یا سایر گزینه‌ها را فراهم می‌کنند.
به‌جای مشخص کردن این موارد به عنوان گزینه‌های خط فرمان، اغلب بهتر است از تنظیمات (به‌ازای هر میزبان) در فایل پیکربندی ssh(1) یعنی ssh_config(5) استفاده شود.
این گزینه برای اشکال‌زدایی خود اسکریپت ssh-copy-id است. این گزینه فلگ -x پوسته را تنظیم می‌کند تا بتوانید دستورات در حال اجرا را مشاهده کنید.
نمایش خلاصه نحوه استفاده (Usage)

رفتار پیش‌فرض بدون گزینه -i، بررسی این است که آیا ssh-add -L خروجی تولید می‌کند یا خیر، و در صورت وجود، از آن کلیدها استفاده می‌شود. توجه داشته باشید که این امر باعث می‌شود توضیح (comment) روی کلید، همان نام فایلی باشد که هنگام بارگذاری کلید در ssh-agent(1) به ssh-add(1) داده شده بود، نه توضیحی که در آن فایل وجود داشت، که این امر کمی مایه تأسف است. در غیر این صورت، اگر ssh-add(1) هیچ کلیدی ارائه ندهد، از محتویات default_ID_file استفاده خواهد شد.

فایل default_ID_file جدیدترین فایلی است که با این الگو مطابقت دارد: ~/.ssh/id*.pub (به استثنای مواردی که با ~/.ssh/*-cert.pub مطابقت دارند). بنابراین اگر کلیدی ایجاد کردید که آن کلیدی نیست که می‌خواهید ssh-copy-id استفاده کند، کافی است دستور touch(1) را روی فایل .pub کلید مورد نظر خود اجرا کنید تا دوباره به عنوان جدیدترین فایل شناخته شود.

اگر قبلاً کلیدهایی را از یک سیستم روی میزبان‌های راه دور زیادی نصب کرده‌اید، و سپس مثلاً یک کلید جدید روی یک ماشین کلاینت جدید ایجاد کرده‌اید، پیگیری اینکه کلید جدید را روی کدام سیستم‌ها نصب کرده‌اید می‌تواند دشوار باشد. یک روش برای رسیدگی به این وضعیت این است که هم کلید جدید و هم کلید(های) قدیمی را در ssh-agent(1) خود بارگذاری کنید. ابتدا کلید جدید را بدون گزینه -c بارگذاری کنید، سپس یک یا چند کلید قدیمی را در agent بارگذاری نمایید، احتمالاً از طریق اتصال ssh به ماشین کلاینتی که آن کلید قدیمی را دارد، با استفاده از گزینه -A برای مجاز ساختن ارسال کارگزار (agent forwarding):

user@newclient$ ssh-add
user@newclient$ ssh -A old.client
user@old$ ssh-add -c
No   ... prompt for pass-phrase ...
user@old$ logoff
user@newclient$ ssh someserver

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

user@newclient$ ssh-copy-id -i someserver

دلیلی که ممکن است بخواهید در این حالت گزینه -i را مشخص کنید این است که مطمئن شوید توضیح روی کلید نصب‌شده همان توضیح موجود در فایل .pub است، نه صرفاً نام فایلی که در agent شما بارگذاری شده بود. این کار همچنین اطمینان می‌دهد که فقط شناسه مورد نظر شما نصب می‌شود، نه تمام کلیدهایی که در ssh-agent(1) خود دارید. البته، می‌توانید شناسه دیگری را مشخص کنید، یا بر اساس ترجیح خود از محتویات ssh-agent(1) استفاده کنید.

با توجه به ذکر گزینه -c در دستور ssh-add(1)، ممکن است هنگام استفاده از ارسال کارگزار (agent forwarding) جهت جلوگیری از ربوده شدن کلید خود، استفاده از این گزینه را در نظر بگیرید؛ اما بسیار بهتر است که در عوض از ProxyCommand و گزینه -W در ssh(1) استفاده کنید تا با جهش از کارسازهای واسط راه دور، همواره احراز هویت مستقیم مبدا به مقصد (end-to-end) انجام شود. به این ترتیب، گام(های) میانی به ssh-agent(1) شما دسترسی نخواهند داشت. یک جستجوی وب برای ssh proxycommand nc می‌تواند روشنگر باشد (توجه: رویکرد مدرن استفاده از گزینه -W به‌جای nc(1) است).

ssh(1), ssh-agent(1), sshd(8)

Philip Hands <phil@hands.com>
17 June 2010 OpenSSH