Klopt ph-cofi eens met je, ik mis dat ook. SecGuru_OTX zit ook met de directe server toegang met strikt toezicht op toegang met de bron. Ik zag laat een post van SecGuru_OTX met een kwaliteit dat ik niets meer te zeggen had. :<)
Ik zie wel veel RDP gebruik voor support naar werkplekken dat gaat op initiatief naar de helpdesk waarna je als werkplekgebruiker tijdens telefonisch contact nog een paar keer toestemming moet verlenen. Brute Force werkt dan echt niet. Een RDP naar een server is nodig omdat die dingen (virtueel) in afgeschermde ruimtes (of buiten de deur) staan waar je als OS beheerder gewoonlijk niets meer te zoeken hebt.
Sorry anoniem 11:02 voor je machientje thuis, in de professionele wereld gaat het er echt anders aan toe.
Door Rinjani: Windows RDP ondersteunt helaas niet de veel veiligere Public/Private key authentication (zoals SSH die heeft).
Heel nuttig in een beperkt aantal situaties. Ik denk aan (s)ftp connecties met vermijden user/password in files en een grid benadering waar je de service-accounts deelt over virtuele machines. Je zult dan ook wel iets met NSF doen. Het zijn de zaken met Linux waar je dat onder Windows niet eens merkt omdat er een domain technologie met trust filosofie bestaat. Dat is een wezenlijk verschil iets wat bij Linux niet eens echt bestaat (ja LDAP in de basis).
De werkelijkheid is veel weerbarstiger. Een systeem en applicatie landschap kent vele services met een boel functies. Wil je dat goed scheiden dan krijg je vele functionele accounts. (service administrators test rol-eigenaren). Het is iets waar -Nix beheerders een broertje dood aan hebben omdat ze dat veel te lastig vinden.
Rlogin login rsh er zijn met Linux nogal wat remote varianten naaste de gewone. https://linux.die.net/man/1/rlogin rssh is weer wat anders https://linux.die.net/man/1/rssh. Een X11 sessie doet een outbound call naar een X-server op een desktop. Het beheer voor Linux servers is nogal command-line minded, dat is wat anders dan een remote desktop.
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Security_Guide/sec-Securing_Services.html
Waar heb ik problemen mee? Nou dat is het verschil tussen het login en rlogin attribuut met shell gebruik voor gebruikers.
Sinds de PDP tijd is de boel gevirtualiseerd en zijn de begrippen lastiger uit te leggen. Alles is tegenwoordig remote (putty-ssh) en zou heel dogmatisch verboden zijn omdat remote logins gevaarlijk zijn.
Terug naar je private key in je lokale putty omgeving (ssh). Stel het werk is geoutsourced dan heb je voor een bepaald service account een onbekend aantal ingehuurde externe personen. Als die onderling allemaal de private key gaan delen omdat het dan werkt dan heb je het equivalent van een sticky note op een terminal. Zoiets is niet controleerbaar.
Wat je wel kunt doen is een gecontroleerde externe verbinding open zetten enkel op vezoek/incident waarna een restricted user via sudo extra privileges krijgt voor de betreffende taak.