Talk:SSH keys

From ArchWiki

pam_tally

With two factor authentication (crypto keys **and** password). I achieve that pam_tally increments by 2 the user errors every time I login. So surely there is an error in the suggested configuration--Xan (talk) 12:00, 30 June 2015 (UTC)Reply[reply]

SSH public key passphrase

I think that we should add `ssh -p -k ~/.ssh/id_ed25519.pub` to page, I saw a nice example from https://blog.0xbadc0de.be/archives/300. Pickfire (talk) 10:09, 13 April 2016 (UTC)Reply[reply]

Starting ssh-agent as a wrapper

In this section, there is a note which says that you "can" add eval$(ssh-agent) to your .xinitrc.

When using ssh-agent as a wrapper to startx, I have noticed that if I have both -- the alias as well as the eval statement in .xinitrc, it spawns 2 ssh-agent processes. I believe this is a leftover note from earlier when we didn't have the section titled "ssh-agent".

Can someone confirm and I will remove that note from the "ssh-agent as a wrapper section", because the way it stands today seems to indicate that you need to do both -- the alias to startx as well as add the eval statement to xinitrc in order for it to work when that is not the case.

Inxsible (talk) 00:46, 4 January 2017 (UTC)Reply[reply]

I'm pretty sure the note was intended like this. -- Lahwaacz (talk) 20:12, 4 January 2017 (UTC)Reply[reply]

Cleaner systemd-based ssh-agent setup

~/.config/environment.d/ssh-agent.conf
SSH_AUTH_SOCK="${XDG_RUNTIME_DIR}/ssh-agent.socket"
~/.config/systemd/user/ssh-agent.service
[Service]
ExecStart=/usr/bin/ssh-agent -D -a "${SSH_AUTH_SOCK}"

[Install]
WantedBy=default.target
~/.zshrc or ~/.bash_profile or ~/.profile or the equivalent
eval $(systemctl --user show-environment | grep SSH_AUTH_SOCK)
export SSH_AUTH_SOCK

Touching three files, instead of two, but the path is defined only in one place. Something similar could be achieved with EnvironmentFile. Thoughts?

Jeremejevs (talk) 17:22, 23 November 2017 (UTC)Reply[reply]

It's arguably not cleaner because you need eval, systemctl and grep to extract the path for the shell. -- Lahwaacz (talk) 18:29, 23 November 2017 (UTC)Reply[reply]

SSH Keys generated without -o flag are not safe

SSH Keys with default parameters are not safe [1], Hacker News discussion[2]. The wiki already suggests that we use -o for increased brute force protection, the suggested command for generating keys should include this. Would there be any compatibility issues with any mainstream system by always generating keys with this flag?

Orekix (talk) 02:47, 4 August 2018 (UTC)Reply[reply]

Good call. I'm rearranging the section. It was much too detailed on the technical aspects. All we really want to know is which key type to use and why. There could be compatibility issues with older (pre 2014) implementations of OpenSSH. Hopefully no server you're running has an OS older than 2014. -- Rdeckard (talk) 14:07, 4 August 2018 (UTC)Reply[reply]
Unfortunately, this flag " -o" is not documented in ssh-keygen's manual page (man or info). If its usage is recommended in the wiki, I think we would need some more links, references, etc., about what it does, why it's not in the manual while being implemented and how you're supposed to find out its existence. Tétrapyle (talk) 09:22, 30 October 2018 (UTC)Reply[reply]
Update. Thanks to information kindly reported by user /dev/zero, this flag is documented in BSD's ssh-keygen manpage. The Gnu/Linux manpage is probably outdated. Tétrapyle (talk)
As far as I know, OpenSSH 7.8 and above set the OpenSSH format for private keys by default: "ssh-keygen(1): write OpenSSH format private keys by default instead of using OpenSSL's PEM format. The OpenSSH format, supported in OpenSSH releases since 2014 and described in the PROTOCOL.key file in the source distribution, offers substantially better protection against offline password guessing and supports key comments in private keys. If necessary, it is possible to write old PEM-style keys by adding '-m PEM' to ssh-keygen's arguments when generating or updating a key." So, there is no need to set the "-o" flag anymore if you use OpenSSH > 7.7. --Ish (talk) 05:39, 8 January 2019 (UTC)Reply[reply]

Intro draft

Comment: Draft to make the intro and Background section account for the server perspective. Section levels are only adjusted for the talk page. Copy editing may be done directly, comments should be added in the Comments subsection. --Larivact (talk) 05:58, 2 January 2019 (UTC)Reply[reply]

SSH uses public-key cryptography to authenticate servers, optionally it can also be used to authenticate clients.

This article assumes you already have a basic understanding of the Secure Shell protocol and have installed OpenSSH.

Key-based client authentication

SSH keys can serve as a means of identifying yourself to an SSH server using challenge-response authentication. The major advantage of key-based authentication is that in contrast to password authentication it is not prone to brute-force attacks and you do not expose valid credentials, if the server has been compromised.[3]

Furthermore SSH key authentication can be more convenient than the more traditional password authentication. When used with a program known as an SSH agent, SSH keys can allow you to connect to a server, or multiple servers, without having to remember or enter your password for each system.

Key-based authentication is not without its drawbacks and may not be appropriate for all environments, but in many circumstances it can offer some strong advantages. A general understanding of how SSH keys work will help you decide how and when to use them to meet your needs.

Background

If an SSH server has your public key on file and sees you requesting a connection, it uses your public key to construct and send you a challenge. This challenge is an encrypted message and it must be met with the appropriate response before the server will grant you access. What makes this coded message particularly secure is that it can only be understood by the private key holder. While the public key can be used to encrypt the message, it cannot be used to decrypt that very same message. Only you, the holder of the private key, will be able to correctly understand the challenge and produce the proper response.

This challenge-response phase happens behind the scenes and is invisible to the user. As long as you hold the private key, which is typically stored in the ~/.ssh/ directory, your SSH client should be able to reply with the appropriate response to the server.

A private key is a guarded secret and as such it is advisable to store it on disk in an encrypted form. When the encrypted private key is required, a passphrase must first be entered in order to decrypt it. While this might superficially appear as though you are providing a login password to the SSH server, the passphrase is only used to decrypt the private key on the local system. The passphrase is not transmitted over the network.

Comments

So there is a new section title, the "public-key cryptography" was moved into a different sentence and the first paragraph of the current Background section is gone:

SSH keys are always generated in pairs with one known as the private key and the other as the public key. The private key is known only to you and it should be safely guarded. By contrast, the public key can be shared freely with any SSH server to which you wish to connect.

-- Lahwaacz (talk) 21:04, 10 February 2019 (UTC)Reply[reply]

SSH Agent File Naming

The current suggested ssh-agent file name is "~/.ssh-agent-thing". I think "~/.ssh-agent.rc" would be more apt, as it bears a certain resemblance to other RC files. Moreover, this will leave the file in the user's home directory as it's never cleaned up. This could be mitigated by writing it to "/tmp/ssh-agent.rc", although I'm not sure what side effects this could have (e.g. on a multi-user system), hence proposing it here before changing the sample script on the page.

CodingKoopa (talk) 18:07, 14 August 2019 (UTC)Reply[reply]

"It's never cleaned up" isn't a major problem as the script will start a new agent on every boot anyway. But you could put the file at $XDG_RUNTIME_DIR/ssh-agent.env to get auto-cleanup and avoid multi-user issues.
...Or you could just tell ssh-agent to put the socket itself at a fixed location such as $XDG_RUNTIME_DIR/ssh-agent.sock, avoiding the extra indirection. That's how the systemd --user example works.
grawity (talk) 19:37, 14 August 2019 (UTC)Reply[reply]
I wasn't able to get it working by using -a to set the socket location and then evaluate that (I got /run/user/1000/ssh-agent.sock: No such device or address, so I assume that the socket can't be used in the way that I thought it could?). Regardless, XDG_RUNTIME_DIR is exactly what I was looking for. Cheers.
CodingKoopa (talk) 20:25, 14 August 2019 (UTC)Reply[reply]

Is there a reason why we don't suggest using the default socket $TMPDIR/ssh-XXXXXXXXXX/agent.<ppid> mentioned in the ssh-agent manpage? That way there is no need for most of this configuration. JoeCool (talk)

ssh-agent invocation in .bashrc?

In the section for ssh-agent it's recommended: "add the following to your ~/.bashrc". I suggest changing that to .bash_profile, because of the following error.

Programs like scp or rsync use ssh, and that calls .bashrc. The command "eval `ssh-agent`" outputs agent pid, which makes these programs fail.

Since .bash_profile is for a login shell, it won't cause this problem (it doesn't).

Ynikitenko (talk) 11:54, 26 February 2020 (UTC)Reply[reply]

.bashrc is sourced only for interactive shells, scp and rsync don't invoke an interactive shell on the remote host. -- Lahwaacz (talk) 12:55, 26 May 2020 (UTC)Reply[reply]

ssh-agent systemd

I tried setting

  SSH_AUTH_SOCK DEFAULT="${XDG_RUNTIME_DIR}/ssh-agent.socket"

in ~/.zshrc but it didn't work. Supplied the solution of:


In the file

   ~/.pam_environment

put

   SSH_AUTH_SOCK DEFAULT="${XDG_RUNTIME_DIR}/ssh-agent.socket"

which works, so I think this is the better solution.

—This unsigned comment is by Fenton.travers (talk) 18:23, 16 April 2021 (UTC). Please sign your posts with ~~~~!Reply[reply]

You are not supposed to put the DEFAULT after the first space in the variable for your shell. This is the syntax for ~/.pam_environment.
-- NetSysFire (talk) 18:33, 16 April 2021 (UTC)Reply[reply]


certificates

There's no mention of certificates. Did I fail at searching? Or should we add it here?

Gcb (talk) 01:18, 18 August 2021 (UTC)Reply[reply]

This page covers the public key authentication, not certificate authentication. Feel free to draft a new page about SSH certificates in your user page. — Lahwaacz (talk) 05:52, 19 August 2021 (UTC)Reply[reply]

AddKeysToAgent Option

The option to automatically add keys to the agent on first use is already mentioned in a tip at the ssh-agent section, however I would argue that its better to have this mentioned in the subsection for better visibility. When I tried to find a way to implement what this option does, I did not find this option in the wiki despite reading most of it. The subsection should make it easier to find. It may also be a good idea to mention this option in the chapters for external helper applications such as keychain, since many use cases for these programs are covered by OpenSSH natively after the new option was introduced. — Valoq (talk) 14:46, 16 October 2022 (UTC)Reply[reply]

The tip is more accurate, shows all the options instead of just "yes", and I think the formatting in a green box stands out sufficiently. There will always be somebody who will not find even the section. — Lahwaacz (talk) 15:21, 16 October 2022 (UTC)Reply[reply]

ssh-keygen now defaults to Ed25519 instead of RSA

I ran ssh-keygen today, and it defaulted to a Ed25519 key instead of RSA. Is the information about defaults out of date? GTcreyon (talk) 15:48, 19 October 2023 (UTC)Reply[reply]

Yes, OpenSSH removed RSA by default since 8.2 release in 2020.
Hanabishi (talk) 15:59, 19 October 2023 (UTC)Reply[reply]