{"id":5765,"date":"2026-09-26T14:29:48","date_gmt":"2026-09-26T11:29:48","guid":{"rendered":"https:\/\/www.dchost.com\/blog\/?p=5765"},"modified":"2026-09-26T06:26:55","modified_gmt":"2026-09-26T03:26:55","slug":"secure-ssh-agent-forwarding-git-deployments-vps","status":"publish","type":"post","link":"https:\/\/www.dchost.com\/blog\/en\/secure-ssh-agent-forwarding-git-deployments-vps\/","title":{"rendered":"Secure SSH Agent Forwarding for Git Deployments on VPS"},"content":{"rendered":"<div class=\"dchost-blog-content-wrapper\"><div class=\"aiw-summary\">\n<p class=\"aiw-box-title\">Quick summary<\/p>\n<p>If you want a VPS to access a private Git repository without copying your private SSH key to the server, SSH agent forwarding can help. The signing operation stays with your local SSH agent, but a VPS you do not fully trust may still request signatures through that agent.<\/p>\n<ul>\n<li>The private key file is not transferred to the VPS, but processes that can access the forwarded agent socket may send signing requests.<\/li>\n<li>Apply <code>ForwardAgent<\/code> only to the single server alias that needs it.<\/li>\n<li>If the VPS is only a network gateway, <code>ProxyJump<\/code> usually provides a narrower access model.<\/li>\n<li>Test the connection first with SSH and then with <code>git ls-remote<\/code>; do not solve an unexplained failure by copying the key to the server.<\/li>\n<\/ul>\n<\/div>\n<p>A deployment script running on your VPS may be unable to fetch code from a private Git repository. The first solution that comes to mind is often copying your local private SSH key to the server. Although this can work, you then become responsible for another copy of the key, its permissions, its rotation and the consequences if the VPS is compromised.<\/p>\n<p>SSH agent forwarding offers another approach. Your SSH client forwards access to a socket belonging to the agent running on your local computer through the session to the VPS. The VPS can pass signing requests to that agent without seeing the private key itself. This meets the goal of not copying the key, but it does not make the VPS trusted automatically.<\/p>\n<div id=\"toc_container\" role=\"navigation\" aria-label=\"Table of Contents\" data-nosnippet class=\"toc_transparent no_bullets toc_numbered toc_title_center\"><p class=\"toc_title\">\u0130\u00e7indekiler<\/p><ul class=\"toc_list\"><li><a href=\"#How_SSH_agent_forwarding_works\"><span class=\"toc_number toc_depth_1\">1.<\/span> How SSH agent forwarding works<\/a><\/li><li><a href=\"#Choose_the_right_access_model\"><span class=\"toc_number toc_depth_1\">2.<\/span> Choose the right access model<\/a><ul><li><a href=\"#When_is_ProxyJump_more_suitable\"><span class=\"toc_number toc_depth_2\">2.1.<\/span> When is ProxyJump more suitable?<\/a><\/li><\/ul><\/li><li><a href=\"#Prerequisites_for_agent_forwarding\"><span class=\"toc_number toc_depth_1\">3.<\/span> Prerequisites for agent forwarding<\/a><ul><li><a href=\"#Check_the_local_agent_and_key\"><span class=\"toc_number toc_depth_2\">3.1.<\/span> Check the local agent and key<\/a><\/li><li><a href=\"#Limit_forwarding_to_the_target_VPS\"><span class=\"toc_number toc_depth_2\">3.2.<\/span> Limit forwarding to the target VPS<\/a><\/li><\/ul><\/li><li><a href=\"#Diagnose_the_VPS_before_changing_it\"><span class=\"toc_number toc_depth_1\">4.<\/span> Diagnose the VPS before changing it<\/a><\/li><li><a href=\"#Test_SSH_then_test_the_repository\"><span class=\"toc_number toc_depth_1\">5.<\/span> Test SSH, then test the repository<\/a><ul><li><a href=\"#Check_whether_Git_uses_another_SSH_configuration\"><span class=\"toc_number toc_depth_2\">5.1.<\/span> Check whether Git uses another SSH configuration<\/a><\/li><\/ul><\/li><li><a href=\"#Understand_the_security_boundary\"><span class=\"toc_number toc_depth_1\">6.<\/span> Understand the security boundary<\/a><\/li><li><a href=\"#Follow_this_troubleshooting_order\"><span class=\"toc_number toc_depth_1\">7.<\/span> Follow this troubleshooting order<\/a><\/li><li><a href=\"#Frequently_Asked_Questions\"><span class=\"toc_number toc_depth_1\">8.<\/span> Frequently Asked Questions<\/a><ul><li><a href=\"#Does_agent_forwarding_store_the_private_key_on_the_VPS\"><span class=\"toc_number toc_depth_2\">8.1.<\/span> Does agent forwarding store the private key on the VPS?<\/a><\/li><li><a href=\"#Does_ForwardAgent_yes_apply_to_every_server\"><span class=\"toc_number toc_depth_2\">8.2.<\/span> Does ForwardAgent yes apply to every server?<\/a><\/li><li><a href=\"#Can_a_cron_job_on_the_VPS_use_agent_forwarding\"><span class=\"toc_number toc_depth_2\">8.3.<\/span> Can a cron job on the VPS use agent forwarding?<\/a><\/li><li><a href=\"#Can_I_run_git_clone_on_the_VPS_with_ProxyJump\"><span class=\"toc_number toc_depth_2\">8.4.<\/span> Can I run git clone on the VPS with ProxyJump?<\/a><\/li><\/ul><\/li><li><a href=\"#Actionable_checklist\"><span class=\"toc_number toc_depth_1\">9.<\/span> Actionable checklist<\/a><\/li><\/ul><\/div>\n<h2><span id=\"How_SSH_agent_forwarding_works\">How SSH agent forwarding works<\/span><\/h2>\n<p>An SSH agent is a background process that handles cryptographic signing operations made with a private key. It does not normally give the remote system a copy of the key file. After you add a key to the agent, your SSH client sends the signing requests needed for a remote connection to that agent.<\/p>\n<p>When forwarding is enabled, the remote session will usually contain an environment variable named <code>SSH_AUTH_SOCK<\/code>. It points to a temporary Unix socket on the remote system. A signing request sent through that socket travels over the SSH connection to your local agent, and the signed response returns to the VPS.<\/p>\n<p>The private key itself is not copied to the VPS in this flow. However, a compromised or malicious VPS may send signing requests to the agent while the SSH session remains open. It cannot read the key, but it may still try to perform actions as the Git account or another service that accepts that key.<\/p>\n<div class=\"aiw-note aiw-note-warning\">\n<p class=\"aiw-box-title\">Caution<\/p>\n<p>Agent forwarding prevents you from giving the private key file to an untrusted server; it does not guarantee safe use of an untrusted server. Use it only with VPSs that you manage, keep updated and understand in terms of access boundaries.<\/p>\n<\/div>\n<h2><span id=\"Choose_the_right_access_model\">Choose the right access model<\/span><\/h2>\n<p>The decision depends on where the Git operation runs. If the VPS is only a jump point, <code>ProxyJump<\/code> is often the narrower model. You run Git on your own computer, while the SSH connection reaches the target Git server through the VPS. No agent socket is opened on the VPS, and the VPS does not need to request signatures as your Git account.<\/p>\n<p>If the Git command really runs on the VPS, such as when a deployment script executes <code>git fetch<\/code> or <code>git clone<\/code> there, two common options are available:<\/p>\n<ul>\n<li><strong>Agent forwarding:<\/strong> The local agent is used temporarily. The private key is not placed on the VPS, but you accept the forwarding risk for the duration of the open session.<\/li>\n<li><strong>Deploy key or separate machine identity:<\/strong> You create a separate, limited key for the VPS. The identity is stored on the server, while its scope and rotation are managed separately.<\/li>\n<\/ul>\n<p>Agent forwarding can be practical for a one-time maintenance task or a controlled deployment session. For continuously running automation, a separate machine identity with access limited to the relevant repository is usually a more predictable design than forwarding a personal key. Check your Git service&#8217;s documentation for repository-scoped or read-only key options.<\/p>\n<p>If several people access the same system, also consider an <strong><a href=\"https:\/\/www.dchost.com\/blog\/en\/ssh-key-management-and-access-sharing-secure-vps-login-architecture-for-small-teams\/\">SSH key management and access sharing<\/a><\/strong> approach. It helps you design access around identities, scope and rotation instead of personal keys and shared accounts.<\/p>\n<h3><span id=\"When_is_ProxyJump_more_suitable\">When is ProxyJump more suitable?<\/span><\/h3>\n<p>If the Git client on your local computer can reach the target repository through the VPS, you can use <code>ProxyJump<\/code> in your SSH configuration and make the VPS only a gateway. <code>ProxyJump<\/code> is available in sufficiently recent OpenSSH clients; check your client version with <code>ssh -V<\/code> and consult your distribution documentation if the option is unknown. For example, your local <code>~\/.ssh\/config<\/code> could contain:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">Host vps-bastion\n    HostName vps.example.net\n    User deploy\n    IdentityFile ~\/.ssh\/id_ed25519\n    IdentitiesOnly yes\n\nHost git-through-vps\n    HostName git.example.com\n    User git\n    ProxyJump vps-bastion\n    IdentityFile ~\/.ssh\/id_ed25519\n    IdentitiesOnly yes<\/code><\/pre>\n<p>You can use the <code>git-through-vps<\/code> alias from your local Git client. The Git operation takes place on your computer, not on the VPS. <code>ProxyJump<\/code> changes the connection path; by itself, it does not expose your agent socket to a remote VPS shell.<\/p>\n<p>When using this method, verify the target Git server&#8217;s host key in your local <code>known_hosts<\/code> file. Verifying the bastion VPS host key does not prove the identity of the target Git server.<\/p>\n<h2><span id=\"Prerequisites_for_agent_forwarding\">Prerequisites for agent forwarding<\/span><\/h2>\n<p>Before changing any configuration, check three things: Is a local agent running? Does it contain the correct key? Is your SSH client configured to forward the agent only to the intended VPS? Also check the versions of the OpenSSH client and server, since supported configuration options can vary between distributions and releases.<\/p>\n<h3><span id=\"Check_the_local_agent_and_key\">Check the local agent and key<\/span><\/h3>\n<p>On Linux or macOS, you can inspect the current agent socket and loaded identities with:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">ssh -V\necho &quot;$SSH_AUTH_SOCK&quot;\nssh-add -l<\/code><\/pre>\n<p>If <code>ssh-add -l<\/code> returns a key, at least one identity is loaded in the agent. If the list is empty, add the key you intend to use:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">ssh-add ~\/.ssh\/id_ed25519\nssh-add -l<\/code><\/pre>\n<p>Replace the filename with your own key. The command does not print the private key contents. Your operating system or key may ask for its passphrase.<\/p>\n<p>On Windows, OpenSSH Agent, WSL and other SSH clients may use different agent implementations. Run the equivalent checks in the terminal environment that will make the SSH connection.<\/p>\n<p>If the agent contains many identities, the SSH server may try more keys than necessary and reach a Git service&#8217;s authentication limit. In that case, <code>IdentitiesOnly yes<\/code> can restrict identity selection for the relevant connection. It does not disable agent forwarding.<\/p>\n<h3><span id=\"Limit_forwarding_to_the_target_VPS\">Limit forwarding to the target VPS<\/span><\/h3>\n<p>Instead of enabling forwarding for every SSH connection, attach it to a specific host alias:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">Host git-deploy-vps\n    HostName vps.example.net\n    User deploy\n    ForwardAgent yes\n    IdentityFile ~\/.ssh\/id_ed25519\n    IdentitiesOnly yes<\/code><\/pre>\n<p>Here, <code>git-deploy-vps<\/code> is only an SSH alias. Defining <code>ForwardAgent yes<\/code> under <code>Host *<\/code> may expose your agent socket to every server you connect to by mistake. To see the effective settings and the order in which they are applied, run:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">ssh -G git-deploy-vps | grep -Ei &#039;forwardagent|hostname|user|identityfile|identitiesonly&#039;<\/code><\/pre>\n<p>The output should show <code>forwardagent yes<\/code>, the expected host name, the expected user and the intended identity settings. This command does not connect to the server or change configuration.<\/p>\n<div class=\"aiw-note aiw-note-example\">\n<p class=\"aiw-box-title\">Example scenario<\/p>\n<p>Assume your local development computer has a key named <code>~\/.ssh\/id_ed25519_work<\/code> that can access only a company repository, while a VPS using the <code>deploy<\/code> account fetches code during each deployment. In this scenario, forwarding is enabled only for the <code>git-deploy-vps<\/code> alias. The private key is not copied to the VPS, and forwarding is not enabled when you connect to other servers.<\/p>\n<\/div>\n<h2><span id=\"Diagnose_the_VPS_before_changing_it\">Diagnose the VPS before changing it<\/span><\/h2>\n<p>After the local checks pass, connect through the alias:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">ssh git-deploy-vps<\/code><\/pre>\n<p>First check whether the agent socket is visible in the remote session:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">printf &#039;%s\\n&#039; &quot;$SSH_AUTH_SOCK&quot;\nssh-add -l<\/code><\/pre>\n<p>If <code>SSH_AUTH_SOCK<\/code> is empty, or <code>ssh-add -l<\/code> says it cannot connect to the agent, forwarding may be disabled in the client configuration, refused by the SSH server or absent from the remote session environment. Do not copy the key to the server at this point. Check the local configuration and the SSH daemon policy first.<\/p>\n<p>An administrator should verify that the server&#8217;s SSH daemon configuration does not disable forwarding through <code>AllowAgentForwarding<\/code>. If a change is needed, make a backup of the current configuration and define how you will restore it before editing. For example, on Linux you can test the relevant configuration after a change with:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">sudo sshd -t -f \/etc\/ssh\/sshd_config<\/code><\/pre>\n<p>Do not reload the SSH service until the test succeeds. The reload command depends on the distribution and service manager, so use the documented command for your system. If the change breaks access, restore the existing file from its backup and test the daemon configuration again. Avoid changing unrelated authentication or network settings in the same step.<\/p>\n<h2><span id=\"Test_SSH_then_test_the_repository\">Test SSH, then test the repository<\/span><\/h2>\n<p>Once the forwarded socket is visible, test Git authentication at the SSH layer. If your Git service uses the SSH user <code>git<\/code> and the host name <code>git.example.com<\/code>, run:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">ssh -T git&#64;git.example.com<\/code><\/pre>\n<p>The first connection may ask you to verify the host key. Confirm its fingerprint through an independent, trusted channel before accepting it. A successful authentication message varies by provider, and the absence of an interactive shell does not by itself indicate failure.<\/p>\n<p>Next, test access to a specific repository without downloading its data:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">git ls-remote git&#64;git.example.com:team\/project.git<\/code><\/pre>\n<p>This command lists repository references. If it succeeds, the SSH identity, repository path and access permission work together. If you receive <code>Permission denied (publickey)<\/code>, inspect which identities are being attempted with verbose SSH output:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">ssh -vT git&#64;git.example.com<\/code><\/pre>\n<p>The output does not contain the private key contents, but it can show whether the agent is being used and how authentication proceeds. When sharing diagnostic output, remove unnecessary usernames, host names and repository paths.<\/p>\n<h3><span id=\"Check_whether_Git_uses_another_SSH_configuration\">Check whether Git uses another SSH configuration<\/span><\/h3>\n<p>If the standalone <code>ssh<\/code> command succeeds but Git fails, check whether Git is using a different client or configuration. Run these commands in the environment where Git runs, such as the repository directory on the VPS:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">git config --show-origin --get core.sshCommand\nenv | grep &#039;^GIT_SSH&#039;<\/code><\/pre>\n<p>A defined <code>core.sshCommand<\/code> may select a separate SSH setup that does not use forwarding. The narrowest correction is to select the intended SSH command for that repository only. For example, if the Git operation runs on the VPS, run this in the VPS repository directory:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">git config core.sshCommand &quot;ssh -F ~\/.ssh\/config&quot;<\/code><\/pre>\n<p>This tells Git to use the standard SSH configuration file in that environment. If your organization requires another SSH client, adjust the value according to its documented standard instead of deleting it at random. After the change, run <code>git ls-remote<\/code> again in the same repository to verify the result.<\/p>\n<h2><span id=\"Understand_the_security_boundary\">Understand the security boundary<\/span><\/h2>\n<p>The main risk of agent forwarding is not that the private key can be read. It is that the agent&#8217;s signing ability can be used during the session. A malicious process on the VPS may use <code>SSH_AUTH_SOCK<\/code> to send signing requests to your agent. The impact depends on the key&#8217;s permissions, the Git account&#8217;s access scope and how long the connection remains open.<\/p>\n<p>For that reason, do not forward personal keys with broad access or keys that reach several production systems. Create a separate work key, limit it to the required repository or environment where possible, and remove it from the agent when the task is complete:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">ssh-add -d ~\/.ssh\/id_ed25519_work\nssh-add -l<\/code><\/pre>\n<p>If you need to remove every identity from the agent, use <code>ssh-add -D<\/code>. This also removes identities used by other projects, so check the effect on active sessions before using it in a shared working environment.<\/p>\n<p>Recent OpenSSH versions and supported agents may provide more advanced controls, such as destination constraints. Do not treat these features as a security boundary until you have confirmed support from the client, agent and key type. The simpler and more portable protections are still limiting forwarding to one host and using a separate, low-privilege key.<\/p>\n<p>For key rotation, file permissions and team access, also review the <strong><a href=\"https:\/\/www.dchost.com\/blog\/en\/vps-ssh-hardening-without-the-drama-fido2-hardware-keys-ssh-ca-and-safe-key-rotation-step-by-step\/\">VPS SSH hardening guide<\/a><\/strong> covering FIDO2, SSH certificates and rotation options. Agent forwarding does not replace key management; it is only a way to use a private key for a specific connection without copying it to the server.<\/p>\n<div class=\"aiw-note aiw-note-tip\">\n<p class=\"aiw-box-title\">Tip<\/p>\n<p>Separate a deployment script from the interactive SSH session used to start it manually. Making continuous automation depend on a local agent and an open developer connection can cause the deployment to stop working when that session closes. For a persistent workflow, evaluate a separate machine identity, a CI\/CD secret mechanism or a repository-scoped deploy key.<\/p>\n<\/div>\n<h2><span id=\"Follow_this_troubleshooting_order\">Follow this troubleshooting order<\/span><\/h2>\n<ol>\n<li><strong>Check the local environment:<\/strong> Use <code>ssh-add -l<\/code> to confirm that the correct key is loaded, and <code>echo \"$SSH_AUTH_SOCK\"<\/code> to confirm that the local socket exists.<\/li>\n<li><strong>Check the SSH settings:<\/strong> In <code>ssh -G git-deploy-vps<\/code>, look for <code>ForwardAgent yes<\/code>, the correct user and the correct host name.<\/li>\n<li><strong>Check the remote socket:<\/strong> In the VPS session, confirm whether <code>SSH_AUTH_SOCK<\/code> is set and whether <code>ssh-add -l<\/code> can reach the agent.<\/li>\n<li><strong>Separate host-key checks:<\/strong> Confirm that the Git service host key is verified in <code>known_hosts<\/code> on the machine where the Git SSH client runs.<\/li>\n<li><strong>Test the SSH layer:<\/strong> Use <code>ssh -vT<\/code> to inspect authentication, then test repository permission with <code>git ls-remote<\/code>.<\/li>\n<li><strong>Inspect Git settings:<\/strong> Make sure <code>core.sshCommand<\/code> or <code>GIT_SSH<\/code> is not selecting an unexpected client or configuration file.<\/li>\n<\/ol>\n<p>If the agent socket is not visible on the server and you cannot change the server policy, ask the system administrator to verify <code>AllowAgentForwarding<\/code> instead of trying to force the setup. Copying the key during a failed attempt turns an unresolved configuration problem into a permanent private-key risk.<\/p>\n<h2><span id=\"Frequently_Asked_Questions\">Frequently Asked Questions<\/span><\/h2>\n<h3><span id=\"Does_agent_forwarding_store_the_private_key_on_the_VPS\">Does agent forwarding store the private key on the VPS?<\/span><\/h3>\n<p>No. In the normal flow, the private key file is not transferred to the VPS. The VPS can still send signing requests through the agent during an open forwarding session, which is why the method is unsuitable for untrusted servers.<\/p>\n<h3><span id=\"Does_ForwardAgent_yes_apply_to_every_server\">Does <code>ForwardAgent yes<\/code> apply to every server?<\/span><\/h3>\n<p>It applies to the host scope where you define it. If you place it under <code>Host *<\/code>, the scope becomes broad. A safer choice is to define it beneath one server alias.<\/p>\n<h3><span id=\"Can_a_cron_job_on_the_VPS_use_agent_forwarding\">Can a cron job on the VPS use agent forwarding?<\/span><\/h3>\n<p>Usually not. Cron does not automatically inherit the environment or agent socket from an interactive SSH session. A CLI job started by cron is also a separate process from PHP-FPM web workers; it does not occupy an FPM worker, and it cannot use the forwarded agent unless the socket is explicitly made available. A persistent job should not depend on a local computer&#8217;s open session. Design it around a separate machine identity.<\/p>\n<h3><span id=\"Can_I_run_git_clone_on_the_VPS_with_ProxyJump\">Can I run <code>git clone<\/code> on the VPS with ProxyJump?<\/span><\/h3>\n<p>No. <code>ProxyJump<\/code> lets your local SSH client reach the target through the VPS. If you want to run <code>git clone<\/code> on the VPS, the VPS needs its own authentication method.<\/p>\n<h2><span id=\"Actionable_checklist\">Actionable checklist<\/span><\/h2>\n<ul>\n<li>Decide whether the Git operation runs locally or on the VPS.<\/li>\n<li>If the VPS is only a gateway, prefer <code>ProxyJump<\/code> to agent forwarding.<\/li>\n<li>If forwarding is required, use a separate, low-privilege SSH key.<\/li>\n<li>Define <code>ForwardAgent yes<\/code> only under one VPS host alias.<\/li>\n<li>Verify the local agent, remote <code>SSH_AUTH_SOCK<\/code>, SSH authentication and <code>git ls-remote<\/code> in that order.<\/li>\n<li>Remove the temporary identity from the agent when the task is complete.<\/li>\n<li>For regular deployment automation, plan a repository-scoped machine identity or CI\/CD secret model instead of a personal agent.<\/li>\n<\/ul>\n<p>Your next step is to identify where the current deployment command runs. If it runs on the VPS, use forwarding as a short-lived, narrowly scoped option. If it is regular automation, design key scope and rotation around a separate machine identity.<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":"<p>Learn how to use SSH agent forwarding for Git deployments on a VPS without copying your private key, while limiting exposure and troubleshooting failures.<\/p>\n","protected":false},"author":4,"featured_media":5762,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[180],"tags":[519,603,600,605,604],"class_list":["post-5765","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-how-to","tag-devops","tag-git-deployment","tag-ssh","tag-ssh-agent-forwarding","tag-vps-security"],"_links":{"self":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/5765","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/comments?post=5765"}],"version-history":[{"count":1,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/5765\/revisions"}],"predecessor-version":[{"id":5767,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/5765\/revisions\/5767"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media\/5762"}],"wp:attachment":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media?parent=5765"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/categories?post=5765"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/tags?post=5765"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}