Difference between revisions of "Talk:SSH keys"

From ArchWiki
Jump to: navigation, search
(cache time: new section)
(PuTTY elliptic curve support: re, close)
 
(50 intermediate revisions by 15 users not shown)
Line 1: Line 1:
Maybe the default 2048 bit rsa key is better?[[User:Vogt|Vogt]] 01:54, 31 August 2008 (EDT)
+
==<s> GnuPG Agent </s>==
  
I have just completed a tidyup, this including removing the section on connection control as I deemed it irrelivant. If needed, it is available in [http://wiki.archlinux.org/index.php?title=Using_SSH_Keys&oldid=66756#SSH_connection_control the history]. [[User:Thelucster|Thelucster]] 13:51, 13 April 2009 (EDT)
+
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}}
  
I'm hesitant to make the edit myself, as I'm new the the whole 'wiki' thing, but I noticed that the Gnupg instructions here seem incomplete. After following them several times myself, I turned to the man pages and found the solution. Edit: Nevermind. My problem was something different, and the current /etc/profile.d script handles the proper exports. [[User:Ryeguy146|Ryeguy146]] 21:19, 22 March 2011 (PDT)
+
: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)
  
== sshd_config ==
+
== kwallet5 ==
  
Sometimes the 'ssh-add' is not enough to log in without a password. It is possible that ssh is configured in such way that only a limited group of users is allowed to the machine.
+
there should be a note about kwallet5 not supporting PGP, for now
In this case - you need root-access to the server! - you have to change the configuration-file. Mostly you can find it as /etc/ssh/sshd_config.
 
If the last line(s) of this file read(s): 'AllowUsers  <username>', you will have to add a similar line with your own username. Don't forget to restart the ssh deamon: '/etc/init.d/sshd restart'.
 
  
== Using pam_ssh module ==
+
--- [[User:Lesto|Lesto]] ([[User talk:Lesto|talk]]) 23:50, 15 March 2015 (UTC)
  
I just want to add that one could also use the pam_ss module, available here
+
: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)
http://pam-ssh.sourceforge.net/
 
or in the AUR to decrypt the ssh key on login and automatically start ssh-agent and add the keys.
 
This way one would have a truely password less ssh session and in the same way not compromise security by using a passphrase less key.
 
  
:I have opened a new section on using pam_ssh to descrypt a user's ssh keys upon login.  My experience with PAM in general is limited, so the content currently consists of a description of pam_ssh, some basic configuration instructions, and some of the limitations of pam_ssh which I have personally encountered. — [[User:Ntwk|Ntwk]] 16:37, 18 December 2011 (EST)
+
== pam_tally ==
  
== ssh-agent ==
+
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)
  
The current wiki entries tells to "$ echo 'eval `ssh-agent`' >> ~/.bashrc" which will everytime spawn a new ssh-agent.
+
== <s>PuTTY elliptic curve support</s> ==
I think a more elegant way is only to add the export commands of ssh-agent to the .bashrc, so one ssh-agent can be used from every shell. This could be put in a small wrapper script:
 
#!/bin/sh
 
# check if ssh-agent is running
 
if [ -n "`ps -e|grep ssh-agent`" ];then
 
        echo "ssh-agent is already running" >&2
 
        exit 1
 
fi
 
# get new sock and pid
 
agent=`ssh-agent |head -2`
 
# delete old sock, pid and comment
 
sed -i -e "/SSH_\(AUTH_SOCK\|AGENT_PID\)/d" ~/.bashrc
 
# insert new sock and pid for new shells
 
echo -e "# auto generated SSH_AUTH_SOCK and SSH_AGENT_PID" >> ~/.bashrc
 
echo $agent >> ~/.bashrc
 
# for evaluation in the current shell
 
echo $agent
 
  
$ eval `./ssh_agent_wrapper.sh` "
+
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.
this would make ssh-agent available on the current and all new shells.
+
[[User:Jwegner|Jwegner]] ([[User talk:Jwegner|talk]]) 04:48, 6 January 2016 (UTC)
  
Be sure you have added the key to your /etc/ssh/ssh_config:
+
:Thanks, info was merged long ago and this stayed open. New version is out now. Updated with [https://wiki.archlinux.org/index.php?title=SSH_keys&type=revision&diff=469983&oldid=468807]. Closing. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 20:25, 6 March 2017 (UTC)
IdentityFile path/to/key
 
  
== Alternative to manual key installation ==
+
== SSH public key passphrase ==
  
We might want to mention that there's a script called 'ssh-copy-id' which comes with OpenSSH that install your public key in a remote machine's authorized_keys. There's a few caveat with it (it changes permissions of the user home directory, which should be a no-op in most situations; see the man page of ssh-copy-id -- and it also tells the user to make sure the script hasn't added extra keys, which might be a bit confusing for some).
+
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)
  
: The article currently gives a description of how to use {{ic|ssh-copy-id}} as well providing instructions on how to manually copy your pivate key to the remote server. I can't find any mention of {{ic|ssh-copy-id}} altering file or directory permissions on the remote server. On the contrary, the {{ic|ssh-copy-id}} man page dated 14 November 1999 currently included in the OpenSSH man page states that it "does not modify the permissions of any pre-existing files of directories." — [[User:Ntwk|Ntwk]] 11:22, 21 December 2011 (EST)
+
== Starting ssh-agent as a wrapper ==
  
== cache time ==
+
In this section, there is a note which says that you "can" add eval$(ssh-agent) to your .xinitrc.
  
In the description of gpg-agent.conf, it says that the example would cache the keys for 3 hours. If that's correct, gpg-agent seems to be using a rather odd unit of time. I tried to check in the man page for gpg-agent but couldn't find the options documented. Is the figure really correct? Or should it be 18000? --[[User:Margali|cfr]] ([[User talk:Margali|talk]]) 21:15, 13 September 2012 (UTC)
+
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.
 +
 
 +
[[User:Inxsible|Inxsible]] ([[User talk:Inxsible|talk]]) 00:46, 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> ==
 +
 
 +
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.
 +
 
 +
 
 +
Many of the above '''expect to find straight, succint info''', which is given right here:
 +
 
 +
 
 +
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.
 +
 
 +
2. You ran '''ssh-keygen''' OK.
 +
 
 +
3. Then you ran '''ssh-copy-id''' with error and '''ssh''' with error as well. So you cannot (immediately) '''ssh''' into your webserver anymore.  :-(
 +
 
 +
4. Even on (Jessie) debian to debian systems, '''ssh-copy-id''' often breaks. (see google for proof)
 +
 
 +
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'''
 +
 
 +
6. also run  '''chmod 700 ~/.ssh'''  and    '''chmod 600 ~/.ssh/authorized_keys'''  in the remote root shell.
 +
 +
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.:
 +
 
 +
 
 +
RSAAuthentication yes  # applies to protocol version 1 only
 +
 
 +
RhostsRSAAuthentication yes
 +
 
 +
PubkeyAuthentication '''yes'''  # this one being germane
 +
 
 +
<nowiki># For</nowiki> this to work you will also need host keys in /etc/ssh_known_hosts
 +
 
 +
<nowiki>#AuthorizedKeysFile</nowiki> %h/.ssh/authorized_keys
 +
 
 +
AuthorizedKeysFile '''/root/.ssh/authorized_keys'''
 +
 
 +
 
 +
 
 +
 
 +
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
 +
 
 +
 
 +
'''ssh -o "PasswordAuthentication yes " -o " PubkeyAuthentication no  "    root@1.2.3.4 '''
 +
 
 +
 
 +
 
 +
--[[User:UBF6|UBF6]] ([[User talk:UBF6|talk]]) 11:28, 10 February 2017 (UTC)
 +
 
 +
: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)
 +
:: 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 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)
 +
 
 +
:::::And the users may be even unable to change the options, so there is no point in dealing with these problems here - on the Arch wiki. Again, consider this topic closed. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 18:21, 10 February 2017 (UTC)

Latest revision as of 20:25, 6 March 2017

GnuPG Agent

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 —This unsigned comment is by Logankoester (talk) 24 February 2015 08:55. Please sign your posts with ~~~~!

The section was eventually merged.[1]Kynikos (talk) 17:08, 28 January 2017 (UTC)

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)

PuTTY elliptic curve support

The development snapshots for the PuTTY SSH suite [2] 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. Jwegner (talk) 04:48, 6 January 2016 (UTC)

Thanks, info was merged long ago and this stayed open. New version is out now. Updated with [3]. Closing. --Indigo (talk) 20:25, 6 March 2017 (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)

/etc/ssh/sshd_config -- quick help for ssh-copy-id

Many people find this article via google because ssh-copy-id did not work for them. Like this is only mildly helpful.


Many of the above expect to find straight, succint info, which is given right here:


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.

2. You ran ssh-keygen OK.

3. Then you ran ssh-copy-id with error and ssh with error as well. So you cannot (immediately) ssh into your webserver anymore.  :-(

4. Even on (Jessie) debian to debian systems, ssh-copy-id often breaks. (see google for proof)

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

6. also run chmod 700 ~/.ssh and chmod 600 ~/.ssh/authorized_keys in the remote root shell.

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.:


RSAAuthentication yes # applies to protocol version 1 only

RhostsRSAAuthentication yes

PubkeyAuthentication yes # this one being germane

# For this to work you will also need host keys in /etc/ssh_known_hosts

#AuthorizedKeysFile %h/.ssh/authorized_keys

AuthorizedKeysFile /root/.ssh/authorized_keys



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


ssh -o "PasswordAuthentication yes " -o " PubkeyAuthentication no " root@1.2.3.4


--UBF6 (talk) 11:28, 10 February 2017 (UTC)

This page deals with SSH keys in general, not only ssh-copy-id. The topic in question is described in the 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. [4]) or default. Closing. -- Lahwaacz (talk) 16:03, 10 February 2017 (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. --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. -- Lahwaacz (talk) 17:04, 10 February 2017 (UTC)
It is possible that on many rental (shared) VPSes sshd_config is modified by the provider or whoever would do it. --UBF6 (talk) 17:44, 10 February 2017 (UTC)
And the users may be even unable to change the options, so there is no point in dealing with these problems here - on the Arch wiki. Again, consider this topic closed. -- Lahwaacz (talk) 18:21, 10 February 2017 (UTC)