I frequently have to connect to vpn for work. So rather than typing the whole cmd, i want to type something like vpn in terminal and it picks up the password from somewhere and the vpn gets connected.
The process I do now is..
sudo openvpn --config <configfile.ovpn>
I'll be prompted to type the password and when i do that it gets connected.
For the same I explored alias but I suppose alias is for much simpler task. Any solutions, how to pass password automatically when terminal ask for it?
You can create an alias and use it .
In your .bashrc, you can create an alias
alias vpn=« Your command »
Then you will just type the command vpn.
Here a link that can help you
When the password is asked interactively the best options is add the --askpass argument and send the password through a file.
openvpn --config <configfile.ovpn> --askpass <file with cred>
You can also add automatically the password using expect or similar, but the best option is using the own openvpn.
--askpass [file]
Get certificate password from console or file before we daemonize.
For the extremely security conscious, it is possible to protect your private key with a password. Of course this means that every time the OpenVPN daemon is started you must be there to
type the password. The --askpass option allows you to start OpenVPN from the command line. It will query you for a password before it daemonizes. To protect a private key with a password
you should omit the -nodes option when you use the openssl command line tool to manage certificates and private keys.
If file is specified, read the password from the first line of file. Keep in mind that storing your password in a file to a certain extent invalidates the extra security provided by using
an encrypted key.
You can put the password into a file and point your OpenVPN client configuration to it.
It is obviously a bad idea for security to store passwords in plain text on your hard drive!
If you still want to do it, put your user name and password in a plain text file on two lines, like so:
username
password
Add a line
auth-user-pass passwordfile
to your OpenVPN client configuration where passwordfile is the name of the file.
Note this only works in OpenVPN 2 and is no longer supported in version 3. See this blog post about it: https://openvpn.net/blog/openvpn-3-linux-and-auth-user-pass/
Related
We have 2 Debian servers, one for testing and one for live. I have some scripts which should be executed to transfer data from live to test. For both the servers we use PublicKeyAuthentication where our id_rsa.pub's contents are added to authorized_keys on test server.
Even after doing this, everytime I initiate a transfer from one server to another, I am being asked for password.
I also tried calling ssh-copy-id, but that didn't help and all I got was a duplicate entry in authorized_keys.
Lastly when I try sshpass, I get the following message, and i cannot enter the password as its just a message.
sshpass -v -p 'PASS' ssh root#our_server
SSHPASS searching for password prompt using match "assword"
SSHPASS read: Enter passphrase for key '/root/.ssh/id_rsa':
Any ideas? Thanks.
From the output of sshpass, it seams that it is asking for the password of the key, not the password for the server:
Enter passphrase for key '/root/.ssh/id_rsa'
Protecting your SSH-keys with a password is a good practice, but you can not fully automate things that way, as you discovered. Depending on your situation, you can do either of the following:
Use an SSH-agent. This is a daemon that will ask your password once, and keep the private key cached until you remove it. This still has the benefit that your SSH-key is stored password-protected on disk, but you can use it as a password-less key.
This has the added benefit that you can forward SSH-agent over SSH: if you SSH from your machine to server A, and then further on to server B, this last connection can use the key stored on your machine (instead of having to copy your key to server A).
Remove the password from the key entirely (you can use ssh-keygen to change the password to be blank)
How do you execute data transfer? Is it scp? Check your system usernames, make sure public keys are installed to authorized_keys file for correct user.
In a shell script file I am using some commands like scp and make install which ask for my password.
I run a shell script to compile a big project, and after some time it asks for my password for using scp. I need to wait for that process and give the password after that.
I just want to do it all by shell script without interaction, so how can I avoid being prompted for the password here?
Short answer: DON'T
Use public key authentication for SCP and sudo with NOPASSWD directive for make install
If you can't use ssh trust and must enter the password later on in your script, use read -s -p "Password:" USER_PASSWORD to silently read in the password. You can then export USER_PASSWORD to an expect script, avoiding it being displayed in ps:
#!/usr/bin/expect -f
spawn scp some.file USER#otherhost:~
expect "assword:"
send -- "$env(USER_PASSWORD)\r"
expect eof
I think it's a better idea to generate an authentication key, and use this key based authentication instead of writing plain text passwords into your scripts.
No, you won't find any method to use SSH config files or a command line option to have a password hard coded and I'm sure this is by design.
If you environment makes this difficult, perhaps it would be helpful to know that the script can specify an identity file using the -i argument so you don't have to have a whole home directory setup or anything like that. There are other options that help use the key authentication that ssh really encourages over password authentication.
If you are using this across several users who you don't want to be bothered to create keys and copy them to the server, you could script that also. It wouldn't be hard to check for an existing key and do a quick test to see if you can make a connection with it. If you can't without a password, then you'd ssh-copy-id to the server asking for the ssh password that one time and at the beginning of the script so very little lag would occur between starting and running the script and it would be only once. You could even setup a separate key for each user for just the script in their own ~/.script/key/ directory so that you would discourage users access to the SSH server.
If you want to really restrict what can be done on the remote server by that user, you could use rssh as the shell on the remote account which will limit the user access to transferring files.
A good way we did this in the past to provide passwords to needed scripts when using key based authentication was impossible or needed to use passwords for apps, services, mysql, whatever...we stored passwords in an encrypted file and then decrypted this file at runtime to provide the password to the scripts.
The password decryption script, let's call it, yourcreds.rb, was restricted to root use only of course and the unencrypted passwords wern't stored anywhere. So for example you could run:
root#host:~# yourcreds.rb | grep mysql | awk {'print $3'}
Which without awk would for example output the stored line:
service | user | password | description | etc...
mysql mysqluser password ....
With yourcreds.rb (or whatever) you can output just the password and easily incorporate this method into scripts / cron jobs in larger or more complex environments.
Also if I remember correctly we didn't have to use grep / awk or anything. We just programmed in opts parse stuff like: yourcreds.rb list mysql or yourcreds.rb -l, etc.
We used blowfish and yamls to store the encrypted passwords. I'm sure you can be creative. Just make sure it's bullet proof to anyone but root.
I'm new to shellscripting (and not well traveled in the world of Linux) and are trying to get a shellscript to automaticly log into an sftp server with my given. Now this is how far I've gotten
#!/bin/bash
HOST='somehost.com'
USER='someusername'
PASSWD='somepass'
sftp $USER#$HOST
Now this is where I run into trouble. At this point I will be prompted for a password. So how do I get the script to automaticly reply with the password when prompted for it? I also tried finding a way to pass along the password with the sftp command, but with no luck. Can anyone help me figure this out?
Use this code:
#!/bin/bash
HOST='somehost.com'
USER='someusername'
PASSWD='somepass'
echo $PASSWD | sftp $USER#$HOST
It's not a good idea to include the password in a command line or such a script. Anyone who has access to the list of running processes could see your password, it could end up in your shell history and log files. So this would create a security hole.
There is more info in this thread where key based authentication is recommended over your proposed method.
Do not store passwords in script files, unless you are compulsive obsessive about keeping your permissions absolutely tight.
For all things ssh/sftp/scp, use public key authentication. Learn about the settings you can set on both the client and the server ends to make it more secure (ip restrictions, user restrictions, cipher restrictions, number of retries, number of simultaneous logins, etc) That alone should eliminate a lot of insecurity due to scripting issues.
If you absolutely must store a password in a variable, do not export it, and unset it the moment you get done using it.
on local host (where the script will be executed) generate ssh key pair:
scriptuser#scripthost:/~$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/michal/.ssh/id_rsa): {press ENTER!}
(...)
copy generated public key from scripthost to the somehost.com and append it to the list of authenticated hosts:
scriptuser#scripthost:/~$ cat ~/.ssh/id_rsa.pub | ssh someuser#somehost.com 'cat >> .ssh/authorized_keys'
now you should be able to use scp or sftp without password:
scriptuser#scripthost:/~$ scp /any/local/file someuser#somehost.com:/remote/location/
use sshpass command.
you can give password along with command
system("ssh test.host.com");
its asking for permentaly add key or not ?
I want automatically it should say yes !
The fact that ssh asks if you want to connect even if the host's public key isn't checked yet is the result of having StrictHostKeyChecking ask (or yes) in your /etc/ssh/ssh_config or ~/.ssh/config. You can set it to no if you want to automatically add unknown host keys to your known_hosts file. If you don't want to make this a permanent configuration change, you can also use it on the command line:
system("ssh -o StrictHostKeyChecking=no test.host.com");
In either case, ssh will issue a warning on host key mismatches an will disable password authentication because of possible man-in-the-middle attacks. You can still login with public-key authentication.
Someone has to agree that the first key is valid. You could require users to add the pertinent information to ~/.ssh/known_hosts manually (or do it yourself).
Run the SSH Agent before you start your application and use it to add a key (option in the menu on Windows or use ssh-add from the command line on Unix).
As Nathon mentioned the right way to fix this is to get the hosts key in your list of known keys. The simple way is to ssh to the host once manually and answer yes and then the key will be cached in $HOME/.ssh/known_hosts. This has to be done for each host you will connect to and for each user that will run the program. If you have admin rights on the system your running ssh from you can also add the host keys to /etc/ssh/ssh_known_hosts to make them available to all users.
If you don't know what host the script will connect to you might need to look into a module like Expect to watch for and respond to the host key prompt. Although automating this step subverts some of the security ssh provides.
Typically in a large network a computer needs to operate behind an authenticated proxy - any connections to the outside world require a username/password which is often the password a user uses to log into email, workstation etc.
This means having to put the network password in the apt.conf file as well as typically the http_proxy, ftp_proxy and https_proxy environment variables defined in ~/.profile
I realise that with apt.conf that you could set chmod 600 (which it isn't by default on Ubuntu/Debian!) but on our system there are people who need root priveleges .
I also realise that it is technically impossible to secure a password from someone who has root access, however I was wondering if there was a way of obscuring the password to prevent accidental discovery. Windows operates with users as admins yet somehow stores network passwords (probably stored deep in the registry obscured in some way) so that in typical use you won't stumble across it in plain text
I only ask since the other day, I entirely by accident discovered somebody elses password in this way when comparing configuration files across systems.
#monjardin - Public key authentication is not an alternative on this network I'm afraid. Plus I doubt it is supported amongst the majority of commandline tools.
#Neall - I don't mind the other users having web access, they can use my credentials to access the web, I just don't want them to happen across my password in plain text.
With the following approach you never have to save your proxy password in plain text. You just have to type in a password interactively as soon as you need http/https/ftp access:
Use openssl to encrypt your plain text proxy password into a file, with e.g. AES256 encryption:
openssl enc -aes-256-cbc -in pw.txt -out pw.bin
Use a (different) password for protecting the encoded file
Remove plain text pw.txt
Create an alias in e.g. ~/.alias to set your http_proxy/https_proxy/ftp_proxy environment variables (set appropriate values for $USER/proxy/$PORT)
alias myproxy='PW=`openssl aes-256-cbc -d -in pw.bin`; PROXY="http://$USER:$PW#proxy:$PORT"; export http_proxy=$PROXY; export https_proxy=$PROXY; export ftp_proxy=$PROXY'
you should source this file into your normal shell environment (on some systems this is done automatically)
type 'myproxy' and enter your openssl password you used for encrypting the file
done.
Note: the password is available (and readable) inside the users environment for the duration of the shell session. If you want to clean it from the environment after usage you can use another alias:
alias clearproxy='export http_proxy=; export https_proxy=; export
ftp_proxy='
I did a modified solution:
edit /etc/bash.bashrc and add following lines:
alias myproxy='read -p "Username: " USER;read -s -p "Password: " PW
PROXY="$USER:$PW#proxy.com:80";
export http_proxy=http://$PROXY;export Proxy=$http_proxy;export https_proxy=https://$PROXY;export ftp_proxy=ftp://$PROXY'
From next logon enter myproxy and input your user/password combination! Now work with sudo -E
-E, --preserve-env
Indicates to the security policy that the user wishes to reserve their
existing environment variables.
e.g. sudo -E apt-get update
Remark: proxy settings only valid during shell session
There are lots of ways to obscure a password: you could store the credentials in rot13 format, or BASE64, or use the same password-scrambling algorithm that CVS uses. The real trick though is making your applications aware of the scrambling algorithm.
For the environment variables in ~/.profile you could store them encoded and then decode them before setting the variables, e.g.:
encodedcreds="sbbone:cnffjbeq"
creds=`echo "$encodedcreds" | tr n-za-mN-ZA-M a-zA-Z`
That will set creds to foobar:password, which you can then embed in http_proxy etc.
I assume you know this, but it bears repeating: this doesn't add any security. It just protects against inadvertently seeing another user's password.
Prefer applications that integrate with Gnome Keyring. Another possibility is to use an SSH tunnel to an external machine and run apps through that. Take a look at the -D option for creating a local SOCKS proxy interface, rather than single-serving -L forwards.
Unless the specific tools you are using allow an obfuscated format, or you can create some sort of workflow to go from obfuscated to plain on demand, you are probably out of luck.
One thing I've seen in cases like this is creating per-server, per-user, or per-server/per-user dedicated credentials that only have access to the proxy from a specific IP. It doesn't solve your core obfuscation problem but it mitigates the effects of someone seeing the password because it's worth so little.
Regarding the latter option, we came up with a "reverse crypt" password encoding at work that we use for stuff like this. It's only obfuscation because all the data needed to decode the pw is stored in the encoded string, but it prevents people from accidentally seeing passwords in plain text. So you might, for instance, store one of the above passwords in this format, and then write a wrapper for apt that builds apt.conf dynamically, calls the real apt, and at exit deletes apt.conf. You still end up with the pw in plaintext for a little while, but it minimizes the window.
Is public key authentication a valid alternative for you?
As long as all three of these things are true, you're out of luck:
Server needs web access
Users need absolute control over server (root)
You don't want users to have server's web access
If you can't remove #2 or #3, your only choice is to remove #1. Set up an internal server that hosts all the software updates. Keep that one locked down from your other users and don't allow other servers to have web access.
Anything else you try to do is just fooling yourself.
we solved this problem by not asking for proxy passwords on rpm, apt or other similar updates (virus databases, windows stuff etc)
That's a small whitelist of known repositories to add to the proxy.
I suppose you could create a local proxy, point these tools through that, and then have the local proxy interactively ask the user for the external proxy password which it would then apply. It could optionally remember this for a few minutes in obfuscated internal storage.
An obvious attack vector would be for a privileged user to modify this local proxy to do something else with the entered password (as they could with anything else such as an email client that requests it or the windowing system itself), but at least you'd be safe from inadvertent viewing.