$ ssh-keygen -t rsa -b 4096 -f ~/.ssh/vps-cloud.web-server.key -C 'My web-server key'
ssh-add -L
ssh-add -D
kill $SSH_AGENT_PID
trap 'kill $SSH_AGENT_PID' 0
$ sudo vim /etc/ssh/sshd_config
$ sudo vim +/PermitRootLogin /etc/ssh/sshd_config
# adduser vivek
ssh-keygen -p
~/.ssh/
directory, your SSH client should be able to reply with the appropriate response to the server.ssh-keygen
command, defaulting to 3072-bit RSA (and SHA256) which the ssh-keygen(1) man page says is 'generally considered sufficient' and should be compatible with virtually all clients and servers:-a
switch to specify the number of KDF rounds on the password encryption.-C
switch, to more easily identify it in places such as ~/.ssh/known_hosts
, ~/.ssh/authorized_keys
and ssh-add -L
output. For example:ssh-keygen
defaults to RSA therefore there is no need to specify it with the -t
option. It provides the best compatibility of all algorithms but requires the key size to be larger to provide sufficient security.-b
option with a higher bit value than the default:ssh-keygen
command, you will be prompted for the desired name and location of your private key. By default, keys are stored in the ~/.ssh/
directory and named according to the type of encryption used. You are advised to accept the default name and location in order for later code examples in this article to work properly.ssh-keygen
command to change the passphrase without changing the actual key. This can also be used to change the password encoding format to the new standard.IdentityFile
directive in your openSSH config file:.pub
extension. Note that the private key is not shared and remains on the local machine.sh
shell such as tcsh
as default and uses OpenSSH older than 6.6.1p1. See this bug report.~/.ssh/id_rsa.pub
you can simply enter the following command.@
to the server name.~/.ssh/id_rsa.pub
you will get an error stating /usr/bin/ssh-copy-id: ERROR: No identities found
. In this case, you must explicitly provide the location of the public key.~/.ssh/authorized_keys
. Begin by copying the public key to the remote server.id_ecdsa.pub
) to your home directory on the remote server via scp
. Do not forget to include the :
at the end of the server address. Also note that the name of your public key may differ from the example given.~/.ssh
directory if it does not yet exist and append your public key to the authorized_keys
file.authorized_keys
file such that it is only readable and writable by you, the owner.ssh
or scp
will need the passphrase in order to decrypt your private key before authentication can proceed.ssh-agent
is the default agent included with OpenSSH. It can be used directly or serve as the back-end to a few of the front-end solutions mentioned later in this section. When ssh-agent
is run, it forks to background and prints necessary environment variables. E.g.eval
command.ssh-agent
is running, you will need to add your private key to its cache:ssh-add
will prompt you to enter your passphrase. Once your private key has been successfully added to the agent you will be able to make SSH connections without having to enter your passphrase.ssh
clients, including git
store keys in the agent on first use, add the configuration setting AddKeysToAgent yes
to ~/.ssh/config
. Other possible values are confirm
, ask
and no
(default).ssh-agent
process runs at a time, add the following to your ~/.bashrc
:ssh-agent
process if there is not one already, and save the output thereof. If there is one running already, we retrieve the cached ssh-agent
output and evaluate it which will set the necessary environment variables.ssh-agent
and alternative agents described later in this section which avoid this problem.SSH_AUTH_SOCK DEFAULT='${XDG_RUNTIME_DIR}/ssh-agent.socket'
to ~/.pam_environment
. Then enable or start the service with the --user
flag.startx
command, you can instead prefix it with ssh-agent
like so:.bash_aliases
file or equivalent:ssh-agent
instances floating around between login sessions. Exactly one instance will live and die with the entire X session.ssh-agent startx
, you can add eval $(ssh-agent)
to ~/.xinitrc
.-Q, --quick
option has the unexpected side-effect of making keychain switch to a newly-spawned ssh-agent upon relogin (at least on systems using GNOME), forcing you to re-add all the previously registered keys.~/.bashrc
is used instead of the upstream suggested ~/.bash_profile
because on Arch it is sourced by both login and non-login shells, making it suitable for textual and graphical environments alike. See Bash#Invocation for more information on the difference between those.--eval
switch outputs lines to be evaluated by the opening eval
command; this sets the necessary environments variables for SSH client to be able to find your agent.--quiet
will limit output to warnings, errors, and user prompts.~/.ssh/
directory, but absolute path can be used for keys in non-standard location. You may also use the --confhost
option to inform keychain to look in ~/.ssh/config
for IdentityFile
settings defined for particular hosts, and use these paths to locate keys.keychain --help
or keychain(1) for details on setting keychain for other shells.$SSH_ASKPASS
or on the terminal..pub
extension. If the private key is a symlink, the public key can be found alongside the symlink or in the same directory as the symlink target (this capability requires the readlink
command to be available on the system).--nogui
option. This allows to copy-paste long passphrases from a password manager for example.--noask
option.--agents
option, e.g.--agents ssh,gpg
. See keychain(1).~/.xinitrc
file to include the following lines, replacing the name and location of your private key if necessary. Be sure to place these commands before the line which invokes your window manager.$HOSTNAME-sh
and $HOSTNAME-sh-gpg
, if they exist. These files store the environment variables of the previous instance of keychain.DISPLAY
variable defined, you also need SSH_ASKPASS
set to the name of your askpass program (in this case x11-ssh-askpass). It bears keeping in mind that the default Arch Linux installation places the x11-ssh-askpass binary in /usr/lib/ssh/
, which will not be in most people's PATH
. This is a little annoying, not only when declaring the SSH_ASKPASS
variable, but also when theming. You have to specify the full path everywhere. Both inconveniences can be solved simultaneously by symlinking:~/bin
is in your PATH
. So now in your .xinitrc
, before calling your window manager, one just needs to export the SSH_ASKPASS
environment variable:ssh-agent startx
and then add ssh-add to your window manager's list of start-up programs.~/.ssh/login-keys.d/
.~/.ssh/login-keys.d/
. Replace the id_rsa
in the example below with the name of your own private key file./etc/pam.d/login
configuration file to include the text highlighted in bold in the example below. The order in which these lines appear is significiant and can affect login behavior.auth
authentication rule added to the end of the authentication stack then instructs the pam_ssh module to try to decrypt any private keys found in the ~/.ssh/login-keys.d
directory. The try_first_pass
option is passed to the pam_ssh module, instructing it to first try to decrypt any SSH private keys using the previously entered user password. If the user's private key passphrase and user password are the same, this should succeed and the user will not be prompted to enter the same password twice. In the case where the user's private key passphrase user password differ, the pam_ssh module will prompt the user to enter the SSH passphrase after the user password has been entered. The optional
control value ensures that users without an SSH private key are still able to log in. In this way, the use of pam_ssh will be transparent to users without an SSH private key./etc/pam.d/
directory./etc/pam.d/system-auth
tossh-agent
process spawned by pam_ssh does not persist between user logins. If you like to keep a GNU Screen session active between logins you may notice when reattaching to your screen session that it can no longer communicate with ssh-agent. This is because the GNU Screen environment and those of its children will still reference the instance of ssh-agent which existed when GNU Screen was invoked but was subsequently killed in a previous logout. The Keychain front-end avoids this problem by keeping the ssh-agent process alive between logins.KeePass -> Tools -> Options -> KeeAgent -> Agent mode socket file -> %XDG_RUNTIME_DIR%/keeagent.socket
-and environment variable:export SSH_AUTH_SOCK='$XDG_RUNTIME_DIR'/keeagent.socket'
.StrictModes
to no
in /etc/ssh/sshd_config
. If authentication with StrictModes off
is successful, it is likely an issue with file permissions persists.~/.ssh/authorized_keys
are entered correctly and only use one single line.