51

Every now and then I get the odd request to provide remote support, troubleshooting and/or performance tuning on Linux systems.

Larger companies often already have well established procedures to provide remote access to vendors/suppliers and I only need to comply to those. (For better or for worse.)

On the other hand small companies and individuals invariably turn to me to instruct them with what they need to do to set up me up. Typically their servers are directly connected to the internet and the existing security measures consist of the defaults for whatever their Linux distribution is.

Nearly always I'll need root level access and whoever will be setting up access for me is not an expert sysadmin. I don't want their root password and I'm also pretty sure my actions won't be malicious, but what reasonably simple instructions should I give to:

  • set up an account and securely exchange credentials
  • set up root (sudo) access
  • restrict access to my account
  • provide audit trail

(And yes I'm aware and always warn those clients that once I do have admin access hiding any malicious actions is trivial, but let's assume that I have nothing to hide and actively participate in creating an audit trail.)

What can be improved on the steps below?


My current instruction set:

set up an account and securely exchange credentials

I provide a password hash and ask that my account is set up with that encrypted password, so we won't need to transmit a clear text password, I'l be the only one that knows the password and we don't start off with a predictable weak password.

sudo useradd -p '$1$********' hbruijn

I provide a public key SSH (specific key-pair per client) and ask they set up my account with that key:

sudo su - hbruijn
mkdir -p ~/.ssh
chmod 0700 ~/.ssh
echo 'from="10.80.0.0/14,192.168.1.2" ssh-rsa AAAAB3NzaC1y***...***== hbruijn@serverfault' >> ~/.ssh/authorized_keys
chmod 0600 ~/.ssh/authorized_keys 

set up root (sudo) access

I ask the client to set up sudo for me with sudo sudoedit or by using their favourite editor and append to /etc/sudoers:

hbruijn ALL=(ALL) ALL

restrict access to my account

Typically the client still allows password based logins and I ask them to add the following two lines to /etc/ssh/sshd_config to at least restrict my account to SSH keys only:

Match user hbruijn
PasswordAuthentication no

Depending on the client I'll route all my SSH access through a single bastion host to always provide a single static IP-address (for instance 192.168.1.2) and/or provide the IP-address range my ISP uses (for instance 10.80.0.0/14). The client may need to add those to a firewall whitelist if SSH access is restricted (more often than not ssh is unfiltered though).

You already saw those ip-addresses as the from= restriction in the ~.ssh/authorized_keys file that limits the hosts from which my key can be used to access their systems.

provide audit trail

Until now no client has asked me for that, and I have not done anything specific beyond the following to cover my ass:

I try to consistently use sudo with individual commands and try to prevent using sudo -i or sudo su -. I try not to use sudo vim /path/to/file but use sudoedit instead.

By default all the privileged actions will then be logged to syslog (and /var/log/secure):

Sep 26 11:00:03 hostname sudo:  hbruijn : TTY=pts/0 ; PWD=/home/hbruijn ; USER=jboss ; COMMAND=sudoedit /usr/share/jbossas/domain/configuration/domain.xml  
Sep 26 11:00:34 hostname sudo:  hbruijn : TTY=pts/0 ; PWD=/home/hbruijn ; USER=root ; COMMAND=/usr/bin/tail -n 5 /var/log/messages

I have mostly gives up on customising my work environments, the only thing I really do is set the following in my ~/.bash_profile increasing the bash history and to include time-stamps:

export HISTSIZE=99999999999
export HISTFILESIZE=99999999999
export HISTIGNORE="w:ls:ls -lart:dmesg:history:fg"
export HISTTIMEFORMAT='%F %H:%M:%S  '
shopt -s histappend
  • 8
    You can log (easy to alter after the fact) and even share sessions in screen, so in extreme cases, your client can watch live what you are doing. – Sven Sep 26 '16 at 12:42
  • If you want to add a better audit trail you should instruct them to enable remote logging if they have the possibility – Fredi Sep 30 '16 at 10:29
24

The only thing that comes to mind would be to add --expiredate to the adduser call.
With that the customer knows that your access will automatically expire at a fixed date.

He still needs to trust you as you have root access and still could remove the expire flag.

15

You can record your sessions with the script(1) utility.

$ script session.log
Script started, file is session.log
$ ls
file1  session.log
exit
Script done, file is session.log

then everything is in session.log.

  • Would you recommend running that on your own host, before starting the ssh session to a remote system, or include it as part of my profile on the remote system? – HBruijn Sep 26 '16 at 16:36
  • 1
    I guess you could do either - I've only used it once mostly people don't really care. – Iain Sep 26 '16 at 16:48
7

Since you are already logging in with an SSH public key, it would tighten things up a little if you didn't supply a password hash; instead tell them to use adduser --disabled-password (equivalently, useradd -p '!', I think), which is effectively equivalent to PasswordAuthentication no for that account, plus there is no chance someone snooping on your email could brute-force the password hash and log in as you.

  • 3
    The addition of the Match user hbruijn \n PasswordAuthentication no to sshd_config should prevent anyone from logging in remotely with my decrypted password (potentially local users could use it with su - hbruijn) but as far as I know I still need to have a valid password for sudo purposes though. Maybe I should simply reset my password after logging in? – HBruijn Sep 26 '16 at 16:09
  • Oh, good point about sudo. I am not sure whether an account in --disabled-password state can be given a password by running passwd from that account. – zwol Sep 26 '16 at 16:57
  • Also what stops anyone listening in on the password hash you provide? That part is a weak link that undermines using ssh keys where it doesn't matter if your public key is intercepted. – JamesRyan Sep 27 '16 at 9:53
  • 3
    Could that weak link be resolved by having the client also add a line in the sudoers file like hbruijn ALL=(ALL) NOPASSWD: /usr/bin/passwd hbruijn? – Dezza Sep 27 '16 at 10:13
2

Why provide a password at all, when you are going to use public/private keys.

Public keys are meant to be shared, so this is what you should use to securily exchange credentials, not hashed passwords.

sudo useradd --disabled-password hbruijn

When sending your public key, verify the fingerprint over a second channel, like a phone call, so you know nobody altered it on it's way in.

Since you won't have a password now to use sudo, you need to also alter your line in the sudoers file to

hbruijn ALL=(ALL) NOPASSWD:ALL

If you're not comfortable with having no password for sudo, and really want a password, there still is no need for you to send your hashed password, let the account be created without password, set your public key, and once your account is set up you can log in over ssh and run passwd to set your own password.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.