[SSH Keys] Welke keys moet ik waar genereren?

[Verwijderd]

Hi,

Misschien een domme vraag maar ik stel hem toch. Ik wil graag een vps middels ssh kunnen benaderen, waar dan ook ter wereld gebaseerd op ssh keys.
Wat ik echter niet goed begrijp van alle tutorials is op welke machine ik de keys moet genereren. Mijn lokale of mijn remote vps?

Het punt is namelijk dat ik vanaf meerdere werkplekken die machine moet kunnen benaderen. Ik zou dan zeggen dat ik mijn keys op de vps moet genereren en dan de pub key moet plaatsen op alle werkplekken waarmee ik in wil loggen. Of werkt dat niet zo?

Heb meerdere google tutorials gevolgd maar die praten allemaal specifiek over slechts één machine helaas. Wellicht dat jullie mij wat uitleg kunnen geven?

[pjottum]

Je maakt een keypair. Eigenlijk maakt het niet uit waar je de key maakt, als je ze maar op de juiste plek opslaat zodat jouw client ze kan gebruiken en de remote server ze kan vinden.

Uitgaande van een linux client machine run je het commando ssh-keygen.

Dus

code:

[leconnaisseur ~]$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/leconnaisseur/.ssh/id_rsa): 
Created directory '/home/leconnaisseur/.ssh'.
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/leconnaisseur/.ssh/id_rsa
Your public key has been saved in /home/leconnaisseur/.ssh/id_rsa.pub
The key fingerprint is:
SHA256:xD76jIAreu3Nl9WuQEhIdEwABaLsYx/lGeFxCd50PNg [e-mail]
The key's randomart image is:
+---[RSA 3072]----+
|. o==B+o=.       |
|o. .ooB+.E       |
|..  .=..o .      |
|.   o.o+         |
| + . o. S  .     |
|. o..  o .. .    |
|  .o. . .o .     |
|. ...+ +o.  .    |
|oo... +.o ..     |
+----[SHA256]-----+
[leconnaisseur ~]$ ll .ssh
total 8
-rw-------. 1 leconnaisseur leconnaisseur 2675 Jul 16 13:48 id_rsa
-rw-r--r--. 1 leconnaisseur leconnaisseur  584 Jul 16 13:48 id_rsa.pub

Die pub moet je kopieren naar je target, ook in de .ssh directory. Heb je al keys, dan hoef je dat niet te doen, maar moet je zorgen dat je keys op de juiste plek staan. De naam id_rsa is niet noodzakelijk, maar dit is op mijn systeem de default zo zonder enige opties.

Overzetten kan je doen met ssh-copy-id:

code:

[leconnaisseur@ ~]$ ssh-copy-id tc@pi2
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/leconnaisseur/.ssh/id_rsa.pub"
The authenticity of host 'pi2 (192.168.0.32)' can't be established.
ED25519 key fingerprint is SHA256:MZDMG9WKYSQ2I3FCQdqVqLkBXoNZmp1WkDSeLmlruDc.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
tc@pi2's password: 

Number of key(s) added: 1

Now try logging into the machine, with:   "ssh 'tc@pi2'"
and check to make sure that only the key(s) you wanted were added.

[leconnaisseur@ ~]$ ll .ssh
total 16
-rw-------. 1 leconnaisseur leconnaisseur 2675 Jul 16 13:48 id_rsa
-rw-r--r--. 1 leconnaisseur leconnaisseur  584 Jul 16 13:48 id_rsa.pub
-rw-------. 1 leconnaisseur leconnaisseur  635 Jul 16 13:50 known_hosts
-rw-r--r--. 1 leconnaisseur leconnaisseur   85 Jul 16 13:50 known_hosts.old

Je ziet, ik accepteer de hostkey en die sla ik op in known_hosts omdat ik de key accepteer die de host biedt. Hostkeys is voor een volgende keer.

Door met ssh-copy-id te werken weet ik zeker dat ik de juiste key kopieer en ik vergroot de kans op de juiste rechten aan de andere kant; daar moet je even goed op letten als je dit met de hand zou doen - de .ssh directory op de target moet 0700 zijn, de authorized_key file moet 0600 zijn.

Als je al een keypair hebt, doe je hetzelfde, je moet de pubkey aan de andere kant in de authorized_keys file zetten zodat de sshserver, sshd, die kan lezen.


Of volg deze oude guide:
https://access.redhat.com...ation-keypairs-generating

[Verwijderd]

Top! Dank je wel voor de heldere uitleg. Normaliter werk ik met UFW en Fail2Ban erbij voor SSH. Heeft dat dan nog wel zin eigenlijk?

[Kabouterplop01]

Verwijderd schreef op zaterdag 16 juli 2022 @ 14:05:
Top! Dank je wel voor de heldere uitleg. Normaliter werk ik met UFW en Fail2Ban erbij voor SSH. Heeft dat dan nog wel zin eigenlijk?

Afhankelijk van wat je wilt. Je kunt je ip adres (mits het vast is) whitelisten in je host.allow en in je UFW dan hoef je geen fail2ban te draaien, maar als het niet vast is dan moet je het wellicht anders doen en een subnet gaan whitelisten en om de rest van dat subnet goed te inspecteren zou je wel moeten fail2ban-en en UFW-en
En je moet uiteraard een passphrase gebruiken of een onmogelijk te onthouden wachtwoord.
Niet met root kunnen inloggen, juiste rechten hebben op het systeem (+ the usual sec actions)

[mafl]

pjottum schreef op zaterdag 16 juli 2022 @ 14:01:
Je maakt een keypair. Eigenlijk maakt het niet uit waar je de key maakt, als je ze maar op de juiste plek opslaat zodat jouw client ze kan gebruiken en de remote server ze kan vinden.

Waar je de key genereert heeft wel beveiligingsimplicaties: Als je dat om de remote machine doet en je huurt die machine bij een onvertrouwde partij dan moet je de private key als strict genomen als `compromised' beschouwen omdat de onvertrouwde partij lokale toegang heeft tot de machine (evil maid). Ik adviseer daarom om private keys altijd lokaal te genereren en lokaal te houden.

[Cyphax]

offtopic:
Ik heb de topictitel iets verduidelijkt/uitgebreid. Met alleen de tags wordt de lading niet zo goed gedekt.

[aawe mwan]

Waar we in dit topic nog niet over gesproken hebben, is dat in de openingspost staat: „vanaf meerdere werkplekken die machine moet kunnen benaderen”. Daarom: hoeveel keyparen ga je genereren?

Voor zover ik weet, is het het verstandigste om voor elke werkplek een eigen SSH keypair te genereren.
Technisch noodzakelijk is dat niet, maar je kunt dan van elke werkplek apart die key op de server dichtzetten.

Andersom: als je op een werkplek meerdere keyparen genereert voor meerdere servers, dan kan je kiezen (lokaal) of je bij een inlogpoging al je public keys naar elke server stuurt, of alleen de relevante (dat is veiliger).

[mafl]

aawe mwan schreef op zondag 7 augustus 2022 @ 10:37:
Waar we in dit topic nog niet over gesproken hebben, is dat in de openingspost staat: „vanaf meerdere werkplekken die machine moet kunnen benaderen”. Daarom: hoeveel keyparen ga je genereren?

Voor zover ik weet, is het het verstandigste om voor elke werkplek een eigen SSH keypair te genereren.
Technisch noodzakelijk is dat niet, maar je kunt dan van elke werkplek apart die key op de server dichtzetten.

Andersom: als je op een werkplek meerdere keyparen genereert voor meerdere servers, dan kan je kiezen (lokaal) of je bij een inlogpoging al je public keys naar elke server stuurt, of alleen de relevante (dat is veiliger).

Ik heb dat opgelost door een VPS als toeganspoort te gebruiken. Elke machine verbindt middels autossh met die VPS en opent een reverse tunnel waardoor de machine benaderbaar is. Zelf moet ik dan alleen een mapping onderhouden van een poort op de VPS naar een machine. Zo zijn ook meteen het firewall probleem, het port forwarding probleem en het het dynamische ip probleem opgelost.

De gebruiker die autossh gebruikt om in te loggen op de VPS heeft als shell /bin/false en mag verder niks, zit in geen enkele groep, en mag van sshd_config alleen reverse tunnels openen.