Quick Start
How to become an SSH Team champion in no time
1. Register your Domain
Your first step is registering for your unique ssh.team domain. Start the sign-up wizard by clicking on the button below. At the end of the wizard, you will have immediate access to your SSH Key Management portal.
2. Install kdeploy on your Desktop
Log in to your new domain and download the kdeploy installer from the Dashboard. This will help you provision your first account; it deploys the key scripts required for integration with your ssh.team domain.
IMPORTANT: Choose the download for the operating system you are currently using; the key scripts are deployed remotely to supported servers over SSH from your Desktop via the command line program kdeploy.
Run the installer for your platform. Once installed, you should have the kdeploy program in your PATH and can invoke it from a terminal or command console.
3. Copy your Authentication Key
From the main navigation menu, choose Configuration->Options
From the options, select Key Server Configuration
Copy the value of the Authentication Key field and keep this safe. You will pass this to kdeploy when provisioning an account. This key is used to authenticate access to the listings of your authorized keys and for provisioning new accounts.
4. Upload or generate an SSH key
When deploying the key scripts, you can see that the integration works by providing an SSH key for testing. We recommend generating a new key for this purpose.
From the main navigation menu, choose Home->Authorized Keys
Then under the empty table listing, click Generate Key.
Complete the form providing a name for the key, choose the key algorithm and provide a passphrase.
Click Generate to complete.
The key should download automatically; if it does not, click Download.
A zip file will be downloaded. Open the zip file containing two files; the .pub extension can identify the public key. The private key has no extension and will have the same name you gave when generating the key.
You will notice that the public key is now listed in your Authorized Keys table.
IMPORTANT: SSH Key Management for Teams does not store private keys in our service or database. Private keys are the end-users responsibility and must be kept safe and secure on the computers they use SSH from.
5. Provision an account
You are now ready to use kdeploy to provision an account for SSH Key Management. You only need to register the accounts you want to use with the key server, but you must use a privileged account to deploy the scripts, either the root account or an account that can sudo to perform privileged operations.
You can use password or public-key authentication to connect to the server you are deploying to.
Understanding the role of the kdeploy program.
kdeploy helps you set up an account to use the authorized keys stored on your ssh.team domain. It connects via SSH to the server, installing some helper scripts/programs and configuring the server for key server integration. This may vary depending on the server type and version. Some servers will not support direct integration, so cronjob (or task scheduler on Windows) will be used to schedule regular synchronization with the server.
In addition to configuring key server integration, kdeploy provides the option to automatically harden the remote SSH server by removing the ability to log in with a password.
Once you have used kdeploy on a server, you should not need to use it again. You and your users will use your standard SSH clients to connect to the SSH server using the keys you have uploaded or generated on your ssh.team domain.
Executing kdeploy
Below is an example of the simplest command line needed to provision root or a privileged account.
<HOST> is the hostname of the SSH server you are provisioning
<USER> is either root or the username of a privileged account you are using to install and will also provision key server access to.
<AUTHKEY> is the Authentication Key you made a copy of earlier.
<KEYSERVER> is your unique ssh.team domain name.
<TESTKEY> is the path to the private key you created earlier
kdeploy -h <HOST> -u <USER> -k <AUTHKEY> -t <TESTKEY> <KEYSERVER>
Example:
kdeploy -h 10.0.200.30 -u lee -k PhAJZysqtndJhOkB -t Testing\ Key jadaptive.ssh.team
Command output
Executing the example command with no other parameters results in the following output as the program connects and sets up the server.
Connecting to lee@10.0.200.30:22
Password:
Downloading latest configuration from jadaptive.ssh.team
Looking up OS information
Remote OS is debian 10
Cleaning any previous key server scripts
Uploading helper program
Installing helper program
Linking commands to /usr/local/bin/
Removing installer
Configuring sshd with AuthorizedKeysCommand
Reading /etc/ssh/sshd_config
Saving /tmp/sshd_config
Moving to /etc/ssh/sshd_config
Completed configuration change
Restarting SSHD
Authorizing account lee for remote assignment
Script deployment complete
Testing authentication with user lee
Test authentication succeeded
Key server integration completed
Some of the key points to note here
“Downloading latest configuration from <ssh.team>”
kdeploy has a configuration file which may be regularly updated to support a wider base of operating systems versions. To save you from having to maintain this yourself, the kdeploy program downloads this automatically.
“Configuring sshd with AuthorizedKeysCommand”
The server will use the OpenSSH AuthoriszedKeysCommand for key server integration. This is the best possible solution and is preferred over scheduled tasks. If you want to force the use of scheduled tasks, use the -S switch at the command line.
“Saving /tmp/sshd_config”
The sshd_config is being updated. If you want to backup the sshd_config before any changes, use the -B switch, and you can also require kdeploy to output the changed sshd_config for your approval by using -C.
“Authorizing account lee for remote assignment”
kdeploy is setting up the account “lee” for remote key assignment. This involves registering the account with your ssh.team domain. As Administrator, you will receive email notification of the assignment. Administrators are assigned to all accounts and cannot be removed.
You can authorize other accounts on the server simultaneously by providing a list of usernames at the end of the kdeploy command after the <KEYSERVER> parameter.
If you want to provision other accounts and not the account being used to connect and set up the integration, use the -N switch to disable provisioning of the connecting account.
“Testing authentication with user <user>”
kdeploy is testing key server integration using the test key you supplied on the command line.
Other options
There are additional switches available
-P will reconfigure the sshd_config to disable password authentication after a successful test. To avoid the lockout of your server, this option will only be used if test authentication is completed.
-R will configure the PermitRootLogin appropriately if you use -P but not -R it will set this to “without-password” but with -R passed, it will set the value to “no”, preventing the root user from logging in. However, you cannot use this switch if you connected using the root user and have not used -N to disable provisioning of the connecting account.
6. Assigning users
You have now deployed the key server scripts to your server and provisioned access to at least one account on that server.
Head back to your ssh.team portal and navigate to Resources->SSH Accounts
This will show you the table of SSH accounts that have been provisioned.
Any user assigned to this resource will have access to the SSH server via the account name registered with ssh.team. If you have not already created other users, you can do this under Security->Users
Once you have a user to assign, edit the SSH Account you want to assign to them. In the Users tab, start typing the user’s name in the Users field. A menu will pop up with matching users; select the user you want to assign to the account. Then click Save.
Assuming this user has uploaded or generated Authorized Keys in their account, their keys will be included in the authorized keys listing. If the server uses scheduled tasks to synchronize, there will be a delay of up to one hour before the user can access the account; if it uses the AuthorizedKeysCommand directive, then access is immediate.
If you set an email address for the user, they will be notified of the assignment.
7. You are a champion
You have now completed your first account provisioning and assignment. Future assignments will now be a breeze, and you can start to build your Key Management infrastructure.