Calendar

[Brian000]

(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 : https://www.pragmaticlinux.com/2021/05/configure-ssh-for-login-without-a-password/)

Code Select Expand


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.

Thanks.

[Brian000]

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 Expand


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

Thanks......

[Brian000]

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??

[Mad Penguin]

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 Expand

ssh-add .ssh/<private key>
(then enter your password) To ensure it's use, in .ssh/config;

Code Select Expand


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/ssh-add.sh

Code Select Expand

#!/bin/bash
ssh-add $HOME/.ssh/id_rsa $HOME/.ssh/anotherkey </dev/null
Make sure it's excutable;

Code Select Expand

chmod a+x ~/.config/autostart-scripts/ssh-add.sh
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).

[Brian000]

Thank you Mr Mad Penguin,

I have a number of different Distros, mostly headless, (but LXQt is this on laptop) and I acknowledge the risk of Single Sign On ("key to the kingdom" threat).  My query came from reading many on line guides which seem to suggest using SSH Keys as a secure alternative to providing a password.  it also fitted my move to Git, which requires SSH to pull/push changes.  it sounds like may have to look at installing the HTTP connector to achieve the same "no password" usage - although that's moving the risk from SSH to HTTP (albeit a much lower risk).

I'm happy with the recommendation to "don't do that!"

Thinking about it, I could move things around, and use CRON from my GIT server to perform the PUSH requests.... thereby removing the need almost completely!  *fingers crossed*

[Mad Penguin]

Mmm, my memory of using Git + https is that it requests a password each time you try to upload or download .. if there is an additional connector that gets around that, I'd still be interested in 'where' it's storing it's password.

The current pattern that *nix employs for user-space and applications is IMO flawed. Programs typically run in the same space in which secure files (keyfiles etc) exist, so any unscrupulous code could potentially (a) steal your credentials and (b) steal all your personal files / data. Moves towards 'snap' packages (and similar container based technologies) move some way to addressing the issue, but because they too are flawed, all too many packages still run in legacy mode which still gives applications access to stuff you typically don't want.

Whereas containers do implement a resilient barrier between different user-spaces, it also blocks access to lots of things you 'do' want access to. The application I'm currently working on for example was initially destined to be deployed as a snap, but after implementing, it turns out the security configuration 'required' just isn't currently possible in the snap world to we've reverted to 'apt'.

Ironically the most secure mechanism I've been able to choose is the one that's always been available under *nix, that is to treat every third party application as a server / service and run it under it's own account. In this way you don't have any 'random' applications running in the same space as your data and credentials. Any data the service has access to is data you have explicitly given it access to, but at the same time the service has access to the Operating System and it's resources. You still have privilege escalation bugs to worry about, but at least at this point we're talking OS bugs rather than explicit attacks.

So currently, I have my login account with ssh keys, git credentials etc, and this is where I do my pulls / commits .. then I have a second account in the same Unix group, which is where I run / test my code .. so if npm or pip downloads something it shouldn't, when it runs, it runs in a user account with no access to private data or ssh credentials. Call me paranoid, but if you look at some of the recent tool-chain corruption attacks .. (!)