Related
I'm using a macbook(MacOS) to connect to a remote Ubuntu server.
I copied the public ssh key to the server using ssh-copy-id and checked that the ssh key works on the terminal. When I do ssh username#x.x.x.x, connection is made without asking for password).
However, when I try to connect to the server through Visual Studio Code, VSCode keeps asking for password. Is there a way to fix this?
Thanks in advance!
It was a problem with the config file.
The VSCode needs the "absolute" path.
In case of MacOS, ssh-copy-id seems to only copy the absolute path relative to the user.
In other words, it omits "/Users/username" before "/.ssh".
Adding "/Users/username" in the IdentityFile attribute in .ssh/config solved the problem.
Check if this microsoft/vscode-remote-release issue 2518 applies:
You should be able to get out of this state by deleting the file (on the remote server side, as sudo root) in the log, /home/#####/.vscode-server/bin/78a4c91400152c0f27ba4d363eb56d2835f9903a/vscode-remote-lock.#####.78a4c91400152c0f27ba4d363eb56d2835f9903a (with unlink) or running the command "Kill VS Code Server on Host..."
If it happens again, you might try setting remote.SSH.useFlock.
The exact command to run in the command palette (View->Command Palette) is:
Remote-SSH: Kill VS Code Server on Host...
Also:
In my case, deleting entire ~/.vscode-server directory after connecting to the container through ssh using terminal worked.
(Deleting only ~/.vscode-server/bin did not work.)
The OP sukrama confirms in the comments having solved the issue
It was a problem with ssh key path in config file.
Here's a quick and handy fix: You do not have to delete the entire .vscode-server folder each time! The problem seems to be a file named 'vscode-remote-lock...'. It can be located inside a folder in ~/.vscode-server/bin/ . That file gets created at each ssh login through vscode. Run the following script on the remote host. It deletes that file whenever it is created:
while true
do
if ls /home/<your-username>/.vscode-server/bin/*/vscode-remote-lock.<your-username>.* 1> /dev/null 2>&1; then
find /home/<your-username>/.vscode-server/bin/*/ -name vscode-remote-lock.<your-username>.* -delete
echo "Killed the troublemaker! ^_^"
fi
done
The file names and the folder names may differ from machine to machine. So find the names on your machine and paste them in the script. Then run the script and you're good to go.
VSCode in my Windows machine was asking for password even with my key correctly configured (it works from the terminal).
My problem was that VSCode was choosing a wrong user. I was using a host configured in my ssh config file, and VSCode was setting the user as DOMAIN\user instead of user. I solved it configuring the correct user in my .ssh/config file:
Host dados
HostName vrt1234
User xxxxx
In case you're having this problem in Windows, keep in mind that the public/private keys that you might use to connect to a remote machine from WSL aren't the same ones that VS Code will use to connect from Windows. You need to create a separate public/private key pair for Windows, and export that private key to the remote server too.
From VS Code remote debug tips and tricks:
In a Powershell window, create a public/private key pair just as you would in a Linux terminal:
ssh-keygen -t rsa -b 4096
Then export it to the remote server:
export USER_AT_HOST="your-user-name-on-host#hostname"
export PUBKEYPATH="$HOME/.ssh/id_rsa.pub"
ssh $USER_AT_HOST "powershell New-Item -Force -ItemType Directory -Path \"\$HOME\\.ssh\"; Add-Content -Force -Path \"\$HOME\\.ssh\\authorized_keys\" -Value '$(tr -d '\n\r' < "$PUBKEYPATH")'"
Make sure you can connect via passwordless SSH via PowerShell.
Finally, in VS Code. press Ctrl+Shift+P to open the command palette and select "Remote-SSH: Open SSH Configuration File..." and edit the config file like so:
Host [convenient name]
HostName [hostname]
User [username]
IdentityFile C:\Users\[username]\.ssh\id_rsa*
Then when you run "Remote-SSH: Connect to Host..." in VS Code and choose the host above, it should connect without prompting for a password.
I had to use UseKeychain yes in my ~/.ssh/config file.
The config file looks like this:
Host server.tld
HostName server.tld
User user
UseKeychain yes
IdentityFile ~/.ssh/key
You have to enter ssh-add -K ~/.ssh/key to add your passphrase to KeyChain first.
Not enough rep to comment, but if you followed the steps from this Stack Overflow post and are still running into issues, your VSCode Remote-SSH config file path may not be set.
Make sure that the setting remote.SSH.configFile is set to ~/.ssh/config.
You could also type Ctrl + Shift + P to open the Command Palette.
Inside the Command Palette type,
Remote-SSH: Kill VS Code Server on Host...
You will be required to type in your server password for it to work.
In case this helps someone, i had a similar issue where VSC was asking for a password (instead of a passphrase).
I noticed that my key was on a network drive and it looks like VSC cannot read it there.
I moved it to a local file (C:) and it worked.
For me it was that my public auth ssh was not working and my home directory permissions were the problem. I had to remove group and other write permissions to my home directory and then everything worked:
chmod go-w ~/
(macos+vscode)
Only this worked for me:
https://www.backarapper.com/add-ssh-keys-to-ssh-agent-on-startup-in-macos/
ie: adding the key by ssh-add and then writing this in the ~/.ssh/config file:
Host *
UseKeychain yes
AddKeysToAgent yes
IdentityFile ~/.ssh/[your-secure-ssh-key-name]
Background:
I have several registry keys that are saved and used to update/configure remote PCs in my environment. I may not have deployed the device, previously, but I use these registry keys to update the PC as I fix/repair/etc...I am part of a team of 45 managing about 25,000 workstations and peripherals in our region of the enterprise.
if I use this command from my Win 10 PC to a Win 7 PC, it executes without problems.
psexec \remotecomputer -u domain\adminaccount regedit.exe /i /s "\server\share\directory1\directory2\directory3\someregistry.reg"
psexec starts regedit, imports the above registry file and closes.
If I run that exact same command from my Win 10 PC to another Win 10 PC, I get the following error, from CMD as ADMIN,
"PsExec could not start regedit.exe on REMOTEPC_HOSTNAME:
The system cannot find the file specified."
it can't find regedit??? WTF??
I'm curious why Win 10 is blocking me, as an admin, from importing a registry key?
I've tried reg import as a solution, but I keep getting syntax errors and it can't find the file/pathway.
It's almost like the remote PC, doesn't recognize admin input due to UAC settings?
In testing, I've set the group policy editor to enable remote registry tools, no change. I've enabled remote registry services and set to start the service automatically. I can access the PC registry via remote registry...but psexec just won't work on the remote device.
I can RDP to the device and run the command line equivalent:
regedit.exe /i /s "\UNC\pathway...\etc*.*reg" it executes, without issues.
this proves that regedit is working
Can anyone provide some expertise on this?
add -s flag to psexec to run regedit
The old PsExec trick of running RegEdit doesn't always work. This is because psexec depend on a hidden SMB Administrator service. (Which in any security sense should be disabled.)
PsExec allows redirects of the input and output of a remotely started
executable through the use of SMB and the hidden $ADMIN share on the
remote system. With this share, PsExec uses the Windows Service
control Manager API to start the PsExecsvc service on the remote
system which creates a named pipe that PsExec communicates with. This
named pipe is what allows for input/output redirection back to the
system that launched PsExec.
So instead, in order to remove any TrustedInstaller owned registry Keys, you can use a different tool. This worked:
ExecTI - Run as TrustedInstaller
Run it to open the ExecTI GUI and enter: C:\Windows\regedit.exe
I need to write a script that transfers files from a folder onto another server (Linux), but the script that's transferring files is on windows, and I was wondering if there was an alternative to scp for PowerShell (or if there was another way of doing this)
There is a handy little tool that comes with Putty called pscp.exe that will do this and can be called in powershell easily.
Example below copies from windows to a CentOS box (logging in as the usercode "bill") and you use the -pw switch in pscp to pass in a password (otherwise the command window that is spawned will prompt for the Linux password):
Start-Process 'C:\Program Files (x86)\PuTTY\pscp.exe' -ArgumentList ("-scp -pw password C:\Document.rtf bill#192.168.0.28:/home/bill/")
PuTTY Secure Copy client
Release 0.62
Usage: pscp [options] [user#]host:source target
pscp [options] source [source...] [user#]host:target
pscp [options] -ls [user#]host:filespec
Options:
-V print version information and exit
-pgpfp print PGP key fingerprints and exit
-p preserve file attributes
-q quiet, don't show statistics
-r copy directories recursively
-v show verbose messages
-load sessname Load settings from saved session
-P port connect to specified port
-l user connect with specified username
-pw passw login with specified password
-1 -2 force use of particular SSH protocol version
-4 -6 force use of IPv4 or IPv6
-C enable compression
-i key private key file for authentication
-noagent disable use of Pageant
-agent enable use of Pageant
-batch disable all interactive prompts
-unsafe allow server-side wildcards (DANGEROUS)
-sftp force use of SFTP protocol
-scp force use of SCP protocol
pscp.exe is a viable option, but I have been using a library from Rebex for a couple years now for SFTP and FTPS transfers in both C# apps and PowerShell scripts with great success. Their package also includes an SCP object but I haven't personally used it.
It does cost money vs. pscp being free. Before selecting the Rebex package, I had considered going the PuTTY route but my team decided that having a library we could easily roll into any app/script was worthwhile in the long term.
You can use WinSCP .NET assembly from PowerShell for SCP transfers.
For example see http://winscp.net/eng/docs/library_powershell#example
The example uses SFTP protocol. To use SCP, just modify it to:
$sessionOptions.Protocol = [WinSCP.Protocol]::Scp
Though if your server support SCP protocol, it's likely it also supports SFTP. SFTP is better choice, if you have the option.
Why use an alternative to SCP when you can use SCP?
Windows has OpenSSH (which includes SCP) as an optional component these days, so you could just use that. It first appeared in the Autumn 2018 version of Windows 10. It's nearly identical to the command you find in most Linux distributions, as it's derived from the same code base. Microsoft just made one or two minor tweaks to make it work on windows.
It is simple to install just go to Start->Settings->Apps->Optional Features->View Features enter in OpenSSH in the search box and check the OpenSSH client and click next. See OpenSSH in Windows for more detailed instructions on how to set it up. For a more PowerShell way of installing it run this from an elevated PowerShell prompt:
Add-WindowsCapability -Online -Name OpenSSH.Client~~~~0.0.1.0
You can use this command to check if there is a newer version and whether you already have it installed:
Get-WindowsCapability -Online | Where Name -Like '*ssh*'
Once installed, you call scp from PowerShell just like you would any other executable command.
scp file.dat user.name#example.com:/target/path
If you really don't want to use SCP use Copy-Item
This requires PowerShell to be installed on your server. Yes you can install PowerShell on Linux. Just call Copy-Item with the -ToSession parameter passed an SSH connected session, I've never actually tried it though. It requires a recent version of PowerShell and some setting up see PowerShell remoting over SSH. Something like this:
Copy-Item C:\localPath\*.* ~\remotePath\ -ToSession (New-PSSession -HostName UserA#LinuxServer01:22 -KeyFilePath c:\\userAKey_rsa)
If both machines are Windows machines you can use the same -ToSession parameter to copy files over WinRM. But both machines have to be domain joined or there is the possibility of security issues.
There is also a ".NET friendly" way:
you can use the SharpSSH dll to execute ssh commands, and do scp/sftp tranfers.
For example:
[Reflection.Assembly]::LoadFrom((Resolve-Path .\Tamir.SharpSSH.dll))
$ssh = New-Object Tamir.SharpSsh.Sftp("server","user","password")
$ssh.Connect()
$ssh.Put("C:\localfile","distantfile")
$ssh.Close()
There is the SSH.Net library, too, it does approximatively the same things.
When I invoke my Perl scripts in the Windows environment without invoking perl first, the parameters are not passed to my script.
For example,
C:\> C:\my-perl-scripts\foo.pl bar
invokes foo.pl but doesn't recognize bar as a parameter (#ARGV is empty). However,
C:\> perl C:\my-perl-scripts\foo.pl bar
works as expected.
Is this a configuration issue?
Ideally, I'd like to be able to distribute some perl scripts, have the user add C:\my-perl-scripts\ to the path and then just be able to invoke foo.pl from anywhere while running cmd.
If they have to specify perl first, then they'll always have to give a complete path.
Any ideas or recommendations?
Edit: To show that the assoc and ftype are correct on my system, I executed the following commands.
C:\>assoc .pl
.pl=Perl
C:\>ftype Perl
Perl="C:\Perl\bin\perl.exe" "%1" %*
C:\>more t.pl
print "'$_'\n" for #ARGV;
C:\>t a b
C:\>perl t.pl a b
'a'
'b'
C:\>t.pl a b
C:\>
I included both the output of t and t.pl to show it's not a %PATHEXT% problem. Both outputted nothing as originally described whereas invoking perl first gave the expected response.
I'm not sure where to look next, but thanks for the suggestions so far. They have been very helpful.
Edit 2: The problem appears to be on my vista business box. On my xp pro box, it works as expected. Both have ActivePerl 5.8.9. I have another vista home box that I have not yet tried yet. I'll post back if I discover anything.
Edit 3: I found the answer (posted below). I found it by running a registry cleaner, removing perl, running the registry cleaner again. On 2nd cleaning, only one invalid entry remained - the one that was causing the problem (probably left over from a previous installation).
I found out what the problem was. Although the ftype and the assoc values were set as suggested, the actual behavior on my system seems to be determined by the registry key
HKEY_CLASSES_ROOT\Applications\perl.exe\shell\open\command
It should have a (Default) string value of "C:\Perl\bin\perl.exe" "%1" %*
When I found this entry, it was set to "C:\Perl\bin\perl.exe" "%1". Changing it immediately fixed the problem.
Why it was set that way in the first place? I don't know. Maybe from a previous installation?
Anyway, thanks for the suggestions, and I hope this answer helps someone else, too.
Hmmm... sounds like the file association for *.pl is messed up somehow. I'm not on a Windows box, so I can't test this. You can check the file association stuff with either the ASSOC or FTYPE command on the command-line. IIRC, "ASSOC .pl" should tell you what the file type is and "FTYPE filetype command" tells the shell what to do with a Perl script. Try something like:
C:\> ASSOC .pl=perlscript
C:\> FTYPE perlscript=C:\Perl\bin\perl.exe %1 %*
From the looks of one of the command references that should do the trick. My guess is that the current association is not passing the parameters along to the script. You should be able to check that by using ASSOC .pl to figure out what the name of the file association is and then using FTYPE to print out the command that the shell is going to execute.
Update
I found an interesting thing that I want to note for posterity. I started seeing exactly this problem on a friends machine at work with respect to some Python scripts. ASSOC and FTYPE resulted in the expected output but the parameters were still not being passed along - exactly what was originally reported.
After a little digging, I found that the registry settings were created somewhere along the line as REG_SZ values. I deleted them and re-created them using ASSOC and FTYPE and everything started working... looking at the registry gave me the answer the new values were created as REG_EXPAND_SZ! These worked exactly as expected.
Update: Given that the following is correct, the only thing left to make sure is that command extensions are not turned off. Try:
cmd /e:on
on the command line before you run your tests. See also Windows XP cmd documentation:
Enabling and disabling command extensions
Command extensions are enabled by default in Windows XP. You can disable them for a particular process by using /e:off. You can enable or disable extensions for all cmd command-line options on a computer or user session by setting the following REG_DWORD values:
HKEY_LOCAL_MACHINE\Software\Microsoft\Command Processor\EnableExtensions\REG_DWORD
HKEY_CURRENT_USER\Software\Microsoft\Command Processor\EnableExtensions\REG_DWORD
Set the REG_DWORD value to either 0x1 (that is, enabled) or 0x0 (that is, disabled) in the registry by using Regedit.exe. User-specified settings take precedence over computer settings, and command-line options take precedence over registry settings.
E:\Temp> assoc .pl
.pl=Perl
E:\Temp> ftype Perl
Perl="C:\opt\Perl\bin\perl.exe" "%1" %*
E:\Temp> #echo %PATHEXT%
.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.PL;.PLX;.WPL;.py;.pyw
E:\Temp> cat t.pl
print "'$_'\n" for #ARGV;
E:\Temp> t a b c d e f g h j
'a'
'b'
'c'
'd'
'e'
'f'
'g'
'h'
'j'
I have used pretty much every ActiveState Perl distribution since 2004. These settings are enough to make it work.
To sum up.
ftype is old and cmd.exe doesn't care whatever it says.
The real deal is the HKEY_CLASSES_ROOT\Applications\perl.exe\shell\open\command thing.
Just run: reg add HKEY_CLASSES_ROOT\Applications\perl.exe\shell\open\command /ve /d "C:\strawberry\perl\bin\perl.exe \"%1\" %*" /f
and everything will be ok. (* given that "C:\strawberry\perl\bin\perl.exe" is the exact path to your perl installation.*)
/ve is meant to work on de “(Default)” REG_SZ value
/d is to assign “data” to the “value”
/f to force substitution (or overwriting) of the preexisting value
In fact, if assoc .pl=Whatever and ftype Whatever doesn't exist (never assigning a value to it, or doing ftype Whatever= to unassign), the scripts could still be invoked without prepending perl.exe.
So, if using Windows >= 6.0 (Vista, 2008, 7, etc.) just forget that the commands assoc and ftype exist at all. Don't bother. Go reg.exe!
I tried updating and associating .pl with the many different PERL entries in the registry that others have tried (.pl, Perl, PerlScript, pl_auto_file, Applications\perl.exe) and none of these worked. I'm running AS Perl 5.14.2 on Windows 7. I then noted that there was an entry for \Applications\perl5.14.2.exe in the registry and it was set to:
"C:\Perl\bin\perl5.14.2.exe" "%1"
Added the %* to this and then I was able to see data in #ARGV.
I also noted that on some of these entries I had a command path entry of "C"\Perl64\..." from a previous 64 bit PERL that I'd installed earlier and uninstalled when I found out that 64 bit PERL isn't as nice with IIS 7 as 32 bit PERL is. So there are dangling installation remnants that are probably affecting things too.
So the answer here is probably not a short one and is in simple words... "It depends..." (on your system and installation).
After fixing file association problem could not pass parameters. A user I support mistakenly associated .pl file extension with notepad after trying to run script from (Windows 7 Professional) command line for first time. Tried all the file association tricks and environment variable fixes to no avail. Uninstalled and reinstalled and tried 32 bit and 64 bit installations. Issue was only present on users profile.
Finally went into the registry and simply deleted the key from
HKEY_CLASSES_ROOT\Applications\perl.exe\shell\open\command
and added back via
reg add HKEY_CLASSES_ROOT\Applications\perl.exe\shell\open\command /ve /d "C:\strawberry\perl\bin\perl.exe \"%1\" %*" /f
started passing parameters again Thanks "lucretius"
I found this additional location in the registry that had to be updated before it would work for me. Note: The name after HKEY_USERS may be different on your machine.
Add %* to default string:
HKEY_USERS\S-1-5-21-1399284159-2775065347-350672949-4058_Classes\pl_auto_file\shell\open\command
"D:\Perl\bin\perl.exe" "%1" %*
Original author answer works. Here's a complete registry file for manually installing PERL on Windows, just add to PATH environment variable: ";C:\PERL\bin;" and make a perl.reg file with notepad containing this:
Windows Registry Editor Version 5.00
[-HKEY_CLASSES_ROOT\.pl]
[HKEY_CLASSES_ROOT\.pl]
#="Perl"
"PerceivedType"="text"
[HKEY_CLASSES_ROOT\.pl\Perl]
[HKEY_CLASSES_ROOT\.pl\Perl\ShellNew]
[HKEY_CLASSES_ROOT\.pl\PersistentHandler]
#="{5e941d80-bf96-11cd-b579-08002b30bfeb}"
[HKEY_CLASSES_ROOT\Applications\perl.exe]
[HKEY_CLASSES_ROOT\Applications\perl.exe\shell]
[HKEY_CLASSES_ROOT\Applications\perl.exe\shell\open]
[HKEY_CLASSES_ROOT\Applications\perl.exe\shell\open\command]
#="\"C:\\Perl\\bin\\perl.exe\" \"%1\" %*"
[HKEY_CLASSES_ROOT\Perl]
[HKEY_CLASSES_ROOT\Perl\shell]
[HKEY_CLASSES_ROOT\Perl\shell\Open]
[HKEY_CLASSES_ROOT\Perl\shell\Open\command]
#="\"C:\\Perl\\bin\\perl.exe\" \"%1\" %*"
[HKEY_CLASSES_ROOT\pl_auto_file]
#=""
[HKEY_CLASSES_ROOT\pl_auto_file\shell]
[HKEY_CLASSES_ROOT\pl_auto_file\shell\open]
[HKEY_CLASSES_ROOT\pl_auto_file\shell\open\command]
#="\"C:\\Perl\\bin\\perl.exe\" \"%1\" %*"
[HKEY_CURRENT_USER\Software\Classes\Applications\perl.exe]
[HKEY_CURRENT_USER\Software\Classes\Applications\perl.exe\shell]
[HKEY_CURRENT_USER\Software\Classes\Applications\perl.exe\shell\open]
[HKEY_CURRENT_USER\Software\Classes\Applications\perl.exe\shell\open\command]
#="\"C:\\Perl\\bin\\perl.exe\" \"%1\" %*"
[-HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.pl]
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.pl]
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.pl\OpenWithList]
"a"="perl.exe"
"MRUList"="ab"
"b"="NOTEPAD.EXE"
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.pl\OpenWithProgids]
"pl_auto_file"=hex(0):
"Perl"=hex(0):
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Perl]
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Perl\shell]
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Perl\shell\Open]
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Perl\shell\Open\command]
#="\"C:\\Perl\\bin\\perl.exe\" \"%1\" %*"
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\pl_auto_file]
#=""
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\pl_auto_file\shell]
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\pl_auto_file\shell\open]
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\pl_auto_file\shell\open\command]
#="\"C:\\Perl\\bin\\perl.exe\" \"%1\" %*"
[HKEY_LOCAL_MACHINE\SOFTWARE\Perl]
#="C:\\PERL\\"
"BinDir"="C:\\Perl\\bin\\perl.exe"
I installed Perl 5.24.3 on Windows2016 and found the JAMS scheduler Agent Shell ignored the .pl extension as if it did not exist. All good from DOS desktop.
The same config on Winows2008 worked fine.
The registry entries created by that ActiveState Perl Install, matched Lucretius Post above, but do not apply globally to all users. Not the default system user for example.
Logging in as the user the Shell will run as, and making the association helped.
Ideally there would be a registry twig to make .pl assoc global ?
While I'm using PSEXEC.exe getting 'Access denied' error for remote systems.
Any idea about how to solve this?
Hi i am placing here a summary from many sources online for various solutions to "access is denied" :
most information can be found here (including requirements needed) - sysinternal help
as someone mentioned add this reg key, and then restart the computer :
reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system
/v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1 /f
Read this knowledge base article to learn what this does and why it is
needed
Disable firewall (note - this will leave you with out any firewall
protection)
netsh advfirewall set allprofiles state off
if target user has a blank PW and you dont want to add one, run on target:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa]
"LimitBlankPasswordUse"=dword:00000000
This didnt work for me, but i have read it did for others in a few places,
on target execute:
Start -> Run -> secpol.msc -> Local Policies -> Security Options -> Network Access: Sharing > and security model for local accounts > Classic – local users authenticate as themselves
if already in 'Classic':
move to "Guest only - .." run from elevated command prompt gpupdate \force
move back to 'Classic - .." again run from elevated command prompt gpupdate \force
This one solved my issue:
run on target from elevated command prompt "net use" look at ouput chart and for shares listed in remote column there (i only deleted the disconnected ones - you can try them all) run "net use [remote path from before list] /delete" then run 'net use \target\Admin$ /user:[user name]' enter prompt password request (if empty PW just press enter), viola should work.
I just solved an identical symptom, by creating the registry value HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system\LocalAccountTokenFilterPolicy and setting it to 1. More details are available here.
This helped in my case:
cmdkey.exe /add:<targetname> /user:<username> /pass:<password>
psexec.exe \\<targetname> <remote_command>
PsExec has whatever access rights its launcher has. It runs under regular Windows access control. This means whoever launched PsExec (be it either you, the scheduler, a service etc.) does not have sufficient rights on the target machine, or the target machine is not configured correctly. The first things to do are:
Make sure the launcher of PsExec is familiar to the target machine, either via the domain or by having the same user and password defined locally on both machines.
Use command line arguments to specify a user that is known to the target machine (-u user -p password)
If this did not solve your problem, make sure the target machine meets the minimum requirements, specified here.
You can try the command
net use \\computername\ipc$ /user:adminname password
to get admin permissions on remote PC before use psexec.
I had the same problem. And after a hard work, I found a easy and full solution:
I use runas to run the script in a admin account
I use the -s parameter in psExec to run in a system account
Inside the PsExec, I login again with a admin account
You can use & to run multiples commands
Remember to replace [USERNAME], [PASSWORD], [COMPUTERNAME], [COMMAND1] and [COMMAND2] with the real values
The code looks like this:
runas /user:[USERNAME] "psexec -e -h -s -u [USERNAME] -p [PASSWORD] \\[COMPUTERNAME] cmd /C [COMMAND1] & [COMMAND2]"
If you whant to debug your script in the another machine, run the following template:
runas /user:[USERNAME] "psexec -i -e -h -s -u [USERNAME] -p [PASSWORD] \\[COMPUTERNAME] cmd /C [COMMAND1] & [COMMAND2] & pause"
Try setting this key on the target (remote) machine, and restart the machine:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System]
"LocalAccountTokenFilterPolicy"=dword:00000001
See: http://forum.sysinternals.com/topic10924.html and http://www.brandonmartinez.com/2013/04/24/resolve-access-is-denied-using-psexec-with-a-local-admin-account/
I just added "-с" parameter. It makes Psexec copy executable to remote machine. So it works without access errors.
I found Sophos kept placing psexec.exe into the Quarantine section. Once I authorized it, it ran fine.
I still use psexec, even on win 10. Replace the psexec.exe in the Windows 10's win32 folder with the older version to work -> I use version 2.11.0.0. The Windows 10 version I was using would only run .bat files as background/hidden process on the remote computer. Took a whole day to figure this out.
Adding the registry key from above to the remote computer helps as well:
reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system /v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1 /f
I found another reason PSEXEC (and other PS tools) fail - If something (...say, a virus or trojan) hides the Windows folder and/or its files, then PSEXEC will fail with an "Access is Denied" error, PSLIST will give the error "Processor performance object not found on " and you'll be left in the dark as to the reason.
You can RDP in; You can access the admin$ share; You can view the drive contents remotely, etc. etc., but there's no indication that file(s) or folder(s) being hidden is the reason.
I'll be posting this information on several pages that i was perusing yesterday while trying to determine the cause of this odd problem, so you might see this elsewhere verbatim - just thought I'd put the word out before anyone else pulled their hair out by the roots trying to understand why the performance counter has anything to do with PSEXEC running.
I had a case where AV was quarantining Psexec - had to disable On-access scanning
For anybody who may stumble upon this. There is a recent (Dec 2013) Security Update from Microsoft Windows on Windows 7 that is preventing remote execution.
See http://support.microsoft.com/kb/2893294/en-us
I uninstalled the Security Update by going to Control Panel\Programs\Programs and Features\Installed Updates
It worked right after that.
The following worked, but only after I upgraded PSEXEC to 2.1 from Microsoft.
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System]
"LocalAccountTokenFilterPolicy"=dword:00000001 See:
http://forum.sysinternals.com/topic10924.html
I had a slightly older version that didn't work. I used it to do some USMT work via Dell kace, worked a treat :)
On Windows Server 2012 R2 I had trouble to run from user account
psexec -u administrator -p password \\machinename -h -s -d -accepteula cmd.exe
But it works fine if you run without parameters -h -s. That's why I use this to solve my trouble:
psexec -accepteula -u administrator -p password \\machinename %PathToLocalUtils%\psexec.exe -h -s -d cmd.exe
I couldn't get access to remote machines unless I had UAC disabled.
That has to be done locally, either from control panel or running the following through cmd:
reg.exe ADD HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v EnableLUA /t REG_DWORD /d 0 /f
While UAC is enabled, make sure you run cmd as administrator.
For a different command I decided to change the network from public to work.
After trying to use the psexec command again it worked again.
So to get psexec to work try to change your network type from public to work or home.
I tried a lot of way but I could not use psexec. It gives "Access denied". After I change the target user account type from Standard to Admin, I connected the machine via psexec.
I researched the reason why admin type account is required then I found this answer.
You can change target machine user account this way: Control Panel -> User Accounts -> Change Account Type. You must enter an admin account and password to change that account if you logged in standard account.
After that I logged in with this command: psexec \\remotepcname -u remoteusername -p remotepassword cmd
Tried all suggestions above, but still was unable to resolve the error. Finally once I made the below change, I could successfully run the PSexec command.
Turns out that when you have UAC enabled psexec does not work as supposed. We need to set HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\EnableLUA to 0 then psexec starts working as expected.