Is Yunohost's SSH setup correct?

Discuss
,
1

So my simple understanding of how the whole ssh keything works is the following:

Your client has an encrypted key, which is called a private key, and your server has a lock with encrypted access codes, called public keys.
Private keys are stored in ~/.ssh/id_rsa on your client, while public keys are stored… somewhere on your server. (I think the file is called id_rsa.pub, while being accompanied with a file called known_hosts)

Since I’m both admin and folatt, it makes sense that I should be able to access both admin and folatt with this same key.
And I don’t need a password for it, because that’s what the key is for.
What I shouldn’t have is a key to root, because root access is a security risk.

What I see on Yunohost:

  • Being asked for user password, not key passphrase
  • Root access

Is this something that is required for a first setup?
If so, then generating keys should be in the installation guide.

Folatt’s list of Linux commands.md

...
Keys are created on the client so that the private key will never be exposed.

## Creating a key pair for private use and transfering the public key to the server.

ssh-keygen -C "$(whoami)@$(hostname)-$(date -I)" -f id_rsa -N <passphrase>
ssh-copy-id -i ~/.ssh/id_rsa.pub <ssh-user>@<deploy-host>

## Getting rid of having to type passphrases over and over again.
echo 'eval `keychain --eval --agents ssh id_rsa`' | tee -a ~/.bash_profile

## Change the key passphrase
ssh-keygen -f ~/.ssh/id_rsa -p
...
2

  • SSH keys have to be configured manually, because the user needs to generate a private/public key somewhere. So we can’t just forbid password login by default. However there are plans to provide a better UI/UX regarding this.

  • Root access is disabled by default after Postinstall in the context of YunoHost (c.f. here). With that said, I personnaly don’t understand/agree with the myth that “Root access is a security risk”. It’s no more a security risk than “admin access” or “bob access”. The primary security risks are : bad passwords, and having no counter-measure like Fail2ban against brute force attacks. Reducing the attack surface by forbidding root login is a good thing, but it’s not a silver bullet, because that will slow down automatic attack who basically only care about root. Eventually, in the context of targeted attacks, having root login disabled and admin login enable doesn’t improve security. What improves security is strong passwords (and even better : using private/public keys), not writing/sharing your password/key all over the place, and running a correctly configured Fail2ban. Imho, if you have this, then “root access” is irrelevant in terms of security risk compared to, say, running Wordpress on your server :confused:.

2 Likes
3

I think that’s more for personal security. In case someone physically wants to mess with your computer, while you’re away.
But you are right and I never gave much thought about it.
Et merci de m’avoir éduqué.