Why Splync Uses SSH — The Invisible Key Behind Secure Servers

While Splync uses HTTPS to protect the route between your smartphone and our server, we still need to protect the server itself to ensure the safety of user data. App developers and system administrators need a way to enter that server to maintain and deploy updates — securely. That’s where SSH (Secure Shell) comes in. It’s a protocol that lets authorized users log into remote computers safely, even across untrusted networks. SSH replaces older, insecure methods like Telnet, which sent usernames and passwords in plain text.

SSH doesn’t rely on a typical password. Instead, it uses cryptographic keys — a matching pair of a public key and a private key. Think of them as a lock and a key that only fit each other. The public key lives on the server, and the private key stays with the user. When you connect, the server challenges you to prove that you hold the private key, without ever revealing it. This makes it nearly impossible for anyone listening in to impersonate you. While conventional passwords can be guessed, leaked, or reused, SSH keys are long, random cryptographic strings — practically unguessable. Even if someone manages to sniff the connection, all they see is encrypted noise. And since SSH keys are never sent over the network, there’s nothing to steal in transit.

If you’ve never seen an SSH key before, it might sound abstract — but it’s really just a long block of encoded text. A public key is typically a few hundred characters long, while a private key can reach well over a thousand. Both are stored as text files, but their contents look like random noise — a mix of letters, numbers, and symbols. The public key is safe to share; it’s like putting your lock on the server. The private key, on the other hand, is your unique digital identity and must never be shared. It’s stored locally on your computer and used only to prove you are who you claim to be —without ever revealing the key itself.

A public key is like a lock you attach to your house. Anyone can see it from the street, just like the lock on your front door. But looking at the lock doesn’t tell anyone how to open it. In other words, anyone can see it, but only the right key can unlock it. On the other hand, the private key is the key that opens the lock — and it stays safely with you. If someone else gets hold of your private key, they can enter your house as if they were you. That’s why it must always be kept secret.

Each public key and private key form a unique one-to-one pair. They’re generated together by a mathematical process so that only that specific private key can match its corresponding public key. You can think of them as a custom-made lock and key — forged together, and no other key in the world fits that lock. Even if you generate another pair using the same algorithm (like RSA or Ed25519), the numbers inside will be completely different. The math that links the two is one-way: you can easily derive the public key from the private key, but it’s practically impossible to reverse the process and find the private key from the public one. That’s why every SSH key pair is unique and secure.

When you log into a server with SSH, your private key never leaves your computer. Instead, the server sends a random challenge — like a one-time puzzle — that only your private key can solve. Your computer signs that challenge mathematically, producing a short answer that the server can check using your public key. If the answer fits, the server knows you hold the correct private key — without ever seeing it. This is the magic of modern cryptography: you can prove your identity without revealing your secret. SSH authentication works because your private key contains all the information to derive the public key, but the reverse is practically impossible.

Every time developers deploy code, update a database, or restart a service, they often connect to their remote servers via SSH. After authentication, they gain a secure command-line connection to the server. From there, they can manage files, restart services, or inspect logs — all encrypted end to end. In the case of Splync, SSH is how we securely manage our cloud server. Every administrative action — deploying updates, checking logs, backing up data — is done through SSH connections protected by cryptographic keys. No one can access the server without the correct private key. Even if someone knew our IP address, without that key, the door simply won’t open.

SSH protects the entrance to the server, and HTTPS protects data in transit. But once data lands inside the database, how do we keep it safe? That’s where hashing and encryption come in — the final layer of defense.