passwords prompted a lot of times

[Borja Martín]

Hi,
I'm trying to deploy my application using Capistrano and using Git as
the scm. The 'problem' I've found is that the passwords(for the remote
server and the git repository) are asked a lot times, about six times
for the remote server and two for the server the git repository is
located. It's the first time I use Capistrano 2.x and I hadn't this
problem with the older version, as it just asked one time for the sshd
server an another one for the svn realm repository.
Is this the usual behaviour?
Besides that, the project seems to be deployed correctly...

This is the recipe I'm using:

###
set :application, "jornadas-uem"
set :repository, "g...@dagi3d.net:/www/git/jornadas-uem.git"
set :port, 23
set :scm, :git
set :deploy_via, :remote_cache
set :user, "deployer"
set :deploy_to, "/var/www/jornadas-uem"
set :use_sudo, false
set :scm_verbose, true

role :app, "remote_host"
###

Regards

[Mislav Marohnić]

On Tue, Oct 21, 2008 at 13:19, Borja Martín <bor...@dagi3d.net> wrote:

Hi,
I'm trying to deploy my application using Capistrano and using Git as
the scm. The 'problem' I've found is that the passwords(for the remote
server and the git repository) are asked a lot times, about six times
for the remote server and two for the server the git repository is
located.

Yeah, that's expected if you use passwords for authentication. Don't use them (especially with git) since they will make your deployments a misery.

Generate a personal SSH key. Append the public part of the key in ".ssh/authorized_keys" on all your deployment servers and for the "git" user on dagi3d.net.

Now load the key in your agent (that depends on your environment -- OS X will do it automatically on first operation). To check if it's working, login to your deployment server. It shouldn't ask you for a password anymore. Then logout and try to pull from the git repo. It also shouldn't ask you for a password.

Next, set up ssh agent forwarding. Put something like this into your local ".ssh/config" (supposing you deploy to "example.com" with the "deploy" user):

Host example.com

  User deploy

  ForwardAgent yes

Now, login to the deployment server with "ssh example.com". Then, pull from your git repo *while on* the remote server. It also shouldn't ask you for your password because it uses your ssh key that was forwarded from your local machine.

[Borja Martín]

Hi Milav,
eventually I did it as you suggested and it worked like charm :)
Thanks

Regards

Mislav Marohnić escribió:

[David Masover]

If there is a way to tell Capistrano to use agent forwarding, I'd do that instead of modifying your global SSH config. I would guess it would be something like:

set :ssh_options, {
  :user => 'deploy'
  :forward_agent => true
}

(Untested...)

Agent forwarding is allowing the remote user to do anything as you for a limited amount of time. That's a security issue -- difficult to exploit, but an issue nonetheless.

For example: My SSH key has access to both the user the application runs as, and root. There's a reason we don't run applications as root -- but this gives that user the ability, temporarily, to obtain root.

[Mislav Marohnić]

On Wed, Oct 22, 2008 at 16:41, David Masover <da...@3mix.com> wrote:

For example: My SSH key has access to both the user the application runs as, and root. There's a reason we don't run applications as root -- but this gives that user the ability, temporarily, to obtain root.

Uh, you shouldn't log in as root. That's bad practice. Sysadmins often deny the root user login rights. You should use a user that's a sudo-er for administrative tasks. 

[David Masover]

First: Sudo is annoying, for this purpose. I've got passwordless SSH to all sorts of places, and yes, my key file is encrypted. If I can login as every user except root, I can still do quite a lot of damage.

So, even if they can't get root, it provides a means for one application to steal another application's user, or for a sandbox experiment to jump into an application user. Me not logging in as root doesn't address the root cause (so to speak).

Second: What does sudo actually buy, in terms of security? I am the admin. I built the virtual machine image. If I want to cause problems, nothing is going to stop me. All this would do is annoy me, pretty much like Vista's UAC.

I understand the purpose of sudo on a desktop machine, but often, I end up doing 'sudo su -' anyway. So I consider ssh-ing as root to be a similar action -- it's like sudoing, but less annoying.

Now, for the automated stuff, sure -- I should be using sudo, and I should have specific tasks as exceptions. Automate as much as possible, and run as little as possible as root.

But sometimes, you just have to edit fstab, or add users, or muck with MySQL permissions, or copy some files (or change ownership on them), or distribute SSH keys, or a dozen other things you didn't plan for, and don't have a dedicated script to automate.

[Gaveen Prabhasara]

Hi,

I'm not going to elaborate on anything, but I'd rather point
out a thing about sudo.

On Wed, Oct 22, 2008 at 10:39 PM, David Masover <da...@3mix.com> wrote:

On Wed, Oct 22, 2008 at 9:55 AM, Mislav Marohnić <mislav....@gmail.com> wrote:

On Wed, Oct 22, 2008 at 16:41, David Masover <da...@3mix.com> wrote:

For example: My SSH key has access to both the user the application runs as, and root. There's a reason we don't run applications as root -- but this gives that user the ability, temporarily, to obtain root.

Uh, you shouldn't log in as root. That's bad practice. Sysadmins often deny the root user login rights. You should use a user that's a sudo-er for administrative tasks.

First: Sudo is annoying, for this purpose. I've got passwordless SSH to all sorts of places, and yes, my key file is encrypted. If I can login as every user except root, I can still do quite a lot of damage.

sudo is annoying, and it's desgined to be annoying. :) Keyfile
authentication is ok. As a pactice I never use key based SSH
authentication outside of a LAN. The point is carrying around
or keeping the key files out side doesn't make me comfortable.
Encrypted keyfiles are better, but you endup with passwords
again. :)

So, even if they can't get root, it provides a means for one application to steal another application's user, or for a sandbox experiment to jump into an application user. Me not logging in as root doesn't address the root cause (so to speak).

Not sure what you mean.

Second: What does sudo actually buy, in terms of security? I am the admin. I built the virtual machine image. If I want to cause problems, nothing is going to stop me. All this would do is annoy me, pretty much like Vista's UAC.

sudo is not like Vistas UAC, at least not what I've seen in my
little Vista exposure. Please see below.

I understand the purpose of sudo on a desktop machine, but often, I end up doing 'sudo su -' anyway. So I consider ssh-ing as root to be a similar action -- it's like sudoing, but less annoying.

How sudo differs significantly and how to stop 'sudo su -'
is to use sudo sparingly. For example rather than using
capuser    ALL=(ALL) ALL
you could try specifiying which commands to have super
user privileges. Allowing all commands the privileges
wouldn't give much advantage as you said, probably
other than the security of obscurity. I've tried Capistrano
with selective sudo privileges. It's a little work, but it
works.

Now, for the automated stuff, sure -- I should be using sudo, and I should have specific tasks as exceptions. Automate as much as possible, and run as little as possible as root.

But sometimes, you just have to edit fstab, or add users, or muck with MySQL permissions, or copy some files (or change ownership on them), or distribute SSH keys, or a dozen other things you didn't plan for, and don't have a dedicated script to automate.

Thanks for voicing many admins. Yes, there are manual
work required usually on production systems. They may
be not as glorious as running two commands and finishing,
but I'd rather rather manually grant a single db user with
minimal privileges needed. :)