Property management shouldn’t feel this complicated.

Yet for many property managers, landlords, and real estate teams, daily operations are still held together by a mix of spreadsheets, phone calls, and disconnected tools.

It works — but only up to a point.

As soon as the number of tenants, payments, and maintenance requests grows, the cracks begin to show.

The Real Problem: Disconnected Operations

Most property setups today are not true systems.

They are collections of separate processes:

• Tenant records stored in one place
• Rent tracked somewhere else
• Maintenance handled informally
• Utility billing processed manually

Each part functions on its own.

But together, they don’t create flow.

They create friction.

Why This Doesn’t Scale

At a small scale, you can manage with workarounds.

But as operations grow:

• Payments become harder to reconcile
• Issues take longer to resolve
• Utility billing becomes inconsistent
• Visibility across the business disappears

At that point, the challenge isn’t effort.

It’s structure.

What a Better System Looks Like

A modern property management system shouldn’t just store data.

It should connect everything.

Every part of the operation should flow into the next:

• Properties → Units → Tenants → Leases
• Leases → Invoices → Payments
• Issues → Technicians → Resolution
• Utility readings → Billing → Reporting

When these flows are connected, the business becomes predictable.

And predictability is what makes scaling possible.

Inside ISHI: A Structured Approach

ISHI was built to bring this structure into property management.

Instead of treating features as separate modules, ISHI connects the entire lifecycle into one system.

🏘️ Property & Unit Management
All properties and units are organized in a clear, structured way

👥 Tenant & Lease Management
Tenants and leases follow a defined lifecycle, including move-in and move-out

💰 Invoicing & Payment Tracking
Invoices are generated and payments tracked with full visibility

📱 Tenant Portal
Tenants can view invoices, make payments, download receipts, and report issues

🛠️ Maintenance Workflow
Issues move from tenants to technicians with clear ownership and tracking

👷 Technician Portal
Technicians receive assigned tasks and update resolution status

💧 Utility Management & Billing
Utility readings are captured, approved, and processed through structured billing cycles

📊 Field Agent Portal
On-ground teams can submit readings directly into the system

What This Means in Practice

With everything connected:

• You no longer chase information across tools
• Teams know exactly what they need to do
• Payments and operations are tracked in real time
• Decision-making becomes data-driven

Instead of reacting to problems, you operate with clarity.

The Bigger Shift

This is part of a larger shift in how systems are used in business.

We are moving from:

Systems that record what happened

to:

Systems that actively run operations

That shift is what turns complexity into structure.

Final Thoughts

If your current setup relies on spreadsheets, manual processes, or scattered tools, you’re not alone.

But there is a better way to manage properties.

And it starts with having a system that connects everything.

🎥 Watch the Full Demo

See how ISHI works across property management, tenant interactions, maintenance, and utility billing in a complete, real-world setup:

🤝 Let’s Talk

If you’re exploring a structured property management system for your business:

🌐 https://ishi.digital
📧 hello@ishi.digital
📱 +254725307131

If you’re working with Git and suddenly hit this error:

sign_and_send_pubkey: signing failed for ED25519 "/home/user/.ssh/id_ed25519" from agent: agent refused operation
git@github.com: Permission denied (publickey).
fatal: Could not read from remote repository.

This means your SSH key is not being used correctly by your system or SSH agent.

This guide will walk you through fixing it step-by-step.

What Causes This Error?

This error typically happens when:

• Your SSH key permissions are incorrect
• The SSH agent is not running properly
• The key is not loaded into the agent
• GitHub does not have your public key
• The wrong SSH key is being used

Step 1: Fix SSH Key Permissions

Run the following commands:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub

Why this matters:
SSH will refuse to use keys that are too open (for security reasons).

Step 2: Restart SSH Agent and Reload Key

Clear existing keys and start fresh:

ssh-add -D
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

If you still see:

agent refused operation

Force restart:

pkill ssh-agent
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

Step 3: Verify SSH Connection to GitHub

Test your connection:

ssh -T git@github.com

Expected output:

Hi username! You've successfully authenticated...

Step 4: Ensure Your SSH Key Is Added to GitHub

Check your public key:

cat ~/.ssh/id_ed25519.pub

Copy the output and add it to GitHub:

• Go to GitHub → Settings → SSH and GPG Keys
• Click New SSH Key
• Paste your key

Step 5: Force Git to Use the Correct Key (Important)

If you have multiple SSH keys, Git might use the wrong one.

Create or edit this file:

nano ~/.ssh/config

Add:

Host github.com
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_ed25519
  IdentitiesOnly yes

Then save and exit.

Step 6: Test Again

ssh -T git@github.com

Then retry your Git command:

git pull
# or
git push

Full Fix Script (Quick Copy-Paste)

If you want a fast fix, run everything at once:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub

pkill ssh-agent
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

ssh -T git@github.com

Common Mistakes to Avoid

• Using the wrong key file (id_rsa vs id_ed25519)
• Not adding the key to GitHub
• Forgetting to restart the SSH agent
• Having multiple SSH keys without a config file

Pro Tip

If you frequently work across multiple GitHub accounts or servers, always use an SSH config file. It saves you hours of debugging.

Conclusion

This error is not a Git problem – it’s an SSH configuration issue.

Once you:

• Fix permissions
• Restart the agent
• Load the key
• Ensure GitHub has your public key

…everything works immediately.

ERPNext is powerful – but in production, your biggest risk is rarely ERPNext itself.

The biggest risk is a Linux server with:

• weak SSH settings
• open ports
• no brute-force protection
• wrong file ownership
• missing TLS/HTTPS
• outdated packages

This guide is a practical hardening checklist for real ERPNext deployments.

Before You Start (Important)

You need:

• a server running Ubuntu/Debian
• ERPNext installed (or you’re about to install)
• SSH access to the server

Golden rule: Do not lock yourself out.
When changing SSH settings, keep one terminal session open while testing a second session.

1) Create a Normal Admin User (Stop Using Root)

Commands

adduser karani

What it does (detailed)

• Creates a new Linux user called karani
• Creates a home directory: /home/karani
• Creates a primary group also called karani
• Prompts you to set a password (even if you later disable password login, it’s still fine)

Why it matters

• root has unlimited control of the entire machine.
• If attackers guess or steal root access, you lose everything instantly.
• A normal user reduces risk and forces you to use sudo (which is logged).

Give the user admin rights (sudo)

usermod -aG sudo karani

Explanation

• usermod modifies an existing user
• -aG sudo means: “append (-a) this user to the group list (-G), adding them to the sudo group”
• On Ubuntu/Debian, users in sudo group can run administrative commands.

Verify

groups karani

You should see sudo listed.

2) Harden SSH (The #1 Real Attack Target)

SSH is the first thing bots attack on the internet.

Open SSH configuration

sudo nano /etc/ssh/sshd_config

• sudo runs as admin
• nano is the editor
• /etc/ssh/sshd_config is the main SSH server config file

Block direct root login

In the file, find or add:

PermitRootLogin no

Meaning:
No one can log into the server directly as root, even if they know the password/key.

Why:
Bots always try “root” first.

Disable password login (keys only)

PasswordAuthentication no

Meaning:
SSH will reject passwords and only accept SSH keys.

Why:
This kills brute-force attacks completely.

Restart SSH so changes apply

sudo systemctl restart ssh

Explanation:

• systemctl controls Linux services
• restart ssh reloads the SSH service with the new config

Test safely (before closing your current session)

Open a new terminal and try:

ssh karani@yourserverip

If it works, you’re safe.

3) Set Up SSH Keys (So Passwords Are Useless)

On your laptop (client machine)

ssh-keygen

What it does:

• Generates a key pair:
  • private key (keep secret): ~/.ssh/id_ed25519 (or id_rsa)
  • public key (shareable): ~/.ssh/id_ed25519.pub
• You can press Enter through prompts.
• Add a passphrase if you want extra security.

Copy your public key to the server

ssh-copy-id karani@yourserverip

What it does:

• Logs into the server once
• Adds your public key into:
  • /home/karani/.ssh/authorized_keys
• After this, your laptop can login without typing the password.

Why this matters:
Even if someone knows your user password, they still can’t SSH in.

4) Firewall the Server with UFW (Only Allow What You Need)

UFW = Uncomplicated Firewall.

Allow SSH first (so you don’t lock yourself out)

sudo ufw allow OpenSSH

Explanation:

• Adds a firewall rule allowing SSH traffic (port 22) using the preset OpenSSH.

Allow web traffic (ERPNext needs this)

sudo ufw allow 80
sudo ufw allow 443

Explanation:

• 80 = HTTP (used for initial web access + Let’s Encrypt validation)
• 443 = HTTPS (secure ERPNext traffic)

Enable the firewall

sudo ufw enable

Meaning:

• Turns UFW on.
• Anything not explicitly allowed becomes blocked.

Check status

sudo ufw status verbose

You should only see: OpenSSH, 80, 443.

Why this matters:
Open ports = open doors.
Most servers get breached because unnecessary ports are exposed.

5) Install Fail2Ban (Auto-ban Attackers)

Fail2Ban watches log files and bans IPs that behave like attackers.

Install

sudo apt install fail2ban -y

Explanation:

• apt install downloads and installs the package
• -y automatically confirms “yes”

Enable on boot

sudo systemctl enable fail2ban

Meaning:

• Fail2Ban will start automatically after reboot.

Start now

sudo systemctl start fail2ban

Meaning:

• Starts it immediately.

Check status

sudo systemctl status fail2ban

If it says “active (running)”, it’s working.

Why this matters:
Bots try thousands of logins daily. Fail2Ban blocks them automatically.

6) Enable HTTPS with Certbot (Production Must Have SSL)

ERPNext handles logins, invoices, customer data. HTTPS is not optional.

Install Certbot and Nginx plugin

sudo apt install certbot python3-certbot-nginx -y

Explanation:

• certbot gets and renews SSL certificates
• python3-certbot-nginx lets certbot automatically modify Nginx config

Issue SSL certificate and configure Nginx

sudo certbot --nginx

What happens:

• It asks for your domain(s)
• It validates domain ownership
• It updates Nginx config to enable HTTPS
• It can redirect HTTP → HTTPS automatically

Test renewal

sudo certbot renew --dry-run

Meaning:

• Simulates renewal to confirm auto-renew will work.

Why this matters:
Without HTTPS, passwords and sessions can be intercepted on networks.

7) Lock ERPNext Files & Folder Ownership (Prevent Silent Breakage)

ERPNext runs as a Linux user (often frappe).

If files are owned incorrectly, ERPNext fails with:

• permission denied
• broken uploads
• failed PDFs
• worker crashes

Go to bench

cd ~/frappe-bench

Fix ownership (critical folders)

sudo chown -R frappe:frappe sites logs config

Detailed explanation:

• chown changes ownership
• -R means recursive (everything inside too)
• frappe:frappe sets:
  • owner = frappe
  • group = frappe
• sites contains site configs + assets
• logs must be writable by ERPNext workers
• config contains common bench settings

Why this matters:
If logs becomes owned by root, ERPNext can’t write logs → workers fail.

Set safe permissions

sudo chmod -R 750 sites logs

Explanation:

• chmod changes permissions
• 750 means:
  • owner: 7 (rwx)
  • group: 5 (r-x)
  • others: 0 (—)
• This blocks “everyone else” from accessing ERPNext internals.

8) Protect Your Database (MariaDB/Postgres)

Rule: Never expose DB ports publicly.

Check open ports

sudo ss -lntp

If you see MariaDB on 0.0.0.0:3306 or Postgres on 0.0.0.0:5432, that’s risky.

Best practice:

• Bind DB to localhost only: 127.0.0.1
• Use strong passwords
• Remove remote root access
• Only allow ERPNext server to connect locally

Why this matters:
Databases are where invoices, customers, and money live.

9) Keep the Server Updated (Patch Security Holes)

sudo apt update && sudo apt upgrade -y

Explanation:

• apt update refreshes package lists
• apt upgrade installs available updates
• -y confirms automatically

Why this matters:
Hackers often use known vulnerabilities in outdated packages.

10) Bonus Hardening Ideas (Next-Level)

If you want to go further:

• enable automatic security updates
• restrict SSH to a known IP (if you have static IP)
• separate ERPNext + DB server for larger deployments
• monitor logs and disk space
• daily automated backups

Final Words

Linux security is not complicated.
It is discipline.

And disciplined servers do not get hacked.

Contact & Links

Upeosoft (ERPNext & SaaS Consulting)
https://upeosoft.com

Code With Karani (Tutorials & Mentorship)
https://codewithkarani.com

Upeo Academy
https://upeo.academy

consult@upeosoft.com
+254725307131

Most ERPNext servers do not fail because of bugs.

They fail because of Linux ownership and permissions.

If you have ever experienced:

Permission denied
403 Forbidden
Uploads not working
PDFs not generating
Background jobs failing
Random worker crashes

…then your server is already telling you something.

Linux is protecting your system – not breaking it.

Linux Does Not Trust You. And That Is a Good Thing.

Linux is designed as a multi-user security system.

It does not assume that you are safe.
It does not assume your scripts are safe.
It does not assume your applications are safe.

Every file and every folder has rules.

Before Linux allows access, it asks:

Who owns this?
Which group is allowed?
What can “others” do?

If you don’t pass these checks – Linux blocks you.

What Files Really Are in Linux

Linux does not care about file types.

Your applications are files.
Your databases are files.
Your ERPNext system is files.
Your logs are files.
Your PDF reports are files.
Your uploads are files.

When Linux blocks file access, entire systems silently collapse.

What Folders Really Are

Folders are not just containers.

They are gates.

Linux checks permissions on folders first – before it even looks at files inside.

If you can’t enter a folder, nothing inside it exists to you.

The Command That Breaks ERPNext (Live Example)

Run this:

sudo chown -R root:root logs
bench restart

You have just told Linux:

Only root can write logs.
ERPNext workers can no longer write logs.
Workers crash.
Background jobs stop.
Uploads silently fail.

The system still “looks fine.”
But it is now broken.

Proving the Failure

Try:

sudo -u frappe touch logs/PROOF

Linux will block you.

ERPNext has lost write permission.

The Correct Fix

sudo chown -R frappe:frappe logs
bench restart

Your server recovers instantly.

Permission Numbers Explained Simply

755 – App folders
644 – Normal files
700 – Private keys
600 – Secrets

Why This Matters for SaaS & ERPNext

Most SaaS downtime is not caused by bugs.

It is caused by permission mistakes.

Learning Linux ownership turns you from an “installer” into an infrastructure engineer.

Final Thought

Linux does not break servers.

Linux protects them.

Once you understand ownership,
Linux becomes predictable – and powerful.

Learn Production Linux

Tutorials & Mentorship
https://www.upeo.academy

ERPNext & SaaS Consulting
https://upeosoft.com
consult@upeosoft.com
+254725307131