CapordiaName the responsible parties before distributing access
Distinguish the person responsible for the rental file, the person who authorizes access to the project and the person who can apply technical changes on the target. The person responsible for the results does not necessarily need to launch processes or administer the machine. Write down the required operations before choosing the rights: read an export, upload inputs, run a task or modify an environment.
Then verify the scope of the access actually granted. If you do not have the right to create identities or set permissions, have the possible procedure confirmed before inviting other contributors. Do not work around this limitation by distributing the Capordia account password. Sharing the work and managing the commercial file are two different matters.
Use an individual identity and know its scope
An individual identity makes it possible to revoke one person's access without replacing the access of the entire team. In a key-based SSH organization, OpenSSH distinguishes the public key known to the server from the private key held by the user. The coordination document may contain a reference or a public key fingerprint; it must never contain the private key or its passphrase.
Two different keys granting access to the same system account do not automatically create two separate file scopes. Permissions depend on the account and on the mechanisms configured on the machine. Decide therefore whether the requirement covers only individual authentication or also separation of actions. For automation, provide an explicit identity and owner, without discreetly reusing a colleague's personal identity.
Verify the target before presenting an identity to it
On first access, check the machine name, the expected account and the fingerprint of its host key against a trusted reference obtained during the access handover process. This host key identifies the server; it is distinct from your user key. An unexpected message about a change in the server's identity deserves scrutiny, not the automatic deletion of the known reference.
OpenSSH stores host keys and reports their changes. Use this information together with the context: an announced rebuild of the machine, a changed address or an unexplained event. Have the change confirmed before proceeding if it is not expected. The goal is not to add a ritual to every connection, but to avoid treating an identity alert as a mere display annoyance.
Fictional example: three contributors, three needs
The fictional team "Dossier des ouvrages" is preparing a week of work. Idriss runs the project A processing jobs, Noémie reviews the exports and Sacha steps in temporarily to configure the environment. The team wants the rights shown in the table, but must verify that they can be applied on the system actually handed over. These are neither existing customer accounts nor team management features announced by Capordia.
The decisive principle is that Noémie does not obtain administrative access just to open a result, and that Sacha's involvement has an end. Human approval alone configures no rights: the technical lead applies the available mechanisms, then each person performs the planned checks. If the desired separation is not achievable, the project must adapt its organization before introducing data that requires this separation.
| Contributor | Need | Desired scope | Review |
|---|---|---|---|
| Idriss, operations | Submit inputs and run project A | Workspace A, without general administration | End of campaign or change of role |
| Noémie, validation | Read the delivered exports | Selected results, without modifying inputs | End of validation |
| Sacha, temporary involvement | Prepare the authorized environment | Defined and approved change | As soon as the task is received |
Prepare an access record and test the limits
The record links a person or an automation, a technical identity, an approver, a scope, a justification and an expiry date. Keep the public key reference and the revocation procedure without storing secrets. The OpenSSH ssh-keygen command can display the fingerprint of a public key: this reference helps identify the right key when adding or removing one, without copying its private part.
Test an authorized action on a synthetic file, then an action deliberately outside the scope, designed to be denied. For a read-only role, opening must work and a controlled modification attempt must be denied. Do not use real data to test a deletion prohibition. Also check shared paths and where outputs go, because correct rights on a folder do not guarantee all the paths used by the program.
Plan the removal and verify a new connection
Trigger the removal at the end of the engagement, when a person leaves, or after a suspected compromise. The owner identifies all affected authorizations, including other access paths allowed for the same identity. They apply the removal according to the actual configuration. OpenSSH's RevokedKeys directive is one possible mechanism among those documented; it must not be assumed to be active on a machine without verification.
Then check that a new authentication with the revoked identity is refused, without removing the owner's recovery access. Examine already open sessions, running tasks, and automation identities separately: revoking an authorization and stopping an activity are different decisions. If a job must continue, transfer its responsibility according to an agreed procedure rather than leaving an orphaned identity.
Avoiding shortcuts that prevent oversight
A shared private key makes it impossible to know who must replace it and often forces a collective rotation. Broad "for now" access tends to last if no one has set its review date. A validation account also used to administer the machine makes separation checks hard to interpret. Fix these problems in the access record before they become an operational dependency.
Also avoid adding agent forwarding, tunnels, or access exceptions solely to work around an undiagnosed difficulty. Have the authorized owner describe the connection requirement and its constraints. This guide does not offer a universal server configuration: the mechanisms depend on the rights handed over, the environment, and the project's requirements. General documentation is not validation of the target.
Handing over an access organization that remains verifiable
On handover, gather the approved matrix, the active identities, the allowed and refused tests, the deadlines, and the person able to revoke access. Check that an absent person can be replaced without sharing their secret. Continuity relies on a procedure and an authorized backup owner, not on a password shared in the project folder.
When handing over, review accesses that have become unnecessary and automations that depend on a personal identity. If an unexpected refusal blocks the work, build a targeted incident report with the technical identity, the path concerned, and the redacted error. Do not add general rights just to make the symptom disappear. The right closure is a necessary access, tested and with a known end date.
Questions to decide
Should the Capordia account be shared with everyone involved?
No. Rental tracking and technical access to the work should be organized separately. Define the possible machine identities with the rights actually handed over. This method assumes no invitation or team-role system in the Capordia space.
Does a public key automatically grant the right permissions?
No. It is used for authentication when authorized; the actions available then depend on the account and system permissions. Verify one permitted action and one action that should be refused on synthetic files.
What should be checked after an contributor leaves?
Revoke their authorizations, verify that a new authentication is refused, and examine sessions, jobs, and automations still tied to their identity. Keep an authorized owner for recovery and follow-up. Do not conclude the removal is complete based on a simple checked box.