Talk:SSH keys

From ArchWiki
Jump to navigation Jump to search

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)

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)