Hi I am accessing a repository through a URL of type svn+ssh://
Reading the following quote from SVN and SSH from Adobe I am a little confused
"Before you configure Subversion or Dreamweaver for SVN+SSH, create an RSA key pair and configure the public key on the server. This public/private key pair is used to authenticate with the server, instead of storing and passing your password in plain text."
So if I just acces a repository by svn+ssh:// pe. from command line, my password is send in clear text ? I thought part of ssh was to encrypt the password, no ?
Maybe I was unclear, I have not generated any keypairs so use my password every time, does that change anything or is the quote written in confusing way ? Thank you.
Part of ssh is to encrypt everything, not just your password. So, your password would not be going over the wire in plain text.
SSH never sends passwords in plain text. However, non-SSH protocols such as svn:// may send the password in plain text. Adobe is recommending that users use SSH. Adobe also recommends that if SSH is used, then RSA key pairs are also used. Key pairs are easier because you don't have to keep typing your password for every operation (when used with an SSH agent).
There is no password at all in this case. All authentication happens based on key pair. One key is on your client machine, another one lies on the server. All traffic is also encrypted.
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.
I have a shell script that starts a For loop, reads from a text file with hostnames, and uses SCP to transfer files to each host. It's been very useful but what is the best way to deal with the password prompt? The only authentication I was given to the servers were a username and password.
As of now, I've had to input my password for each server. It's been duoable since the server count is low but I'd like to have a better solution in the future. Any help/suggestions would be great.
Thanks!
Most servers also support publickey authentication. Generate a keypair on your local host, then copy the ~/.ssh/id_rsa_pub to remote host's ~/.ssh/authorized_keys (or append to it if it already exists). Deal with the keyphrase locking your secret key by using ssh-agent.
For this kind of interactive action you can use Expect scripts. You can easily define a remote call where you expect for a especific string (f.e "username:") and then send the known password.
I need to write a shell script that will login to the linux servers that have key pair and pass phrase both.
Any lead would be appreciated.
In my opinion in this scenario the use of a pass phrase for a key doesn't make sense. Because you have to put it somewhere in the script file more or less plain text. Then the pass phrase is not secure and from my perspective the whole key is compromised (more or less).
Maybe there's a way by using ssh-agent and register the keys to the agent.
Configuring a server with both a keypair and a password really isn't recommended (or any configuration where one has to store a passphrase on disk, for that matter).
Having said that, sshpass would probably do what you want. I assume you already know how and where to keep your keyfiles.
I configured msmtp with my gmail account.
I obviously want to avoid writing my password in plaintext format in the config file.
Luckily enough msmtp offer the option passwordeval which can be used to obtain the password from the output of an an executable.
The question is: how should I use it?
I found here the following suggestion:
passwordeval gpg -d /some/path/to/.msmtp.password.gpg
That doesn't make much sense to me: if someone is able to access my config file he will certainly manage to run such a command and obtain the password from gpg.
So I believe I'm left with the only option of obfuscating the password within the binary executable even if I read almost everywhere that this is bad!
My impossible-to-hack implementation is: if the sendmail process is running output the correct pass, otherwise give a fake pass.
Your suggestions?
Other (more secure) tricks different from storing the pass in the binary file?
From Sukima's comment:
The reason gpg -d works is because it requires the private key of the person the file is encrypted to. So just placing that encrypted file in the public it is still encrypted an only one person (the one with the secret key) can decrypt it. It is assumed that the secret key is locked up on the user's machine and not leaked. It also assumes that they have not setup any agents which cache the unlock password while a hacker has direct access to the same machine. All of which is highly unlikely in 99% of all attacks.
There is not a standard solution on how to save credentials with the constraint of
having to use the credentials in plain text later
and in an unattended way
on a system which is not completely controlled by you (if it is you just set appropriate rights on the files holding the secrets)
You have several solutions, none solves perfectly your problem:
encrypt your credentials in a symmetric way: you need to input the key to decrypt them
encrypt in an asymmetric way: you need to provide your private key, which must be stored somewhere (unattended approach) or keyed in
obfuscate: as you mention, this only protects from some population
get it from somewhere else - you need to identify a way or another your system
You need to take into account which risk is acceptable and go from there.
I found the following claim in the documentation for Net::OpenSSH:
Note that using password
authentication in automated scripts is
a very bad idea. When possible, you
should use public key authentication
instead.
What's flawed in using password authentication in automated scripts?
Passwords are easier to guess/brute force than private keys (unless you are running Debian ;)
Imagine you have a user account which runs 120 different automated scripts. If you hardcode password into each of them you now have 120 places to change it.
If you place the password into a config file and have all 120 scripts read it from the file sooner or later somebody will accidentally make that file world readable. ssh won't work when the private key is not 600.
Somebody can decide to change user's password without thinking about the possibility of it being hardcoded in some script. You are more likely to stop and think before changing the private key.
Probably because with password authentication, you have to hard code the password itself into the script or at least into some sort of configuration file.
It's never a good idea to hard code your plain ssh password i think :)
Public key authentication should always be preferred for any remote resource. It is statistically impossible to guess the challenge response and can thwart MITM attacks. Although this does not rule out the possibility of the attacker being extremely lucky.
If the attacker can read files on the remote system, the password or the private key must be in plain text and there for can be read. Asymmetric cryptography isn't a magic wand that solves all problems.
One possibility for this warning in the docs is that if you use a password and the script isn't checking the sshd's public key then a MITM attack could obtain the clear text password. You should be checking the remote servers authentication by hard-coding the public key. The ssh command on the cli does this automatically and will throw a warning if a server's key changes. If you aren't checking the authentication credentials of the remote server and you are using public key authentication then an attacker can only MITM that session because the attacker will not be able to obtain the client's private key to re-auth.