Using SSH public-key authentication to connect to a remote system is a robust, more secure alternative to logging in with an account password or passphrase. SSH public-key authentication relies on asymmetric cryptographic algorithms that generate a pair of separate keys (a key pair), one 'private' and the other 'public'. You keep the private key a secret and store it on the computer you use to connect to the remote system. Conceivably, you can share the public key with anyone without compromising the private key; you store it on the remote system in a .ssh/authorized_keys
directory.
To use SSH public-key authentication:
~/.ssh/authorized_keys
file in your account.To set up public-key authentication using SSH on a Linux or macOS computer:
Please do NOT click on ‘save public key’, as Puttygen uses a different format to OpenSSH. Thankfully, Puttygen does display the OpenSSH-compatible public key in the field labeled ‘Public key for pasting into OpenSSH’. Select all the text in this field and copy it to clipboard. Go back to the CloudSigma SSH key screen and paste this into.
To generate RSA keys, on the command line, enter:
Enter
or Return
without entering a filename.Alternatively, you can enter a filename (for example, my_ssh_key
) at the prompt, and then press Enter
or Return
. However, many remote hosts are configured to accept private keys with the default filename and path (~/.ssh/id_rsa
for RSA keys) by default. Consequently, to authenticate with a private key that has a different filename, or one that is not stored in the default location, you must explicitly invoke it either on the SSH command line or in an SSH client configuration file (~/.ssh/config
); see below for instructions.
Enter
or Return
. If you press Enter
or Return
without entering a password, your private key will be generated without password-protection.Your private key will be generated using the default filename (for example, id_rsa
) or the filename you specified (for example, my_ssh_key
), and stored on your computer in a .ssh
directory off your home directory (for example, ~/.ssh/id_rsa
or ~/.ssh/my_ssh_key
).
The corresponding public key will be generated using the same filename (but with a .pub
extension added) and stored in the same location (for example, ~/.ssh/id_rsa.pub
or ~/.ssh/my_ssh_key.pub
).
~/.ssh/id_rsa.pub
) to your account on the remote system (for example, [email protected]
); for example, using command-line SCP: Windows server 2008 r2 activation key generator. You'll be prompted for your account password. Your public key will be copied to your home directory (and saved with the same filename) on the remote system.
~/.ssh/authorized_keys
file in your account (if your account doesn't have ~/.ssh/authorized_keys
file, system administrators can create one for you). Once your public key is added to your ~/.ssh/authorized_keys
file on the remote system, the setup process is complete, and you should now be able to SSH to your account from the computer that has your private key.~/.ssh/authorized_keys
file, create one; on the command line, enter the following commands: ~/.ssh/authorized_keys
file, executing these commands will not damage the existing directory or file.~/id_rsa.pub
) to a new line in your ~/.ssh/authorized_keys
file; on the command line, enter: You may want to check the contents of ~/.ssh/authorized_keys
to make sure your public key was added properly; on the command line, enter:
~/id_rsa.pub
) from your account on the remote system; on the command line, enter:Alternatively, if you prefer to keep a copy of your public key on the remote system, move it to your .ssh
directory; on the command line, enter:
[email protected]
) from the computer (for example, host1
) that has your private key (for example, ~/.ssh/id_rsa
):If the private key you're using does not have the default name, or is not stored in the default path (not ~/.ssh/id_rsa
), you must explicitly invoke it in one of two ways:
-i
flag and the path to your private key.For example, to invoke the private key host2_key
, stored in the ~/.ssh/old_keys
directory, when connecting to your account on a remote host (for example, [email protected]
), enter:
~/.ssh/config
), if it exists/etc/ssh/ssh_config
)The SSH client configuration file is a text file containing keywords and arguments. To specify which private key should be used for connections to a particular remote host, use a text editor to create a ~/.ssh/config
that includes the Host
and IdentityFile
keywords.
For example, for connections to host2.somewhere.edu
, to make SSH automatically invoke the private key host2_key
, stored in the ~/.ssh/old_keys
directory, create a ~/.ssh/config
file with these lines included:
Once you save the file, SSH will use the specified private key for future connections to that host.
You can add multiple Host
and IdentityFile
directives to specify a different private key for each host listed; for example:
Alternatively, you can use a single asterisk ( *
) to provide global defaults for all hosts (specify one private key for several hosts); for example:
For more about the SSH client configuration file, see the OpenSSH SSH client configuration file on the web or from the command line (man ssh_config
).
The PuTTY command-line SSH client, the PuTTYgen key generation utility, the Pageant SSH authentication agent, and the PuTTY SCP and SFTP utilities are packaged together in a Windows installer available under The MIT License for free download from the PuTTY development team.
After installing PuTTY:
2048
).putty_key
), select a location on your computer to store it, and then click Save.putty_private_key
), select a location on your computer to store it, and then click Save.putty_rsa
), select a location on your computer to store it, and then click Save.If the remote system does not support password-based authentication, you will need to ask system administrators to add your public key to the ~/.ssh/authorized_keys
file in your account (if your account doesn't have ~/.ssh/authorized_keys
file, system administrators can create one for you). Once your public key is added to your account's ~/.ssh/authorized_keys
file on the remote system..
~/.ssh/authorized_keys
file, create one; on the command line, enter the following commands:If your account on the remote system already has ~/.ssh/authorized_keys
, executing these commands will not damage the existing directory or file.
~/.ssh/authorized_keys
file, and then save and close the file.putty_private_key.ppk
), select the file, and then click Open.If your private key is not passphrase-protected, Pageant will add your private key without prompting you for a passphrase.
Either way, Pageant stores the unencrypted private key in memory for use by PuTTY when you initiate an SSH session to the remote system that has your public key.
Deathstar
), and then click Save.Startup
folder to launch Pageant and load your private key automatically whenever you log into your desktop. For instructions, finish the rest of the following steps.Startup
folder. Press Win-r
, and in the 'Open' field, type shell:startup
, and then press Enter
.Startup
folder, and then select New and Shortcut.pageant.exe
) followed by the path to your private key file (for example, putty_private_key.ppk
); enclose both paths in double quotes; for example: PAGEANT
).The next time you log into your Windows desktop, Pageant will start automatically, load your private key, and (if applicable) prompt you for the passphrase.
rsa
, dsa
, rsa1
, ed25519
or ecdsa
private keys.The below requirements are needed on the host that executes this module.
Parameter | Choices/Defaults | Comments |
---|---|---|
attributes string | The attributes the resulting file or directory should have. To get supported flags look at the man page for chattr on the target system. This string should contain the attributes in the same order as the one displayed by lsattr. The = operator is assumed as default, otherwise + or - operators need to be included in the string. | |
comment added in 2.9 | Provides a new comment to the public key. When checking if the key is in the correct state this will be ignored. | |
force boolean |
| Should the key be regenerated even if it already exists |
group string | Name of the group that should own the file/directory, as would be fed to chown. | |
mode string | The permissions the resulting file or directory should have. For those used to /usr/bin/chmod remember that modes are actually octal numbers. You must either add a leading zero so that Ansible's YAML parser knows it is an octal number (like 0644 or 01777 ) or quote it (like '644' or '1777' ) so Ansible receives a string and can do its own conversion from string into number.Giving Ansible a number without following one of these rules will end up with a decimal number which will have unexpected results. As of Ansible 1.8, the mode may be specified as a symbolic mode (for example, u+rwx or u=rw,g=r,o=r ).As of Ansible 2.6, the mode may also be the special string preserve .When set to preserve the file will be given the same permissions as the source file. | |
owner string | Name of the user that should own the file/directory, as would be fed to chown. | |
path path / required | Name of the files containing the public and private key. The file containing the public key will have the extension .pub . | |
selevel string | Default: | The level part of the SELinux file context. This is the MLS/MCS attribute, sometimes known as the range .When set to _default , it will use the level portion of the policy if available. |
serole string | When set to _default , it will use the role portion of the policy if available. | |
setype string | When set to _default , it will use the type portion of the policy if available. | |
seuser string | By default it uses the system policy, where applicable.When set to _default , it will use the user portion of the policy if available. | |
size integer | Specifies the number of bits in the private key to create. For RSA keys, the minimum size is 1024 bits and the default is 4096 bits. Generally, 2048 bits is considered sufficient. DSA keys must be exactly 1024 bits as specified by FIPS 186-2. For ECDSA keys, size determines the key length by selecting from one of three elliptic curve sizes: 256, 384 or 521 bits. Attempting to use bit lengths other than these three values for ECDSA keys will cause this module to fail. Ed25519 keys have a fixed length and the size will be ignored. | |
state string |
| Whether the private and public keys should exist or not, taking action if the state is different from what is stated. |
type string |
| The algorithm used to generate the SSH private key. rsa1 is for protocol version 1. rsa1 is deprecated and may not be supported by every version of ssh-keygen. |
unsafe_writes boolean |
| Influence when to use atomic operation to prevent data corruption or inconsistent reads from the target file. By default this module uses atomic operations to prevent data corruption or inconsistent reads from the target files, but sometimes systems are configured or just broken in ways that prevent this. One example is docker mounted files, which cannot be updated atomically from inside the container and can only be written in an unsafe manner. This option allows Ansible to fall back to unsafe methods of updating files when atomic operations fail (however, it doesn't force Ansible to perform unsafe writes). IMPORTANT! Unsafe writes are subject to race conditions and can lead to data corruption. |
Common return values are documented here, the following are the fields unique to this module:
Key | Returned | Description |
---|---|---|
comment string | changed or success | Sample: |
filename | changed or success | Path to the generated SSH private key file /tmp/id_ssh_rsa |
fingerprint string | changed or success | Sample: SHA256:r4YCZxihVjedH2OlfjVGI6Y5xAYtdCwk8VxKyzVyYfM |
public_key string | changed or success | Sample: ssh-rsa AAAAB3Nza(..omitted..)veL4E3Xcw test_key |
size integer | changed or success | Sample: |
type | changed or success | Algorithm used to generate the SSH private key rsa |
Hint
If you notice any issues in this documentation, you can edit this document to improve it.