Difference between revisions of "Talk:SSH keys"

From ArchWiki
Jump to navigation Jump to search
(re)
 
(42 intermediate revisions by 12 users not shown)
Line 1: Line 1:
==<s> GnuPG Agent </s>==
 
 
This section (apparently a candidate for merging with GnuPG#gpg-agent) is out of date since GnuPG 2.1 and no longer works as instructed due to the deprecation of GPG_AGENT_INFO. See https://wiki.archlinux.org/index.php/GnuPG#GPG_AGENT_INFO
 
{{unsigned|24 February 2015 08:55|Logankoester}}
 
 
:The section was eventually merged.[https://wiki.archlinux.org/index.php?title=SSH_keys&diff=421921&oldid=421918] — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 17:08, 28 January 2017 (UTC)
 
 
 
== kwallet5 ==
 
== kwallet5 ==
  
Line 17: Line 10:
  
 
With two factor authentication ([https://wiki.archlinux.org/index.php/SSH_keys#Two-factor_authentication_and_public_keys 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--[[User:Xan|Xan]] ([[User talk:Xan|talk]]) 12:00, 30 June 2015 (UTC)
 
With two factor authentication ([https://wiki.archlinux.org/index.php/SSH_keys#Two-factor_authentication_and_public_keys 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--[[User:Xan|Xan]] ([[User talk:Xan|talk]]) 12:00, 30 June 2015 (UTC)
 
== PuTTY elliptic curve support ==
 
 
The development snapshots for the PuTTY SSH suite [http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html] now support elliptic curve SSH keys, including ECSDA and ED25519. It may be a good idea to update the note in [[SSH_keys#ECDSA]] to mention that this is now an option.
 
[[User:Jwegner|Jwegner]] ([[User talk:Jwegner|talk]]) 04:48, 6 January 2016 (UTC)
 
  
 
== SSH public key passphrase ==
 
== SSH public key passphrase ==
Line 39: Line 27:
 
:I'm pretty sure the note was intended [https://wiki.archlinux.org/index.php?title=SSH_keys&diff=461444&oldid=460060 like this]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:12, 4 January 2017 (UTC)
 
:I'm pretty sure the note was intended [https://wiki.archlinux.org/index.php?title=SSH_keys&diff=461444&oldid=460060 like this]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:12, 4 January 2017 (UTC)
  
== <s> /etc/ssh/sshd_config -- quick help for  '''ssh-copy-id'''</s> ==
+
== Cleaner systemd-based ssh-agent setup ==
 +
 
 +
{{hc|~/.config/environment.d/ssh-agent.conf|<nowiki>
 +
SSH_AUTH_SOCK="${XDG_RUNTIME_DIR}/ssh-agent.socket"
 +
</nowiki>}}
 +
 
 +
{{hc|~/.config/systemd/user/ssh-agent.service|<nowiki>
 +
[Service]
 +
ExecStart=/usr/bin/ssh-agent -D -a "${SSH_AUTH_SOCK}"
 +
 
 +
[Install]
 +
WantedBy=default.target
 +
</nowiki>}}
 +
 
 +
{{hc|~/.zshrc or ~/.bash_profile or ~/.profile or the equivalent|<nowiki>
 +
eval $(systemctl --user show-environment | grep SSH_AUTH_SOCK)
 +
export SSH_AUTH_SOCK
 +
</nowiki>}}
 +
 
 +
Touching three files, instead of two, but the path is defined only in one place. Something similar could be achieved with {{ic|EnvironmentFile}}. Thoughts?
 +
 
 +
[[User:Jeremejevs|Jeremejevs]] ([[User talk: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. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk: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 [https://latacora.singles/2018/08/03/the-default-openssh.html], Hacker News discussion[https://news.ycombinator.com/item?id=17682946]. 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?
 +
 
 +
[[User:Orekix|Orekix]] ([[User talk: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. -- [[User:Rdeckard|Rdeckard]] ([[User_talk: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. [[User:Tétrapyle|Tétrapyle]] ([[User talk:Tétrapyle|talk]]) 09:22, 30 October 2018 (UTC)
 +
 
 +
:: ''Update''. Thanks to information kindly [https://bbs.archlinux.org/viewtopic.php?pid=1814785#p1814785 reported] by user /dev/zero, this flag is documented in [https://www.freebsd.org/cgi/man.cgi?query=ssh-keygen&sektion=1&manpath=OpenBSD BSD's ssh-keygen manpage]. The Gnu/Linux manpage is probably outdated. [[User:Tétrapyle|Tétrapyle]] ([[User talk: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. --[[User:Ish|Ish]] ([[User talk:Ish|talk]]) 05:39, 8 January 2019 (UTC)
 +
 
 +
== <s>Title</s> ==
 +
 
 +
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?
 +
 
 +
--[[User:Larivact|Larivact]] ([[User talk: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. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk: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. --[[User:Larivact|Larivact]] ([[User talk: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. --[[User:Indigo|Indigo]] ([[User talk: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. --[[User:Larivact|Larivact]] ([[User talk: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 [https://wiki.archlinux.org/index.php?title=SSH_keys&diff=560130&oldid=560129 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?
 +
:::::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk: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 [[Special:Diff/561320|added a respective flag]]. Closing this; will open a new section for the expansion. --[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 20:10, 1 January 2019 (UTC)
  
Many people find this article via google because '''ssh-copy-id''' did not work for them. Like [https://debian-administration.org/article/530/SSH_with_authentication_key_instead_of_password  this] is only ''mildly'' helpful.
+
:::::::Yes, I think that will be a much more productive approach. I look forward to your suggestions. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk: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. -- [[User:JMyreen|JMyreen]] 12:22, 23 December 2018 (UTC)
  
Many of the above '''expect to find straight, succint info''', which is given right here:
+
::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. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 17:59, 23 December 2018 (UTC)
  
 +
== <s>Section on YubiKeys</s> ==
  
1. You do not want to enter a strong password to '''ssh''' into your remote webserver, so you use keyfiles ('''/home/YOU/.ssh/id_rsa.pub''') instead.
+
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. -- [[User:JMyreen|JMyreen]] 13:37, 23 December 2018 (UTC)
  
2. You ran '''ssh-keygen''' OK.
+
: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:
 +
:# Create a subsection at the end of [[YubiKey#CCID_Smartcard]] (which you just expanded with information), or
 +
:# 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? --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 17:34, 23 December 2018 (UTC)
  
3. Then you ran '''ssh-copy-id''' with error and '''ssh''' with error as well. So you cannot (immediately) '''ssh''' into your webserver anymore. :-(
+
: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). --[[User:JMyreen|JMyreen]] 21:00, 23 December 2018.
  
4. Even on (Jessie) debian to debian systems, '''ssh-copy-id''' often breaks. (see google for proof)
+
::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. --[[User:Indigo|Indigo]] ([[User talk: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. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 23:13, 23 December 2018 (UTC)
 +
::Closing. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 10:29, 3 January 2019 (UTC)
  
5. '''ssh-copy-id''' performs ''a very simple task'' which is easy to do manually ''instead'' using '''fish''' and midnight commander ('''mc'''): you need to copy or append your local file '''/home/YOU/.ssh/id_rsa.pub''' to the remote file '''/root/.ssh/authorized_keys''' . It can be done with '''cp ./key1 ./authorized_keys''' as remote root in '''/root/.ssh/''' or in case of multiple keys '''cat ./newkey >> ./authorized_keys'''
+
== Intro draft ==
  
6. also run  '''chmod 700 ~/.ssh'''  and     '''chmod 600 ~/.ssh/authorized_keys'''  in the remote root shell.
+
{{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. --[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 05:58, 2 January 2019 (UTC)}}
 
7. But this will only work if the remote '''sshd''' is set up properly to begin with. Your local '''ssh''' talks to the remote '''sshd'''. Use '''ssh -vvv''' to bughunt. Verify that the remote server '''/etc/ssh/sshd_config''' allows password-less '''ssh''' by switching from '''no''' to '''yes''' etc. e.g.:
 
  
 +
[[SSH]] uses [[Wikipedia:Public-key cryptography|public-key cryptography]] to authenticate servers, optionally it can also be used to authenticate clients.
  
RSAAuthentication yes  # applies to protocol version 1 only
+
This article assumes you already have a basic understanding of the [[Secure Shell]] protocol and have [[install]]ed [[OpenSSH]].
  
RhostsRSAAuthentication yes
+
=== Key-based client authentication ===
  
PubkeyAuthentication '''yes'''  # this one being germaine
+
SSH keys can serve as a means of identifying yourself to an SSH server using [[Wikipedia:Challenge-response authentication|challenge-response authentication]]. The major advantage of key-based authentication is that in contrast to password authentication it is not prone to [[Wikipedia:Brute-force attack|brute-force attacks]] and you do not expose valid credentials, if the server has been compromised.[https://tools.ietf.org/html/rfc4251#section-9.4.4]
  
<nowiki># For</nowiki> this to work you will also need host keys in /etc/ssh_known_hosts
+
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.
  
<nowiki>#AuthorizedKeysFile</nowiki> %h/.ssh/authorized_keys
+
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.  
  
AuthorizedKeysFile '''/root/.ssh/authorized_keys'''
+
==== Background ====
  
 +
If an SSH server has your [[Wikipedia:Public key|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 [[Wikipedia:Challenge-response authentication|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 {{ic|~/.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.
  
8. That's it. '''reboot''' or '''sshd''' restart usually is not necessary. You now can log in without a password. So you might disable passwords on the remote webserver now to mitigate remote passwords attacks. But passwords are still helpful if you lose the keyfile or do not have it at hand on a different local machine. In any case you can force the use of passwords, e.g. for testing with
+
=== 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 -o "PasswordAuthentication yes " -o " PubkeyAuthentication no  "    root@1.2.3.4 '''
+
: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.
  
 +
-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 21:04, 10 February 2019 (UTC)
  
 +
== SSH Agent File Naming ==
  
--[[User:UBF6|UBF6]] ([[User talk:UBF6|talk]]) 11:28, 10 February 2017 (UTC)
+
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.
  
:This page deals with SSH keys in general, not only ssh-copy-id. The topic in question is described in the [[SSH_keys#Copying_the_public_key_to_the_remote_server|third section]] and troubleshooting naturally belongs to the end. Satisfying some specific search results or users of other Linux distributions is not the primary concern here and definitely not a sole reason to move something to the start of the page. As for your configuration sample, all options are either irrelevant (see e.g. [http://serverfault.com/questions/743847/openssh-rsaauthentication]) or default. Closing. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 16:03, 10 February 2017 (UTC)
+
[[User:CodingKoopa|CodingKoopa]] ([[User talk:CodingKoopa|talk]]) 18:07, 14 August 2019 (UTC)
:: OK RSAAuthentication yes (This option applies to protocol version 1 only) seems default, still any of the options mentioned might be changed by other tools such as '''sshguard''' or such.  --[[User:UBF6|UBF6]] ([[User talk:UBF6|talk]]) 16:46, 10 February 2017 (UTC)
 
  
:::[[sshguard]] does not change sshd_config at all. If the file changes, it's only due to user intervention - at least in Arch. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 17:04, 10 February 2017 (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 {{ic|$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 {{ic|$XDG_RUNTIME_DIR/ssh-agent.sock}}, avoiding the extra indirection. That's how the systemd --user example works.
 +
:
 +
:[[User:Grawity|grawity]] ([[User talk:Grawity|talk]]) 19:37, 14 August 2019 (UTC)
  
::::It is possible that on many rental (shared) VPSes '''sshd_config''' is modified by the provider or whoever would do it. --[[User:UBF6|UBF6]] ([[User talk:UBF6|talk]]) 17:44, 10 February 2017 (UTC)
+
::I wasn't able to get it working by using {{ic|-a}} to set the socket location and then evaluate that (I got {{ic|/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, {{ic|XDG_RUNTIME_DIR}} is exactly what I was looking for. Cheers.
 +
::
 +
::[[User:CodingKoopa|CodingKoopa]] ([[User talk:CodingKoopa|talk]]) 20:25, 14 August 2019 (UTC)

Latest revision as of 20:25, 14 August 2019

kwallet5

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)

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)

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)

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

~/.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)

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)

Title

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.

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)

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)