https://wiki.archlinux.org/api.php?action=feedcontributions&user=Ish&feedformat=atomArchWiki - User contributions [en]2024-03-28T17:16:46ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=Talk:SSH_keys&diff=562330Talk:SSH keys2019-01-08T05:39:09Z<p>Ish: /* SSH Keys generated without -o flag are not safe */</p>
<hr />
<div>== kwallet5 ==<br />
<br />
there should be a note about kwallet5 not supporting PGP, for now<br />
<br />
--- [[User:Lesto|Lesto]] ([[User talk:Lesto|talk]]) 23:50, 15 March 2015 (UTC)<br />
<br />
: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. [[User:Neitsab|Neitsab]] ([[User talk:Neitsab|talk]]) 11:21, 21 October 2015 (UTC)<br />
<br />
== pam_tally ==<br />
<br />
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)<br />
<br />
== SSH public key passphrase ==<br />
<br />
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. [[User:Pickfire|Pickfire]] ([[User talk:Pickfire|talk]]) 10:09, 13 April 2016 (UTC)<br />
<br />
== Starting ssh-agent as a wrapper ==<br />
<br />
In this section, there is a note which says that you "can" add eval$(ssh-agent) to your .xinitrc. <br />
<br />
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".<br />
<br />
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.<br />
<br />
[[User:Inxsible|Inxsible]] ([[User talk:Inxsible|talk]]) 00:46, 4 January 2017 (UTC)<br />
<br />
: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)<br />
<br />
== Cleaner systemd-based ssh-agent setup ==<br />
<br />
{{hc|~/.config/environment.d/ssh-agent.conf|<nowiki><br />
SSH_AUTH_SOCK="${XDG_RUNTIME_DIR}/ssh-agent.socket"<br />
</nowiki>}}<br />
<br />
{{hc|~/.config/systemd/user/ssh-agent.service|<nowiki><br />
[Service]<br />
ExecStart=/usr/bin/ssh-agent -D -a "${SSH_AUTH_SOCK}"<br />
<br />
[Install]<br />
WantedBy=default.target<br />
</nowiki>}}<br />
<br />
{{hc|~/.zshrc or ~/.bash_profile or ~/.profile or the equivalent|<nowiki><br />
eval $(systemctl --user show-environment | grep SSH_AUTH_SOCK)<br />
export SSH_AUTH_SOCK<br />
</nowiki>}}<br />
<br />
Touching three files, instead of two, but the path is defined only in one place. Something similar could be achieved with {{ic|EnvironmentFile}}. Thoughts?<br />
<br />
[[User:Jeremejevs|Jeremejevs]] ([[User talk:Jeremejevs|talk]]) 17:22, 23 November 2017 (UTC)<br />
<br />
: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)<br />
<br />
== SSH Keys generated without -o flag are not safe ==<br />
<br />
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?<br />
<br />
[[User:Orekix|Orekix]] ([[User talk:Orekix|talk]]) 02:47, 4 August 2018 (UTC)<br />
<br />
: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)<br />
<br />
:: 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)<br />
<br />
:: ''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]])<br />
<br />
::: 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)<br />
<br />
== <s>Title</s> ==<br />
<br />
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?<br />
<br />
--[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 19:57, 22 December 2018 (UTC)<br />
<br />
: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)<br />
<br />
::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)<br />
<br />
:::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)<br />
<br />
::::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)<br />
<br />
:::::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.<br />
:::::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?<br />
:::::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 21:14, 23 December 2018 (UTC)<br />
<br />
::::::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)<br />
<br />
:::::::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)<br />
<br />
: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)<br />
<br />
::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)<br />
<br />
== <s>Section on YubiKeys</s> ==<br />
<br />
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)<br />
<br />
: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.<br />
:For the move over, I see two main options:<br />
:# Create a subsection at the end of [[YubiKey#CCID_Smartcard]] (which you just expanded with information), or<br />
:# 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.<br />
: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)<br />
:What do you think? --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 17:34, 23 December 2018 (UTC)<br />
<br />
: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.<br />
<br />
::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)<br />
::Done. You find the remainder at [[SSH_keys#Storing SSH keys on hardware tokens]], linking over to the new section.<br />
::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)<br />
::Closing. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 10:29, 3 January 2019 (UTC)<br />
<br />
== Intro draft ==<br />
<br />
{{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)}} <br />
<br />
[[SSH]] uses [[Wikipedia:Public-key cryptography|public-key cryptography]] to authenticate servers, optionally it can also be used to authenticate clients.<br />
<br />
This article assumes you already have a basic understanding of the [[Secure Shell]] protocol and have [[install]]ed [[OpenSSH]].<br />
<br />
=== Key-based client authentication ===<br />
<br />
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]<br />
<br />
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.<br />
<br />
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. <br />
<br />
==== Background ====<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== Comments ===</div>Ishhttps://wiki.archlinux.org/index.php?title=Talk:SSH_keys&diff=562329Talk:SSH keys2019-01-08T05:38:50Z<p>Ish: /* SSH Keys generated without -o flag are not safe */</p>
<hr />
<div>== kwallet5 ==<br />
<br />
there should be a note about kwallet5 not supporting PGP, for now<br />
<br />
--- [[User:Lesto|Lesto]] ([[User talk:Lesto|talk]]) 23:50, 15 March 2015 (UTC)<br />
<br />
: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. [[User:Neitsab|Neitsab]] ([[User talk:Neitsab|talk]]) 11:21, 21 October 2015 (UTC)<br />
<br />
== pam_tally ==<br />
<br />
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)<br />
<br />
== SSH public key passphrase ==<br />
<br />
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. [[User:Pickfire|Pickfire]] ([[User talk:Pickfire|talk]]) 10:09, 13 April 2016 (UTC)<br />
<br />
== Starting ssh-agent as a wrapper ==<br />
<br />
In this section, there is a note which says that you "can" add eval$(ssh-agent) to your .xinitrc. <br />
<br />
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".<br />
<br />
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.<br />
<br />
[[User:Inxsible|Inxsible]] ([[User talk:Inxsible|talk]]) 00:46, 4 January 2017 (UTC)<br />
<br />
: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)<br />
<br />
== Cleaner systemd-based ssh-agent setup ==<br />
<br />
{{hc|~/.config/environment.d/ssh-agent.conf|<nowiki><br />
SSH_AUTH_SOCK="${XDG_RUNTIME_DIR}/ssh-agent.socket"<br />
</nowiki>}}<br />
<br />
{{hc|~/.config/systemd/user/ssh-agent.service|<nowiki><br />
[Service]<br />
ExecStart=/usr/bin/ssh-agent -D -a "${SSH_AUTH_SOCK}"<br />
<br />
[Install]<br />
WantedBy=default.target<br />
</nowiki>}}<br />
<br />
{{hc|~/.zshrc or ~/.bash_profile or ~/.profile or the equivalent|<nowiki><br />
eval $(systemctl --user show-environment | grep SSH_AUTH_SOCK)<br />
export SSH_AUTH_SOCK<br />
</nowiki>}}<br />
<br />
Touching three files, instead of two, but the path is defined only in one place. Something similar could be achieved with {{ic|EnvironmentFile}}. Thoughts?<br />
<br />
[[User:Jeremejevs|Jeremejevs]] ([[User talk:Jeremejevs|talk]]) 17:22, 23 November 2017 (UTC)<br />
<br />
: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)<br />
<br />
== SSH Keys generated without -o flag are not safe ==<br />
<br />
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?<br />
<br />
[[User:Orekix|Orekix]] ([[User talk:Orekix|talk]]) 02:47, 4 August 2018 (UTC)<br />
<br />
: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)<br />
<br />
:: 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)<br />
<br />
:: ''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]])<br />
<br />
::: 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.<br />
<br />
== <s>Title</s> ==<br />
<br />
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?<br />
<br />
--[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 19:57, 22 December 2018 (UTC)<br />
<br />
: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)<br />
<br />
::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)<br />
<br />
:::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)<br />
<br />
::::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)<br />
<br />
:::::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.<br />
:::::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?<br />
:::::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 21:14, 23 December 2018 (UTC)<br />
<br />
::::::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)<br />
<br />
:::::::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)<br />
<br />
: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)<br />
<br />
::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)<br />
<br />
== <s>Section on YubiKeys</s> ==<br />
<br />
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)<br />
<br />
: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.<br />
:For the move over, I see two main options:<br />
:# Create a subsection at the end of [[YubiKey#CCID_Smartcard]] (which you just expanded with information), or<br />
:# 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.<br />
: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)<br />
:What do you think? --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 17:34, 23 December 2018 (UTC)<br />
<br />
: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.<br />
<br />
::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)<br />
::Done. You find the remainder at [[SSH_keys#Storing SSH keys on hardware tokens]], linking over to the new section.<br />
::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)<br />
::Closing. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 10:29, 3 January 2019 (UTC)<br />
<br />
== Intro draft ==<br />
<br />
{{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)}} <br />
<br />
[[SSH]] uses [[Wikipedia:Public-key cryptography|public-key cryptography]] to authenticate servers, optionally it can also be used to authenticate clients.<br />
<br />
This article assumes you already have a basic understanding of the [[Secure Shell]] protocol and have [[install]]ed [[OpenSSH]].<br />
<br />
=== Key-based client authentication ===<br />
<br />
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]<br />
<br />
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.<br />
<br />
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. <br />
<br />
==== Background ====<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== Comments ===</div>Ishhttps://wiki.archlinux.org/index.php?title=User:Ish&diff=562328User:Ish2019-01-08T05:35:45Z<p>Ish: Created page with "Security consultant | Arch user"</p>
<hr />
<div>Security consultant | Arch user</div>Ish