It's Friday, 5:00 PM. A production server has a critical failure and your internal team is overwhelmed. You decide to hire an external expert or freelancer to put out the fire.
The moment of truth arrives: You have to give them access to the server.
As a SysAdmin, you know rule number one is "never share the root password". But in the real world, sometimes SSH key configurations take too long or the access is for a web interface (GUI) that requires a username and password.
How do you hand over the keys to the kingdom to a stranger without compromising the security of the entire infrastructure in the long term? The answer lies in ephemeral transmission.
The "Zombie Access" Risk
The problem with working with contractors is not trust (we assume they have signed an NDA), but digital hygiene.
If you send a root password (or database administrator password) via email, WhatsApp, or Slack, you are creating a Zombie Access:
- The credential lives forever in your "Sent" folder.
- It lives forever in the freelancer's chat history.
- If the freelancer is hacked months later, the attackers have direct access to your server.
To mitigate this, you need sysadmin security tools that guarantee the credential only exists during transit.
Security Protocol: "Create, Share, Rotate"
To share root password securely, we suggest the following strict protocol:
1. Create (Isolate)
Never send your own password. Create a temporary credential specific for that intervention.
- Ideally: Create a user with limited sudo.
- If using root is unavoidable: Change the current password to a random and long temporary one.
2. Share (with Nurbak)
Here is where most fail. Don't use chat.
- Take the temporary password.
- Paste it into Nurbak.
- Critical configuration: Set "1 View" (Burn on read).
- Send the link to the contractor.
Why use Nurbak here?
Because it gives you implicit delivery confirmation. If the link stops working, you know the contractor (or someone else) already has the credential. If you used email, you would never know if the message was intercepted or if it remains there dormant.
3. Rotate (Revoke)
Once the contractor's work is finished:
- Kill the temporary user or change the root password immediately.
Since you used Nurbak, you don't need to worry about "deleting the message" from the chat. The link that remained in the history is useless.
Common Use Cases for Temporary Access Credentials
Beyond the Linux root user, this method is the standard for sharing:
- Hosting/CPanel Access: Where often there is no real multi-user support.
- Database Credentials: postgres or MySQL root for a one-off migration.
- PEM/Private Keys: If you absolutely must share an SSH key file (bad practice, but sometimes necessary), Nurbak is the only acceptable medium because it ensures the file doesn't stay floating on the network.
Comparison: Access Management for Contractors
| Method | Security Level | Leak Risk | Recommended |
|---|---|---|---|
| Email / WhatsApp | 🔴 Critical | Very High. Multiple copies. | NEVER |
| Password Manager (Shared Vault) | 🟡 Medium | Requires external account. Slow. | If fixed collaborator |
| Ephemeral Link (Nurbak) | 🟢 High | None after reading. Fast. | Ideal for Freelancers |
Conclusion: Paranoia is a Virtue
In systems administration, convenience is usually the enemy of security. However, tools like Nurbak allow a middle ground: it is as fast as sending a chat, but complies with the strictest security protocols.
The next time you have to give access to an outsider, don't give them the master key. Give them a one-time pass.
Do you have a freelancer waiting for access?
Don't send it via email. Generate a secure link that self-destructs right now.