GOAL
Remotely access from a machine to another, using psexec, in order to start/stop a net service.
CONFIGURATION
Windows 10 Pro on both machines
PsExec v2.2
ISSUE
Couldn't access MACHINE_IP:
Access denied.
PREMISE
from now on, I'll refer to those machines as A and B
A is able to ping B
the accounts I used to accomplish that task are both administrators
WHAT I'VE TRIED
The first attempt was quite simple; so, from A, I ran:
psexec \\B_IP -u B_ADMIN_NAME -p B_ADMIN_PWD net stop SERVICE_NAME
but, as a result, I got the "Access denied" error.
Searching for the issue, I've found a lot of possible solutions but, unfortunately, noone worked for me. Here's what I tryied:
disable Windows Defender on A and B
disable User Account Control on A and B
uncheck "Use Sharing Wizard" from "Folder Options > View > Advanced Settings" on A and B
add the new DWORD (32-bit) LocalAccountTokenFilterPolicy (set to 1) inside "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System" on A and B
save credetials before execute psexec using cmdkey.exe /add:B_IP /user:B_IP\B_ADMIN_NAME /pass:B_ADMIN_PWD
try to get admin permissions on remote PC before using psexec with net use \\B_IP\ipc$ /user:B_ADMIN_NAME B_ADMIN_PWD
try to run psexec as administrator using runas /user:B_ADMIN_NAME "psexec -e -h -s -u B_ADMIN_NAME -p B_ADMIN_PWD \\B_IP cmd /C net stop SERVICE_NAME"
Another strange thing is that A cannot access to B via filesharing.
To be precise, it can access to \\B_IP but not to \\B_IP\C$ nor \\B_IP\ADMIN$.
I think those two issues (access denied with psexec and filesharing) are somehow related but, as I said, noone of the previous solutions worked for me.
Any other ideas would be very appreciated.
Thanks.
IIRC the admin$ share uses SMB1/CIFS which 1709 or 1803 automatically disabled because MS considers SMB1 not secure enough.
(If you're using a samba server and your windows client cannot access network shares anymore after upgrading to one of these versions, the answer below should also work for you)
It has to be manually reactivated through "turn windows features on or off"
full name : SMB 1.0/CIFS File Sharing Support.
Be aware that this feature contains both client and server, be sure to expand the feature's tree to check if you correctly install the one you need (server for psexec, client for network shares)
Related
I need to use my local computer to simulate a test stand which will be on a domain and access a remote computer which is on a workgroup using PsExec. The testing computer is built from an imaging tool. The IP will be the same every time but the name isn't. The process I'm working with was used on an embedded XP system and is now being upgraded to WIN10. I've added network security using GPO and have found workarounds to be able to open the connection but for some reason just trying to run cmd on the remote machine does not work when using the IP, only the name. Using the IP returns the "access is denied" error. I have already added the token filter key to the registry. Has anyone heard of something like this before?
I have a script I'm trying to run but in the meantime I'm just trying to get
psexec \IP_ADDERESS -h -u USER_NAME(this is an admin) -p PASSWORD cmd
edit: I have to keep my computer on a domain but I have a spare that I was able to put on a workgroup with the test system. Running psexec went perfect. It makes no sense why it works for the name and not ip on a domain->workgroup connection and works exactly how I need it to on a workgroup->workgroup connection.
Is it possible in VSCode to edit files within WSL2 of a remote PC. (This is like a combination of Remote-WSL and Remote-SSH.) I can connect to that remote PC via ssh and RDP.
The path \\wsl$\ does not seem to be available in my remote-ssh connection.
PCA - me, local, VSCode
^
|
ssh and/or RDP
|
V
PCB - remote, WSL2
(I currently have Windows OpenSSH set up on the remote PC, with the default CMD shell. I tried setting the shell to Bash but then the remote extension wouldn't install.)
Update Setting PC-B's ssh server shell to bash.exe does solve all my problems. I'm not sure why it didn't work before. See my answer below for more details.
Answering my own question I was certain I'd tried this before and it had not worked, but now that I try it again it works. Perhaps I just needed a reboot of Windows and WSL2.
Enable Windows SSH server on PC-B and set the shell to be bash.exe
# Powershell as Administrator
Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0
Set-Service -Name sshd -StartupType 'Automatic'
New-ItemProperty -Path "HKLM:\SOFTWARE\OpenSSH" -Name DefaultShell -Value "C:\WINDOWS\System32\bash.exe" -PropertyType String -Force
If you want authorized_keys-based login to this PC and your account is an Administrator account, you will need to follow the special instructions here: https://learn.microsoft.com/en-us/windows-server/administration/openssh/openssh_keymanagement (I have heard of having to manually fix the administrator_authorized_keys file permission at some point too. https://stackoverflow.com/a/64868357/600360 )
Using Remote-SSH connect VSCode from PC-A to PC-B (using Windows credentials) and tell VSCode that it is a linux server (because you're connecting to bash.exe within WSL2).
If you're behind a proxy server, add the proxy to your ~/.wgetrc.
Voila.
These steps taken from THE EASY WAY how to SSH into Bash and WSL2 on Windows 10 from an external machine where you can find more details.
If you want to connect to remote WSL, you probably should set it up to run own sshd instead of relying on hosting Windows to do the tunneling.
If I have got your problem statement right, the flow seems to be outlined in one of VS Code blog posts. Here I'll mention steps I think you will need to get to your target state.
Firstly, disable sshd on remote Windows so it does not occupy port 22. then, install and start sshd inside PCB:
# from PCB command prompt
# something like that, depending on your choice of distro
sudo apt remove openssh-server && sudo apt install openssh-server
# this would again depend on your chosen distro
sudo /etc/init.d/ssh start # after i do this - windows pops up a firewall prompt to allow me create a rule. you might need to add it manually
then you'd need to either enable password logins via ssh or (preferably) generate a key pair and put your public key into /home/your_name/.ssh/authorized_keys on PCB.
Assuming you have OpenSSH for Windows installed (this seems to be the client Remote SSH relies on), on your PCA follow something like so:
# something along these lines on your PCA
PS C:\WINDOWS\system32>ssh-keygen
# note location of .pub file and copy its contents into remote ./ssh/authorized_keys
# add generated private key to ssh-agent service
PS C:\WINDOWS\system32> Start-Service ssh-agent # if this fails - ensure service is installed and enabled
PS C:\WINDOWS\system32> ssh-add path\to\your\private_key # ensure you have dropped all permission except your own user
Watch out for permissions:
ssh keys are considered secret, so neither client nor server would start unless you drop all permissions from your key material. On linux do chmod 600 .ssh/authorized_keys, and for windows ssh-agent follow instructions from this SE answer.
The above may seem a bit daunting but is in fact very standard SSH setup procedure
easy steps
just update your vscode to the latest version
install Remote Development extension pack
allow WSL2 connection in the settings
if my answer helped you upvoted :D
I know it's been a while since the post, but here is a useful answer that uses Remote -- Tunnels extension.
https://stackoverflow.com/a/75389647
It appears that, for now, you need to manually install the CLI in WSL in order for it to work. The downloads can be found here. Since you are on Windows, I would recommend the x64 CLI download. When you extract the tar.gz file, you will get a file named code. I would recommend moving it to your home directory for ease. To open the tunnel, run ./code tunnel (from wherever you put the code file) to force the new CLI. If you use code tunnel it will still use the Windows version.
Source: https://github.com/microsoft/vscode/issues/171196
I am using psexec to execute commands on remote server. Here is my command,
PsExec.exe" -u user \\server -h run.bat
I am entering the password manually. here I am using standard user account due to security issues. When I run the command I am getting the error,
"Make sure that the default admin$ share is enabled"
I read here that it cannot be done without admin privileges.
But when I test the same command in LAN it works in standard user.
How it works in LAN not in Remote server ?
Is there any alternative tools which will work in standard user ?
Please help me.
As an alternate tool, you can use Powershell and WinRM. Powershell allows you to execute a command, or an interactive session, on the remote windows server.
An example of executing a command is available here:
How to programmatically/remotely execute a program in EC2 Windows instance
If you need an interactive session, look at the Powershll command 'Enter-PSSession': https://technet.microsoft.com/en-us/library/hh849707.aspx
here's my situation.
I'm running Cruise Control as a Windows Service and trying to get it to connect to a Mercurial Repository on BitBucket over SSH.
I'm pretty sure that everything's configured OK (PuttyGen, Pagaent, etc). I'm remoting onto the server using the same account that I am using to run the service and if I issue hg pull -b ssh://#bitbucket.org// from a command line everything works. I added -v to the ssh configuration in mercurial.ini and I can see all of the steps that are taken.
If I run CC.NET from a command prompt then it builds fine. In the console window I can see the same logging from the SSH operation.
However, if I run CC.NET as a service (using the same user account that I'm logged in on) the call to BitBucket times out. I can find no way to work out why either. The build log doesn't help and neither do ccnet.log or ccnet.trace in the temp directory. I was expecting one of them to contain the logging from the SSH operation, but they don't.
Can anyone help? Is it that running as a service prevents it from connecting to Pagaent (I've started Pagaent by adding it to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run). When I did the pull from the command line I had to OK a dialog, but only once. Is it waiting on the same dialog now that it's running as a service?
Getting close to my wits end here.
Thanks
I did get it working in the end. The trick was to create the public key without a passphrase. When running as a service the solution has to be completely non-interactive and the passphrase option with pagaent.exe just isn't.
Here are the steps:
Use PutTTygen to generate a secure key WITHOUT a passphrase. If you really do need one then you can add it to the mercurial.ini file, but defeats the point for me as it's in plain sight anyway.
Copy a mercurial.ini to two locations: C:\Windows\System32\config\systemprofile and C:\Windows\SysWOW64\config\systemprofile. Probably only one of these was really necessary, but I didn't have the time to experiment. The first is the home directory for the system user when running 64 bit apps, the SysWOW64 location for 32 bit. Make sure that if you do the same as me then keep both files in sync - or go one further and work out which is the correct location.
Add something like this line under the [ui] key in both files:
ssh = "D:\Program Files\TortoiseHg\TortoisePlink.exe" -ssh -2 -C -batch -v -i "[Path to your ppk file]"
Add the passphrase to the end of the command if one was created in step 1.
Make sure that TortoisePlink.exe is specified, not Plink.exe. They should both be in the same directory.
Download psexec from http://technet.microsoft.com/en-gb/sysinternals/bb842062.aspx
Run d:\PSTools\PsExec.exe -s -i cmd.exe. This will open a command line as the system account in interactive mode.
Now do an hg pull, or hg clone or whatever.
A dialog should pop up with a confirmation message. This is a one time thing and the reason that you have to do the PsExec step. OK the dialog.
Now cc.net should be able to be run as a service under the local system account using SSH!
I was wondering if anyone has tried using teamcity's command line builder to perform ssh remote login.
Right now, I would like to automate some testing on a QNX neutrino OS which is currently unsupported by teamcity. As a work around, I setup a ssh server on the target qnx machine so i could ssh and sftp the executables in.
Firstly, the source are compiled on Windows XP using qnx's compiler (based on g++). Followed by sftp-ing the executables into qnx neutrino.
Next, using ssh, script the login to remotely start the test apps and send the results back to the remote agent for publishing.
The batch script I created works well standalone, however, after hooking it up on the remote agent, it fails to login ssh and hangs indefinitely at the following command:
ssh -l "./.sh"
Notes:
I have added the remote agent's RSA public key in the QNX .ssh/authorized keys file, automatic login is working.
Is there a need to add the teamcity server's RSA public key in too?
Anyone has any idea on this problem?
I had a few weird problems with key-based SSH logins on QNX related to file permissions for the keys in .ssh. and permissions of parent folders (/home/username and /root).
Add
LogLevel DEBUG3
to /etc/openssh/sshd_config, make sure syslog is configured and is logging sshd output, restart sshd and try again - it will most likely complain about something.
Also, ssh -l "./.sh" makes no sense - -l is used to specify the user name, something is off there.