Teller - the open-source universal secret manager for developers

Overview






πŸ’» Never leave your terminal for secrets
πŸ“Ÿ Create easy and clean workflows for working with cloud environments
πŸ”Ž Scan for secrets and fight secret sprawl


Teller - the open-source universal secret manager for developers

Never leave your terminal to use secrets while developing, testing, and building your apps.

Instead of custom scripts, tokens in your .zshrc files, visible EXPORTs in your bash history, misplaced .env.production files and more around your workstation -- just use teller and connect it to any vault, key store, or cloud service you like (Teller support Hashicorp Vault, AWS Secrets Manager, Google Secret Manager, and many more).

You can use Teller to tidy your own environment or for your team as a process and best practice.

Quick Start with teller (or tlr)

You can install teller with homebrew:

$ brew tap spectralops/tap && brew install teller

You can now use teller or tlr (if you like shortcuts!) in your terminal.

teller will pull variables from your various cloud providers, vaults and others, and will populate your current working session (in various ways!, see more below) so you can work safely and much more productively.

teller needs a tellerfile. This is a .teller.yml file that lives in your repo, or one that you point teller to with teller -c your-conf.yml.

Create your configuration

Run teller new and follow the wizard, pick the providers you like and it will generate a .teller.yml for you.

Alternatively, you can use the following minimal template or view a full example:

project: project_name
opts:
  stage: development

# remove if you don't like the prompt
confirm: Are you sure you want to run in {{stage}}?

providers:
  # uses environment vars to configure
  # https://github.com/hashicorp/vault/blob/api/v1.0.4/api/client.go#L28
  hashicorp_vault:
    env_sync:
      path: secret/data/{{stage}}/services/billing

  # this will fuse vars with the below .env file
  # use if you'd like to grab secrets from outside of the project tree
  dotenv:
    env_sync:
      path: ~/billing.env.{{stage}}

Now you can just run processes with:

$ teller run node src/server.js
Service is up.
Loaded configuration: Mailgun, SMTP
Port: 5050

Behind the scenes: teller fetched the correct variables, placed those (and just those) in ENV for the node process to use.

Features

Running subprocesses

Manually exporting and setting up environment variables for running a process with demo-like / production-like set up?

Got bitten by using .env.production and exposing it in the local project itself?

Using teller and a .teller.yml file that exposes nothing to the prying eyes, you can work fluently and seamlessly with zero risk, also no need for quotes:

$ teller run -- your-process arg1 arg2... --switch1 ...

Inspecting variables

This will output the current variables teller picks up. Only first 2 letters will be shown from each, of course.

$ teller show

Local shell population

Hardcoding secrets into your shell scripts and dotfiles?

In some cases it makes sense to eval variables into your current shell. For example in your .zshrc it makes much more sense to use teller, and not hardcode all those into the .zshrc file itself.

In this case, this is what you should add:

eval "$(teller sh)"

Easy Docker environment

Tired of grabbing all kinds of variables, setting those up, and worried about these appearing in your shell history as well?

Use this one liner from now on:

$ docker run --rm -it --env-file <(teller env) alpine sh

Scan for secrets

Teller can help you fight secret sprawl and hard coded secrets, as well as be the best productivity tool for working with your vault.

It can also integrate into your CI and serve as a shift-left security tool for your DevSecOps pipeline.

Look for your vault-kept secrets in your code by running:

$ teller scan

You can run it as a linter in your CI like so:

run: teller scan --silent

It will break your build if it finds something (returns exit code 1).

Use Teller for productively and securely running your processes and you get this for free -- nothing to configure. If you have data that you're bringing that you're sure isn't sensitive, flag it in your teller.yml:

dotenv:
  env:
    FOO:
      path: ~/my-dot-env.env
      severity: none # will skip scanning. possible values: high | medium | low | none

By default we treat all entries as sensitive, with value high.

Redact secrets from process outputs, logs, and files

You can use teller as a redaction tool across your infrastructure, and run processes while redacting their output as well as clean up logs and live tails of logs.

Run a process and redact its output in real time:

$ teller run --redact -- your-process arg1 arg2

Pipe any process output, tail or logs into teller to redact those, live:

$ cat some.log | teller redact

It should also work with tail -f:

$ tail -f /var/log/apache.log | teller redact

Finally, if you've got some files you want to redact, you can do that too:

$ teller --in dirty.csv --out clean.csv

If you omit --in Teller will take stdin, and if you omit --out Teller will output to stdout.

Populate templates

Have a kickstarter project you want to populate quickly with some variables (not secrets though!)?

Have a production project that just has to have a file to read that contains your variables?

You can use teller to inject variables into your own templates (based on go templates).

With this template:

Hello, {{.Teller.EnvByKey "FOO_BAR" "default-value" }}!

Run:

$ teller template my-template.tmpl out.txt

Will get you, assuming FOO_BAR=Spock:

Hello, Spock!

Prompts and options

There are a few options that you can use:

  • carry_env - carry the environment from the parent process into the child process. By default we isolate the child process from the parent process. (default: false)

  • confirm - an interactive question to prompt the user before taking action (such as running a process). (default: empty)

  • opts - a dict for our own variable/setting substitution mechanism. For example:

opts:
  region: env:AWS_REGION
  stage: qa

And now you can use paths like /{{stage}}/{{region}}/billing-svc where ever you want (this templating is available for the confirm question too).

If you prefix a value with env: it will get pulled from your current environment.

Providers

For each provider, there are a few points to understand:

  • Sync - full sync support. Can we provide a path to a whole environment and have it synced (all keys, all values). Some of the providers support this and some don't.
  • Key format - some of the providers expect a path-like key, some env-var like, and some don't care. We'll specify for each.

General provider configuration

We use the following general structure to specify sync mapping for all providers:

# you can use either `env_sync` or `env` or both
env_sync:
  path: ... # path to mapping
  remap:
    PROVIDER_VAR1: VAR3 # Maps PROVIDER_VAR1 to local env var VAR3
env:
  VAR1:
    path: ... # path to value or mapping
    field:  # optional: use if path contains a k/v dict
    decrypt: true | false # optional: use if provider supports encryption at the value side
    severity: high | medium | low | none # optional: used for secret scanning, default is high. 'none' means not a secret 
    redact_with: "**XXX**" # optional: used as a placeholder swapping the secret with it. default is "**REDACTED**"
  VAR2:
    path: ...

Remapping Provider Variables

Providers which support syncing a list of keys and values can be remapped to different environment variable keys. Typically, when teller syncs paths from env_sync, the key returned from the provider is directly mapped to the environment variable key. In some cases it might be necessary to have the provider key mapped to a different variable without changing the provider settings. This can be useful when using env_sync for Hashicorp Vault Dynamic Database credentials:

env_sync:
  path: database/roles/my-role
  remap:
    username: PGUSER
    password: PGPASSWORD

After remapping, the local environment variable PGUSER will contain the provider value for username and PGPASSWORD will contain the provider value for password.

Hashicorp Vault

Authentication

If you have the Vault CLI configured and working, there's no special action to take.

Configuration is environment based, as defined by client standard. See variables here.

Features

  • Sync - yes
  • Mapping - yes
  • Key format - path based, has to start with secret/data/

Example Config

hashicorp_vault:
  env_sync:
    path: secret/data/demo/billing/web/env
  env:
    SMTP_PASS:
      path: secret/data/demo/wordpress
      field: smtp

Consul

Authentication

If you have the Consul CLI working and configured, there's no special action to take.

Configuration is environment based, as defined by client standard. See variables here.

Features

  • Sync - yes
  • Mapping - yes
  • Key format
    • env_sync - path based, we use the last segment as the variable name
    • env - any string, no special requirement

Example Config

consul:
  env_sync:
    path: ops/config
  env:
    SLACK_HOOK:
      path: ops/config/slack

Heroku

Authentication

Requires an API key populated in your environment in: HEROKU_API_KEY (you can fetch it from your ~/.netrc).

Features

  • Sync - yes
  • Mapping - yes
  • Key format
    • env_sync - name of your Heroku app
    • env - the actual env variable name in your Heroku settings

Example Config

heroku:
  env_sync:
    path: my-app-dev
  env:
    MG_KEY:
      path: my-app-dev

Etcd

Authentication

If you have etcdctl already working there's no special action to take.

We follow how etcdctl takes its authentication settings. These environment variables need to be populated

  • ETCDCTL_ENDPOINTS

For TLS:

  • ETCDCTL_CA_FILE
  • ETCDCTL_CERT_FILE
  • ETCDCTL_KEY_FILE

Features

  • Sync - yes
  • Mapping - yes
  • Key format
    • env_sync - path based
    • env - path based

Example Config

etcd:
  env_sync:
    path: /prod/billing-svc
  env:
    MG_KEY:
      path: /prod/billing-svc/vars/mg

AWS Secrets Manager

Authentication

Your standard AWS_DEFAULT_REGION, AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY need to be populated in your environment

Features

  • Sync - yes
  • Mapping - yes
  • Key format
    • env_sync - path based
    • env - path based

Example Config

aws_secretsmanager:
  env_sync:
    path: /prod/billing-svc
  env:
    MG_KEY:
      path: /prod/billing-svc/vars/mg

AWS Paramstore

Authentication

Your standard AWS_DEFAULT_REGION, AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY need to be populated in your environment

Features

  • Sync - no
  • Mapping - yes
  • Key format
    • env - path based
    • decrypt - available in this provider, will use KMS automatically

Example Config

aws_ssm:
  env:
    FOO_BAR:
      path: /prod/billing-svc/vars
      decrypt: true

Google Secret Manager

Authentication

You should populate GOOGLE_APPLICATION_CREDENTIALS=account.json in your environment to your relevant account.json that you get from Google.

Features

  • Sync - no
  • Mapping - yes
  • Key format
    • env - path based, needs to include a version
    • decrypt - available in this provider, will use KMS automatically

Example Config

google_secretmanager:
  env:
    MG_KEY:
      # need to supply the relevant version (versions/1)
      path: projects/44882/secrets/MG_KEY/versions/1

.ENV (dotenv)

Authentication

No need. You'll be pointing to a one or more .env files on your disk.

Features

  • Sync - yes
  • Mapping - yes
  • Key format
    • env - env key like

Example Config

You can mix and match any number of files, sitting anywhere on your drive.

dotenv:
  env_sync:
    path: ~/my-dot-env.env
  env:
    MG_KEY:
      path: ~/my-dot-env.env

Doppler

Authentication

Install the doppler cli then run doppler login. You'll also need to configure your desired "project" for any given directory using doppler configure. Alternatively, you can set a global project by running doppler configure set project from your home directory.

Features

  • Sync - yes
  • Mapping - yes
  • Key format
    • env - env key like

Example Config

doppler:
  env_sync:
    path: prd
  env:
    MG_KEY:
      path: prd
      field: OTHER_MG_KEY # (optional)

Security Model

Project Practices

  • We vendor our dependencies and push them to the repo. This creates an immutable, independent build, that's also free from risks of fetching unknown code in CI/release time.

Providers

For every provider, we are federating all authentication and authorization concern to the system of origin. In other words, if for example you connect to your organization's Hashicorp Vault, we assume you already have a secure way to do that, which is "blessed" by the organization.

In addition, we don't offer any way to specify connection details to these systems in writing (in configuration files or other), and all connection details, to all providers, should be supplied via environment variables.

That allows us to keep two important points:

  1. Don't undermine the user's security model and threat modeling for the sake of productivity (security AND productivity CAN be attained)
  2. Don't encourage the user to do what we're here for -- save secrets and sensitive details from being forgotten in various places.

Thanks:

To all Contributors - you make this happen, thanks!

Copyright

Copyright (c) 2021 @jondot. See LICENSE for further details.

Comments
  • How would you suggest setting secrets?

    How would you suggest setting secrets?

    Hi, this looks like an interesting project and our team is investigating whether it's a good fit for our workflow. We're wondering how you would suggest giving developers access to change secrets though, since this tool seems to only read from the secret stores. When using it, do you give developers direct access to the secret store to update values? Thanks!

    question 
    opened by systemist 21
  • Teller env output multiple formats

    Teller env output multiple formats

    Hi guys! I really like this tool, I just have one concern and that is that it would be great with multiple formats for teller env Some flag to be able to set what shall be outputed.

    F.ex, google cloud functions have a way to set envs via file, but they expect a yml file. You can set via an array, but again, this format only outputs as an .env file.

    Has there been any thoughts around this or exist some undocumented code?

    Some documentation, search for --env-vars-file in https://cloud.google.com/sdk/gcloud/reference/functions/deploy

    opened by vongohren 10
  • Question: hashicorp vault auth

    Question: hashicorp vault auth

    Hi. I've recently discovered your project and fascinated with capabilities it provides. However, there is some things that are not completely clear for me. As you might guessed from a title, I am figuring out how does Teller authenticates against Hashicorp Vault. Readme says:

    if for example you connect to your organization's Hashicorp Vault, we assume you already have a secure way to do that, which is "blessed" by the organization.

    Does this mean that Teller inherits all auth methods Vault provides, or it is up to me how to acquire and feed Teller with VAULT_TOKEN? I am specifically interested in AWS Auth method, since Teller might perfectly fit to my ECS runtime as secret injection tool.

    opened by NikitaGl 10
  • Can't access Vault secrets

    Can't access Vault secrets

    I'll preface this by saying I'm pretty new to Vault in general, and odds are I'm just doing something incorrectly. For some reason Teller is unable to read from my Vault cluster. I've done several different combinations of secret locations to try and get it to read, for example:

    • secret/data/{{stage}}/test/teller
    • secret/data/{{stage}}/test
    • secrets/{{stage}}/test/teller
    • secrets/{{stage}}/test
    • {{stage}}/test/teller
    • {{stage}}/test

    Regardless of what I use I get back the error that data not found at <insert_vault_string>. However, I am able to read it just fine by running the vault kv get developement/test/teller directive. Any insight into what I may be doing wrong here?

    Teller Config:

    project: teller-test
    confirm: Are you sure you want to run on {{stage}}?
    opts:
      region: env:AWS_REGION
      stage: development
    providers:
      hashicorp_vault:
        env_sync:
          path: 'secret/data/{{stage}}/test/teller'
        env:
          TELLER_TEST_SECRET:
            path: '{{stage}}/test'
            field: teller
    

    Screenshot of Vault store:

    image

    Screenshot of terminal call:

    image

    opened by voodooGQ 8
  • filter teller-specific output by default

    filter teller-specific output by default

    Feature Request

    The logging of teller-specific output interferes when you are trying to capture the output if the command being run. Example, I can't pass the output to jq because of the teller output:

    % teller run -- command.sh
    -*- teller: loaded variables for dev-docs using .teller.yml -*-
    { "result": "uuid" }
    
    % teller run -- command.sh | jq -c .result
    <jq parsing error because of teller debug output>
    

    I'd like to be able to control the output of this logging via the --log-level parameter. Logging of this sort could be info level so setting to warn or error would prevent the output.

    An alternative would be to log to stderr so that I can choose the stream to process.

    Kludge solution, pipe output to grep -v "\-\*-", but I'd rather have the output off by default.

    enhancement 
    opened by cnygardtw 7
  • Provider request - parent_process_env

    Provider request - parent_process_env

    New Provider Request

    Instead of carry_env option, we should have a parent_process_env provider. So we can selectively load up parent process env vars as needed. It would also allow renaming the field/variable as needed.

    It's very useful if we need to run a docker container:

    $ docker run --rm -it --env-file <(teller env) alpine sh
    
    // Should also will populate the following for various use-cases:
    $ teller show
    $ teller json
    $ teller yaml
    
    providers:
      parent_process_env:
        env:
          GIT_SHA:
    
    

    Details

    • Name: parent_process_env
    • Modes: read
    new-provider 
    opened by kevbook 6
  • What is the best way to manage environments?

    What is the best way to manage environments?

    I have not found any where I can set environment via cli flag, but I can use seperate files. How are you using this today? Or what is your best practise suggstion on this problem?

    opened by vongohren 6
  • Cloudflare worker secrets Write-only Providers support

    Cloudflare worker secrets Write-only Providers support

    Hello πŸ‘‹ !

    I was having a look though the teller roadmap and see that there are plans for adding "write only" provider support. I think this is an excellent Idea and would be something would be really useful. In particular for our team, adding support for cloudflare workers secrets would be extremely useful for our workflows. I would be happy to contribute a PR for this.

    Has there been any work put into designing/implementing this feature yet?

    Cheers

    new-provider 
    opened by jkirkpatrick24 5
  • Possibility for defaults and not required in the config file

    Possibility for defaults and not required in the config file

    Default value for opts

    I use this alot

      opts:
      #region: env:AWS_REGION    # you can get env variables with the 'env:' prefix
      prefix: env:PREFIX
    

    But it would be great with a way to say that something was default?

    dotenv not required

    I also use this alot

    dotenv:
        env_sync:
          path: ./.env.local
    

    It would be great to have an option to mark this as not required meaning that it does not crash when there is not file found. Because this particular example is only used for local override of config

    enhancement 
    opened by vongohren 5
  • Support hashicorp vault database secrets engine

    Support hashicorp vault database secrets engine

    I think teller may be able to help a use case that I have in fetching hashicorp vault dynamic database secrets. The dynamic database secrets engine creates and returns a username and password for databases. This is useful for security reasons but can be cumbersome when using database clients such as psql or mysql.

    I think teller might be helpful by fetching the dynamic username and password from vault, setting the correct environment variables, and runing the database client. However, the data structure returned by vault is slightly different than the kv data structure.

    The vault kv data structure containing secrets returns a double data.data{} object. Whereas the vault database secrets engine returns data{}.

    If teller supported the database endpoint the following .teller.yml could be used to set the correct environment variables and connect to postgres:

    project: postgres_client
    providers:
      hashicorp_vault:
        env:
          PGUSER:
            path: database/creds/my-role
            field: username
          PGPASSWORD:
            path: database/creds/my-role
            field: password
    

    Then, one could connect to the database using psql:

    teller run psql -h db.example.com -d postgres
    

    I think support could be added to teller by adjusting the double data.data{} assumptions in hashicorp_vault.go#L60 and hashicorp_vault.go#L84.

    Any thoughts on this? I can open a PR if their is interest.

    opened by derektamsen 5
  • GH-134: localstack compatibility for aws providers

    GH-134: localstack compatibility for aws providers

    Related Issues

    #134

    Description

    Add environment variable to allow custom aws endpoint for aws providers to work with localstack

    Motivation and Context

    Allow developers to use services locally that we use for our deployed environments

    How Has This Been Tested?

    Tested against localstack when AWS_ENDPOINT environment variable is set. Tested against live aws when AWS_ENDPOINT environment variable is absent

    Checklist

    • [x] Tests
    • [x] Documentation
    • [x] Linting: make files had issues locally
    opened by JacobJohansen 4
  • Drift Check Only For Secret Keys Not Values

    Drift Check Only For Secret Keys Not Values

    Question

    Is your feature request related to a problem? Please describe. We have a use case to only check for the keys between 2 providers, not their value while checking for the drift. Is it possible right now?

    enhancement 
    opened by mohit-bureau 0
  • Is it possible to define the teller version used for current projects yaml

    Is it possible to define the teller version used for current projects yaml

    Feature Request

    Is your feature request related to a problem? Please describe. I have yamls that are using newest feature, like from 1.5.1. But since we have been using it for a while it might be that developers dont have updated. How can I enforce this for certain projects?

    Describe the solution you'd like A tag or something inside the teller.yml file to say what version this yml file supports so that people know to update when coming across that current project file

    Describe alternatives you've considered None, this is just a question to hear what your thoughts are

    enhancement 
    opened by vongohren 2
  • Add remap_with option

    Add remap_with option

    Related Issues

    https://github.com/tellerops/teller/issues/138

    Description

    Introduces a new setting called remap_with to env_sync, which is similar to remap, but it supports remapping more than just the env name, but rather severity or redact_with as well.

    Usage:

    env_sync:
      path: database/roles/my-role
      remap_with:
        username:
          field: PGUSER
          severity: none
        password:
          field: PGPASSWORD
          severity: high
          redact_with: "**XXX**"
    

    Motivation and Context

    I have a project with about 50 secrets using env_sync, but there's a secret which is a common word, and the severity should be "none", and I believe it's not currently possible to change the severity of specific fields. I would like to use teller scan, but if it means I would have to specify those 50 secrets using env in order to change the severity of just 1 secret, I would rather not use it and preserve env_sync.

    How Has This Been Tested?

    I copied the test for the current remap functionality, and tested it works with the new RemapWith config.

    Checklist

    • [x] Tests
    • [x] Documentation
    • [x] Linting
    opened by danielr18 0
  • Support changing the severity of specific fields with env_sync

    Support changing the severity of specific fields with env_sync

    Feature Request

    I would like to support changing the severity of specific fields with env_sync, in order to improve the usefulness of teller scan.

    Describe alternatives you've considered This can be currently achieved by not using env_sync, but rather env. If you only want to change the severity of a few fields, it means you still have to add all the fields you want to sync.

    enhancement 
    opened by danielr18 2
  • AWS Secrets Manager: error invalid character 'a' looking for beginning of value

    AWS Secrets Manager: error invalid character 'a' looking for beginning of value

    Expected Behavior

    When I run tlr show, my secret from AWS Secrets Manager should be displayed

    Current Behavior

    Error is raised:

    ➜  spg-test git:(spg-test) βœ— AWS_ACCESS_KEY_ID=AKIAXXXXXXXXX AWS_SECRET_ACCESS_KEY=XXXXXXXXXXX AWS_DEFAULT_REGION=us-east-1 tlr show
    FATA[0000] could not load all variables from the given existing providers  error="invalid character 'a' looking for beginning of value"
    

    Possible Solution

    N/A

    Steps to Reproduce

    1. Create config file:
    project: myproject
    
    providers:
      aws_secretsmanager:
        env:
          FOO:
            path: /myapp/mysecret
    
    1. run the command shown previously

    Context

    I triple-checked that

    • my AWS credentials are OK
    • the secret exists in the specified AWS region and account (see screenshot below)

    Screen Shot 2022-09-02 at 11 01 53 AM

    Specifications

    • Version:
    Teller 1.5.4
    Revision 604abece2a4a4ca1e32c6d812f5f0aa0e256548c, date: 2022-08-25T06:19:45Z
    
    • Platform: Mac OS 12.4
    bug 
    opened by spg 1
Releases(v1.5.6)
Owner
Automated Code Security for Modern Teams
null
painless task queue manager for shell commands with an intuitive cli interface (execute shell commands in distributed cloud-native queue manager).

EXEQ DOCS STILL IN PROGRESS. Execute shell commands in queues via cli or http interface. Features Simple intuitive tiny cli app. Modular queue backend

Mohammed Al Ashaal 13 Dec 14, 2022
CLI for Shamir's Secret Sharing and AES key generation, encryption, and decryption.

Shush ?? This simple program will help you run Shamir's Secret Sharing algorithm on any file using the split and merge commands.

null 24 Feb 1, 2022
Procmon is a Linux reimagining of the classic Procmon tool from the Sysinternals suite of tools for Windows. Procmon provides a convenient and efficient way for Linux developers to trace the syscall activity on the system.

Process Monitor for Linux (Preview) Process Monitor (Procmon) is a Linux reimagining of the classic Procmon tool from the Sysinternals suite of tools

Windows Sysinternals 3.5k Dec 29, 2022
sg is the CLI tool that Sourcegraph developers can use to develop Sourcegraph.

sg is the CLI tool that Sourcegraph developers can use to develop Sourcegraph.

Sourcegraph 26 Dec 14, 2022
An open-source GitLab command line tool bringing GitLab's cool features to your command line

GLab is an open source GitLab CLI tool bringing GitLab to your terminal next to where you are already working with git and your code without switching

Clement Sam 2.1k Dec 30, 2022
Upterm is an open-source solution for sharing terminal sessions instantly over the public internet via secure tunnels.

Upterm is an open-source solution for sharing terminal sessions instantly over the public internet via secure tunnels.

Owen Ou 570 Jan 8, 2023
a Go language free and open-source document for learning from zero level

Go document a GO language free and open-source document for learning from zero level Please publish and collaborate OPEN-SOURCE Sections About go lang

Erfan Hanifezade 15 Jan 8, 2023
:zap: boilerplate template manager that generates files or directories from template repositories

Boilr Are you doing the same steps over and over again every time you start a new programming project? Boilr is here to help you create projects from

Tamer Tas 1.5k Jan 6, 2023
The slightly more awesome standard unix password manager for teams

gopass Introduction gopass is a password manager for the command line written in Go. It supports all major operating systems (Linux, MacOS, BSD) as we

Gopass 5k Jan 4, 2023
Command Line Alias Manager and Plugin System - Written in Golang

aly - Command Line Alias Manager and Packager Aly offers the simplest way to manage, share, and obtain command line aliases! Warning: This project is

Max Bridgland 21 Jun 16, 2022
The Todo List / Task Manager for Geeks in command line

The CLI To-Do List / Task Manager for Geeks ??‍?? Developer / DevOps / Sysadmin? A command line hero? ?? Live with the dark terminal? ?? Think in Mark

Anis uddin Ahmad 413 Dec 15, 2022
Secure, private and feature-rich CLI password manager

Kure Kure is a free and open-source password manager for the command-line. This project aims to offer the most secure and private way of operating wit

GastΓ³n Palomeque 125 Nov 17, 2022
file manager on terminal written in Go

ff ff is file manager written in Go. Features preview file/directory copy/paste file make a new file/directory rename a file/directory edit file with

skanehira 75 Nov 18, 2022
GodSpeed is a robust and intuitive manager for reverse shells.

GodSpeed is a robust and intuitive manager for reverse shells. It supports tab-completion, verbose listing of connected hosts and easy interaction with selected shells by passing their corresponding ID.

RedCode Labs 76 Dec 12, 2022
A terminal based file manager

Keep those files organized About The Project A terminal based file manager Built With Go bubbletea bubbles lipgloss Installation go install github.com

Tyler Knipfer 370 Dec 27, 2022
A multiple reverse shell sessions/clients manager via terminal written in go

A multiple reverse shell sessions/clients manager via terminal written in go

Krisna Pranav 11 Nov 9, 2022
Moldy CLI the best project starter and manager of the world

You don't know how to start your project ... you want to help other people know your tool or language. Use Moldy! the best helper to start your project

Moldy Community 25 Oct 17, 2022
Bucket-ssh. A fuzzy ssh manager for managing and categorizing ssh connections.

Bssh is an ssh bucket for categorizing and automating ssh connections. Also, with parallel command execution and connection checks(pings) over categories (namespaces).

Furkan Aksoy 17 Oct 25, 2022
Declarative CLI Version manager. Support Lazy Install and Sharable configuration mechanism named Registry. Switch versions seamlessly

aqua Declarative CLI Version manager. Support Lazy Install and Sharable configuration mechanism named Registry. Switch versions seamlessly. Index Slid

Shunsuke Suzuki 250 Dec 29, 2022