Home / server / Questions / 181131
Accepted
Paras Chopra
Asked: 2010-09-15 11:21:14 +0800 CST

How to grant temporary access to server?

  • 772

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

linux ubuntu guest

7 Answers

  1. 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.

    • 15
  2. Best Answer

    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.

    • 8

  3. 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.

    • 2

  4. 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.

    • 2

  5. 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.

    • 0

  6. 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...

    • 0

  7. 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:

    1. you ssh into the server using your credentials
    2. start a nc server listing on port 2222
    3. connect the two sessions: whenever anyone connects to 2222, they actually send commands to the opened ssh session
    4. publish your port 2222 to the internet using the same ssh client

    Follow me :)

    Public an open SSH session to port 2222

    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! :)

    Improvement: co-operation

    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!

    Improvement: auto-restart

    If the session quits, you might want to auto-restart it. Put the whole coproc && eval thing into a while true ; do ... done loop

    • 0