Difference between revisions of "Talk:SSH keys"

From ArchWiki
Jump to navigation Jump to search
Line 59: Line 59:
 
6. also run  '''chmod 700 ~/.ssh'''  and    '''chmod 600 ~/.ssh/authorized_keys'''  in the remote root shell.
 
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: Verify that the remote server '''/etc/ssh/sshd_config''' allows password-less '''ssh''' by switching from '''No''' to '''yes''' etc. e.g.:
+
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.:
  
  

Revision as of 12:15, 10 February 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)

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)

why is /etc/ssh/sshd_config only mentioned at the end of article ? 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

PubkeyAuthentication yes

#AuthorizedKeysFile %h/.ssh/authorized_keys

AuthorizedKeysFile /root/.ssh/authorized_keys

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

RhostsRSAAuthentication yes


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.

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