Enterprise Linux Services: Essential Services Every Administrator Should Know

A Linux server in an enterprise environment rarely exists just to run an application. It often provides authentication, file sharing, remote administration, name resolution, monitoring, web services, databases, automation endpoints, and infrastructure services to hundreds or thousands of users and systems. For a Linux administrator, knowing how to install a package is not enough. You need to understand which service does what, which protocol it uses, where it stores its configuration, how it is secured, and how to troubleshoot it.

SSH: The Foundation of Linux Administration

SSH, or Secure Shell, is arguably the most important service for a Linux administrator.

It provides encrypted remote access to Linux servers and is commonly used for:

• Remote administration.
• Command execution.
• File transfers.
• Automation.
• Port forwarding.
• Secure tunnelling.
• Git operations.
• Infrastructure automation.

The server normally listens on:

TCP/22

Check the service:

systemctl status sshd

On some distributions, the service may be named ssh:

systemctl status ssh

Connect to a server:

ssh admin@192.168.10.50

Using a specific private key:

ssh -i ~/.ssh/id_ed25519 admin@192.168.10.50

Copy a file:

scp application.conf admin@192.168.10.50:/tmp/

For enterprise environments, administrators should generally prefer SSH keys over password authentication, disable direct root login where appropriate, restrict access using firewall and identity controls, and maintain appropriate logging.

Configuration is commonly found at:

/etc/ssh/sshd_config
/etc/ssh/sshd_config.d/

Always validate the configuration before restarting SSH:

sshd -t

This is particularly important when administering a remote production server. A configuration error followed by an SSH restart can lock you out.

SFTP: Secure File Transfer over SSH

SFTP is frequently confused with FTP.

They are fundamentally different.

SFTP is an SSH-based file transfer protocol.

It normally operates through the SSH service:

Client
   |
   | TCP/22
   |
   v
sshd
   |
   +---- SFTP subsystem

Connect using:

sftp admin@192.168.10.50

Upload:

put application.zip

Download:

get application.log

List remote files:

ls

SFTP is often the preferred choice when an organisation simply needs secure file transfer rather than legacy FTP compatibility.

It also has an important enterprise feature: chroot-based restricted SFTP environments.

For example, an organisation can provide a user with SFTP access without giving that user an interactive shell.

This is useful for:

• Application integrations.
• Vendor file exchange.
• Financial file processing.
• Data ingestion.
• Managed file transfer workflows.

FTP and vsftpd

FTP is one of the oldest file transfer protocols still encountered in enterprise environments.

The traditional FTP architecture uses separate control and data connections.

FTP Client
    |
    | Control connection
    | TCP/21
    |
    v
FTP Server
    |
    | Data connection
    |
    +------------------>

The problem is that traditional FTP does not provide encryption by default.

Credentials and data can therefore be exposed on an untrusted network.

This is why modern environments generally prefer:

SFTP
FTPS
Managed File Transfer

rather than plain FTP.

vsftpd

vsftpd, or Very Secure FTP Daemon, is a commonly encountered Linux FTP server.

Configuration is commonly located at:

/etc/vsftpd.conf

Service management:

systemctl status vsftpd
systemctl enable --now vsftpd

Check listening ports:

ss -lntp | grep vsftpd

If FTP is required for legacy integration, administrators should carefully configure encryption, authentication, user restrictions, passive-mode ports, firewall rules, logging, and SELinux/AppArmor policies.

NFS: Native Linux and UNIX File Sharing

NFS, or Network File System, is one of the most important file-sharing technologies in Linux environments.

It allows a client to mount a remote filesystem as if it were a local directory.

             NFS Server
          /data/projects
                 |
                 |
             Network
                 |
                 v
             NFS Client
          /mnt/projects

The client can then access:

ls /mnt/projects

as if the files were locally mounted.

Common enterprise use cases include:

• Shared application data.
• Virtualisation infrastructure.
• Linux home directories.
• Backup repositories.
• Container storage.
• Shared development environments.

View exports on an NFS server:

exportfs -v

Typical export configuration:

/etc/exports

Example:

/data/projects 10.10.20.0/24(rw,sync)

Apply exports:

exportfs -ra

On the client:

showmount -e 10.10.20.10

Mount:

mount -t nfs 10.10.20.10:/data/projects /mnt/projects

For persistent mounting, configure /etc/fstab.

NFS permissions require careful understanding of Linux UID/GID mapping. A user being able to access a directory locally does not automatically mean that the same user will have access through NFS.

Enterprise NFS administration therefore involves more than simply mounting a directory. Administrators need to understand:

• UID/GID consistency.
• Root squashing.
• Export restrictions.
• NFS versions.
• Network security.
• File locking.
• Performance.
• High availability.

SMB/CIFS and Samba

If NFS is commonly associated with Linux and UNIX environments, SMB is heavily associated with Windows environments.

Linux can access SMB file shares using the CIFS client.

A typical architecture looks like:

Windows Client
       |
       | SMB
       |
       v
   Samba Server
       |
       v
Linux Filesystem

Samba allows Linux systems to provide SMB services.

Check Samba:

systemctl status smb

On distributions where the service naming differs, check:

systemctl list-unit-files | grep -E 'smb|samba'

Configuration is commonly stored in:

/etc/samba/smb.conf

Validate the configuration:

testparm

List shares:

smbclient -L //server.example.com -U username

Mount an SMB share:

mount -t cifs //server/share /mnt/share \
    -o username=myuser

Enterprise Samba environments can integrate with Microsoft Active Directory, allowing Linux servers to participate in Windows-centric identity and file-sharing environments.

This makes Samba particularly important for Linux administrators working in mixed Windows and Linux infrastructure.

HTTP and HTTPS

Almost every enterprise Linux server administrator will eventually work with HTTP.

Linux commonly hosts:

• Web applications.
• REST APIs.
• Reverse proxies.
• Load balancers.
• Internal portals.
• Monitoring systems.
• Package repositories.

Common web servers include:

Apache HTTP Server
Nginx

Check listening services:

ss -lntp | grep -E ':80|:443'

Test a web endpoint:

curl -I https://example.com

For local troubleshooting:

curl -v http://localhost:8080/

In modern architectures, Nginx or Apache may not actually serve application content. They may instead act as a reverse proxy:

Internet
    |
    v
Nginx / Apache
    |
    +----> Application Server
    |
    +----> API Server
    |
    +----> Static Content

Understanding reverse proxying, TLS certificates, HTTP headers, connection handling, and logs is therefore increasingly important for Linux administrators.

DNS: The Service Behind Almost Everything

DNS is frequently blamed when an application cannot connect to another system.

Sometimes DNS really is the problem.

Sometimes it is not.

Linux administrators should understand:

/etc/hosts
/etc/resolv.conf
systemd-resolved
DNS servers
Forward lookup
Reverse lookup
Search domains

Test resolution:

getent hosts server.example.com

Using DNS utilities:

dig server.example.com

Reverse lookup:

dig -x 192.168.10.50

Check resolver configuration:

resolvectl status

LDAP and Enterprise Identity

Enterprise Linux servers frequently depend on centralised identity services.

LDAP is commonly used to provide directory services, while environments based on Microsoft Active Directory often expose LDAP-compatible interfaces.

Linux systems may use components such as:

SSSD
LDAP
Kerberos
PAM
NSS

The architecture can look like:

Linux Server
     |
     v
    SSSD
     |
     +--------> LDAP / Active Directory
     |
     +--------> Kerberos

SSSD is particularly important because it provides a common integration layer for identity and authentication.

Useful troubleshooting commands include:

systemctl status sssd
sssctl domain-list
sssctl domain-status

Administrators working with enterprise Linux should understand the difference between:

• Local users.
• Directory users.
• Authentication.
• Authorisation.
• Identity lookup.
• Kerberos tickets.
• Sudo policies.

This becomes especially important when hundreds or thousands of servers use centralised identity.

rsync: Efficient Data Synchronisation

rsync is not simply another file-copy command.

It is an efficient file synchronisation utility that can minimise data transferred between systems.

Basic example:

rsync -av /data/ admin@server:/backup/data/

Synchronise a remote directory:

rsync -av admin@server:/data/ /backup/data/

For large datasets, rsync can be significantly more efficient than repeatedly copying everything.

Common use cases include:

• Backup.
• Migration.
• Server synchronisation.
• Website deployment.
• Data replication.
• Disaster recovery workflows.

Be careful with:

--delete

For example:

rsync -av --delete source/ destination/

--delete can remove files from the destination that do not exist in the source.

Always understand the source and destination paths before executing destructive synchronisation commands.

Chrony: Enterprise Time Synchronisation

Time synchronisation is often underestimated.

Incorrect server time can cause problems with:

• Kerberos.
• TLS certificates.
• Distributed applications.
• Databases.
• Log correlation.
• Cluster operations.
• Authentication.

Modern enterprise Linux systems commonly use chrony.

Check:

systemctl status chronyd

Check synchronisation:

chronyc tracking

View configured sources:

chronyc sources -v

A healthy enterprise environment normally has a consistent time hierarchy:

Enterprise NTP Sources
        |
        v
  Infrastructure
     Servers
        |
        v
 Application Servers
        |
        v
 Clients / Workloads

Time synchronisation should be treated as infrastructure, not merely an optional system setting.

Logging: journald and rsyslog

When something breaks on a Linux server, logs are usually the first place to investigate.

Modern Linux systems commonly use:

systemd-journald

Query logs:

journalctl

Show logs for a service:

journalctl -u sshd

Show recent entries:

journalctl --since "30 minutes ago"

Follow logs in real time:

journalctl -f

Traditional syslog infrastructure may also use:

rsyslog

Configuration is commonly found under:

/etc/rsyslog.conf
/etc/rsyslog.d/

Enterprise environments often forward logs to a central platform:

Linux Servers
     |
     +----> journald
     |
     +----> rsyslog
              |
              v
       Central Log Platform
              |
       +------+------+
       |             |
     Search        Alerts

Centralised logging is critical for troubleshooting, security monitoring, auditing, and incident response.

Firewall: The Invisible Gatekeeper

A service can be running perfectly and still be unreachable because the firewall blocks its port.

Common enterprise Linux firewall technologies include:

firewalld
nftables
iptables
ufw

On modern RHEL-based environments, firewalld is commonly used as a management layer.

Check:

systemctl status firewalld

List active configuration:

firewall-cmd --list-all

Check listening ports independently:

ss -lntup

UFW: Ubuntu's Practical Host Firewall

For Ubuntu administrators, UFW (Uncomplicated Firewall) is an important tool to know.

UFW provides a simpler command-line interface for configuring host firewall policies without requiring administrators to write complex low-level firewall rules directly.

Check its status:

sudo ufw status verbose

A typical server might start with:

sudo ufw default deny incoming
sudo ufw default allow outgoing

Then explicitly allow the services the server requires:

sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

For better SSH access control, restrict SSH to an administration network:

sudo ufw allow from 10.10.10.0/24 to any port 22 proto tcp

Review the resulting policy:

sudo ufw status numbered

Common operational mistake: enabling the firewall before allowing SSH on a remotely administered server.

For example, this sequence can lock an administrator out:

sudo ufw enable

if SSH access has not already been permitted.

A safer sequence is:

sudo ufw allow 22/tcp
sudo ufw enable
sudo ufw status verbose

For production environments, administrators should also consider whether firewall restrictions should be applied at multiple layers:

Internet
   |
Cloud Firewall / Security Group
   |
Network Firewall
   |
Linux Host Firewall
   |
Application

UFW is therefore particularly useful for host-level access control on Ubuntu, while enterprise environments may additionally enforce controls through cloud security groups, network firewalls, Kubernetes network policies, or central security platforms.

The important principle is the same regardless of the tool:

Only expose the ports and source networks that a server actually requires.

This distinction is important.

If ss shows that an application is listening on TCP/443, but clients cannot connect, investigate the network path and firewall.

The troubleshooting chain should be:

Application
     |
Port listening?
     |
Firewall?
     |
Server interface?
     |
Routing?
     |
Network ACL?
     |
Remote firewall?
     |
Destination?

The Enterprise Linux Administrator's Service Map

A useful mental model is to group services by function.

What an Administrator Should Check First

When handed an unfamiliar Linux server, a useful initial assessment is:

hostnamectl
uname -r
ip addr
ip route
ss -lntup
systemctl --failed
df -h
free -h
systemctl list-units --type=service --state=running

Then investigate the services relevant to the server's role.

A file server might require:

NFS
SMB
SSH
DNS
chrony
logging
firewall

A web server might require:

SSH
Nginx/Apache
DNS
TLS
chrony
logging
firewall

An enterprise application server might require:

SSH
HTTP/HTTPS
DNS
LDAP/SSSD
chrony
logging
firewall
database connectivity

The exact combination depends on the workload.

Security Should Be Part of Every Service Configuration

A Linux administrator should never treat "the service is running" as the definition of success.

For every network service, ask:

Who can connect?
Which IP addresses can connect?
Which port is exposed?
Is encryption enabled?
How are users authenticated?
What permissions do they have?
Where are logs stored?
Are failed attempts logged?
Is the service patched?
Is the firewall restricting access?

For example, exposing SSH to an entire network when only an administration subnet needs access is unnecessary attack surface.

Similarly, exposing an NFS export to an entire corporate network when only a small application subnet requires access is poor access control.

Conclusion

An enterprise Linux administrator does not need to memorise every Linux service or every configuration parameter.

What matters is understanding the role of the major services and being able to troubleshoot them systematically.

At a minimum, an administrator should be comfortable with:

SSH       Remote administration
SFTP      Secure file transfer
FTP       Legacy file transfer
vsftpd    FTP server
NFS       Linux/UNIX file sharing
SMB       Windows-compatible file sharing
Samba     SMB server on Linux
HTTP      Web services
DNS       Name resolution
LDAP      Directory services
SSSD      Linux identity integration
rsync     Data synchronisation
chrony    Time synchronisation
journald  System logging
rsyslog   Centralised/legacy syslog
firewalld Firewall management
ufw       Ubuntu host firewall
nftables  Linux packet filtering

More importantly, learn how these services interact.

A typical enterprise server is not a collection of isolated services. It is part of a larger infrastructure:

                  Enterprise Network
                         |
          +--------------+--------------+
          |              |              |
         DNS          Identity       NTP
          |              |              |
          +--------------+--------------+
                         |
                    Linux Server
                         |
       +-----------------+-----------------+
       |                 |                 |
      SSH             Web/API           File Services
       |                 |                 |
      SFTP          Nginx/Apache       NFS / SMB
       |                 |                 |
       +-----------------+-----------------+
                         |
                    Application
                         |
                    Logs / SIEM

Once an administrator understands this service map, Linux server administration becomes much more structured.

You stop asking, "Which command should I run?"

Instead, you start asking the more useful questions:

• Which service provides this capability?
• Which process is listening?
• Which port is involved?
• How is the user authenticated?
• Which network path does the traffic follow?
• Which firewall controls it?
• Where are the logs?
• What happens if the service fails?

That mindset is what turns Linux administration from command execution into enterprise infrastructure engineering.