Apache License 2.0

项目介绍

kadeessh/kadeessh 是一个托管在 GitHub 上的开源项目,主要使用 Go 编写,采用 Apache License 2.0 许可证,目前获得 564 个 Star、15 次 Fork。

仓库全名
kadeessh/kadeessh
开源许可证
Apache License 2.0
Star 数
564
Fork 数
15
未关闭 Issue
8

README 摘要

Kadeessh This is still under heavy WIP. Kadeessh (formerly Caddy-SSH) is an extensible, modular SSH server built as Caddy app. The project aims to provide an ssh server with safe, modern, and secure defaults. What's Kadeessh? Kadeesh (كديش) is the Levantine Arabic word for hinny, the reciprocal of mule. This name is a hat-tip to the basic components of the project, i.e. Caddy and SSH. Install You start by looking…

完整内容见 GitHub 原始 README 或本页 。

常见问题

kadeessh 用什么语言开发?

主要使用 Go 编写,采用 Apache License 2.0 许可证,目前有 564 个 Star。

kadeessh 可以免费商用吗?

仓库采用 Apache License 2.0 许可证,可免费使用与修改,商业使用请遵守许可证条款(例如保留版权声明与许可声明)。

如何获取 kadeessh 的源码?

可以直接克隆仓库:git clone https://github.com/kadeessh/kadeessh.git,默认分支为 master;安装与运行步骤见仓库 README。

kadeessh 最近还在维护吗?

仓库最近一次更新为 7月19日,当前有 8 个未关闭 Issue;Star 数为 564,可作为社区活跃度的参考。

关于

Kadeessh (formerly Caddy-SSH) is a general-purpose, extensible, modular, memory-safe SSH server built in Go

描述取自 GitHub 官方 API,中文内容由 GitRead 中文社区 编辑团队整理。

简要分析

热度分
603
价值分
343
活跃状态
活跃

语言占比

Dockerfile
Go

Release

README

Kadeessh

This is still under heavy WIP.

Kadeessh (formerly Caddy-SSH) is an extensible, modular SSH server built as Caddy app. The project aims to provide an ssh server with safe, modern, and secure defaults.

What’s Kadeessh?

Kadeesh (كديش) is the Levantine Arabic word for hinny, the reciprocal of mule. This name is a hat-tip to the basic components of the project, i.e. Caddy and SSH.

Install

You start by looking for the binaries in the GitHub Releases page. Download the executable then place it somewhere in your PATH.

The other way is to build the project using xcaddy with the command:

xcaddy build --with github.com/kadeessh/kadeessh[@<version>]

where [@<version>] is optional and <version> may be replaced by the desired version.

Sample Config

Note: The password is test. Once satisfied with the design and implementation, the packages will be extracted outside of internal.

Shell
{
  "apps": {
    "ssh": {
      "grace_period": "2s",
      "servers": {
        "srv0": {
          "address": "tcp/0.0.0.0:2000-2012",
          "pty": {
            "pty": "allow"
          },
          "configs": [
            {
              "config": {
                "loader": "provided",
                "no_client_auth": false,
                "authentication": {
                  "username_password": {
                    "providers": {
                      "static": {
                        "accounts": [
                          {
                            "name": "user1",
                            "password": "JDJhJDE0JDcxOENoL2duS3FuR2VPRUpLa2lVM085Mk40T1JkcHBvQW4ycHU2c0FkMm1qLkhKejhzWG9t"
                          }
                        ]
                      }
                    }
                  }
                }
              }
            }
          ],
          "actors": [
            {
              "match": [
                {
                  "user": {
                    "users": [
                      "user1"
                    ]
                  }
                }
              ],
              "act": {
                "action": "shell"
              }
            }
          ]
        }
      }
    }
  }
}
Custom config based on remote address: allow local users, except root, to login without authentication
{
  "apps": {
    "ssh": {
      "grace_period": "2s",
      "servers": {
        "srv0": {
          "address": "tcp/0.0.0.0:2000-2012",
          "pty": {
            "pty": "allow"
          },
          "configs": [
            {
              "match": [
                {
                  "remote_ip": {
                    "ranges": [
                      "192.168.0.0/16"
                    ]
                  }
                }
              ],
              "config": {
                "loader": "provided",
                "no_client_auth": true
              }
            },
            {
              "config": {
                "loader": "provided",
                "authentication": {
                  "deny_users": ["root"],
                  "public_key": {
                    "providers": {
                      "os": {}
                    }
                  }
                }
              }
            }
          ],
          "actors": [
            {
              "act": {
                "action": "shell"
              }
            }
          ]
        }
      }
    }
  }
}
Jump server

As a jump server, the jump server establishes a local forwarding channel to upstream, per the documentation of the -J option, so we need to enable this in the config.

Reference:

-J destination Connect to the target host by first making a ssh connection to the jump host described by destination and then establishing a TCP forwarding to the ultimate destination from there. Multiple jump hops may be specified separated by comma characters. This is a shortcut to specify a ProxyJump configuration directive. Note that configuration directives supplied on the command-line generally apply to the destination host and not any specified jump hosts. Use ~/.ssh/config to specify configuration for jump hosts.

{
  "apps": {
    "ssh": {
      "grace_period": "2s",
      "servers": {
        "srv0": {
          "address": "tcp/0.0.0.0:2000-2012",
          "configs": [
            {
              "config": {
                "loader": "provided",
                "signer": {
                  "module": "fallback"
                },
                "authentication": {
                  "public_key": {
                    "providers": {
                      "os": {}
                    }
                  }
                }
              }
            }
          ],
          "localforward": {
            "forward": "allow"
          }
        }
      }
    }
  }
}
Shell Session with Authorization Module

The app provides modular authorization process to control the session authorization based on the session context details. One of the authorization modules provided is max_session, which restricts the number of currently active sessions to a certain number. The other one is public, which grants access without restriction and is the default if none is provided. Here’s an example config of how to restrict the server to authorize only 2 active sessions:

{
  "apps": {
    "ssh": {
      "grace_period": "2s",
      "servers": {
        "srv0": {
          "address": "tcp/0.0.0.0:2000-2012",
          "authorize": {
            "authorizer": "max_session",
            "max_sessions": 2
          },
          "pty": {
            "pty": "allow"
          },
          "configs": [
            {
              "config": {
                "loader": "provided",
                "no_client_auth": false,
                "authentication": {
                  "public_key": {
                    "providers": {
                      "os": {}
                    }
                  }
                }
              }
            }
          ],
          "actors": [
            {
              "act": {
                "action": "shell"
              }
            }
          ]
        }
      }
    }
  }
}
Shell with `force_command`

Runs the go version command for authenticated users, regardless of the command the user has sent.

{
  "apps": {
    "ssh": {
      "grace_period": "2s",
      "servers": {
        "srv0": {
          "address": "tcp/0.0.0.0:2000-2012",
          "pty": {
            "pty": "allow"
          },
          "configs": [
            {
              "config": {
                "loader": "provided",
                "no_client_auth": false,
                "authentication": {
                  "public_key": {
                    "providers": {
                      "os": {}
                    }
                  }
                }
              }
            }
          ],
          "actors": [
            {
              "act": {
                "action": "shell",
                "force_command": "go 'version'"
              }
            }
          ]
        }
      }
    }
  }
}

Reference

Questions

Q: I deny PTY allocation in config, but the request is processed and executed anyways. Why?

A: This is a quirk in OpenSSH which defaults to auto if the -t option on the client (i.e. forcing tty allocation). It asks for the tty allocation but switches the mode to auto when denied and proceeds without the tty allocation request. The StackOverflow answer explaining the details is here.

评论

暂无评论