ssh-copy-idInstall your public key on a server
ssh-copy-id logs in to a server once (usually with a password) and appends your public key to ~/.ssh/authorized_keys with the right permissions, skipping keys that are already there. After that, you log in with the key instead of a password.
ssh-copy-id [-i [IDENTITY.pub]] [-p PORT] [-o SSH_OPTION] [-f] [-n] [USER@]HOSTYou have password access to a new VM and want to switch to key-based login.
ssh-copy-idA small shell script shipped with the OpenSSH client that uses ssh to install keys.
ssh-copy-id is a shell script around ssh. First it tries to log in using the new key itself (with password prompts disabled) to find out which of the keys are already accepted, and drops those. Then it opens one normal ssh session, where you authenticate however you can today (password, or an existing key passed with -o IdentityFile), and runs a small remote shell snippet: create ~/.ssh with mode 700 if missing, append the keys to ~/.ssh/authorized_keys, set the file to 600, and restore the SELinux context with restorecon if available. It never touches the private key. Permissions matter because sshd's StrictModes (on by default) ignores authorized_keys if the home directory, ~/.ssh or the file is writable by group or others. On cloud images password login is usually disabled, so ssh-copy-id needs another way in first, and many teams manage keys with cloud-init, configuration management or SSM instead.
ssh-copy-id uses one password login to append your public key; afterwards the server verifies a signature made with your private key.
ssh-copy-id picks the key to install: -i FILE, keys in ssh-agent, or your newest ~/.ssh/id_*.pub. Only the public half is ever read.
-i FILEPublic key file to install (.pub is added if you give the private key name)-p PORTConnect to a non-standard SSH port-o OPTIONPass an ssh option, e.g. -o 'IdentityFile ~/.ssh/old.pem' to log in-nDry run: show which keys would be installed, change nothing-fForce: install without checking whether the key is already there-sUse SFTP to upload the key (for servers without a normal shell)-t PATHInstall into a different file than ~/.ssh/authorized_keysssh-copy-id -i ~/.ssh/id_ed25519 thinking you must point at the private keyIt works (it adds .pub itself), but people then try copying the private key by hand elsewhere. Only the .pub ever goes to a server.
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@hostLeaving PasswordAuthentication yes after everyone has keysThe server stays open to password brute-forcing for no reason.
Set PasswordAuthentication no in /etc/ssh/sshd_config.d/ and reload ssh, after testing key login in a second sessionFixing 'still asks for password' by chmod 777 on ~/.sshStrictModes makes sshd ignore keys in group- or world-writable locations; looser permissions make it worse.
chmod 755 ~ (or 750), chmod 700 ~/.ssh, chmod 600 ~/.ssh/authorized_keys, owned by the userTry these on a Linux machine of your own. Each task has a hint and a solution.
Write the single command that would install ~/.ssh/lab_key.pub for user deploy on 10.0.1.30 port 2222, as a dry run. (The sandbox has no remote server, so just compose it.)
Do by hand what ssh-copy-id does, for your own account on this machine: install ~/.ssh/lab_key.pub into ~/.ssh/authorized_keys with the correct permissions.
Check that your home directory, ~/.ssh and authorized_keys would pass sshd's StrictModes.
ssh-copy-idInstall your public key on a server
ssh-copy-id logs in to a server once (usually with a password) and appends your public key to ~/.ssh/authorized_keys with the right permissions, skipping keys that are already there. After that, you log in with the key instead of a password.
ssh-copy-id [-i [IDENTITY.pub]] [-p PORT] [-o SSH_OPTION] [-f] [-n] [USER@]HOSTYou have password access to a new VM and want to switch to key-based login.
ssh-copy-idA small shell script shipped with the OpenSSH client that uses ssh to install keys.
ssh-copy-id is a shell script around ssh. First it tries to log in using the new key itself (with password prompts disabled) to find out which of the keys are already accepted, and drops those. Then it opens one normal ssh session, where you authenticate however you can today (password, or an existing key passed with -o IdentityFile), and runs a small remote shell snippet: create ~/.ssh with mode 700 if missing, append the keys to ~/.ssh/authorized_keys, set the file to 600, and restore the SELinux context with restorecon if available. It never touches the private key. Permissions matter because sshd's StrictModes (on by default) ignores authorized_keys if the home directory, ~/.ssh or the file is writable by group or others. On cloud images password login is usually disabled, so ssh-copy-id needs another way in first, and many teams manage keys with cloud-init, configuration management or SSM instead.
ssh-copy-id uses one password login to append your public key; afterwards the server verifies a signature made with your private key.
ssh-copy-id picks the key to install: -i FILE, keys in ssh-agent, or your newest ~/.ssh/id_*.pub. Only the public half is ever read.
-i FILEPublic key file to install (.pub is added if you give the private key name)-p PORTConnect to a non-standard SSH port-o OPTIONPass an ssh option, e.g. -o 'IdentityFile ~/.ssh/old.pem' to log in-nDry run: show which keys would be installed, change nothing-fForce: install without checking whether the key is already there-sUse SFTP to upload the key (for servers without a normal shell)-t PATHInstall into a different file than ~/.ssh/authorized_keysssh-copy-id -i ~/.ssh/id_ed25519 thinking you must point at the private keyIt works (it adds .pub itself), but people then try copying the private key by hand elsewhere. Only the .pub ever goes to a server.
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@hostLeaving PasswordAuthentication yes after everyone has keysThe server stays open to password brute-forcing for no reason.
Set PasswordAuthentication no in /etc/ssh/sshd_config.d/ and reload ssh, after testing key login in a second sessionFixing 'still asks for password' by chmod 777 on ~/.sshStrictModes makes sshd ignore keys in group- or world-writable locations; looser permissions make it worse.
chmod 755 ~ (or 750), chmod 700 ~/.ssh, chmod 600 ~/.ssh/authorized_keys, owned by the userTry these on a Linux machine of your own. Each task has a hint and a solution.
Write the single command that would install ~/.ssh/lab_key.pub for user deploy on 10.0.1.30 port 2222, as a dry run. (The sandbox has no remote server, so just compose it.)
Do by hand what ssh-copy-id does, for your own account on this machine: install ~/.ssh/lab_key.pub into ~/.ssh/authorized_keys with the correct permissions.
Check that your home directory, ~/.ssh and authorized_keys would pass sshd's StrictModes.