Skip to content

[Feature]: Please Explore the SSH port and ability #365

@hero

Description

@hero

Hi, thanks for this great project! 🙌

I'm using the Docker-based macOS environment and successfully accessed the desktop via VNC (port 5900) and the web UI (port 8006). I also enabled Remote Login (SSH) from within the macOS GUI (System Settings → Sharing → Remote Login).

However, I found that I'm unable to connect via SSH, even with proper port mapping. After checking the Dockerfile and container configuration, it appears that only ports 8006 and 5900 are exposed by default, while SSH uses port 22, which is not currently exposed.

Since SSH access is essential for many development workflows — especially for automation, scripting, remote debugging, and headless operations — I'd like to request that port 22 be exposed by default in the image.

🔧 Suggested Fix:
Add the following line to the Dockerfile:

EXPOSE 22

And update the documentation to suggest mapping it when running the container:

-p 2222:22  # for example

This would allow users to securely access the macOS terminal via SSH, greatly improving the usability of this image for CI/CD, remote development, and scripting scenarios.

Thanks for considering this enhancement! Let me know if you'd like a PR for this change.

Describe the solution you'd like.

I would like the base image to explicitly expose port 22 so that SSH can be used out-of-the-box when users enable Remote Login in macOS.

Specifically:

Add EXPOSE 22 in the Dockerfile to declare the SSH port.
Update the README with an example docker run command that includes -p 2222:22 (or similar) to map the SSH port.
Optionally, document how to set a password and enable Remote Login for SSH to work properly.
This change would allow developers to:

Automate tasks via SSH scripts
Integrate with CI/CD pipelines
Use familiar tools like scp, rsync, or IDEs with remote development support
Operate the macOS instance headlessly without relying on VNC
The impact is minimal (one extra port), but the usability improvement is significant.

Describe alternatives you've considered.

I’ve explored several workarounds:

Manually modifying the Docker run command:

I tried adding -p 2222:22 when starting the container, but since port 22 is not declared with EXPOSE, some tooling and orchestration systems (like Docker Compose without explicit ports) may not handle it as expected. While this can work, it’s not discoverable or user-friendly.
Building a custom image:

I considered forking the repo and building my own version with EXPOSE 22. This works, but it creates maintenance overhead and duplicates effort across users who want the same feature.
Using VNC + Terminal app:

While functional for manual use, this is not scriptable or automatable — it defeats the purpose of having a containerized dev environment.
Reverse tunneling or sidecar containers:

These are overly complex solutions for what should be a simple use case.
Ultimately, exposing port 22 directly in the official image is the cleanest, most standard, and widely expected behavior for any development-oriented container.

Additional context
SSH is fundamental to Unix-like development environments.
Other similar projects (e.g., Linux-based dev containers) almost always expose SSH by default.
The current setup encourages VNC-only interaction, which limits automation potential.
Please consider this enhancement to improve the developer experience. I’d be happy to submit a PR if you’re open to it!

Additional context

No response

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions