Implement bssh-server with SFTP/SCP support

## Goals

This issue aims to implement a Rust-based SSH server that eliminates complex deployment dependencies of openssh-server while including full sftp and scp functionality, deployable as a single static binary like dropbear for container environments.

Since we have already implemented SSH/SFTP/SCP client functionality in this project, we will reference the related code and background knowledge, use common implementations where possible, and add content appropriately for the server context.

---

## Architecture Design

### Project Structure

```
bssh/
├── src/
│   ├── bin/
│   │   ├── bssh.rs           # Existing client binary (unchanged)
│   │   ├── bssh_server.rs    # New server binary entry point
│   │   └── bssh_keygen.rs    # New key generation tool
│   │
│   ├── server/               # New server module
│   │   ├── mod.rs
│   │   ├── handler.rs        # SSH server handler (russh::server::Handler)
│   │   ├── sftp.rs           # SFTP server (russh_sftp::server)
│   │   ├── scp.rs            # SCP protocol server
│   │   ├── session.rs        # Session management
│   │   │
│   │   ├── auth/             # Server authentication
│   │   │   ├── mod.rs
│   │   │   ├── password.rs   # Password verification
│   │   │   ├── publickey.rs  # Public key verification
│   │   │   └── provider.rs   # Extensible auth provider trait
│   │   │
│   │   ├── config/           # Server configuration
│   │   │   ├── mod.rs
│   │   │   ├── types.rs      # Server config types
│   │   │   └── loader.rs     # YAML/CLI config loader
│   │   │
│   │   ├── audit/            # Audit logging subsystem
│   │   │   ├── mod.rs
│   │   │   ├── event.rs      # Audit event types
│   │   │   ├── exporter.rs   # Exporter trait
│   │   │   ├── file.rs       # File exporter (JSON Lines)
│   │   │   ├── otel.rs       # OpenTelemetry exporter
│   │   │   └── logstash.rs   # Logstash exporter
│   │   │
│   │   ├── filter/           # File transfer filtering
│   │   │   ├── mod.rs
│   │   │   ├── policy.rs     # Filter policy engine
│   │   │   ├── path.rs       # Path-based filters
│   │   │   └── pattern.rs    # Pattern-based filters
│   │   │
│   │   └── security/         # Server security features
│   │       ├── mod.rs
│   │       ├── rate_limit.rs # Auth attempt rate limiting
│   │       └── access.rs     # IP-based access control
│   │
│   ├── keygen/               # Key generation module
│   │   ├── mod.rs
│   │   ├── ed25519.rs
│   │   └── rsa.rs
│   │
│   └── shared/               # Client/Server shared code
│       ├── mod.rs
│       └── ... (extracted from existing modules)
```

### Code Reuse Strategy

#### Directly Reusable (No Changes)
| Module | Purpose | Location |
|--------|---------|----------|
| Logging system | tracing-based structured logging | `src/utils/logging.rs` |
| File utilities | glob, walk, format | `src/utils/fs.rs` |
| Buffer pool | Memory-efficient buffer management | `src/utils/buffer_pool.rs` |
| Input validation | Username, hostname, path validation | `src/security/validation.rs` |
| Rate limiter | Token bucket algorithm | `src/jump/rate_limiter.rs` |

#### Partially Reusable (Extend/Modify)
| Module | Reusable Part | Modifications Needed |
|--------|---------------|---------------------|
| `ssh/tokio_client/authentication.rs` | AuthMethod, ServerCheckMethod types | Add server auth verification logic |
| `ssh/tokio_client/error.rs` | Error type structure | Add server-specific errors |
| `config/types.rs` | Config structure patterns | Add server config types |
| `ssh/auth.rs` | Input validation, timing attack mitigation | Adapt for server context |

#### New Development Required
- SSH server handler (`russh::server::Handler`)
- SFTP server handler (`russh_sftp::server::Handler`)
- SCP protocol implementation
- Server authentication verification
- Audit logging with exporters
- File transfer filtering engine
- Key generation tool

### Key Traits (Extensibility)

```rust
/// Extensible authentication provider
#[async_trait]
pub trait AuthProvider: Send + Sync {
    async fn verify_password(&self, user: &str, password: &str) -> Result<bool>;
    async fn verify_publickey(&self, user: &str, key: &PublicKey) -> Result<bool>;
    async fn get_user_info(&self, user: &str) -> Result<Option<UserInfo>>;
}

/// Extensible audit exporter
#[async_trait]
pub trait AuditExporter: Send + Sync {
    async fn export(&self, event: AuditEvent) -> Result<()>;
    async fn flush(&self) -> Result<()>;
}

/// Extensible file transfer filter
pub trait TransferFilter: Send + Sync {
    fn check(&self, path: &Path, operation: Operation, user: &str) -> FilterResult;
}
```

---

## Key Features and Design

- Full compatibility with OpenSSH client
- Full compatibility with bssh client from this project
- Built-in SFTP and SCP server functionality
- Detailed audit logging for files transferred via SFTP and SCP
- Interface and settings to stream audit logs to external log collectors such as otel or logstash (generalized structure to add new log collectors in the future)
- Security feature to deny file transfers based on specific paths or filename patterns according to filtering policy settings (generalized structure to easily add filtering logic in the future)
- Authentication methods initially support only password and public key (generalized structure to add Kerberos authentication in the future)
- Remove distribution-dependent features like PAM or nsswitch as much as possible and design to describe only minimal necessary content in configuration files
- Design to inject options for user environment such as login shell via configuration files considering container environment
- Design to allow main configuration options via CLI arguments (for container provisioner implementation convenience)
- Arbitrary SSH keypair generation in OpenSSH key format via separate keygen executable (ed25519, rsa methods)
- Basic server security features like fail2ban included with related option settings

---

## Implementation Phases

### Phase 0: Project Structure
- [ ] #124 - Create shared module structure for client/server code reuse

### Phase 1: Core SSH Server
- [ ] #125 - Implement basic SSH server handler with russh
- [ ] #126 - Implement public key authentication for server
- [ ] #127 - Implement password authentication for server
- [ ] #128 - Implement command execution handler
- [ ] #129 - Implement PTY/shell session support
- [ ] #130 - Create server configuration system
- [ ] #131 - Create server CLI interface (bssh-server binary)

> **Note**: After Phase 1 implementation, PR #154 was required to fix PTY shell output issues and publish the bssh-russh crate. This work was necessary to support high-frequency PTY operations for interactive shell sessions.

### Phase 2: File Transfer
- [ ] #132 - Implement SFTP server handler
- [ ] #133 - Implement SCP server protocol

### Phase 3: Audit Logging
- [ ] #134 - Design and implement audit event types and logging infrastructure
- [ ] #135 - Implement file-based audit exporter (JSON Lines)
- [ ] #136 - Implement OpenTelemetry audit exporter
- [ ] #137 - Implement Logstash audit exporter

### Phase 4: File Transfer Filtering
- [ ] #138 - Implement file transfer filtering infrastructure
- [ ] #139 - Implement path-based and pattern-based filter rules

### Phase 5: Security Features
- [ ] #140 - Implement authentication rate limiting (fail2ban-like)
- [ ] #141 - Implement IP-based access control
- [ ] #142 - Implement session management and limits

### Phase 6: Key Generation
- [ ] #143 - Implement bssh-keygen tool

### Phase 7: Documentation
- [ ] #144 - Create server configuration manual and manpages

---

## Build Artifacts

- `bssh-server` executable
- `bssh-keygen` executable
- Configuration manual markdown file and manpage file including options provided by each executable

---

## Configuration Example

```yaml
# bssh-server.yaml
server:
  bind_address: "0.0.0.0"
  port: 22
  host_keys:
    - /etc/bssh/ssh_host_ed25519_key
    - /etc/bssh/ssh_host_rsa_key

auth:
  methods:
    - publickey
    - password
  password_file: /etc/bssh/users.yaml
  authorized_keys_dir: /etc/bssh/authorized_keys/

shell:
  default: /bin/sh
  env:
    PATH: /usr/local/bin:/usr/bin:/bin

sftp:
  enabled: true

scp:
  enabled: true

filter:
  enabled: true
  rules:
    - pattern: "*.key"
      action: deny
    - path_prefix: "/etc/shadow"
      action: deny

audit:
  enabled: true
  exporters:
    - type: file
      path: /var/log/bssh/audit.jsonl
    - type: otel
      endpoint: http://localhost:4317

security:
  max_auth_attempts: 5
  ban_time: 300
  max_sessions_per_user: 10
  allowed_ips:
    - 10.0.0.0/8
    - 192.168.0.0/16
```

---

## Dependencies

Current russh ecosystem fully supports server implementation:
- `russh = "0.56.0"` - SSH client/server library
- `russh-sftp = "2.1.1"` - SFTP client/server library
- `russh-keys` - Key management

No additional major dependencies required for basic implementation.

---

## Development Path Analysis

### Dependency Chains

The following diagram shows the dependency relationships between issues:

```
Chain A (Foundation → Core Server):
#124 → #125 → #126 → #128 → #129
         ↓
       #127

Chain B (Configuration):
#124 → #130 → #131

Chain C (File Transfer):
#125 → #132 → #133
         ↓
       #134

Chain D (Audit System):
#124 → #134 → #135
         ↓
       #136
         ↓
       #137

Chain E (Filtering):
#124 → #138 → #139

Chain F (Security):
#124 → #140
#130 → #141
#125 → #142

Chain G (Key Generation):
#124 → #143

Chain H (Documentation):
All features → #144
```

### Parallel Development Schedule

| Stage | Issues | Prerequisites | Can Run In Parallel |
|-------|--------|---------------|---------------------|
| **Stage 1** | #124 | None | Single issue (foundation) |
| **Stage 2** | #125, #130, #134, #138, #140, #143 | #124 | All 6 issues can run in parallel |
| **Stage 3** | #126, #127, #131, #132, #135, #136, #137, #139, #141 | Stage 2 respective deps | Multiple parallel tracks |
| **Stage 4** | #128, #133, #142 | Stage 3 respective deps | 3 issues can run in parallel |
| **Stage 5** | #129 | #128 | Single issue |
| **Stage 6** | #144 | All previous | Documentation (final) |

### Parallel Development Groups

**Group 1 - Foundation (Sequential):**
```
#124 (shared module) - Must complete first
```

**Group 2 - After #124 (6 parallel tracks):**
```
Track A: #125 (SSH handler)
Track B: #130 (config system)
Track C: #134 (audit infra)
Track D: #138 (filter infra)
Track E: #140 (rate limiting)
Track F: #143 (keygen)
```

**Group 3 - After respective dependencies:**
```
After #125: #126, #127, #132, #142 (parallel)
After #130: #131, #141 (parallel)
After #134: #135, #136, #137 (parallel)
After #138: #139
```

**Group 4 - After Group 3:**
```
After #126: #128
After #132: #133
```

**Group 5 - Final implementation:**
```
After #128: #129 (PTY support)
```

**Group 6 - Documentation:**
```
After all: #144
```

### MVP Critical Path

For a Minimum Viable Product (basic SSH server with SFTP), the critical path is:

```
#124 → #125 → #126 → #128 → #130 → #131 → #132
```

This sequence delivers:
1. Shared module structure (#124)
2. Basic SSH server handler (#125)
3. Public key authentication (#126)
4. Command execution (#128)
5. Configuration system (#130)
6. CLI binary (#131)
7. SFTP support (#132)

### Recommended Team Assignment

For a team of 3 developers:

| Developer | Primary Track | Issues |
|-----------|--------------|--------|
| Dev 1 | Core SSH | #124 → #125 → #126 → #127 → #128 → #129 |
| Dev 2 | Config + Security | #130 → #131 → #140 → #141 → #142 |
| Dev 3 | File Transfer + Audit | #132 → #133 → #134 → #135 → #136 → #137 |

The filtering (#138, #139), keygen (#143), and documentation (#144) can be picked up by any developer as they complete their primary track.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Implement bssh-server with SFTP/SCP support #123

Goals

Architecture Design

Project Structure

Code Reuse Strategy

Directly Reusable (No Changes)

Partially Reusable (Extend/Modify)

New Development Required

Key Traits (Extensibility)

Key Features and Design

Implementation Phases

Phase 0: Project Structure

Phase 1: Core SSH Server

Phase 2: File Transfer

Phase 3: Audit Logging

Phase 4: File Transfer Filtering

Phase 5: Security Features

Phase 6: Key Generation

Phase 7: Documentation

Build Artifacts

Configuration Example

Dependencies

Development Path Analysis

Dependency Chains

Parallel Development Schedule

Parallel Development Groups

MVP Critical Path

Recommended Team Assignment

Sub-issues

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Module	Purpose	Location
Logging system	tracing-based structured logging	`src/utils/logging.rs`
File utilities	glob, walk, format	`src/utils/fs.rs`
Buffer pool	Memory-efficient buffer management	`src/utils/buffer_pool.rs`
Input validation	Username, hostname, path validation	`src/security/validation.rs`
Rate limiter	Token bucket algorithm	`src/jump/rate_limiter.rs`

Module	Reusable Part	Modifications Needed
`ssh/tokio_client/authentication.rs`	AuthMethod, ServerCheckMethod types	Add server auth verification logic
`ssh/tokio_client/error.rs`	Error type structure	Add server-specific errors
`config/types.rs`	Config structure patterns	Add server config types
`ssh/auth.rs`	Input validation, timing attack mitigation	Adapt for server context

Stage	Issues	Prerequisites	Can Run In Parallel
Stage 1	#124	None	Single issue (foundation)
Stage 2	#125, #130, #134, #138, #140, #143	#124	All 6 issues can run in parallel
Stage 3	#126, #127, #131, #132, #135, #136, #137, #139, #141	Stage 2 respective deps	Multiple parallel tracks
Stage 4	#128, #133, #142	Stage 3 respective deps	3 issues can run in parallel
Stage 5	#129	#128	Single issue
Stage 6	#144	All previous	Documentation (final)

Developer	Primary Track	Issues
Dev 1	Core SSH	#124 → #125 → #126 → #127 → #128 → #129
Dev 2	Config + Security	#130 → #131 → #140 → #141 → #142
Dev 3	File Transfer + Audit	#132 → #133 → #134 → #135 → #136 → #137

Implement bssh-server with SFTP/SCP support #123

Description

Goals

Architecture Design

Project Structure

Code Reuse Strategy

Directly Reusable (No Changes)

Partially Reusable (Extend/Modify)

New Development Required

Key Traits (Extensibility)

Key Features and Design

Implementation Phases

Phase 0: Project Structure

Phase 1: Core SSH Server

Phase 2: File Transfer

Phase 3: Audit Logging

Phase 4: File Transfer Filtering

Phase 5: Security Features

Phase 6: Key Generation

Phase 7: Documentation

Build Artifacts

Configuration Example

Dependencies

Development Path Analysis

Dependency Chains

Parallel Development Schedule

Parallel Development Groups

MVP Critical Path

Recommended Team Assignment

Sub-issues

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions