Difference between revisions of "Talk:SSH keys"

From ArchWiki
Jump to navigation Jump to search
m (separate section for new post - I don't see how kwallet5 is related to a 6 year old post)
(→‎pam_tally: new section)
Line 76: Line 76:
--- [[User:Lesto|Lesto]] ([[User talk:Lesto|talk]]) 23:50, 15 March 2015 (UTC)
--- [[User:Lesto|Lesto]] ([[User talk:Lesto|talk]]) 23:50, 15 March 2015 (UTC)
== pam_tally ==
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)

Revision as of 12:00, 30 June 2015


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. 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.
-- Kobussie, 10 February 2009

Using pam_ssh module

I just want to add that one could also use the pam_ss module, available here 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.
-- Pladen, 27 March 2009

I have opened a new section on using pam_ssh to decrypt 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.
-- Ntwk 16:37, 18 December 2011 (EST)


The current wiki entries tells to $ echo 'eval `ssh-agent`' >> ~/.bashrc which will everytime spawn a new ssh-agent. 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:

# check if ssh-agent is running
if [ -n "`ps -e|grep ssh-agent`" ];then
        echo "ssh-agent is already running" >&2
        exit 1
# 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` " 

this would make ssh-agent available on the current and all new shells.

Be sure you have added the key to your /etc/ssh/ssh_config:

IdentityFile path/to/key

-- Cameris, 14 July 2009

Alternative to manual key installation

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).
-- Hexanol, 14 June 2010

The article currently gives a description of how to use 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 ssh-copy-id altering file or directory permissions on the remote server. On the contrary, the 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."
-- Ntwk 11:22, 21 December 2011 (EST)

cache time

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?
-- cfr (talk) 21:15, 13 September 2012 (UTC)


Those who connect from Windows often use PuTTY to hook up over ssh; as of April 2013, PuTTY does not support ECDSA. I forget that periodically and waste time creating such a key, assuming I'm not alone there, I added it under the encryption method.
-- Nitmd April 7, 2013‎

That's a good note to add. I revised the wording of it and made it stand out more by using a template. Also, please remember to sign your posts by typing four tildes (~~~~).
-- Jstjohn (talk) 22:09, 7 April 2013 (UTC)

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 ~~~~!


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

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


With two factor authentication (crypto keys **and** password). I achieve that pam_tally increments by 2 the user errors every time I login. So surely there is an error in the suggested configuration--Xan (talk) 12:00, 30 June 2015 (UTC)