1
0
Fork 0
mirror of https://we.phorge.it/source/phorge.git synced 2024-12-29 17:00:59 +01:00
phorge-phorge/scripts/ssh/ssh-exec.php

92 lines
2.4 KiB
PHP
Raw Normal View History

Implement SSHD glue and Conduit SSH endpoint Summary: - Build "sshd-auth" (for authentication) and "sshd-exec" (for command execution) binaries. These are callable by "sshd-vcs", located [[https://github.com/epriestley/sshd-vcs | in my account on GitHub]]. They are based on precursors [[https://github.com/epriestley/sshd-vcs-glue | here on GitHub]] which I deployed for TenXer about a year ago, so I have some confidence they at least basically work. - The problem this solves is that normally every user would need an account on a machine to connect to it, and/or their public keys would all need to be listed in `~/.authorized_keys`. This is a big pain in most installs. Software like Gitosis/Gitolite solve this problem by giving you an easy way to add public keys to `~/.authorized_keys`, but this is pretty gross. - Roughly, instead of looking in `~/.authorized_keys` when a user connects, the patched sshd instead runs `echo <public key> | sshd-auth`. The `sshd-auth` script looks up the public key and authorizes the matching user, if they exist. It also forces sshd to run `sshd-exec` instead of a normal shell. - `sshd-exec` receives the authenticated user and any command which was passed to ssh (like `git receive-pack`) and can route them appropriately. - Overall, this permits a single account to be set up on a server which all Phabricator users can connect to without any extra work, and which can safely execute commands and apply appropriate permissions, and disable users when they are disabled in Phabricator and all that stuff. - Build out "sshd-exec" to do more thorough checks and setup, and delegate command execution to Workflows (they now exist, and did not when I originally built this stuff). - Convert @btrahan's conduit API script into a workflow and slightly simplify it (ConduitCall did not exist at the time it was written). The next steps here on the Repository side are to implement Workflows for Git, SVN and HG wire protocols. These will mostly just proxy the protocols, but also need to enforce permissions. So the approach will basically be: - Implement workflows for stuff like `git receive-pack`. - These workflows will implement enough of the underlying protocol to determine what resource the user is trying to access, and whether they want to read or write it. - They'll then do a permissons check, and kick the user out if they don't have permission to do whatever they are trying to do. - If the user does have permission, we just proxy the rest of the transaction. Next steps on the Conduit side are more simple: - Make ConduitClient understand "ssh://" URLs. Test Plan: Ran `sshd-exec --phabricator-ssh-user epriestley conduit differential.query`, etc. This will get a more comprehensive test once I set up sshd-vcs. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T603, T550 Differential Revision: https://secure.phabricator.com/D4229
2012-12-19 20:08:07 +01:00
#!/usr/bin/env php
<?php
$root = dirname(dirname(dirname(__FILE__)));
require_once $root.'/scripts/__init_script__.php';
$original_command = getenv('SSH_ORIGINAL_COMMAND');
$original_argv = id(new PhutilShellLexer())->splitArguments($original_command);
$argv = array_merge($argv, $original_argv);
Implement SSHD glue and Conduit SSH endpoint Summary: - Build "sshd-auth" (for authentication) and "sshd-exec" (for command execution) binaries. These are callable by "sshd-vcs", located [[https://github.com/epriestley/sshd-vcs | in my account on GitHub]]. They are based on precursors [[https://github.com/epriestley/sshd-vcs-glue | here on GitHub]] which I deployed for TenXer about a year ago, so I have some confidence they at least basically work. - The problem this solves is that normally every user would need an account on a machine to connect to it, and/or their public keys would all need to be listed in `~/.authorized_keys`. This is a big pain in most installs. Software like Gitosis/Gitolite solve this problem by giving you an easy way to add public keys to `~/.authorized_keys`, but this is pretty gross. - Roughly, instead of looking in `~/.authorized_keys` when a user connects, the patched sshd instead runs `echo <public key> | sshd-auth`. The `sshd-auth` script looks up the public key and authorizes the matching user, if they exist. It also forces sshd to run `sshd-exec` instead of a normal shell. - `sshd-exec` receives the authenticated user and any command which was passed to ssh (like `git receive-pack`) and can route them appropriately. - Overall, this permits a single account to be set up on a server which all Phabricator users can connect to without any extra work, and which can safely execute commands and apply appropriate permissions, and disable users when they are disabled in Phabricator and all that stuff. - Build out "sshd-exec" to do more thorough checks and setup, and delegate command execution to Workflows (they now exist, and did not when I originally built this stuff). - Convert @btrahan's conduit API script into a workflow and slightly simplify it (ConduitCall did not exist at the time it was written). The next steps here on the Repository side are to implement Workflows for Git, SVN and HG wire protocols. These will mostly just proxy the protocols, but also need to enforce permissions. So the approach will basically be: - Implement workflows for stuff like `git receive-pack`. - These workflows will implement enough of the underlying protocol to determine what resource the user is trying to access, and whether they want to read or write it. - They'll then do a permissons check, and kick the user out if they don't have permission to do whatever they are trying to do. - If the user does have permission, we just proxy the rest of the transaction. Next steps on the Conduit side are more simple: - Make ConduitClient understand "ssh://" URLs. Test Plan: Ran `sshd-exec --phabricator-ssh-user epriestley conduit differential.query`, etc. This will get a more comprehensive test once I set up sshd-vcs. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T603, T550 Differential Revision: https://secure.phabricator.com/D4229
2012-12-19 20:08:07 +01:00
$args = new PhutilArgumentParser($argv);
$args->setTagline('receive SSH requests');
$args->setSynopsis(<<<EOSYNOPSIS
**ssh-exec** --phabricator-ssh-user __user__ __commmand__ [__options__]
Receive SSH requests.
EOSYNOPSIS
);
// NOTE: Do NOT parse standard arguments. Arguments are coming from a remote
// client over SSH, and they should not be able to execute "--xprofile",
// "--recon", etc.
$args->parsePartial(
array(
array(
'name' => 'phabricator-ssh-user',
'param' => 'username',
),
));
try {
$user_name = $args->getArg('phabricator-ssh-user');
if (!strlen($user_name)) {
throw new Exception("No username.");
}
$user = id(new PhabricatorUser())->loadOneWhere(
'userName = %s',
$user_name);
if (!$user) {
throw new Exception("Invalid username.");
}
if ($user->getIsDisabled()) {
throw new Exception("You have been exiled.");
}
$workflows = array(
new ConduitSSHWorkflow(),
);
// This duplicates logic in parseWorkflows(), but allows us to raise more
// concise/relevant exceptions when the client is a remote SSH.
$remain = $args->getUnconsumedArgumentVector();
if (empty($remain)) {
throw new Exception("No interactive logins.");
Implement SSHD glue and Conduit SSH endpoint Summary: - Build "sshd-auth" (for authentication) and "sshd-exec" (for command execution) binaries. These are callable by "sshd-vcs", located [[https://github.com/epriestley/sshd-vcs | in my account on GitHub]]. They are based on precursors [[https://github.com/epriestley/sshd-vcs-glue | here on GitHub]] which I deployed for TenXer about a year ago, so I have some confidence they at least basically work. - The problem this solves is that normally every user would need an account on a machine to connect to it, and/or their public keys would all need to be listed in `~/.authorized_keys`. This is a big pain in most installs. Software like Gitosis/Gitolite solve this problem by giving you an easy way to add public keys to `~/.authorized_keys`, but this is pretty gross. - Roughly, instead of looking in `~/.authorized_keys` when a user connects, the patched sshd instead runs `echo <public key> | sshd-auth`. The `sshd-auth` script looks up the public key and authorizes the matching user, if they exist. It also forces sshd to run `sshd-exec` instead of a normal shell. - `sshd-exec` receives the authenticated user and any command which was passed to ssh (like `git receive-pack`) and can route them appropriately. - Overall, this permits a single account to be set up on a server which all Phabricator users can connect to without any extra work, and which can safely execute commands and apply appropriate permissions, and disable users when they are disabled in Phabricator and all that stuff. - Build out "sshd-exec" to do more thorough checks and setup, and delegate command execution to Workflows (they now exist, and did not when I originally built this stuff). - Convert @btrahan's conduit API script into a workflow and slightly simplify it (ConduitCall did not exist at the time it was written). The next steps here on the Repository side are to implement Workflows for Git, SVN and HG wire protocols. These will mostly just proxy the protocols, but also need to enforce permissions. So the approach will basically be: - Implement workflows for stuff like `git receive-pack`. - These workflows will implement enough of the underlying protocol to determine what resource the user is trying to access, and whether they want to read or write it. - They'll then do a permissons check, and kick the user out if they don't have permission to do whatever they are trying to do. - If the user does have permission, we just proxy the rest of the transaction. Next steps on the Conduit side are more simple: - Make ConduitClient understand "ssh://" URLs. Test Plan: Ran `sshd-exec --phabricator-ssh-user epriestley conduit differential.query`, etc. This will get a more comprehensive test once I set up sshd-vcs. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T603, T550 Differential Revision: https://secure.phabricator.com/D4229
2012-12-19 20:08:07 +01:00
} else {
$command = head($remain);
$workflow_names = mpull($workflows, 'getName', 'getName');
if (empty($workflow_names[$command])) {
throw new Exception("Invalid command.");
}
}
$workflow = $args->parseWorkflows($workflows);
$workflow->setUser($user);
$sock_stdin = fopen('php://stdin', 'r');
if (!$sock_stdin) {
throw new Exception("Unable to open stdin.");
}
$sock_stdout = fopen('php://stdout', 'w');
if (!$sock_stdout) {
throw new Exception("Unable to open stdout.");
}
$socket_channel = new PhutilSocketChannel(
$sock_stdin,
$sock_stdout);
$metrics_channel = new PhutilMetricsChannel($socket_channel);
$workflow->setIOChannel($metrics_channel);
$err = $workflow->execute($args);
$metrics_channel->flush();
} catch (Exception $ex) {
echo "phabricator-ssh-exec: ".$ex->getMessage()."\n";
exit(1);
}