Talk:SSH keys

From ArchWiki
Jump to navigation Jump to search


there should be a note about kwallet5 not supporting PGP, for now

--- Lesto (talk) 23:50, 15 March 2015 (UTC)

Are you sure it is the case? Can you provide some source, a bug report or something? For now we have SSH keys#Store SSH keys with Kwallet linking to KDE_Wallet#Using_the_KDE_Wallet_to_store_ssh_keys which only has a vague, unsourced "May have a bug" accuracy template. Neitsab (talk) 11:21, 21 October 2015 (UTC)


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)

SSH public key passphrase

I think that we should add `ssh -p -k ~/.ssh/` to page, I saw a nice example from Pickfire (talk) 10:09, 13 April 2016 (UTC)

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)

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

Cleaner systemd-based ssh-agent setup

ExecStart=/usr/bin/ssh-agent -D -a "${SSH_AUTH_SOCK}"

~/.zshrc or ~/.bash_profile or ~/.profile or the equivalent
eval $(systemctl --user show-environment | grep 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)

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)

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)

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)
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)
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)


I think the article should be renamed to SSH key-based authentication because it is mainly about public key authentication. Naming it "SSH keys" is misleading, because with SSH there are always SSH keys involved (the ones of the server) no matter the authentication method used. The parts of the Generating an SSH key pair section that also apply to servers (ssh-keygen and Choosing the authentication key type) would then need to be merged with OpenSSH. Thoughts?

--Larivact (talk) 19:57, 22 December 2018 (UTC)

It is not "mainly about public key authentication" because SSH keys#Generating an SSH key pair is about actually generating the keys and SSH keys#SSH agents does not describe authentication either, it is about storing the local keys securely and conveniently. Your proposal to change the title does not make sense without massive reorganization to the whole page and other related pages, which I consider unnecessary and counterproductive. -- Lahwaacz (talk) 20:44, 22 December 2018 (UTC)
SSH agents are just convenience tools for public key authentication. Yes, I already pointed out that Generating an SSH key pair would need to be merged. In fact the introduction is already written as if the article were solely about key-based authentication. Rewriting it to actually explain "SSH keys" would be way more work than merging a single section. --Larivact (talk) 16:28, 23 December 2018 (UTC)
Aside from OpenSSH already being longer than this article, I disagree it's useful to merge Generating an SSH key pair over there. It is two distinct tasks to configure the methods the ssh server accepts for logins, and generating respective keys/storing them safely. Most of this article is written from client-perspective and the client/user needs to make a (somewhat) informed decisions/configurations. --Indigo (talk) 17:59, 23 December 2018 (UTC)
This is not about server configuration. My point is that key generation is the same for clients and servers and should therefore be described in OpenSSH because, as you just said, this article is about the client-side. --Larivact (talk) 19:06, 23 December 2018 (UTC)
I don't see anything which limits the scope of this page to clients, regardless what most of the content is about. The page is properly linked from both client and server sections of OpenSSH, it doesn't make sense to move the key generation to OpenSSH because the only considerable place is just after the installation section where it can be linked from both client and server sections without using forward references, but readers should not be forced to skim over involved details regarding public key cryptography just to get to the ssh command. Plus, as Indigo said, the OpenSSH page is already long enough.
You just admitted that SSH keys are different topic than "SSH key-based authentication", so why can't you accept that the topic of this page is "SSH keys" and live with it?
-- Lahwaacz (talk) 21:14, 23 December 2018 (UTC)
Well I guess what really bothered me is that the article does not live up to its scope. If the scope cannot be narrowed, the content needs to be expanded. I added a respective flag. Closing this; will open a new section for the expansion. --Larivact (talk) 20:10, 1 January 2019 (UTC)
Yes, I think that will be a much more productive approach. I look forward to your suggestions. -- Lahwaacz (talk) 22:51, 1 January 2019 (UTC)
I agree with Larivact that the article could favorably be renamed, maybe even to "SSH key-based client authentication". The point with using keys is authentication, and it doesn't make sense to have an article on just key generation and storage without mentioning what the purpose of the keys is. If the article is too focused on just generating the keys the article should be expanded, instead of keeping the old name. The part on SSH agents, while not strictly describing authentication, is part of the authentication story and it is a service to the readers to find it here. -- JMyreen 12:22, 23 December 2018 (UTC)
I sure agree it is useful to expand info about SSH Keys to the extend necessary to supplement the OpenSSH article and respective manuals. It's complex enough. --Indigo (talk) 17:59, 23 December 2018 (UTC)

Section on YubiKeys

I agree that the section on YubiKeys could possibly be moved to the YubiKey page, but the YubiKey page is getting too long already. I was not sure where to put it, and chose the SSH Keys page because it deals with exactly the issues at hand in this article, it only presents an alternative to storing the private keys on disk. The focus is primarily on SSH keys, not the YubiKey. This section can also be expanded to include other brands of cryptographic tokens. I don't understand the argument on the "proprietary nature" of the YubiKey, especially regarding the packages. Granted, the YubiKey itself is a closed piece of hardware, but the specifications on how to interact with it are totally open, and follows open standards as much as possible. Yubico's tools are all open source, and opensc (one of the two packages mentioned) is not specific to the YubiKey. Nobody is complaining that a Logitech mouse is proprietary because the code on the microcontroller is closed source. N.b. I have no affiliation with Yubico other than having bought two of their products. -- JMyreen 13:37, 23 December 2018 (UTC)

Thanks for your prompt remarks. Please don't put that much emphasis on me writing "propietary nature". It was in no way meant discrediting (yes, I agree their open-source approach and documentation is far above average). I just wanted to bring across that it is a proprietary hardware, much like a TPM (article covers similar) but less widespread in usage, and you configure it with its custom (open-sourced) tools.
For the move over, I see two main options:
  1. Create a subsection at the end of YubiKey#CCID_Smartcard (which you just expanded with information), or
  2. Create a new Yubikey#SSH section and move it under that, YubiKey#Two-factor authentication with SSH could be moved in that new section as well, making it two round SSH-related examples.
My preference would be (1.) since that indeed has the linkage to SSH keys, and no example is covered yet. (YubiKey#Challenge-Response could gain the two-factor section later, but that's nothing to discuss here)
What do you think? --Indigo (talk) 17:34, 23 December 2018 (UTC)
On your request, I have removed the section "Using a YubiKey with SSH" from this page. If time permits I may republish it on the YubiKey page (it will need editing). --JMyreen 21:00, 23 December 2018.
Oh, you misunderstood "move" as "remove" there. We move articles or sections according to Help:Procedures. I can help you with that, perform the move and do first adjustments to it. Then you can read over it and see what else you want to change. I take for granted you agree to Yubikey#CCID Smartcard above for now & I'll note here when I moved it. --Indigo (talk) 22:16, 23 December 2018 (UTC)
Done. You find the remainder at SSH_keys#Storing SSH keys on hardware tokens, linking over to the new section.
Once you had a read over it (at leisure), let me know what you think. --Indigo (talk) 23:13, 23 December 2018 (UTC)
Closing. --Indigo (talk) 10:29, 3 January 2019 (UTC)

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)

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.


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.


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)

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)

"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)
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)