passing username/password to openVPN CLI directly - windows

I want to make a script that asks the user for username and password and uses these for a few things at once, including connecting to OpenVPN without needing to either
store the password on the disk
ask the user for the data many times over
for example you can run net use with user and password to mount shares, however openVPN seemingly only has an option to pass a file with username and password.
On Linux there seemingly are solutions like this, however I don't seem to find anything similar for windows yet.
Is there a solution?

Related

Lost .pem file. Need help connecting to EC2 remote server

My secretary created a new instance in Amazon using their EC2 server but lost the .pem file. Doing research online I was able to go to the instance system settings/get system log and retrieve some type of password there. The instance system log shows something like this:
2019/04/15 12:15:19Z: Username: Username
2019/04/15 12:15:19Z: Password: <Password>
It is a very long code of random characters.
Is there any way I can use this to log in via remote desktop or is there a way to decrypt it? I tried several decryption methods online and they said this was not a valid "hash"...whatever this means. I am not a technical person so I need hopefully a response in layman terms.
It appears that you are connecting to a Windows instance. When a new Amazon EC2 Windows instance is launched, a program on the AMI (disk image) automatically generates a random Administrator password. This is done so that you can access the instance, but nobody else can.
To keep the password secret, the program encrypts the password with the keypair nominated when the instance was launched. The encrypted password is passed back to AWS via the console. That is the string of 'random characters' you saw.
To decrypt the password, you can use the Get Windows Password feature, which requires you to supply the nominated keypair. It will then decrypt the password, which can be used to login to the instance as Administrator.
Since you no longer have the keypair, you cannot decrypt the password and therefore cannot login to the server. This is good! This proves that security works, because you would not want other people to be able to login to the server.
So, can do you regain access?
Refer to the steps on: I need to reset the administrator password on a Windows Server instance in Amazon EC2
Basically, there are two methods:
If Systems Manager is enabled for the instance, you can run a "rescue" script
Otherwise, there is a series of scripts that assist with the process of:
Detaching the disk
Attaching it to another instance
Resetting a configuration on the disk
Reattaching the disk to the original instance
The second process is a bit like plugging a USB disk into another computer to change a file (except that EC2 disks are managed differently).

Powershell RDP authentication on domain

I'm trying to create a powershell script to start and authenticate an RDP session to multiple machines by IP range.
I'm very new to powershell, and windows/domain scripting in general.
I have written a powershell script using Connect-Mstsc that allows me to enter my username and password, as well as an IP range and it works, opens a session to all machines in the range and uses the credentials to authenticate me to connect to the machines.
My issue is, I'd like this script to perform LOCAL authentication on the machines as well, right now, when it runs, if I give it a range of say, 5 IP addresses, it opens 5 RDP sessions to the machines, which is good, but each session is sitting there at the login prompt. I would like it to automatically log me in on each machine locally using the same user/password I supply, and then hopefully execute a batch file from a network share on login.
I've done quite a bit of research on this, and I've come up empty, and given my beginner experience level I'm not sure I'm even looking in the right places.

windows batch file to call remote executable with username and password

Hi I am trying to get a batch file to call an executable from the server and login. I have a monitoring program that allows me send and execute the script. OK here goes....
//x3400/NTE_test/test.exe /USER:student password
Now this doesn't work. The path is right because when I type it in at the run menu in xp it works. Then I manually login and the script runs. How can I get this to login and run that exe I need it to?
Part 2:
Some of the machines have already logged in with the password saved (done manually). Should I have a command to first clear that password then login?
Thanks for any replies, I appreciate the help
Jake
(note: this question probably belongs on serverfault.com or superuser.com)
If the login that needs to happen is the login for the network share, you can have your script do that using the net use command:
net use //x3400/NTE_test /USER:student password
//x3400/NTE_test/test.exe
If the login is something specific to the ``test.exe` program, then you'll have to find out from its documentation how to pass credentials on the command line.
In either case, you need to consider the security implications of having a user's password in a script. If the user is has an account with the same name and password on the x3400 server as on the machine he's running on (or if the x3400 machine is in the same domain as his machine), there should be no need for him to provide credentials. This might be a better way to handle the password.

is it safe to call "plink.exe" in an application

i want to use "plink.exe -u username -pw securepassword" on my windows visual c++ program.
will username and password remain safe while calling this command? I mean can a hacker steal or sniff the username and password? (consider hacker can't get to the password directly from the exe file)
Use SSH Keys so your program does not have to use a password directly. Even if the hacker can sniff the username, a strong password should prevent an attack.
If I had access to plink.exe (presumably running on the local box) then I could replace it with a Trojan version that logged your user/pass - but still otherwise worked as normal. Its potentially a bad idea, but then again, if I have access to the box then all bets are off.
Does the hacker somehow have access to memory but not the executable? He could certainly pull it from memory, but it's hard to know what security problems you're facing without knowing the actual situation

How to capture your username on Box A after you have SSHed onto Box B?

Maybe not the best worded question, but hopefully it's a straightforward problem.
The scenario is SSHing from a personal account on box A to a generic account on box B. The script running on box B needs to capture the personal account name for logging purposes. Is there any way of capturing this, either via SSH itself or some information captured by the shell? We are using ssh2 (Reflections), and KornShell (ksh) on Solaris.
If you have full control of the client machine, you can deploy identd to get the username.
Full procedure to get name from script:
Walk up process tree, find sshd
Walk netstat -p to find the remote IP and port.
Connect to client on port 113 and ask.
You may have to disable privilege separation for this to work as-is; however it should be trivial to modify to work w/o it.
You can't log the remote username reliably
You can log the IP of the connection (see the SSH_CONNECTION variable)
You could have a standard where they use an alias for ssh that logs the remote username as part of the login process, or where they store their username in a .ssh/environment file (but allowing environments to be set may require ssh/sshd config changes).
alias sshblah='ssh blah "REMOTEUSER=$USER; bash'
(Except that doesn't work, and I haven't tried to figure out why - and it would be different if you use tcsh, etc).
You can use environment passing in this manner, and select which variables you allow to be set. You'd have to get the users to set some alternate to $USER, like $REMOTE_USER=$USER, and then allow $REMOTE_USER to pass through. And you're trusting they don't set it incorrectly, or forget to set it (you can handle that case with a little annoyance by modifying this mechanism).
Note that you almost have to trust the client connecting to tell you who the user is - you can make it hard/annoying to spoof the username, but unless you use per-user certificates instead of a generic login/password they all know, you can't verify who connected.

Resources