Vraag Sudo als een ander gebruikers- en actief scherm


Ik ben er vandaag achter gekomen dat het draaiende scherm als een andere gebruiker waar ik tegenaan loop, niet zal werken!

d.w.z.

ssh bob@server         # ssh into server as bob
sudo su "monitor" -
screen                 # fails

Ik heb een script dat wordt uitgevoerd als de "monitor" -gebruiker. We voeren het uit in een schermsessie om de uitvoer op het scherm te zien. Het probleem is dat we een aantal gebruikers hebben die inloggen met hun eigen account (bijv. Bob, james, susie, enz ...) en vervolgens sudo in de "monitor" -gebruiker. Hen toegang geven tot de "monitor" -gebruiker is uitgesloten.


150
2018-02-25 15:07


oorsprong


Is dit de fout die je krijgt? "Kan uw terminal niet openen" / dev / pts / 0 '- controleer alstublieft. " - Jim
yep, dat is die ene. Ik begrijp waarom het gebeurt, maar is er een oplossing? - luckytaxi
Een opmerking over uw opdrachten: ik blijf mensen zien rennen sudo su "user" -. Waarom niet gebruiken sudo -u user -s? - Andrew Aylett
@Jim: +1 voor het leveren van het ontbrekende foutbericht. - Dennis Williamson
@Andrew De meeste jongens die ik ken, doen dat sudo su - Ik denk dat het gewoon is waar mensen aan wennen (in mijn geval is dat omdat je geen sudo-vlaggen hoeft te kennen sudo su - Ik denk niet dat ik ooit de sudo manpage heb gelezen :) - voretaq7


antwoorden:


Probeer te rennen script /dev/null als de gebruiker jou su voordat het scherm wordt gestart - het is een getto-kleine hack, maar het zou het scherm gelukkig moeten maken.


220
2018-02-25 16:46



Re: veiligheidsimplicaties, geen waarvan ik weet (maar dat betekent niet dat er geen :) - IIRC dit is afhankelijk van een neveneffect van "script" openen van een nieuw eindapparaat (zoals de gebruiker die aanroept) , en omdat je de output van het script naar / dev / null stuurt, is er niets om vast te leggen. Het is ook zeker veiliger dan gebruikers toevoegen aan de tty-groep (IMHO) - voretaq7
@nalply Eerlijk gezegd zou je meerdere shells niet verwarrend moeten vinden als je een Unix systeembeheerder bent - dat gezegd hebbende, script kan worden gebruikt om te lanceren screen. Dan hoef je maar twee keer af te sluiten (een keer voor screen, een keer voor su). (Dit is iets de script man pagina kan voor u verduidelijken, als u de tijd neemt om het te lezen ...) - voretaq7
Of ren gewoon sudo -u bob script -q -c 'screen -dr myscreen' /dev/null. Dan heb je maar één terminal om af te sluiten / los te maken. - Andy Shulman
Bedankt, dit heeft me gered. Maar waarom lost dit dit op? Van wat ik begrijp, wordt alles afgedrukt, van stdout tot ... nergens. En dat herstelt op de een of andere manier het scherm. - sudo
@sudo Om zijn ding te doen script opent zijn eigen tty-apparaat, eigendom van de gebruiker die het heeft uitgevoerd (kijk in /dev en je zult het zien verschijnen nadat je het hebt uitgevoerd script). screen grijpt vervolgens dat tty-apparaat (dat eigendom is van de gebruiker die loopt) screen dus het heeft geen moeite om er toegang toe te hebben). Het is een totale hackjob, maar het werkt. Als ik naar een aantal van mijn machines kijk, lijkt het erop dat nieuwe versies van het scherm setuid-root lijken te installeren, wat ook werkt, maar dat betekent dat je nog een andere setuid-root binary hebt die rondzweven, wat sommige mensen terecht ongemakkelijk maakt. - voretaq7


Ik gebruik een wrapper-functie in de buurt screen voor de gebruiker (s) die ik sudo su naar. Dit is de wrapper-functie die ik aan de gebruiker (s) heb toegevoegd ~/.bashrc:

functiescherm () {
  / usr / bin / script -q -c "/ usr / bin / scherm $ {*}" / dev / null
}

Hierdoor kan ik alle opties en parameters gebruiken voor screen die ik misschien zou willen gebruiken. Ik overweeg deze functie systematisch te zetten.


32
2017-08-13 13:45



Werkt perfect. Voor degenen die dit systeem willen, raad ik aan dit toe te voegen aan /etc/bash.bashrc - werkt voor alle gebruikers. - Someguy123
Dit geeft geen argumenten om correct te screenen, anders een goede oplossing. - augurar


Aangenomen dat ze sowieso SSH opnemen in de host, zou je de publieke ssh-sleutels kunnen toevoegen voor elke gebruiker die toegang moet hebben tot de monitoraccount in het bestand ~ monitor / .ssh / authorized_keys. Vervolgens kunnen ze op de externe machine van elke gebruiker worden uitgevoerd

ssh -t monitor@remote.machine scherm -RD


7
2018-02-25 16:52



Dit is een andere goede benadering - je zou echter geforceerde commando's in het geautoriseerde sleutelsbestand moeten specificeren (per luckytaxi's "die hen toegang geeft tot de 'monitor' gebruiker is uitgesloten)" noot hierboven - geforceerde commando's kunnen ze beperken tot gewoon het bevestigen van de schermsessie) - voretaq7
Ik wist niet zeker hoe ik dat moest aanpakken in mijn antwoord, omdat hij zei: "hen toegang geven" is uitgesloten ", maar zei ook" ... ze sudo in de 'monitor' gebruiker ". Maar ik ben het ermee eens, dwingende opdrachtbeperking in de authorized_keys zou daar voor moeten zorgen. - Alex


Ervan uitgaande dat we het hebben over deze fout:

$ sudo su - bob
$ screen
Cannot open your terminal '/dev/pts/5' - please check.

Hier is een one-liner (kan bijvoorbeeld worden gebruikt als "alias gobob"):

sudo su - bob -c "script -c bash /dev/null"'

Uitleg:

Hiermee wordt een shell (zoals login-shell) als gebruiker gestart. Gebruiker bob start script, dat wordt verteld om een ​​bash op te roepen (kan dash of ksh zijn ...) en een kopie van de sessie wordt weggegooid.


6
2018-02-22 08:36





Waarschijnlijk zou het moeten veranderen van rechten op het betreffende apparaat of een monitor moeten toevoegen aan een groep die toestemming heeft om dat apparaat te lezen, dat zou mijn eerste neiging zijn. Maar je zou de veiligheidsimplicaties van dit moeten afwegen.


0
2018-02-25 15:51





Je zegt dat je doet:

sudo su "monitor" -

Ik vraag me af over het laatste streepje. Ik doe meestal:

sudo su - username

Het streepje (per de su man-pagina) vertelt su om "de shell een login-shell te maken". Dit betekent dat het alle gebruikelijke shell-opstartscripts zal vinden en dingen als PATH en HOME correct zal instellen.


0
2018-02-25 18:44



Nee. sudo su - username en sudo su username - hetzelfde doen. - Tim Ludwinski


Ik heb net dit probleem getroffen. Lost het op chmod +rw $(tty) voordat je sudo uitvoert. Het probleem met deze oplossing is dat iedereen daarna verbinding kan maken en op uw terminal kan snuffelen.


-2
2018-06-22 02:09



Klinkt als een geweldige oplossing. - Evan Carroll
@EvanCarroll Het is een geweldige oplossing, behalve het gedeelte waar het wordt gegeven de hele wereld lees en schrijf toegang tot zijn terminal. Gewoon een klein beveiligingsprobleem - Geen enkel programma zou zich daar zorgen over maken, behalve natuurlijk alles wat terminalbeveiliging controleert voordat het wachtwoorden accepteert (gpg bijvoorbeeld). En hij zal zeker nooit op een systeem zitten met kwaadwillende gebruikers die de tty en snuif wachtwoorden ... - voretaq7
Wees gewaarschuwd: probeer dit nooit thuis! dit is gevaarlijk!!! - ruizpauker