At the moment I'm trying to use node-sftp in order to provide my nodejs script with the ability to SFTP with a private key.
That module appears to be broken since v 0.6 of node (tty.open is no longer a method).
So i've tried to use a child process and spawn my sftp command.
Now the connection appears to work fine (I checked the ftp servers logs # /var/log/auth.log)
I can also see some output in the Node window...
Permanently added '46.x.x.x' (RSA) to the list of known hosts.
Connected to 46.x.x.x.
Changing to: /home/deploy/somefolder
When I connect directly via the command line using the following command it ends up with a prompt like sftp>, which is waiting for my FTP commands
sftp -o Port=22 -o PasswordAuthentication=no -o IdentityFile=private_key -o UserKnownHostsFile=/v/null -o StrictHostKeyChecking=no -o BatchMode=yes deploy#46.x.x.x:/home/deploy/somefolder
Does anyone have any suggestions on where I might be going wrong?
Its hard to say without a little more detail, but I would take a look at:
https://github.com/chjj/pty.js/
This will emulate a tty device that you can read and write to.
If you can provide some additional code you have tried, we may be able to point you in a better direction.
You could also try cloning the node-sftp module from: https://github.com/ajaxorg/node-sftp.git and using the library directly instead of from npm, it looks like the latest version in github has support for node versions newer that 0.6
Related
Background
I have a command-line application that I use to connect to a remote device on port 1234. I cannot change the port number, and I do not have access to the source to rebuild this tool. I'm currently working in a lab where all ports except SSH are blocked. To get around this, I create a tunnel, i.e.:
ssh -L 1234:remotehost:1234 sshuser#remotehost
Now, I can just point my CLI program at localhost:1234 to connect with my CLI tool to the desired host.
Problem
This CLI tool needs to run for about an hour straight, and I have about 200 remote hosts to test with it. I would like to parallelize this task. Unfortunately, I can only create a single tunnel on my local machine using port 1234.
Question
Is there a (trivial/simple/automated) way to jail/sandbox my CLI tool so that I can launch 100 instances in parallel (i.e. via a shell script) so that each instance "thinks" it's talking to port 1234? For example, does Docker or KVM provide some sort of anonymous/on-demand compute node feature that I could setup rapidly? I'd rather not have to resort to manually deploying and managing a slew of VirtulBox hosts via vagrant.
The simple answer is that you can use multiple IP addresses locally. Each local IP address on the client will allow you to create another tunnel. Currently, you are using localhost. But your client also has an IP address. You can prove my point by trying this syntax:
ssh -f -N -L 127.0.0.1:1234:remotehost1:1234 sshuser#remotehost1 # this is default
ssh -f -N -L <local-IP1>:1234:remotehost2:1234 sshuser#remotehost2 # specifying non-default value <local-IP1>
Now, you just need to figure out how to give your client multiple IP addresses (secondary addresses). Then you can expand this beyond 2 parallel sessions.
I've also added -f and -N to your ssh syntax to put ssh into the background (-f) and to not issue any commands.
Using -R tunnels in the past, I've found that I need to enable GatewayPorts on the server (/etc/ssh/sshd_config). In the case of -L , I don't see the need. However, the ssh man-page explicitly mentioned GatewayPorts associated with the -L function. You may need to play around a bit. I just tried this out on my Mac and I was able to get it going without any GatewayPorts considerations.
To work remotely I need to SSH into the main server and then again into the departmental server.
I would like to set up a tunnel using sublime text 3 wbond sftp package to view and edit files remotely but I can't seem to find any information for setting up a tunnel. Is this even possible?
The reason I'm interested in this particular package is because I am unable to install any packages locally on the server, hence using something like rsub is not possible.
Any other suggestions besides sublime sftp are welcome.
I'm not sure the SFTP plugin would allow to do this directly.
What i would suggest is for you to use ssh -L to create a tunnel.
ssh -L localhost:random_unused_port:target_server:22 username_for_middle_server#middle_server -nNT
Use the password/identity_file for the middle server
The -nNT is to avoid opening an interactive shell in the middle server.
IMPORTANT: You need to keep the ssh -L command running so keep that shell open.
In this way you can connect to the target_server as such:
ssh username_for_target_server#localhost -p random_port_you_allocated
Similarly you can setup the SFTP plugin file as such
{
...
"host":"localhost",
"user":"username_for_target_server",
"ssh_key_file": "path_to_target_server_key",
"port":"random_port_you_allocated",
....
}
As a sidenote, always use the same port to tunnel to the same server, otherwise, with the default ssh configuration, you will be warned of a "Man in the middle attack" because the signature saved in the .ssh/known_hosts will not match with the previous one. This can be avoided by disabling this feature but I wouldn't recommend it.
I have been using shelljs to execute certain set of commands. So i tried to connect to a remote ubuntu server over ssh via shelljs.
This is my nodejs file.
var shelljs = require('shelljs');
shelljs.exec('ssh -i [path/to/pem/file] ubuntu#[taregt_ip]');
But i get this error:
Pseudo-terminal will not be allocated because stdin is not a terminal.
So how to solve this issue or is there any other utility to connect to ssh with one single command.
EDIT: the link you guys are posting for me to refer in not the duplicate of my problem.
SSH doesn't always allocate a pseudo-terminal. That is explained in this existing answer. You should add the -tt flag to force this.
That said, I wouldn't use shelljs to do ssh. As you are just executing a local binary, this solution a) is not portable and b) will not know how to parse errors or deal with unexpected output. I have used ssh2 in the past for similar projects, as it has an interactive SSH option, which makes it easy to create streams (STDOUT and STDIN) from an SSH connection.
I've been working on a file server product that uses smbcilent to transfer files between client computers and the server. It's been working great so far with our LAMP (Ubuntu) server and Windows machines.
I'm currently trying to expand the setup to include Mac's, but am having trouble with the server accessing the share on the Mac.
Here's my command and error (bracketed descriptions replace private info):
# smbclient //10.101.0.7/[share-file] -U [username]%[password] -c ls
WARNING: The "syslog" option is deprecated
NTLMSSP packet check failed due to short signature (0 bytes)!
NTLMSSP NTLM2 packet check failed due to invalid signature!
session setup failed: NT_STATUS_ACCESS_DENIED
Things I've tried:
✓ Accessing share using a Windows machine to ensure the share is setup properly - check! Works fine there.
✓ Invoking -S off or --signing=off in the command - no change.
✓ Just looking at the shares first using smbclient -L 10.101.0.7 -U [username]%[password] - same error.
✓ Googling for an answer - check! Several people with similar problems, but no working solutions so far.
The most promising thing I've see so far involves compiling smbclient 4.4 from sources and running that with no authentication (-U ""%""), but that seems like a temporary solution based on a bug rather than a solid plan that will work for a long time. (But I'll try that next if I can't find any better ideas...)
Thanks for reading and trying to help!
Try adding --option="ntlmssp_client:force_old_spnego = yes" to the smbclient command as suggested on the samba-technical mailing list.
For me, this now lists shares on a Mac OSX server:
smbclient -U$user%$password -L $mac_host --option="ntlmssp_client:force_old_spnego = yes"
For mounting, you may need to add the nounix,sec=ntlmssp options as in
sudo mount -t cifs //$mac_host/$share $mountpoint -o nounix,sec=ntlmssp,username=$user,password=$password
On recent versions of MacOS (e.g. Monterey) it is necessary to do several configuration steps to enable smb access from Linux:
Open System Preferences.
Select Sharing.
Select File Sharing.
Ensure that the directory is listed in Shared Folders.
Right-click/two-finger click on the share directory.
Click on Advanced Options
Ensure Only allow SMB encrypted connections is checked.
Click OK
Click on Options
Click on the checkbox for Share files and folders using SMB.
Under Windows File Sharing ensure the appropriate user is checked.
Type the user's password in the 'Authenticate' dialog bo and press 'OK'.
Click 'Done'.
You should now be able to connect from Linux to the MacOS share using the commands given by #mivk.
I have to remotely connect to a gateway(working on Linux platform), inside which I have couple of executable files (signingModule.sh and taxModule.sh).
Now I want to write one script in my desktop which will connect to that gateway and run signingModule.sh and taxModule.sh in two different terminals.
I have written below code:
ssh root#10.138.77.150 #to connect to gateway
sleep 5
cd /opt/swfiscal/signingModule #path of both modules
./signingModule #executable.
But through this code I am able to connect my gateway but after connecting to gateway nothing is happening.
2nd code:
source configPath # file where i have given path of both the modules
cd $FCM_SCRIPTS # variable in which i have stored the path of modules
ssh root#10.138.77.150 'sh -' < startSigningModule** #to connect and run one module.
as an output of this i am getting:
-source: configPath: file not found
Please help me working this out. Thanks in advance.
Notes:
I can copy paste my files in that gateway if required.
Gnome-Terminal or any other alternatives of this is not working in my gateway
ssh root#10.138.77.150 "cd /opt/swfiscal/signingModule && ./signingModule"
Line source configPath doesn't work because you need specify full path to the file.
You can pass several commands to ssh to run them in sequence; but I prefer a different solution: I have whole scripts locally; and running them remotely means:
Using scp to copy my script to the remote system
Using ssh to then run the script on the remote system
The big advantage here: there is always a potential for getting things wrong (for example: quoting) when directly giving commands to ssh. But when you put everything into a script, you have exact/full control over what is going to happen. You can put things like "set -e" into your script to improve error handling ...
(and of course, you can also automate the two steps listed above!)