Releases: kadeessh/kadeessh
Releases · kadeessh/kadeessh
v0.0.2
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
andMatchCriticalOption
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
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
andnot
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 inssh
app are calledactors
. There are currently 2 actors:static
andshell
. - 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 currentlydeny
andallow
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
, andchained
. - 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), andfile
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
.