Skip to content

Releases: kadeessh/kadeessh

v0.0.2

20 Sep 21:17
Compare
Choose a tag to compare

This is the first release with the new name of Kadeessh. I will be trying to revive the development. Breaking changes should be expected as I'm trying to improve the function and experience. Goals for the next release:

  • To have friendly user experience for SSH certificates
  • Proper and complete Windows support

As always, feedback is welcome.

Changelog

  • b42b6dc actor_matcher: register MatchGroup type
  • ac88810 actor_matcher: register the MatchExtension and MatchCriticalOption types
  • d890664 authentication: tighten authentication
  • da220e0 bug: pty: do not spread the command slice supplied by the client
  • 1d980ce dep: swap os/user for github.com/tweekmonster/luser for more robust pure-go support
  • fdf5edb feat: implement semantically correct handling of shell/pty sessions across platforms
  • 4b3e639 pam: validate the user's account as part of the authentication flow (thank you, @porcupineyhairs)
  • 36463e0 pty: improve log message
  • 2eb47db pty: shell: ensure pty is closed at the end of the shell handle
  • 5120828 signer: don't error loading ECDSA signer if it doesn't exist
  • 82a18a7 signer: refactor

v0.0.1

28 Mar 14:18
Compare
Choose a tag to compare

The general purpose SSH server build atop Caddy in pure Go is finally here! 🎉 This has been the stress-reliever for so long, and it's finally good to share. Please read the announcement blog post for the rationale behind it and the implementation: Introducing Caddy SSH.

Here is a rundown its features:

  • Extensible core; almost everything is backed by Caddy modules implementing particular interfaces, which empowers the community to build modules to customize the server to their needs
  • The server configuration may be built and customized per session by utilizing the same concept of request matchers of Caddy's HTTP app. The current implementation only provides remote_ip and not matchers due to constraints of x/crypto/ssh, but we hope more connection context parameters are present at configuration time in the future.
  • If you're familiar with handlers from the HTTP app then you will not much out of your comfort zone. Their cousins in ssh app are called actors. There are currently 2 actors: static and shell.
  • If you're heavy user of tunnels, worry not. Forward and reverse tunnels are supported, and they can be protected behind asker modules as their authorization gate. There are currently deny and allow ask-ees.
  • Authorization is not limited to tunnels! While authentication flows can only filter out approved/disallowed groups and users, authorizer modules can use any parameter within the session context or outside of them. The app currently provides the following authorizers: public, reject, max_session, and chained.
  • Signers, aka hostkeys, can be sourced from anywhere if you just use the right module! File-backed hostkeys are commonly known, but what if we fetched them from Hashicorp Vault? Or get them from a microservice that implements custom logic for issuing hostkeys? It's all possible! The currently available implementations are: fallback which will look for existing hostkeys and will generate them if missing (only generates 4096-bit RSA and x25519), and file which is similar to our old friend.

The implementation packages are currently all under internal until the dust settles. Once we are a-ok 👍🏼 with the design and implementation, they will be exported outside of internal.