Related
When I try downloading a file from my server onto my computer, it actually downloads the file onto the server.
(Note I am already SSH'd into my server before typing this command. I've watched tutorials on YouTube and people are using their terminal without SSHing into any particular server, however I don't think I can do this with PuTTY on Windows?)
scp -r -P2222 kwazy#mywebsite.example:/home2/kwazy/www/utrecht-connected.nl ~/Desktop/
The problem is that I am specifying the location to download the file as only ~/Desktop/
This creates a folder called Desktop in my server, instead of copying the files onto my local desktop.
I am able to use this command on Linux.
I have successfully download the folder onto my desktop:
I still need insight onto how I can do this on a Windows machine.
There's no way to initiate a file transfer back to/from local Windows from a SSH session opened in PuTTY window.
Though PuTTY supports connection-sharing.
While you still need to run a compatible file transfer client (pscp or psftp), no new login is required, it automatically (if enabled) makes use of an existing PuTTY session.
To enable the sharing see:
Sharing an SSH connection between PuTTY tools.
Even without connection-sharing, you can still use the psftp or pscp from Windows command line.
See How to use PSCP to copy file from Unix machine to Windows machine ...?
Note that the scp is OpenSSH program. It's primarily *nix program, but you can run it via Windows Subsystem for Linux or get a Windows build from Win32-OpenSSH (it is already built-in in the recent versions of Windows 10 and in Windows 11).
If you really want to download the files to a local desktop, you have to specify a target path as %USERPROFILE%\Desktop (what typically resolves to a path like C:\Users\username\Desktop).
Alternative way is to use WinSCP, a GUI SFTP/SCP client. While you browse the remote site, you can anytime open SSH terminal to the same site using Open in PuTTY command.
See Opening Session in PuTTY.
With an additional setup, you can even make PuTTY automatically navigate to the same directory you are browsing with WinSCP.
See Opening PuTTY in the same directory.
(I'm the author of WinSCP)
try this scp -r -P2222 kwazy#mywebsite.example:/home2/kwazy/www/utrecht-connected.nl /Desktop
Another easier option if you're going to be pulling files left and right is to just use an SFTP client like WinSCP. Then you're not typing out 100 characters every time you want to pull something, just drag and drop.
Just noticed /Desktop probably isn't where you're looking to download the file to. Should be something like C:\Users\you\Desktop
OpenSSH has been added to Windows as of autumn 2018, and is included in Windows 10 and Windows Server 2019.
So you can use it in command prompt or power shell like bellow.
C:\Users\Parsa>scp parsa#192.168.100.11:/etc/cassandra/cassandra.yaml F:\Temporary
parsa#192.168.100.11's password:
cassandra.yaml 100% 66KB 71.3KB/s 00:00
C:\Users\Parsa>
(I know this question is pretty old now but this can be helpful for newcomers to this question)
if you install git with git bash, you get SCP available on windows.
You can use WinSCP : https://winscp.net/eng/download.php
Or MobaXterm : https://mobaxterm.mobatek.net/download.html
It feels like FTP client. Also I don't remember setting up anything on my machine for this. It just fresh install and install SSH server (IDK if it matters though).
For MobaXterm :
If your server have a http service you can compress your directory and download the compressed file.
Compress:
tar -zcvf archive-name.tar.gz -C directory-name .
Download throught your browser:
http://the-server-ip/archive-name.tar.gz
If you don't have direct access to the server ip, do a ssh tunnel throught putty, and forward the 80 port in some local port, and you can download the file.
You can use the WinSPC program. Its access to any server is pretty easy. The program gives its guide too. I hope it's helpfull.
If you need something with GUI you can use FileZilla. it support SFTP.
It's perfectly working with ssh and you can even edit files and it will automatically upload the changes.
I have a Perl script which maps two drives, and then proceeds to copy files one of the drives to the other. The Perl script is located on a Windows box, but we are SSHing from a Linux box into the Windows box to execute the script. When I run the script directly from the Windows box, everything works without issue, the drives are mapped and the files are copied over successfully. When I attempt to execute the script from my Linux box via SSH, the script fails and I get the following output:
The local device name is already in use.
Error mapping source \\xxx.xxx.net\localdirectory
This error occurs when attempting to map the first drive, I don't know if it would fail on the second drive as well since it has not made it that far.
I have several other Perl scripts that are executed this same way (via ssh from Linux to Windows box) and they execute without issue, this is the only one that maps a drive though. This is the code I am using to execute the script:
#!/bin/sh
ssh -t -t user#server "cd /Path/to/Perl/Script; /cygdrive/C/Perl/bin/perl.exe Script.pl"
What user is your ssh daemon running as? Presumably System. That user doesn't have authority to map network drives, as far as I recall. Can you not just do this on the Linux box directly using samba?
In case anyone needs this in the future, we we're able to get it working. The issue was due to the SVCCopSSH being used for the CopSSH service on our Windows machine. We had to disable the CopSSH service, set the Log On as the network account we were using to SSH from Linux to Windows, and restart the service. This fixed all issues we were having.
I am attempting to install PostgreSQL 9 (postgresql-9.0.3-1-windows.exe) on my WinXP machine and get the following error at the start:
Some googling around yielded some advice that suggested Windows Scripting Host might be disabled. I've checked and WSH is definitely enabled, so it must be something else. Question is, what?
I can see a file called prerun_checks.vbs is created in %TEMP% and when I try to run this manually, I get the following:
Which looks like a permissions error. However, I am an Admin, and I've given myself full control of the temp folder and it's still not working.
Any help appreciated.
In my case the solution was related to NotePad++ being the default application for opening .vbs files. If you have the same situation, here's an elaborate solution:
http://igordcard.blogspot.co.il/2012/03/unable-to-write-inside-temp-environment.html
In a nutshell, in the registry, you need to go to HKEY_CLASSES_ROOT\.vbs, and set the (Default) entry back to the string VBSFile.
This is a an old thread, but I just had the same problem on windows 10:
Unable to write inside TEMP environment path
Solve by the following steps
Check that the problem is related to Windows Script Host.
From cmd run wscript.exe
If you get an error Windows Script Host is not enabled then you can solved it by running the following from cmd
Fix for Current User
REG DELETE "HKCU\SOFTWARE\Microsoft\Windows Script Host\Settings" /v Enabled /f
Fix for Local Machine
REG DELETE "HKLM\SOFTWARE\Microsoft\Windows Script Host\Settings" /v Enabled /f
Now you can install psql
As I was finishing off my question above, our IT chap turned up and knew what the problem was immediately: it's McAfee. It prevents anything from running in a TEMP folder, including Windows Scripting Host scripts. Disabling McAfee for the duration of the installation fixed the problem for me.
So if you see this problem, try disabling your anti-virus.
The answer in the following page helpped me.
http://forums.enterprisedb.com/posts/list/3040.page
run-> regedit and take backup of registry using export
HKEY_LOCAL_MACHINE->SOFTWARE->Classes->CLSID->B54F3741-5B07-11cf-A4B0-00AA004A55E8} -> InprocServer32
Modify registry entry with new value as C:\Windows\System32\vbscript.dll
In fact, I found there are 3 entries of HKEY_LOCAL_MACHINE->SOFTWARE->Classes->CLSID->B54F3741-5B07-11cf-A4B0-00AA004A55E8}, and set the first one as above, it works.
If anyone else is searching for information on this and doesn't have any luck here, you might want to look at:
http://wiki.postgresql.org/wiki/Troubleshooting_Installation
For follow-ups to the mailing list please read:
http://wiki.postgresql.org/wiki/Guide_to_reporting_problems
Well, in my case nothing worked, and disabling McAffee needed a special ticket with my company's security team to actually do... so I installed using the binaries, by following this guide Helpful Guide.
In summary, download the binary from here, unzip it, go inside the pgsql folder, create log and data directories in there, and then open a command prompt, navigate to where the pgsql\bin folder is, and run initdb -U postgres -A password -E utf8 -W -D POSTGRESQL_ROOT\data
You can start and stop the server by running
"POSTGRESQL_ROOT/bin/pg_ctl" -D "POSTGRESQL_ROOT/data" -l "POSTGRESQL_ROOT/log/pgsql.log" start
and
"POSTGRESQL_ROOT/bin/pg_ctl" -D "POSTGRESQL_ROOT/data" -l "POSTGRESQL_ROOT/log/pgsql.log" stop
where POSTGRESQL_ROOT is the full path to the pgsql folder.
All the above did not work for me. I was getting an error like:
Script output:
CScript Error: Windows Script Host access is disabled on this machine. Contact your administrator for details.
so after a couple of googling i found the solution:
Navigate to the following key:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows Script Host\Settings
In the right panel, you will see Enabled. If you see the entry 0, it means that the Windows Script Host access is disabled on your Windows machine.
Double Click on it and give it Value Data 1 to enable it.
A value of 1 will enable Windows Script Host
A value of 0 will disable Windows Script Host.
for windows 10 navigate to
HKEY_CURRENT_USER\Software\Microsoft\Windows Script Host\Settings
To prevent further problems you should also exclude the data directory (where Postgres puts its data) from being scanned by your virus-scanner
In my case it was another application that caused the problem. Not Notepad++. To others who encounter this problem, you can diagnose it by first deleting all files in C:\Documents and Settings\UserName\Local Settings\Temp so that you'll be able to find the bitrock_installer.log easily when you try installing postgresql again and view the instructions in it. Changing the (Default) key in the HKEY_CLASSES_ROOT, .vbs section of the registry to VBSFile solved it.
I had this issue when trying to install the 32 bit version on Windows 7 64 bit.
Trying the install kit for 64 bit presented no errors, but the solutions presented by others are also valid.
In my case I've downloded McAfee removal tool
MCPR (McAfee Consumer Product Removal)
which cleaned up some tailings after McAfee uninstallation.
Some registry entries which previously had InprocServer32 values like 'c:\program files\common files\mcafee\systemcore\...' changed back to its original values:
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{B54F3741-5B07-11cf-A4B0-00AA004A55E8}\InprocServer32\(default) = vbscript.dll
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Wow6432Node\CLSID\{B54F3741-5B07-11cf-A4B0-00AA004A55E8}\InprocServer32\(default) = C:\Windows\SysWow64\vbscript.dll
After that I successfully installed PostgreSQL 9.3
it happens when Notepad++ associates .vbs file types.
you can open notepad++ -> Preferences -> fileAssociation
Remove the .vbs from the registered exts.
Close the notepad++. Try installing Postgres again.
In my case Changing the (Default) key in the HKEY_CLASSES_ROOT, .vbs section of the registry to VBSFile solved it. BlueFish is grab .vbs file association.
In the temp directory, my bitrock_installer.log file had the following:
Executing cscript //NoLogo "C:\Users\MyUser\Local
Settings\postgresql_installer_1b4eec8be6\prerun_checks.vbs"
Script exit code: 1
Script output:
Input Error: Can not find script file "C:\Users\MyUser\Local
Settings\postgresql_installer_1b4eec8be6\prerun_checks.vbs".
Turns out that Windows has a symlink between the following directories:
C:\Users\cpetrie\Local Settings\Temp
C:\Users\cpetrie\AppData\Local\Temp
For some reason my "TMP" and "TEMP" user variables were referencing the "Local Settings" path instead of the "AppData" path. Changing this fixed my install issue.
My problem was Smad-Av which disables Windows Scripts from running,
Only after going through this thread i remembered.
I just right clicked the Smad-Av icon and selected Allow Windows-Script & Office-Macro (Permanent).
I had the same problem with installing PostgreSQL (Unable to write in TEMP environment variable path), the problem was in Windows Script Host which was disabled (check the log file to see if this is your problem). enable it with register editor (run-->regedit) at this location Computer\HKEY_CURRENT_USER\Software\Microsoft\Windows Script Host\Settings by setting its value at 1
For more details check this web link: http://1stopit.blogspot.com/2011/01/postgresql-83-and-84-fails-to-install.html
I had the same problem in Windows 10 and the culprit was the OS's permission, or rather the lack thereof, on allowing the executable to write on the User dedicated Temp folder.
Solved it by following my gut and changing the User Temp folder to the same with the system's : Win + Pause/Break to have the Computer Properties window appear (you can do that manually by right-click on Computer icon on Desktop -> Properties) -> click on Advanced System Settings on the panel on the left -> click on Environment Variables and
under "System variables" - Variables, find the TEMP and TMP ones and copy their paths. Then, under "User variables for Administrator" - Variables, find the TEMP and TMP ones and paste the paths. It's most always "C:\Windows\TEMP" anyways ;)
There's this site I read : https://www.askvg.com/where-does-windows-store-temporary-files-and-how-to-change-temp-folder-location/
search for "Registery Editor" and run it.
choose HKEY_CURRENT_USER => SOFTWARE => Microsoft => Windows script host => Setting (Computer\HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows Script Host\Settings)
open "Enabled" and change value data to "1".(you will find it with a vlaue of 0).
Happy coding!
Check the log in the system's TEMP directory (provided the installer is able to write into it).
There's lot of information about the errors.
My issue was that VBS files were associated with a text editor (probably the anti virus software is the culprit) .
Here you can find some reg edit scripts to revert to the default behaviour:
http://www.nilpo.com/2009/07/windows-xp/restoring-vbs-vbscript-script-file-file-associations/#more-107
Cheers
My solution is similiar to #5, with an Explantion of how and why McAfee ruins your vbscript registration.
Apparently, when I had McAfee antivirus software on my computer, it bashed the vbscript.dll registration that Windows Scripting Host needs to run .VBS files.
In the exported .REG file:
[HKEY_CLASSES_ROOT\CLSID{B54F3741-5B07-11cf-A4B0-00AA004A55E8}\InprocServer32]
#="C:\Program Files\Common Files\McAfee\SystemCore\ScriptSn.20120327211246.dll"
That SHOULD be changed back to "C:\Windows\System32\vbscript.dll" now.
McAfee apparently installs a DLL that hijacks the vbscript.dll in order to try to protect bad scripts from running. When I uninstalled McAfee in favor of Microsoft
Security Essentials, McAfee did not restore the registry paths ("not
my problem"), and the McAfee DLL, of course, was removed from the location during uninstall, so the vbscript.dll registration in fact pointed to NOWHERE and NOTHING.
There has to be a better way to write Antivirus software so that it doesn't disable the user's operating system when it is uninstalled, or when features
are turned off, or replace registration. See the following:
https://kc.mcafee.com/corporate/index?page=content&id=KB71660
I have a 64-bit OS. The registry path was changed in a number of locations.
The regular class ID should point to the "C:\Windows\System32\vbscript.dll" 64-bit file.
The "Wow6432Node" registry paths should point to the "C:\Windows\SysWOW64\vbscript.dll" 32-bit file.
Yes, the 64-bits are in the "32" folder and the 32-bits are in the "SysWOW64" folder. Microsoft didn't want to change the name of the main "System32" execution folder when it migrated to 64-bits.
HKEY_CLASSES_ROOT\CLSID{B54F3741-5B07-11cf-A4B0-00AA004A55E8}
C:\Windows\System32\vbscript.dll
HKEY_CLASSES_ROOT\Wow6432Node\CLSID{B54F3741-5B07-11cf-A4B0-00AA004A55E8}
C:\Windows\SysWOW64\vbscript.dll
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID{B54F3741-5B07-11cf-A4B0-00AA004A55E8}
C:\Windows\System32\vbscript.dll
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Wow6432Node\CLSID{B54F3741-5B07-11cf-A4B0-00AA004A55E8}
C:\Windows\SysWOW64\vbscript.dll
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Classes\CLSID{B54F3741-5B07-11cf-A4B0-00AA004A55E8}
C:\Windows\SysWOW64\vbscript.dll
Before you start messing with the registry, check if WSH is actually disabled or not. To do that run wscript.exe in the DOS box.
If you see a dialog box called "Windows Script Host Settings", WSH is enabled, and your problem with PostgreSQL installation must be related to something else.
If you get an error box that says "Windows Script Host access is disabled on this machine. Contact your administrator for details", WSH is disabled, and your problem with PostgreSQL installation may be related to it (or may be not).
For me, my problem was related to Windows script. I resolved this by right-clicking on smadav icon in the hidden icons in the task bar and checked "Allow Windows-script and Office-Macro (Permanent)". Then double click on the PostgreSQL setup again.
First go to registry Editor then choose HKEY_CURRENT_USER > software > Microsoft > Windows script host > setting > default > add value data to 1 and click Ok. done!
After disabling Smad Av, it still did not work. So, I right clicked on the Smad Av tray icon and I selected 'Allow Windows-Script & Office-Macro (Permanent)' and it worked.
I program with eclipse and sometimes use GUI text editors like SciTE or vim. However, I'm at a point in a project that requires me to edit files over a ssh connection in a 80 column SSH window.
Since I have to (* shiver*) sudo vim before I can open the file I'm not sure how to open the file in an editor outside the terminal (that would allow me to see the text wider than 80 columns). If the command line was larger then I guess using straight vim wouldn't be a problem.
I'm at a loss of how to deal with this situation and how I could turn this nightmare into a manageable coding environment.
Maybe you should simply mount the remote filesystem to your local machine and then use whatever editor you like. If running a Debian derivative, install sshfs
sudo apt-get install sshfs
and then mount the remote filesystem ( issue on your local machine )
mkdir ~/remote_code
sshfs $USER#remote.example.com:/home/$USER/code ~/remote_code
Once this is done you can access the code in ~/remote_code w/ any of your GUI tools and without the bandwidth overhead of using ssh -X (however you still need a good connection w/ a low ping time).
PS: When using ssh I can make the terminal as wide as it fits my screen and then use its full width, so I fear I don't completely understand your issue.
WinSCP is a SSH client ftp-like. The default editor is primitive but can be change.
There are various options.
You can make the terminal larger. ;)
If you have a graphical environment installed on the machine you are ssh'ing into, you can login with ssh -X (or xdeep-putty if you are on Windows) to enable window forwarding. You can then run your favourite editor on the remote machine, whose graphical output is forwarded.
Finally, you can mount the ssh connection into your file system, using for example fuse (similar options might exist for non-linux operating systems). That allows you to access any file on the remote machine as if it were in your filesystem, with your favourite editor, locally.
I'm not 100% sure if this works for files owned by root, but if your desktop is KDE & your remote system is Linux (or pretty much any form of *nix), you can get konqueror to access the remote machine using the "fish://" protocol. From there you can open the file from konqueror using kate, or your preferred editor, and konqueror will take care of copying the file to your local machine and copying it back when you save.
Failing which the X11 forward is a good option, but X11 over ssh to remote sites can be slow. "ssh -X -C" compresses the data stream and can give better performance.
Notepad ++ has a plugin for editing files remotely over ssh. I've used it before, but I definitely prefer Kate on KDE using the fish protocol.
http://www.inmotionhosting.com/support/website/ftp-client-setup/connect-ftp-notepad-plus
Forward your X11 session to your terminal.
http://dragonwall.net/xdeep-putty.html
This probably belongs on superuser.com.
You might try the Komodo editor. It has a feature to load a 'remote file' over ssh. It's really convenient.
Emacs and ange-ftp.
If you're on Ubuntu, go to Nautilus (file explorer), connect to server (adding sftp:// to the hostname), then voila! You can easily launch gedit to edit your files now.
On Windows, you can use MobaXterm ( http://mobaxterm.mobatek.net ): it has a built-in SSH client with a very useful "SFTP browser".
As soon as you connect to your remote server using SSH, you will see your remote files displayed in this graphical SFTP browser. Just double-click on your files and you will be able to edit them directly on your remote server through SFTP.
I use Cyberduck and Sublime Text 2
FileZilla did the trick for me. Notepad++ can be used with it which is awesome.
If you using windows, try Editplus. It's not free but allows you to open files directly over scp. Custom syntax files are coming really handy, too.
Recent versions of ultraedit do exactly what the OP is asking for elegantly (IDM software, v10 and up support SSH iirc). I do most of my coding remotely like that, been using it for years, works great with no intermediate files etc. Obviously it also does FTP etc too if you're so inclined.
I actually found this page whilst looking for a linux equivalent of ultraedit..
If you are more GUI-oriented and use one of the more newbie-friendly Linux distros like Ubuntu or Mint, this is another option and does not require any more installations.
You should have nemo as your default file manager. It may not be called "Nemo" on the menu, so go under Help > About of your file manager ("Files" app) to see.
In nemo, go to File > Connect to server, enter your remote machine's details (SSH's default port is 22), and then open the files just like any file on your local machine, with whatever editor you prefer. You can even close Nemo and continue working in your editor.
From the address bar, it seems to be using the sftp protcol.
Just be aware that if your remote host has an inactivity timeout for the SSH connection, this will also prevent you from saving changes in the editor after the timeout has dropped the connection...
Since sshfs is not supported in WSL at the moment, the tool that worked for me is sshfs-win.
Installation Steps
Go here and click "download winfsp"
Install it
Go here and download the installer
Install it
Open windows explorer and right-click "This PC" > "Map Network Drive..."
Select a drive letter (B:), type in "\\sshfs\debian#10.13.100.36" and click Finish
Boom, done. Now you can have a B: drive on your computer and just do whatever with those files. Open them with VSCode, delete them, whatever you like
If you work in IntelliJ IDEA, you can use Friendly Terminal plugin instead of the native terminal. It allows to open and edit remote files in IntelliJ IDEA editor. Video
I had enabled telnet client feature on Windows 2008, and tried to launch it from a Perl script:
perl -e "system('c:\windows\system32\telnet localhost')"
Then I got an error like this:
'c:\windows\system32\telnet' is not recognized as an internal or external command,
operable program or batch file.
I could run it from 'cmd' terminal, or, if I copy the telnet.exe to local dir, it could be launched. I examined the permissions of telnet.exe under c:\windows\system32, no special finding.
Could anybody help me on this case? Thanks a lot!
I ran into the exact same problem recently, trying to launch telnet and the rdp client programmatically. The problem is related to an aspect of windows "design" called file system redirection:
"Windows on Windows 64-bit (WOW64) provides file system redirection. In a 64-bit version of Windows Server 2003 or of Windows XP, the %WinDir%\System32 folder is reserved for 64-bit applications. When a 32-bit application tries to access the System32 folder, access is redirected to the following folder: %WinDir%\SysWOW64. By default, file system redirection is enabled."
http://www.codeproject.com/tips/55290/Disabling-Windows-file-system-redirection-on-a-CFi.aspx
I think you have to specify the full name of the program, that is telnet.exe. But you'd be better off using Net::Telnet module or something like Expect.pm that handles interactive sessions programmatically.
hi you are using Perl, so i was wondering why you don't use Net::Telnet, instead of the telnet.exe of windows, which AFAIK is not friendly for programming.
On my computer following code works (Windows 7):
$telnet = $ENV{'WINDIR'} . '\system32\telnet.exe';
system("$telnet 192.168.1.1");
It must be either a) permissions b) incorrect path, c) you need .exe at the end or d) you need to capitalise the "c:"
You might want to verify under what account Perl execute and check if that account has permissions to run executables like telnet.
Just to verify the theory, I'd run Perl under a high privileged account (like admin) to check if it runs telnet and then tweak the account it is running under.
Hope this helps!
Read about console host.
ConHost represents a permanent change in the way that console application I/O is handled.
See also a related post on SysInternals forums.
I do not have access to any Windows Server 2008 machines right now, so I cannot test this, but can you check what happens when you run wperl -e "system('c:\windows\system32\telnet localhost')" from the equivalent of Start -> Run on that OS.
The answer is: using sysnative instead of system32, because the 32-bits application is not allowed to have access to the system32 directory (64-bit application). By using this alias sysnative it wil work.