Server Fault Asked by Paras Chopra on January 1, 2022
I’ve hired a remote consultant to tune up my servers. Now, I am not 100% confident about giving him root password and allow him to do whatever he wants to do on the servers. Ideally, I want to see everything he is doing to my servers (in realtime) and also find a way not to share root password with him.
Are there any best practices in allowing a remote-consultant to access your server?
EDIT: To clarify, I want to do some kind of screen share with the consultant. Is there any method by which his commands are tunneled through my account without he getting any password ever?
PS: My servers are on Ubuntu 9.10
I've found a really cool way to give a one-time access to another user.. by sharing your own session.
This solution builds on bash coprocesses. The idea is:
ssh
into the server using your credentialsnc
server listing on port 2222Follow me :)
Start an ssh coprocess and publish its i/o on your local port 2222:
$ coproc ssh user@server -tt
$ eval "exec nc -kl 0.0.0.0 2222 <&${COPROC[0]} >&${COPROC[1]}"
Install [ngrok]. Grab an authtoken from their website:
$ npm install ngrok -g
$ ngrok authtoken <token> # grab it from their website:
Publish your port 2222 to the Internet:
$ ngrok tcp 2222
Forwarding tcp://0.tcp.ngrok.io:16135 -> localhost:2222
Now tell your friend to connect to the server using telnet:
$ telnet 0.tcp.ngrok.io 16135
Don't keep the connection open for too long; it's not secure at all! :)
Now let's watch what your friend is doing on that server using tmux shared sessions. Like this:
$ ssh user@host -t -- tmux new -As shared-session
this starts a named session that everyone can connect to. Let's use it in our scenario:
$ coproc ssh user@server -tt -- tmux new -As shared-session
$ eval "exec nc -kl 0.0.0.0 2222 <&${COPROC[0]} >&${COPROC[1]}"
$ ngrok tcp 2222
Forwarding tcp://0.tcp.ngrok.io:16135 -> localhost:2222
now you connect to this session to watch what people are doing there:
$ ssh user@server -t -- tmux new -As shared-session
now tell your friend to connect to it
$ telnet 0.tcp.ngrok.io 16135
Watch carefully :) As he starts typing rm -rf /*
, kill the first terminal window!
If the session quits, you might want to auto-restart it. Put the whole coproc && eval
thing into a while true ; do ... done
loop
Answered by kolypto on January 1, 2022
If you only allow public key access to you server but no password login, you can revoke the access right at any time you want by removing the key you gave to the consultant.
Once on the machine, GNU screen should provide all wanted functionality - as Cristian Ciupitu suggested. If you want to add extra comfort, sudosh2 might help you, but your shells history and screen hardcopy could help you to play back the commands later on...
Answered by MaoPU on January 1, 2022
I'm adding another, different answer in response to your update.
Using GNU screen, you can share a screen with another user. This means he can type commands, and you see everything he types. You can type commands and he can see what you type. When he's prompted for a password you can type the password, but the password contents are not printed to the screen (Note: While the text is not printed to the screen, I'm not sure if the other user would be able to gain access to your keystrokes some other way, or have access to the keystroke buffer, etc.).
More information at http://www.debian-administration.org/article/Using_GNU_screen%27s_multiuser_feature_for_remote_support
Another suggestion: Change the root password to a temporary password beforehand. When he is gone, restore the root password to the original password.
Answered by Stefan Lasiewski on January 1, 2022
You can let him connect with a regular account and then monitor his SSH session. The screen based solution is the best in my opinion and will let you do "pair" system administration. For example he could type the sudo commands and you would type the password in case it's needed.
P.S. If you use screen it doesn't mean you shouldn't also use sudosh2 or other solutions.
Answered by Cristian Ciupitu on January 1, 2022
First, you should have clearly defined objectives for what you'd like him to do. Once those objectives are defined you can grant him the level of access required to achieve those objectives.
It's like dropping my car off at the repair shop and telling them to "fix it up". Next thing you know I've got a bill for thousands of dollars and they've done things I didn't want done and didn't ask for.
Answered by joeqwerty on January 1, 2022
Instead of granting him the root password, use sudo.
If you want to see everything he is doing in realtime as superuser, check out sudosh2. From the docs:
sudosh is an auditing shell filter and can be used as a login shell. Sudosh records all keystrokes and output and can play back the session as just like a VCR.
"All keystrokes" includes keystrokes from backspaces, delete characters, BASH's 'erase word', etc. You can watch someone's embarrassing typos and corrections, etc.
sudosh will support syslog, and you could send the logs to a remote syslog sever. This would ensure that the user could not the erase all copies of the audit logs.
Note that the original project sudosh (the first version) has been abandoned by it's author. sudosh2 is alive and well.
Answered by Stefan Lasiewski on January 1, 2022
It really depends on what level of access you want to give him/her. I would never enable remote root logins in the first place. Only "normal" accounts should have remote access, then configure sudo for whatever that person needs.
Answered by Chris S on January 1, 2022
Get help from others!
Recent Questions
Recent Answers
© 2024 TransWikia.com. All rights reserved. Sites we Love: PCI Database, UKBizDB, Menu Kuliner, Sharing RPP