My OS is Windows 10 (x64) and I installed both Powershell 7 and cygwin.
Then, I installed "sshpass" using cygwin.
And, here are the cases I am experiencing right now.
From cmd, if I enter "C:\cygwin64\bin\mintty.exe -", cygwin pops up with initial directory "~". Then, if I type "sshpass -p<password> ssh <username>#<host>", it perfectly works smoothly!
From cmd, if I enter "C:\cygwin64\bin\mintty.exe", cygwin pops up with directory "/cygdrive/c/Users/myname". Then, if I type "sshpass -p<password> ssh <username>#<host>", it asks me to type the password. This means that sshpass is not working correctly here.
From powershell, if I type "C:\cygwin64\bin\sshpass.exe -p<password> C:\cygwin64\bin\ssh <username>#<host>", nothing happens.
My questions are the following:
How do I properly run sshpass command in Powershell?
Let's say my ip address is 1.1.1.1 and I am connecting to a server whose ip is 2.2.2.2, and both computers OS systems are Windows. When I connect to the server through ssh, it shows the "cmd" terminal of the server. How can I change it to show "cygwin" terminal when I connect to the server?
I am having very hard time fixing this out.. Thank you very much in advance..
I am not sure i am getting this, anyway, if i understand correctly you have a hard time launching sshpass from powershell.
Try using Start-Process commandlet: (maybe add the full path to ssh in arguments (?))
start-process -filepath C:\cygwin64\bin\sshpass.exe -ArgumentList '-p<password> ssh <username>#<host>' -Wait -NoNewWindow
Anyway instead of reaching linux commands to windows and run it from powershell, why don't you check powershell modules?
ssh using powerShell script by passing the password along with the Commnad
Also, Powershell Remoting towards linux is a thing nowadays, and it runs over ssh (not bash afaik)
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
SO I have surfed this site and the web and I feel as though I am missing something simple.
I find related questions but none that combine a scriptblock and remote calling of a 3rd party app (not a simply windows function or app)
I have the following string that I can copy into a command window and run without issue
"C:\Program Files (x86)\Vizient\Vizient Secure Channel v2.1\VizientSC.exe" UID=me#musc.edu PWD=XXXXXXXXX HCOID=123456 PRODTYPE=PRO-UHCSECURECHANNEL-CDB PACKAGETYPE=OTH FOLDERPATH="\\da\db5\MyFiles\Viz\20180413"
To simplify this, lets just assume I want to run this same String every time BUT with a REMOTE call.
I have written this many different ways but to no avail using
Invoke-Command -ComputerName "edwsql" -ScriptBlock { .........
I simply want to run the designated string using cmd.exe on a remote machine.
The EXE being run in the string is a 3rd party software that I do not want to install all all possible locations. Much simpler to run remote form the box it is already installed and is secure.
Can someone point me in the right direction???? Pls???? I'm new to PowerShell. I am trying to phase out some old PERL as the folks who can support that on the client site are few and far between these days.
You don't need to try so hard. PowerShell can run commands. If the command you want to run contains spaces, enclose in " (as you have done) and invoke it with the & (call or invocation) operator. This is all you need to do:
& "C:\Program Files (x86)\Vizient\Vizient Secure Channel v2.1\VizientSC.exe" UID=me#musc.edu PWD=XXXXXXXXX HCOID=123456 PRODTYPE=PRO-UHCSECURECHANNEL-CDB PACKAGETYPE=OTH FOLDERPATH="\\da\db5\MyFiles\Viz\20180413"
If a parameter on the executable's command line contains any characters that PowerShell interprets in a special way, you will need to quote it.
I am trying to install a msi from a network share remotely.
$app = [WMICLASS]"\\$pcname\ROOT\CIMV2:Win32_Product"
$app.Install($AppPath)
I am getting an err 1619. From some sources say that WMI cannot install remotely with first coping it to the local computer and running it. Some sources use this command to exactly.
That way works great, but I want to install via share so when the developer updates this msi, it will update the installed instances automagiclly. If I install them locally, the update would not be detected (not sure of this).
So I have tried using methods along these lines:
Invoke-Command -ComputerName $pcname{ msiexec /quiet /i "\\appsvr\apps\theapp.msi" }
Those commands seem to go off into the blackhole, those that command works when run locally.
Anyone have a method for doing this that works?
In your last scenario, you're credentials are likely getting lost. This is known as the "double-hop authentication" (or maybe it's "second-hop") problem. You're using creds from ServerA, to run something on ServerB, but it in the end has to connect to ServerC.
There's a fix if you have PowerShell v2 installed everywhere and are willing to accept the implications:
http://blogs.msdn.com/powershell/archive/2008/06/05/credssp-for-second-hop-remoting-part-i-domain-account.aspx
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.