Vraag hoe creëer je een ssh-sleutel voor een andere gebruiker?


Ik probeer een ssh-sleutel te maken voor een andere gebruiker. Ik ben ingelogd als root. Kan ik de bestanden die door ssh-keygen worden gegenereerd gewoon bewerken en van root veranderen naar de gebruiker die ik wil?


76
2017-10-22 19:24


oorsprong


Als u de sleutel voor de gebruiker genereert, moet u ook een veilige methode hebben om de persoonlijke sleutel en de wachtwoordzin voor de gebruiker te krijgen. Het is veel beter dat de gebruiker de sleutel genereert en u vervolgens de openbare sleutel e-mailt. - Iain
Maar is dat niet moeilijk, staat u wachtwoordinlogs niet toe? Als ik alleen-key ben en ik een nieuwe gebruiker opzet, kunnen ze niet inloggen om hun sleutel in te stellen. - LVLAaron


antwoorden:


Daar zou je mee kunnen doen ssh-keygenOnthoud echter dat de privésleutel bedoeld is als privé voor de gebruiker, dus u moet heel voorzichtig zijn om deze privé te houden, net zo veilig als het wachtwoord van de gebruiker. Of zelfs veiliger, aangezien het niet waarschijnlijk is dat de gebruiker dit bij het eerste inloggen moet wijzigen.

ssh-keygen -f anything maakt twee bestanden in de huidige map. anything.pub is de openbare sleutel die u aan de gebruiker kunt toevoegen ~/.ssh/authorized_keys op elke bestemmingsserver.

Het andere bestand, zojuist gebeld anything is de privésleutel en moet daarom veilig worden opgeslagen voor de gebruiker. De standaardlocatie zou zijn ~username/.ssh/id_rsa (hier genoemd id_rsa, wat standaard is voor rsa-sleutels). Vergeet niet dat de .ssh map kan niet worden gelezen of beschrijfbaar door iemand anders dan de gebruiker, en de basismap van de gebruiker kan niet door iemand anders dan de gebruiker worden beschreven. Evenzo moeten ook de machtigingen op de privésleutel goed zijn: lezen / schrijven voor alleen de gebruiker en de .ssh-map en privé-sleutelbestand moeten eigendom zijn van de gebruiker.

Technisch gezien zou je de sleutel overal kunnen opslaan. Met ssh -i path/to/privatekey je zou die locatie kunnen opgeven tijdens het verbinden. Nogmaals, de juiste eigendomsrechten en permissies zijn kritiek en ssh zal niet werken als je ze niet goed hebt.


74
2017-10-22 19:35



+1 om aan te geven dat het een private (!) -Sleutel is - mailq
U gaat ervan uit dat de gebruiker een echt persoon is. Als de login een niet-interactieve gebruiker is die wordt gebruikt om utility-taken uit te voeren (bijvoorbeeld het uitvoeren van maine-scripts op externe servers), dan zou u waarschijnlijk de sleutel voor die gebruiker handmatig genereren. Dat heeft natuurlijk zijn eigen veiligheidsimplicaties, maar dat is een ander verhaal. - Rilindo
@Rilindo ssh -i naar een private sleutel voor een niet-gepriviligeerd proces is hoe ik meer dan een paar geautomatiseerde rsync back-upprocessen aan. :) - Shadur
Ik hou niet van dat soort antwoorden dat zegt "je zou dat niet moeten doen" maar beantwoord de vraag niet. Hoewel dit misschien juist en nuttig is voor de context van de oorspronkelijke vraag, kunnen andere mensen dezelfde vraag hebben in een andere situatie. "ssh-sleutels mogen nooit voor een andere gebruiker worden gegenereerd": dat klopt in het eenvoudige geval. Maar overweeg meerdere identiteiten van dezelfde fysieke persoon, bijvoorbeeld. Er kunnen meerdere accounts zijn op meerdere systemen, niet allemaal staan ​​ze toe dat je sleutels genereert of privé-sleutels adequaat kunt beschermen. - Gustave
usersof user's - User


er is geen gebruikersinformatie in de SSH-sleutels.

Het laatste veld in een openbare sleutel is een commentaar (en kan worden gewijzigd door de volgende opdracht uit te voeren ssh-keygen -C newcomment).

U hoeft niets speciaals te doen om een ​​sleutel voor een andere gebruiker te maken, zet hem gewoon op de juiste locatie en stel de rechten in.


108
2017-10-22 19:55



Dat is het juiste antwoord. - sebnukem
Ik test en bevestig gewoon, niet alleen is het een opmerking, maar het kan ook worden verwijderd en de toetsen werken nog steeds. Ik dacht altijd dat het belangrijk was! Bedankt voor het geven van het juiste antwoord. Net als de bovenstaande opmerkingen, heb ik een reden om sleutels te maken voor andere gebruikers, maar ik zeg niet waarom, dus er is geen argument. - FreeSoftwareServers


Word de gebruiker door te gebruiken su en voer de sleutel uit als die gebruiker:

[root@kvm0001 ~]# su - joeuser
[joeuser@kvm0001 ~]$ ssh-keygen -t dsa (or rsa1 or rsa, depending on your security requirements)
Generating public/private dsa key pair.
Enter file in which to save the key (/home/joeuser/.ssh/id_dsa):

16
2017-10-22 19:35



Waarom specificeren de DSA? - Ram
Oeps, kracht van gewoonte. Laat me updaten. - Rilindo
je zou rsa moeten gebruiken (of mogelijk één van de eliptische curve-varianten). dsa is beperkt tot onveilige keysizes. rsa1 is een verouderd formaat voor ssh1 dat niemand meer zou moeten gebruiken. - Peter Green
Mijn joeuser is een servicegebruiker, daarom kan ik niet als ze inloggen. Hoe kan ik een servicegebruiker (die alleen processen uitvoert) een ssh-sleutel geven? - Jonathan
@JonathanLeaders U geeft de shell op voor de gebruiker wanneer die gebruiker wordt. Iets als dit: `` `[root @ ip-10-254-41-211 ~] # grep ftp / etc / passwd ftp: x: 14: 50: FTP-gebruiker: / var / ftp: / sbin / nologin [root @ ip-10-254-41-211 ~] # su - ftp su: warning: kan directory niet wijzigen naar / var / ftp: geen bestand of map Dit account is momenteel niet beschikbaar. [root @ ip-10-254-41-211 ~] # su -s / bin / bash ftp bash-4.2 $ whoami ftp bash-4.2 $ `` ` - Rilindo


Als gezien hier, kunt u chmod gebruiken om de leesrechten van de map van de gebruiker waaraan u de SSH-sleutel wilt toevoegen te wijzigen.

vim /home/username/.ssh/authorized_keys

Plak vervolgens de sleutel in een nieuwe regel onderaan dat bestand


5
2018-01-09 23:42



Link is dood ... - Nyxynyx