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.
Related
I am aware that you can launch docker containers remotely in VSCode. Is it possible to do the same with singularity containers?
Update: the solution to this was published in the same issue (https://github.com/microsoft/vscode-remote-release/issues/3066#issuecomment-1019500216) as before by user oschulz:
As promised, here are some instructions on how to use Singularity with VS-Code Remote SSH via SSH RemoteCommand. The procedure described below makes VS-Code run it’s remote server component inside a Singularity container instance (other runtimes like Shifter work too).
Acknowledgement: Credit for a lot of this goes to #gipert, who refined my original approach (using a custom SSH script) when support for RemoteCommand became available in VS-Code recently
Step 1
Use VS-Code >= v1.64 (includes support for the SSH RemoteCommand setting). Install the Pre-Release version of the Remote SSH extension
Important: In the VS-Code settings, set "remote.SSH.enableRemoteCommand": true.
Step 2
In your "$HOME/.ssh/config", add something like
Host myimage1~*
RemoteCommand singularity shell /path/to/image1.sif
RequestTTY yes
Host myimage2~*
RemoteCommand singularity shell /path/to/image2.sif
RequestTTY yes
Host somehost myimage1~somehost myimage2~somehost
HostName some.host.somewhere
User your_username_
Host otherhost myimage1~otherhost myimage2~otherhost
HostName some.otherhost.somewhere
User your_username_
Test whether this works using ssh myimage1~somehost. This should drop you into an SSH session inside of an instance of the "/path/to/image1.sif" container image on some.host.somewhere.
Connecting to the remote host with VS-Code: F1 > "Connect to Host" > "myimage1~somehost” should now get you a remote VS-Code session running in the container image as well. The same for "myimage2~somehost", "myimage1~otherhost" and "myimage2~otherhost".
Step 3
However, since VS-code reuses remote server instance, that's not sufficient to run multiple container images on the same host at the same time. To get separate (per container) VS-Code server instances the same host, add something like this to your VS-Code preferences:
"remote.SSH.serverInstallPath": {
"myimage1~somehost": "~/.vscode-container/myimage1",
"myimage1~otherhost": "~/.vscode-container/myimage1",
"myimage2~somehost": "~/.vscode-container/myimage2",
"myimage2~otherhost": "~/.vscode-container/myimage2"
}
Request to the VS-Code dev team
Could "remote.SSH.serverInstallPath" be controlled via an environment variable? This would allow us to eliminate all these cumbersome "remote.SSH.serverInstallPath" preferences. The environment variable could be set by a container startup script on the remote side (like the one below) automatically, depending on the selected container image.
Other Container runtimes
To use a different container runtime than Singularity (e.g. Shifter, Charliecloud, etc.), simply replace singularity shell /path/to/image1.sif by the appropriate command for your runtime.
On some systems (e.g. with Shifter at NERSC) you may also need to override $XDG_RUNTIME_DIR, since it's default location may not be writable from within a container instance. In such cases, it's best to use a custom container run-script like
#!/bin/sh
export XDG_RUNTIME_DIR="${TMPDIR:-/tmp}/`whoami`/run"
exec shifter --image="$1"
So in your SSH config, use
RemoteCommand /my/homedir/.local/bin/run_container image_name
I maintain a little container start-script called cenv that handles $XDG_RUNTIME_DIR (and quite a bit more, including some default bind-mounts) automatically for both Singularity and Shifter (contributions welcome).
Tips and tricks
If things don't work, try "Kill server on remote" from VS-Code and reconnect.
You can also try starting over from scratch with brute force: Close the VS-Code remote connection. Then, from an external terminal, kill the remote VS-Code server instance:
$ ssh somehost
$ kill -9 -1
(Will kill all processes you own on the remote host.)
Remove the ~/.vscode-server directory.
Old:
I believe this is still not supported. Refer to this issue: https://github.com/microsoft/vscode-remote-release/issues/3066, and there are also some ideas for potential workarounds in the same link.
I typically use VS Code's Remote-SSH extension to connect to an AWS instance where I do my work. There's a nice section of their documentation about how to do that here. I hate just using the terminal alone because I like the debugger and the ability to open up folders and files for viewing. Until recently I had been SSH-ing from my MacBook Pro (A) to an AWS instance running Ubuntu 18.04.4 LTS (B) without any issues. Now, however, I need to work on a new instance, also Ubuntu 18.04.4 LTS, (C) that I can only SSH into from B, and not from A.
This part of the documentation indicates that I can SSH from A to B and then forward a port to create an SSH tunnel. However, this only allows me to open a terminal into C. However, this doesn't allow me to open folders and files in the Explorer like I want to.
I've followed Qinsheng's instructions here to set up an SSH tunnel and use the Remote-SSH extension's "ProxyJump" functionality My config file looks like this:
Host B
HostName B.mydomain.com
IdentityFile /Users/MyID/.ssh/B_private_key
User me
Host C
HostName C
IdentityFile /Users/MyID/.ssh/C_private_key
ProxyJump B
User me
This works perfectly when I use the terminal on VS Code to run ssh C. Without having to input any password(s) I am taken to C and can perform my work. However, when I try to use the "Remote-SSH: Connect to Host" functionality to SSH into C, using ProxyJump through B and subsequently open a folder/view files there, I get the message "Could not establish connection to 'C'". The stack trace looks like this:
[13:59:48.537] Log Level: 2
[13:59:48.539] remote-ssh#0.51.0
[13:59:48.539] darwin x64
[13:59:48.541] SSH Resolver called for "ssh-remote+C", attempt 1
[13:59:48.541] SSH Resolver called for host: C
[13:59:48.541] Setting up SSH remote "C"
[13:59:48.546] Acquiring local install lock: /var/folders/w2/0w6jys8d34x940rj7f5r20vnh83ht7/T/vscode-remote-ssh-C-install.lock
[13:59:48.590] Looking for existing server data file at /Users/MyID/Library/Application Support/Code/User/globalStorage/ms-vscode-remote.remote-ssh/vscode-ssh-host-v1-91899dcef7b8110878ea59626991a18c8a6a1b3e-0.51.0/data.json
[13:59:48.593] Using commit id "91899dcef7b8110878ea59626991a18c8a6a1b3e" and quality "stable" for server
[13:59:48.595] Install and start server if needed
[13:59:48.599] Checking ssh with "ssh -V"
[13:59:48.629] > OpenSSH_8.1p1, LibreSSL 2.7.3
[13:59:48.632] askpass server listening on /var/folders/w2/0w6jys8d34x940rj7f5r20vnh83ht7/T/vscode-ssh-askpass-c4eabfddec4ae91c1e423a3167dd184d8553da26.sock
[13:59:48.633] Spawning local server with {"ipcHandlePath":"/var/folders/w2/0w6jys8d34x940rj7f5r20vnh83ht7/T/vscode-ssh-askpass-b00842fb08dbbff49678439b1335f105364fd9d5.sock","sshCommand":"ssh","sshArgs":["-v","-T","-D","52911","-o","ConnectTimeout=15","C"],"dataFilePath":"/Users/MyID/Library/Application Support/Code/User/globalStorage/ms-vscode-remote.remote-ssh/vscode-ssh-host-v1-91899dcef7b8110878ea59626991a18c8a6a1b3e-0.51.0/data.json"}
[13:59:48.633] Local server env: {"DISPLAY":"1","ELECTRON_RUN_AS_NODE":"1","SSH_ASKPASS":"/Users/MyID/.vscode/extensions/ms-vscode-remote.remote-ssh-0.51.0/out/local-server/askpass.sh","VSCODE_SSH_ASKPASS_NODE":"/Users/MyID/Desktop/Visual Studio Code.app/Contents/Frameworks/Code Helper (Renderer).app/Contents/MacOS/Code Helper (Renderer)","VSCODE_SSH_ASKPASS_MAIN":"/Users/MyID/.vscode/extensions/ms-vscode-remote.remote-ssh-0.51.0/out/askpass-main.js","VSCODE_SSH_ASKPASS_HANDLE":"/var/folders/w2/0w6jys8d34x940rj7f5r20vnh83ht7/T/vscode-ssh-askpass-c4eabfddec4ae91c1e423a3167dd184d8553da26.sock"}
[13:59:48.635] Spawned 29414
[13:59:48.734] > local-server> Spawned ssh: 29415
[13:59:48.738] stderr> OpenSSH_8.1p1, LibreSSL 2.7.3
[13:59:48.740] stderr> /bin/false: No such file or directory
[13:59:48.740] stderr> kex_exchange_identification: Connection closed by remote host
[13:59:48.741] > local-server> ssh child died, shutting down
[13:59:48.745] Local server exit: 0
[13:59:48.745] Received install output: OpenSSH_8.1p1, LibreSSL 2.7.3
/bin/false: No such file or directory
kex_exchange_identification: Connection closed by remote host
[13:59:48.746] Stopped parsing output early. Remaining text: OpenSSH_8.1p1, LibreSSL 2.7.3/bin/false: No such file or directorykex_exchange_identification: Connection closed by remote host
[13:59:48.746] Failed to parse remote port from server output
[13:59:48.747] Resolver error:
[13:59:48.750] ------
It seems clear to me that the main problem is something trying to access /bin/false as the interpreter. I assume that this is an issue with my MacBook Pro (A). I did notice that when running echo $SHELL on A that it was returning /bin/false, but I ran export SHELL=/bin/bash to change that and followed the suggestions in this post to set VS Code's integrated shell for MacOS to /bin/bash as well. I've checked echo $SHELL on B as well and it is similarly showing /bin/bash too.
My questions are these:
Is what I am trying to accomplish possible?
If it is, what am I doing wrong?/what can I check to help make sure that I can get to the VS Code functionalities that I want?
I figured it out. I had a bunch of /bin/false references in my /etc/passwd file, so I changed those out to /bin/bash and now it works like a charm. :)
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.
I need to somehow run a script which resides on a remote machine running Ubuntu.
SSH or any other connection type that requires complex encryption is not possible.
The client that will connect to the remote machine is only capable of opening a port and sending and receiving strings.
Can anyone tell me how to do this?
Why is your remote Ubuntu machine "not natively capable of SSH". That's nonsense.
But if you want a solution, use expect - it can run ftp/telnet or any other terminal-based application. It can react to different input, and type in a password.
There are python and perl-based packages that also do this.
I just figured how to connect to my webhost with PuTTy .
But how to I connect to my localhost? I put
Servername: localhost
port: 22 (I've tried 80 too)
And it gives me an error "failed to connect"
How do I connect?
If you are using Cygwin on your local host, you can connect to Cygwin's sshd (SSH Daemon).
3 easy commands to install the sshd as a service: (always there when you startup the machine)
$ ssh-host-config -y # enable sshd. "-y" answers yes to all queries.
$ cygrunsrv --start sshd # start it as an autostart Windows service
$ ssh localhost # try to recursively log in via ssh
Taken from: http://nfnaaron.posterous.com/tag/puttycyg#Section2
(The second approach)
=> You get the entire ssh infrastructure: public key authentication, ssh-agent, etc...
Ensure that you have running a SSH server (such as openssh-server) running on localhost and not just a web server (such as apache). Also ensure, that localhost is really mapping to 127.0.0.0/8
The solution in the answer above won't work unless you have installed Cygwin with the OpenSSH package selected - you have to do this manually during the installation process (see option a below).
Depending on the intended purpose of your connection you can try one of the options below, option (b) being much easier to install but lacking the *nix shell capabilities.
a. You can install a Cygwin shell with ssh server, this site (http://ist.uwaterloo.ca/~kscully/CygwinSSHD_W2K3.html) has instructions for Windows Server but they work for other Windows too with may be some of the questions shown in the output on the page not appearing on non-server version of Windows. Also, where it says in the instructions to issue the command:
mount -s --change-cygdrive-prefix /
delete the -s option so that the command is
mount --change-cygdrive-prefix /
(at least this was the case for me on Windows 7).
b. PuTTy site suggests WinSSHD (http://www.bitvise.com/winsshd-download). It's an easy self-installer. Once it's up you have to click onthe StartSSHD link about 1/3rd of the screen down on the first page of the config window. Then you can connect your PuTTy to localhost. However, in my experience, it didn't provide any *nix command support, only the native Windows ones and I couldn't find anything in their user guide on this.
Hope this helps.
Just adding this answer in case anyone is still looking for a solution.
In your hostname (or IP address) section, enter localhost or 127.0.0.1
Leave the port to its default value 22
Click on open
Now a login shell will popup -
Log in as your username, your username is basically what you get when you type whoami in your Terminal.
In the password section, type the password that you use as your system's password.
The above steps should connect localhost with ssh(PuTTY)