Hi guys, this maybe so simple i have just not come across it before and thought id ask for advice on the correct "ISPconfig" way of doing this i need to give a Dev some temp sudo access so he can install some things on the server. side point is there some trick to updating mdbtools?... He has ssh access through the client user account. Is there a simple "click this button" option hidden somewhere? or can a make a second account that has sudo somewhere that isnt going to break anything? likely a stupid question but im running ubuntu 20.04 with ispconfig 3.2 auto installer.
Sudo can not be configured through ISPConfig. You'll have to configure it manually in the sudoers file. I have not tried it for ISPConfig ssh users, so it might be that you must configure sudo for the webID user of the site and not the actual ssh user of this client, as the client's SSH user shares the uid with the webID user of the site.
Personally I never like to give such developers access to systems I manage. Either I will install the software for them, they get their own managed separate server managed by me (at their expense of course), or they go their own way. In the ISPConfig support channel I often get new clients who gave a developer who "is very experienced and careful" access and now have a broken system. And I have not said anything about sensitive data they can but shouldn't access
yeah. ordinarily i wouldnt. but he is the only client on the server and if he breaks it i can just role it back. and its temp access while he does this and then i will be removing the access. But... just to check... are there any issues or compatibility issues with later versions of mdbtools than whats installed in the auto installer?
why not just add their public ssh-key to the authorized-keys file of the user you already login to the server with yourself, which already has sudo access? let them make the changes required, and then remove their key from the authorized-keys file.. simple. no new accounts to create/delete. no new permissions to apply to / remove from accounts. plus you know exactly where the correct command history is, so it's very easy to check they've not done anything underhand while they were on the server.
