Does anybody know how to start sshd automatically on the BeagleBone Black ? I've replaced dropbear with OpenSSH. The standard systemctl enable sshd doesn't work, but strangely systemctl start sshd does. I'm quite new to systems with systemd replacing init, so hopefully I'm not just missing something trivial / simple. The BeagleBone Black in question is running Angstrom Linux and is using the opkg package manager. OpenSSH was installed with opkg install openssh. When I run systemctl enable sshd#.service, I get the following message:
The unit files have no [Install] section. They are not meant to be enabled
using systemctl.
Possible reasons for having this kind of units are:
1) A unit may be statically enabled by being symlinked from another unit's
.wants/ or .requires/ directory.
2) A unit's purpose may be to act as a helper for some other unit which has
a requirement dependency on it.
3) A unit may be started when needed via activation (socket, path, timer,
D-Bus, udev, scripted systemctl call, ...).
The version I have installed is OpenSSH_6.0p1, OpenSSL 1.0.1e 11 Feb 2013
Apparently systemd has both an sshd.service unit and an sshd.socket unit, that are intended to be used mutually exclusively of each other. The sshd daemon should be started and connected automatically by systemd every time an outside process connects to port 22.
Related
Original Post
I have a Windows workstation with WSL2 and Docker installed that I am able to use for container based development in VS Code. I would like to be able to develop inside the containers on this system remotely. I am able to SSH directly into the WSL2 environment on the workstation and am able to start the docker daemon without logging directly into Windows by creating a Task to start the daemon automatically as described here: https://stackoverflow.com/a/59467740/10692741
However when I try to access Docker on the remote machine by following this guide: https://code.visualstudio.com/docs/remote/containers-advanced#_developing-inside-a-container-on-a-remote-docker-host, I get the following error:
error during connect: Get http://docker/v1.24/version: net/http: HTTP/1.x transport connection broken: malformed HTTP status code "\x00c\x00o\x00m\x00m\x00a\x00n\x00d\x00"
I have also tried connecting via a SSH tunnel as outlined here: https://code.visualstudio.com/docs/remote/troubleshooting#_using-an-ssh-tunnel-to-connect-to-a-remote-docker-host and am unable to connect to Docker as well.
Has anyone had success with a setup like this? Or is this not supported due to limitations with Docker on Windows, WSL2, and/or Windows OpenSSH implementation?
Update: 2021-01-21
When I SSH into the Windows machine remotely, I am able to see the docker containers in the VS Code extension. I am able to start them, stop them, and enter into them with the shell. However, when I try to attach VS Code I get same error shown above.
Things that may have possibly affected this over the past couple days:
Adding SSH keys on my local machine to the ssh-agent via ssh-add /my/key
Exposing Docker daemon on tcp://localhost:2375 without TLS on the remote Windows machine
Also I want to note that the I've tried using Windows, Mac, and Linux as the local machine. With Mac and Linux I am able to open a remote session into the Windows machine, but from the Windows local machine I am able to SSH into the remote Windows machine but cannot open a remote connection in VS Code for some reason.
Ok, I was able to get this working using the port/socket forwarding technique. For sake of clarity, I'll use:
local development workstation, local workstation, or just workstation to indicate the computer from which we wish to use VSCode to access Docker containers on ...
the remote Docker host, remote, or just Docker host
Sanity check -- Do you have Docker Desktop installed on both systems? On the local development workstation, you can skip the WSL2 integration, but you'll at least need the client tools, since the VSCode extension uses them.
Steps I took:
I already had Docker with WSL2 integration set up on my main system (which for the purposes of this exercise, became my remote Docker host), along with VSCode, so I knew everything was working there. It sounds like that was your starting point as well.
On another system on the same network (accessed with RDP to make it simple), I already had VSCode installed as well, with the Remote Development Extension Pack. I also have WSL on that system, but only a v1 instance there. Not that WSL on the workstation should be a factor at all for the purposes of this exercise.
I installed Docker Desktop for Windows on that local development workstation.
I also installed the Docker extension for VSCode, since I didn't yet have it on the local development workstation.
On the workstation, I was not yet set up to SSH from PowerShell into my WSL Ubuntu distro on the remote. From PowerShell on the workstation, I generated an ECDSA key (per this and other documents) and added the public key to my authorized_keys on the the remote.
On the workstation, I started the OpenSSH Authentication Service and added the newly created key to the agent (in PowerShell) with ssh-agent add ~\.ssh\id_ecdsa.
I logged out of the workstation and back in so that the path changes were picked up for the Docker desktop install.
I was then able to ssh from Powershell on the local to Ubuntu/WSL on the remote with the port forwarding. Since I'm using the Windows 10 OpenSSH server as a jumphost to my WSL SSH servers, my command looked slightly different (with a -o "ProxyCommand ... mainly), but overall the structure is the same as the one listed in the "SSH Tunnel" doc you linked in your question.
On the remote (manually, not through any integration from the local), I did a basic docker run -it --rm Ubuntu and left it open.
On the local, from PowerShell, I set the DOCKER_HOST environment variable via [System.Environment]::SetEnvironmentVariable("DOCKER_HOST","tcp://localhost:23750").
I was then able to see the remote container using docker ps on the local. I could also docker exec -it containername bash into it remotely.
Of course, the above two steps aren't needed in the long term for VSCode, they were just part of my process to make sure everything was up and running (since, as you might expect, I did have several points at which I failed during this process).
So with that working, it was a simple matter in VSCode to change the Docker extension's DOCKER_HOST setting to tcp://localhost:23750. And voila, I could see all images on the remote as well as attach to them from VSCode.
Other thing(s) to check
I'll add to this list if we find additional reasons why it might not be working, but for now:
You mention that you are starting the Docker Desktop daemon automatically at startup via Task Manager, but you don't mention anything about the WSL2 instance. However, since you are able to ssh into it, I assume you have a way to bring it up as well? My experience has been that, unless the owning user is logged in, WSL terminates any instances after a few seconds, even if a service is running. There's a workaround, I believe, that I can dust off if this is a problem.
I am trying to get the yuma123 open source implementation of a NETCONF Server running on an embedded Linux system.
The NETCONF Server uses sshd, and yuma123 appears to assume that it is the openssh implementation of sshd as it uses the /etc/ssh/sshd_config file.
In particular, the README file in yuma123 states:
Tell sshd to listen on port 830. Add the following 2 lines to /etc/ssh/sshd_config:
Port 830
Subsystem netconf "/usr/sbin/netconf-subsystem --ncxserversockname=830#/tmp/ncxserver.sock"
However, the embedded system currently uses the dropbear cut-down implementation of sshd due to memory constraints, and I am having difficulty getting openssh (together at the same time with yuma123) installed on the embedded system due to the size of the executables, dependant libraries etc.
Can I get/amend the dropbear sshd to give me similar functionality? Can I cut-down the openssh sshd drastically to a small enough size? Any (other) suggestions on a good way forward to resolve this?
According to the dropbear source code, the only subsystem built into the dropbear SSH server is optional support for SFTP, which I'll describe below.
Supporting another subsystem requires making source code changes to dropbear. If that's an option, the code at issue is in the function sessioncommand() in the file svr-chansession.c:
#if DROPBEAR_SFTPSERVER
if ((cmdlen == 4) && strncmp(chansess->cmd, "sftp", 4) == 0) {
m_free(chansess->cmd);
chansess->cmd = m_strdup(SFTPSERVER_PATH);
} else
#endif
{
m_free(chansess->cmd);
return DROPBEAR_FAILURE;
}
Basically, you'd add some code similar to the "sftp" section which checks for your subsystem name and invokes the desired command.
If you don't want to build a custom version of dropbear, then you might be able to make do with a forced command. There are two ways to do this.
If the users of this subsystem will be authenticating with an SSH key, then you could put a "command" directive in the user's authorized_keys file:
command="/usr/sbin/netconf-subsystem..." ssh-rsa AAAAB3NzaC1yc2...
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
When a client authenticates with the key from this line in the file, then any command, shell or subsystem request from the client will cause dropbear to invoke the listed command instead of the command requested by the client. This is an OpenSSH server feature that's also supported by dropbear.
Alternately, dropbear has a command-line option -c which lets you specify a forced command for all clients:
dropbear -p 830 ... -c '/usr/sbin/netconf-subsystem ...'
Dropbear will invoke the specified command for any client connecting to this dropbear instance. If you want to permit clients to do other things besides running that command, you'd have to run two instances of dropbear, listening on different ports or addresses.
SFTP Subsystem support:
I'll describe this because doesn't seem to be well documented.
If dropbear is compiled with the option DROPBEAR_SFTPSERVER, then dropbear will invoke the command "/usr/libexec/sftp-server" for clients requesting the "sftp" subsystem. For that to work, the administrator would normally build a copy of the OpenSSH sftp-server program from the OpenSSH source code, and install the resulting program as /usr/libexec/sftp-server.
Changing dropbear to run a different command requires altering the dropbear source code and recompiling dropbear.
I wanted to start the docker daemon with an open TCP address like this: docker daemon -H tcp://0.0.0.0:2375, but the terminal suggested that I use dockerd instead, which is apparently not a program that comes with the Docker Client for mac. Is there a way I can either
A - get some form of dockerd on my mac machine.
B - get around the use of dockerd by some other method.
?
Install socat command: brew install socat
Choose a port: (in the example 8099)
Run: socat -d -d TCP-L:8099,fork UNIX:/var/run/docker.sock
and then use tcp://localhost:8099 as API URL
works for me, hope this helps
Finally I found the config of mac docker like dockerd.
Click the docker icon in the menu bar, preferences, advanced
get around the use of dockerd by some other method. (2016)
Note that in 2022, you can go without dockerd/Docker Desktop entirely.
See Batuhan Apaydin's article "A modern toolkit to start working with container images on macOS that meets your needs without requiring a Docker Daemon or even Docker Desktop".
It uses lima+nerdctl
The nerdctl tool is designed as a drop-in replacement for the Docker client
And Lima is a hypervisor that launches Linux virtual machines with automatic file sharing, port forwarding, and containerd.
The name of lima comes from an abbreviation of the first two capital letters of LInux MAchines.
The design of Lima is similar to WSL2, but Lima focuses on macOS as the primary target host.
Lima uses QEMU, which is a generic and open source machine emulator and virtualizer, as a hypervisor under the hood to achieve the virtualization thing.
Lima can also work with other container engines such as Podman and even for non-container applications.
By default, when lima launches a VM, it runs buildkitd and containerd in a rootless way and also downloads necessary client tooling around them such as buildctl, nerdctl.
Everything will be set up for us. So, all that’s left is building, pulling, and running containers
For buildkit, Batuhan proposes developer-guy/buildkit-machine
buildkit-machine allows you to make buildkitd daemon accessible in your macOS environment.
To do so, it uses lima, which is a Linux subsystem for macOS, under the hood.
lima spins up a VM that runs buildkitd daemon in a rootless way which means that sock file of the buildkitd daemon is now be able to accessible from /run/user/<USERID>/buildkit/buildkitd.
So: no more Docker Desktop / dockerd, and use container in a rootless mode!
For more, see Bret Fisher's video "Free Docker Desktop Alternatives: DevOps and Docker Live Show (Ep 156)" (Jan. 2022)
I have found a workaround for this in the official forum
https://forums.docker.com/t/using-pycharm-docker-plugin-with-docker-beta/8617/9
$socat TCP-LISTEN:2376,reuseaddr,fork UNIX-CLIENT:/var/run/docker.sock
That workaround opens port 2376 to the world... as TLS isn't enabled, this is a bad idea as anyone on the same network can hijack your docker daemon
It is not supported to run dockerd on Mac. From this issue:
I think on Darwin it should never suggest to run dockerd. The daemon runs in a Linux virtual machine, so you do not need to (and cannot) run it manually.
If you want to do any specific configuration on mac, you might have already installed Docker Desktop. Docker desktop supports configuration using UserInterface shown below in the screenshot.
I have a java application running as a service on Debian. How to I make sure this service is restarted after the system reboots?
You can start with the documentation here
Debian makes use of System V-style init scripts for daemon management. This allows daemons to operate conditionally, based on the current RunLevel of the computer. For example, a daemon can be configured to run only when the computer is in single-user mode (runlevel 1) or, more commonly, when in multi-user mode (runlevels 2-5). For more information, see Init and RunLevel.
Installed Webmin successfully on a Debian system.
Created a virtual server, added some users and a domain.
Installed ProFTPD via Webmin's unused modules.
Added a new user with same named group via System -> Users and Groups.
Tried to connect via ftp using my server's external ip and my new user's credentials.
This should work according to most tutorials but it doesn't.
I'm suspecting some other service handles FTP requests before ProFTPD.
Is there a way to monitor protocol handlers? Could it be something else?
Thanks in advance.
because webmin try start it as deamon, but maybe (like me on archlinux) you need to start it as system service... on root:
systemctl start proftpd.service
If you want to look at the logs error (if there is errors, but if server is not start, it should ne have error...) then use:
journalctl -xe command (as root), or
systemctl --failed , or
systemctl status proftpd.service (all of these commands under root user or sudoers users).
So first of all, check that service is running:
systemctl status
then check the config file of webmin service for proftpd use the correct protocol for call service (systemd for example), and then use correct sentence code for start/stop it. Check also it goes to look at the correct config file of proftpd current install place (depend of your distribution or the way you install it).
proftpd is not installed by webmin, proftpd is installed, then from webmin, you install a module who has to communicate with allready installed application proftpd. If this module is well configured for point on actual proftpd installation and correct call of service, then all will have to works.
(please, if this answer help you, do up vote for my answer, without notation when i help, i can not help more because i'm locked by the system, hope you understand)
Have a look at the server's log, check le ProFTP daemon status, check the firewall