How to enable SSH on BusyBox without recompiling BusyBox? - linux

I want to enable SSH service on BusyBox server (currently I can connect only via Telnet), so I think , that I need to compile SSH server , and send it to BusyBox router. So my question is - how to create SSH server binary to send it to BusyBox via FTP?

You're taking a wrong direction.
1/ "How to enable SSH on BusyBox."
You can't.
2/ And "without recompiling BusyBox?"
You won't, because #1.
Because busybox in itself does not provide an SSH server nor client.
Now that your question is answered:
The usual way to add an SSH server to a busybox based system is to add dropbear, first on the list of "tiny utilities whose functionality is not provided by busybox":
https://busybox.net/tinyutils.html
https://matt.ucc.asn.au/dropbear/dropbear.html
How to compile dropbear (because you will have to), then install and run on your system is now another topic, on which no one can help you without further details on your target system or your cross toolchain.

Related

Pass password through jenkins build step

I'm trying to add a build step in jenkins to copy files from my build server to my web application server. I've got the following command working in the command prompt
sudo scp -r /var/lib/jenkins/workspace/demoproj/publish root#0.0.0.0:/usr/temp
but when I run this command, it prompts me for a password every time. I found out about sshpass, but when I run this command...
sudo sshpass -p "passwordhere" scp -r /var/lib/jenkins/workspace/demoproj/pub root#0.0.0.0:/usr/temp
the terminal gets stuck. And never makes it through.
My main problem is if I add the first command to a build step in jenkins, it won't be able to pass the password over. How can I either supply the password in jenkins, or modify the command to pass over my credentials?
Helpful information: I'm using Putty on Windows 10 to connect to my
Ubuntu 16.04.3 LTS x64 servers from another Ubuntu 16.04.3 server.
First, sshpass needs to be installed on both the systems that is, the one running your jenkins instance as well as the one you are trying to access that is: root#0.0.0.0. You can verify it by doing 'which sshpass' or 'whereis sshpass'. If its not installed even in one of them then you need to install it first.
Also, Have you ever tried doing a ssh to the said machine: root#0.0.0.0 from the system where you have your jenkins instance? If not then there might not be an entry in the 'known-hosts' of either system. for that you can do ssh with '-o StrictHostKeyChecking=no' option to make an automatic entry in known-hosts.
Alternatively, if you dont want to enter password again and again you should work with 'keys'. Generate a unique key for both the systems and do an scp or ssh with -i option.
You should use jenkins credentials instead of using sensitive passwords directly into the scripts. Put the whole scp or ssh part inside a block which looks like: withCredentials(){}.
What's the point of having CI if you are required to be nearby to enter password every time? Install "publish over ssh" plugin, it has a step to send stuff over ssh.
https://wiki.jenkins.io/display/JENKINS/Publish+Over+SSH+Plugin
Look at "Use SSH during a build" section, you can use "send files or execute commands over SSH" build step. This shall become available after plugin installation.

SCP error: Bad configuration option: PermitLocalCommand

When I execute this command below:
scp -P 36000 hdfs#192.168.0.114:~/tmp.txt SOQ_log.txt
I get an error:
command-line: line 0: Bad configuration option: PermitLocalCommand
Does anyone know why?
scp runs a copy of the ssh program to create the communications channel, and it runs ssh with the options:
-oForwardAgent=no -oPermitLocalCommand=no -oClearAllForwardings=yes
So that explains where the "PermitLocalCommand" option is coming from in the first place. I'll add that sftp uses the same options to run ssh, so it'll probably display the same behavior.
"PermitLocalCommand" is normally a valid ssh configuration option. If your copy of ssh is complaining about it, then it seems that your copy of ssh isn't the normal copy of ssh that goes with your copy of scp.
This serverfault question suggests that the error could be due to someone installing a malware version of ssh (ie, a rootkit) on your system. This forum thread also suggests that the problem is due to having an altered version of ssh, which was fixed by removing and reinstalling the OpenSSH client utilities.
An alternate explanation would be that someone--maybe your Linux distro maintainer--has installed a version of ssh on your system with that option removed, and you're using it unawares. Or you have a very old version of the ssh program for some reason, which doesn't support the option.
My system is CentOs 5.9
I'm facing the same problem, I found it to be due to this configuration line in /etc/ssh/sshd_config:
# override default of no subsystems
Subsystem sftp /opt/libexec/sftp-server
But I cannot run /opt/libexec/sftp-server, it is broken for some reason
now it is solved by reinstall the remote openssh-server:
yum erase openssh-server
yum install openssh-server
now the changes to
# override default of no subsystems
Subsystem sftp /usr/libexec/openssh/sftp-server
and /usr/libexec/openssh/sftp-server is runnable
don't forget to execute:
/etc/init.d/sshd restart
Sometimes command cannot parse this kind of stuff
:~/
Id change it to the full path.

How to log in into the linux terminal as ROOT user using ruby script

I want to run a script on remote server using SSH.
I have write all the code which runs properly using system command.
To run my code on remote server I need some packages which I need to install on remote server.
To do so I need login into remote terminal as a ROOT user. When I try to do using Ruby script so I get something like following
[not_root_user#remote_server]$ su
Password:
I need some command using which I can able to login into the remote server something like following
[not_root_user#remote_server]$ su -p ******
[root#remote_server]#
Is there any linux command which accepts the password in it?
So you want your script to act as root?
It's not really recommended, but you can use expect: http://en.wikipedia.org/wiki/Expect
The wiki there has a walkthrough for a basic automated telnet session that you could adapt to your needs.
However, you're going to have your root password in plain text, which could be a security issue. If you go that route, I'd definitely obliterate all copies of that script from the universe once this package is installed.
But if you're allowing direct root logins, you've already got a bit of a security problem. Sudo works out-of-the-box on every modern linux distro I've used, I'd stick with that, if possible.
Another option which is equally tasteless would be to set up root-to-root login without a password via ssh.
Sudo would be my first option to getting around this. Although not the best option.
You can also use Key authentication with SSH, and if password authentication is turned off there is no need to enter a password.

Remote development - Edit on Windows & Build on Linux

I am looking for a solution for a remote development environment as follows:
Editor - Windows Source Insight / Visual Studio
Source control - Clearcase
Build server - Linux
The above can't be modified.
In my current setup, I can view and edit the sources on Windows using a Windows Cleacase client.
My problem is mainly the build (and the later on, the debug) process.
I need to invoke 'make' from Windows on a specific Clearcase view on the Linux Server.
I can login in a separate process using SSH to the Linux server and run 'make', but it is a cumbersome procedure.
I am also unable to view the 'make' results and double-lick them to go to the specific warning/errors.
Is there any way to remotely bind a Windows command/batch to a Linux environment?
Perhaps through SSH?
Thank you for any suggestion you might have.
The usual solution is rather a pull strategy (where your build server fetches information on Linux, rather than trying to pilot everything from Windows.
If you follow the SSH path, be aware of technote swg21351507:
Linux SSH connection hangs when attempting to exit after starting ClearCase.
This can affect the use of scripts to start/stop ClearCase remotely using SSH.
Cause
This is a due to a OpenSSH server design, which will not close the console until all process/jobs executed by the user are completed.
Refer to this SSH FAQ for further details, regarding background jobs.
Resolving the problem
Redirect the ClearCase start script to either /dev/null or to a log file.
Example:
/usr/atria/etc/clearcase start < /dev/null >& /dev/null
/usr/atria/etc/clearcase start < /tmp/ccstart >& /tmp/ccstart
Try sshfs. I don't if there is a sshfs client for windows. If not, you can try NFS, or even SAMBA. Those definately work in Windows and Linux.
I just came across this and wanted to answer, even if the original poster has surely resolved their issue. This could be quite easily resolved by installing a jenkins instance on the build machine. You could kick off the build from the web interface and have it pull the files from clearcase and tell you the results.

When SSHing into system, is there a way to launch netbeans from command-line like I do VIM?

VIM seems integrated to the terminal. Can I open a remote file from the command-line with netbeans? Does it have shell integration? Any further explanation on this so I can better conceptually understand it would be very appreciated.
Few options:
Using ssh -X to forward X. Then you
can start netbeans remotely.
Use sshfs so you mount the
remote filesystem locally over ssh.
You can use then local copy of
netbeans to work on remote files.
Using rsync to have a local copy
The best one - use version control
Yes, you can, providing certain conditions are met!
Using ssh, you can tunnel the display of X-Window applications, meaning you can run the application (the X-Client) on one machine, and have it display on another (the X-Server).
You'll need to launch ssh with the -X option (or -Y, but preferably -X) to allow tunnelling, and then run NetBeans from the commandline as usual:
netbeans MyFile.java
Read about X-forwarding. The link points to a very verbose and detailed howto/tutorial.

Resources