Results 1 to 11 of 11
  1. #1

    Firing a Server Admin Company -- Security Questions

    I'm about to "fire" the server admin company I'm currently using. They've been a major disappointment.

    I'm wondering what I should look out for security-wise? For instance, I just learned about RSA keys and how they might have one on the server. So even if I change the root password, they could still gain access to the server.

    Is there anything else I should know about/remove?

    Thanks in advance for any assistance.


  2. #2
    Join Date
    Nov 2003
    Auckland, New Zealand
    Generally, your next hired company will be able to remove these keys if they do have them installed. Make sure you tell your next company to remove these. They are quite easy to remove. If this is a good company with a good reputation, they won't do anything to get any sort of a bad reputation with accessing the server once they no longer have any mandate to do so.
    BLUETRIDENT.NET - Reliable Shared, Reseller and Dedicated Hosting Solutions Provider
    Managed Hosting with Personal Service
    Highspeed Content Servers, Lighttpd, Ruby on Rails, Cluster Servers & Rich Web Application Hosting

  3. #3
    Join Date
    Aug 2003
    Odds are that if it is a true "company" you are dealing with they will just forget you ever existed and move on.

    It is good to change your root password frequently anyways, so you certainly want to change it, and be sure any unwanted keys are removed from the box.
    If you want to take it one step further, change any control panel passwords that you might have sent to them to do work (I'd change these anyways if they were sent via email).
    Wayne Reavill. CEO,

  4. #4
    Join Date
    May 2002
    Kingston, Ontario
    I agree removing keys, change root password details and if you want to go a step further you could always block their connecting IP from the servers firewall.
    Upload Guardian 2 - Malicious Upload Scanner - Windows and Linux!
    Instantly scan uploaded files
    Get notified when released

  5. #5
    Join Date
    Nov 2006
    College Station, TX
    Blocking their IP is an exercise in frustration for both of you. Anyone can get around that.

    Chances are, if they're professionals, they won't have an issue with you taking your business elsewhere. But yes, what everyone else said about password changes. Also, check for .forward entries or their email address on your system. And then keep an eye on logwatch (you are running logwatch, right?) for the next few days to make sure they aren't attempting to log in from their IP address (because you didn't block it...) and/or aren't successfully logging in or otherwise accessing the system.

  6. #6
    Thanks everyone. Sounds like there isn't anything else to worry about other than the RSA keys (after I change the root and admin logins).

    Karl: You mention .forward entires. Where would I find those? I'm using cPanel.


  7. #7
    Join Date
    Nov 2006
    College Station, TX
    .forward entries are a unix server thing. They'll forward email sent to the local account (i.e. [email protected]) to the specified email address. They're located in the home directory for that local user.

    I'm not too familiar with Cpanel anymore (we stopped using it when Apache 2 had been out for three years, and cPanel still hadn't upgraded their software to work with Apache2 ... and we haven't looked back!), but if you're on a Linux system, they should be in the user's home directory. Check /root, and /home/(username). You'll need to do the cpanel equipvalent of 'show hidde files' -- " ls -al " from the shell.

  8. #8
    Join Date
    Aug 2003
    East Coast
    before firing the old management team, you should bring the new guys on and let them know your worried about the old company leaving something that might get them back into the system, Although that would be the END all for any server mangement company.

    This way the new server management company can lock out the old guys before they know what is coming and you can cancel their services..

  9. #9
    Join Date
    Apr 2005
    rm -rf ~/.ssh
    passwd root
    killall -9 bash

    login again

    Zach E. -
    Shared Web Hosting, Reseller Hosting, Cloud VPS & Dedicated Servers
    UK: 0800 138 3235 ❘ USA: 1-800-995-8256

  10. #10
    Greetings Michelle:

    Please do avoid any suggestions to "rm" files especially by force unless you know what files you are removing.

    That stated, check the following:

    1. root ssh keys are typically stored in /root/.ssh/authorized_keys and /root/.ssh/authorized_keys2

    There may be more than one key, and you don't want to delete needed keys; however, good individuals and companies should include a description of the key, or limit key by IP therefore identifying which key belongs to whom.

    Also, if the admin first logged in as a regular user prior to su'ing to root, there can be keys in their end user home directory.

    2. Do change the root password; that should be a regular thing in any event. Now a days, 16-character wide is typically best.

    3. IP addresses for the admin can be in /etc/hosts.allow, files included in /etc/hosts.allow as well as iptables.

    In terms of additional root users, check /etc/passwd for "x:0" (you will see the pattern when you look at the root user). Technically, there should be only one root user ability (identified by the "x:0"

    Thank you.
    Peter M. Abraham
    LinkedIn Profile

  11. #11
    Join Date
    Nov 2005
    check make sure they have no backdoor logins.
    GS RichCopy 360 Enterprise - Voted #1 for data migration and replication in terms of performance and features. Replicate data across between servers in the same network, WAS, or even across the internet

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts