The Linux Community Forum

General Help & Advice => Linux Support => Topic started by: Brian000 on January 07, 2022, 10:11:24 pm

Title: SSH Key authentication
Post by: Brian000 on January 07, 2022, 10:11:24 pm
(Lubuntu - 5.11.0-43-generic #47~20.04.2-Ubuntu)

I have played with SSH authentication in the past and failed then too - but didn't have a use for it.... However, that's changed because I'm looking at using GIT and therefore need to be able to SSH onto my GIT server via cron - so I'm back setting up SSH key authentication.

This is a single computer, which I'm SSHing back to itself for testing and I have done what the internet suggests is the "usual" - being:
(only one of so many examples : (

Code: [Select]
ssh-keygen -f .ssh/id_gitserver
eval "$(ssh-agent -s)"
ssh-add .ssh/id_gitserver
ssh-copy-id -i .ssh/id_gitserver [email protected]

"OK, nice!", I think to myself when it all works! However, it seems that I need to rerun the two commands; "eval" and "ssh-add" (which requires the passphase) whenever I logout and back in....  I see that I now have a lot of "ssh-agent" processes running, so I'm pretty sure this isn't how it should work - but does anybody know what I'm doing wrong?

Some posts suggest that I should use "ssh-agent bash" instead of the EVAL command - but I that gives similar/same results.

There is a risk from my testing, that I have nested connections, but I expect the SSH keys to authenticate from my git user regardless of anything.

Title: Re: SSH Key authentication
Post by: Brian000 on January 08, 2022, 12:00:19 am
I have a fudge which seems to work - but I don't like it!

Generating an SSH-KEY without a passphase, and lock down the SSH connection on the server instead.

This means (assuming I understand it correctly) that the client connection can remain "insecure", because the server only permits access from  clients with the SSH-KEY (and from the named user).  Further, setting the PasswordAuthentication to "no", means that the same named user can only ever use the key.

Changing /etc/ssh/ssh_conf - adding another "host" directive like:
Code: [Select]
    Host gitserver
    HostName localhost
    User git
    IdentityFile ~/.ssh/id_gitserver
    IdentitiesOnly yes
    SendEnv LANG LC_*
    PasswordAuthentication no

Nb: for my testing both gitserver and localhost are in my /etc/hosts.

If anybody has a better idea of how to connect via SSH without requiring a password, please reply because I'm happy to continue playing.....

Title: Re: SSH Key authentication
Post by: Brian000 on January 08, 2022, 10:21:05 am
It appears that I do not understand it correctly! ;)

The HOST directive is a client side “shortcut” - so when I type “ssh gitserver” it knows which user and host to use!

So, that’s not quite what I’m after, but at least i know i can use the ssh-key (just need to secure that)

….but what is the right way to do this??
Title: Re: SSH Key authentication
Post by: Mad Penguin on January 21, 2022, 01:13:26 pm
As I understand it; on most desktops (?) when you log in it should activate the desktop's chosen keychain application and it should prompt you for a password to unlock your keychain. Once unlocked, subsequent use of the keychain should be transparent. (i.e. no password needed at the point of use, because it pulls it from the keychain) So to add your private ssh key to your keychain;
Code: [Select]
ssh-add .ssh/<private key>
(then enter your password) To ensure it's use, in .ssh/config;
Code: [Select]
Host *
   AddKeysToAgent yes
   IdentityFile ~/.ssh/<private key>
As for not using a password (  :)  ) , consider that some random bit of code in some random bit of software that you've installed onto your computer decided it's going to issue a single command at some point in it's lifecycle to copy .ssh/* to some random location out there on the Internet. If it were to happen (looking at toolchain polution at the moment, the odds seem high) , a passwordless key is potentially going to give a remote attacker passwordless access to your remote systems. (a short password, pretty much the same) Current recommendation seems to be >= 15 characters, avoiding dictionary words, dates etc. I know it's a pain (esp. if agent/keychain isn't set up) but for my $0.02, no passwords isn't worth the risk  :)

=== UPDATE ===
I appreciate this is a bit vague, bit it does differ from system to system. Just to prove the point I setup a clean machine to provide a concrete example. Assuming you have a working ssh setup and have done as described above, and assuming you're using a KDE-Plasma desktop (which is my current choice of desktop), you also need to create; ~/.config/autostart-scripts/
Code: [Select]
ssh-add $HOME/.ssh/id_rsa $HOME/.ssh/anotherkey </dev/null
Make sure it's excutable;
Code: [Select]
chmod a+x ~/.config/autostart-scripts/
Then log out .. when you log back in, it should ask if you want to allow the desktop to unlock the Wallet, select allow Always, then it will ask for your ssh password(s), make sure you click the "save" tickbox under the password. If you check a "ssh" command, it should now work without asking for a password. If you now log out and in again, it should ask for your wallet password to unlock your wallet (if your wallet password is different from your login password), but after that you should be good to go ... If you now launch the KDE Wallet manager, you should see an entry for "ksshaskpass", and if you open that, under password you should see your key(s).
SimplePortal 2.3.3 © 2008-2010, SimplePortal