[Capistrano/Git] Deployen hangt op password na tweede deploy

[Nila]

Ik ben aan het experimenteren met het deployen van een website via Capistrano. En dit lukt zover maar als ik kort na de eerste deployment nogmaals het project deploy dan blijft het proces hangen op connectie met de git
server (wachtwoord).

In de onderstaande situatie heb ik de paden en applicatienaam voorzien van placeholders.

Het gaat nu alleen even over deployen naar de staging server. Overigs ben ik vrij nieuw met deze workflow dus mochten jullie uit ervaring tips of verbeteringen hebben sta ik hier uiteraard voor open.

Relevante software en hardware die ik gebruik:
Capistrano
Git
Commandline (Terminal)

De situatie:

Git Server:
Develop branch
Master branch

Lokaal word per bug of task een aparte branch gemaakt, zodra de bugfix of task correct is uitgevoerd en gecontroleerd worden deze lokaal gemerged in de develop branch. En gepushed naar de git server.

Staging Server:
Om het project te kunnen beoordelen en controleren maak ik gebruik van een staging omgeving identiek aan de live omgeving.

Production Server:
Uiteindelijk nadat staging geheel akkoord is en alle tickets in het ticket systeem zijn afgehandeld merg ik alles in de master branch en zet ik versie tag (1.0.0) voor deze en gaat het project live.

Capistrano:

capfile

code:

# Load DSL and set up stages
require "capistrano/setup"

# Include default deployment tasks
require "capistrano/deploy"

# Load custom tasks from `lib/capistrano/tasks` if you have any defined
Dir.glob("lib/capistrano/tasks/*.rake").each { |r| import r }

config/deploy.rb

code:

set :keep_releases, 10 # or any other number of releases you would like to keep
set :ssh_options, {
    forward_agent: true,
    port: 22
}

set :pty, true
set :format, :pretty
set :log_level, :debug

set :application, "Naam van Appicatie" # set the name of you application here

set :stages, ["staging", "production"] # Set staging and production environment
set :default_stage, "staging" # Use staging environment as the default one to prevent accidentally deploying to production

set :deploy_via, :remote_cache # it will only fetch from the repository on server, not clone the entire repository from scratch

set :use_sudo, false # do not use sudo

# Git
set :scm, :git # set git as a Source Code Manager
set :repo_url, "ssh://pad-naar-git-locatie.git"

set :branch, "develop" # set git branch here

# Serverrole
role :web, "[e-mail]" # HTTP Server
role :app, "[e-mail]" # server with your app
role :db,  "[e-mail]", :primary => true # database server
role :db,  "[e-mail]"

config/deploy/staging.rb

code:

set :tmp_dir, "/pad-naar-staging-locatie/applicatienaam/tmp"
set :deploy_to, "/pad-naar-staging-locatie/applicatienaam"

Eerste keer deployen met (cap staging deploy) gaat goed. als ik vlak daarna opnieuw wil deployen hangt hij dus op password.

code:

cap staging deploy --trace
** Invoke staging (first_time)
** Execute staging
** Invoke load:defaults (first_time)
** Execute load:defaults
** Invoke deploy (first_time)
** Execute deploy
** Invoke deploy:starting (first_time)
** Execute deploy:starting
** Invoke deploy:check (first_time)
** Execute deploy:check
** Invoke git:check (first_time)
** Invoke git:wrapper (first_time)
** Execute git:wrapper
INFO [f1c58664] Running /usr/bin/env mkdir -p /pad-naar-staging-locatie/applicatienaam/tmp/ as [e-mail]
DEBUG [f1c58664] Command: /usr/bin/env mkdir -p /pad-naar-staging-locatie/applicatienaam/tmp/
Password:*************
INFO [f1c58664] Finished in 3.083 seconds with exit status 0 (successful).
DEBUG Uploading /pad-naar-staging-locatie/applicatienaam/tmp/git-ssh.sh 0.0%
INFO Uploading /pad-naar-staging-locatie/applicatienaam/tmp/git-ssh.sh 100.0%
INFO [abe882ed] Running /usr/bin/env chmod +rx /pad-naar-staging-locatie/applicatienaam/tmp/git-ssh.sh as [e-mail]
DEBUG [abe882ed] Command: /usr/bin/env chmod +rx /pad-naar-staging-locatie/applicatienaam/tmp/git-ssh.sh
INFO [abe882ed] Finished in 0.014 seconds with exit status 0 (successful).
** Execute git:check
INFO [9f4b3e07] Running /usr/bin/env git ls-remote --heads ssh://pad-naar-git-locatie.git as [e-mail]
DEBUG [9f4b3e07] Command: ( export GIT_ASKPASS="/bin/echo" GIT_SSH="/pad-naar-staging-locatie/applicatienaam/tmp/git-ssh.sh" ; /usr/bin/env git ls-remote --heads ssh://pad-naar-git-locatie.git )
DEBUG [9f4b3e07]    Password:

Overigs als je enige tijd wacht 20+ min en opnieuw het deploy command uitvoer deployed hij gewoon naar de staging server.

Mocht ik iets vergeten zijn zal ik dit aanvullen indien nodig.

[xleeuwx]

Wij gebruiken voor de deployments ssh-keys, zodat je van de wachtwoorden geneuzel af bent ( wordt ook aangeraden door capistrano)

Ik verwacht dat de client waar cap [branch] deploy wordt gedraaid geen toegang heeft met ssh-key.

Om even wat meer duidelijkheid te krijgen:
- Welke Gitserver gebruik je
- waar vandaan wordt gedeployed ("cap staging deploy")


In het meest ergste geval (liever natuurlijk geen wachtwoorden in je code / config), dit kan je natuurlijk wel even gebruiken om te testen. :
http://capistranorb.com/d...o-prompt-for-a-password/#

[ Voor 46% gewijzigd door xleeuwx op 06-05-2016 11:40 . Reden: Bron gewijzigd ]

[Nila]

xleeuwx schreef op vrijdag 06 mei 2016 @ 11:37:
Wij gebruiken voor de deployments ssh-keys, zodat je van de wachtwoorden geneuzel af bent ( wordt ook aangeraden door capistrano)

Ik verwacht dat de client waar cap [branch] deploy wordt gedraaid geen toegang heeft met ssh-key.

De eerste keer doet hij het wel, maar ik ga is even wat research doen naar ssh-keys.

Ik maak gebruik van Souretree om met de git server te connecten, en te mergen, pullen en pushen enz. Als ik connect met een nieuwe repository hoef ik overigs geen wachtwoord in te voeren.

Om even wat meer duidelijkheid te krijgen:
- Welke Gitserver gebruik je
- waar vandaan wordt gedeployed ("cap staging deploy")

OS X 10.11.4 (Build 15E65), Server 5.1 (Build 15S5127) - Via de servertool maak ik in xcode repository in.
Daarbij deploy ik van mijn lokale machine.

In het meest ergste geval (liever natuurlijk geen wachtwoorden in je code / config), dit kan je natuurlijk wel even gebruiken om te testen. :
http://capistranorb.com/d...o-prompt-for-a-password/#

Ga even nalazen, misschien heb ik iets over het hoofd gezien

[base_]

In het kort: een private/public key aanmaken en de public key op de server in ~/.ssh/authorized_keys zetten.
Na installatie moet ssh <user>@<server> niet meer om een password vragen omdat hij jouw key bij het verbinden gebruikt en jouw public key in authorized keys staat van de betreffende user op de server..
https://coolestguidesonth...passwords-osx-10-6-linux/

[xleeuwx]

Nila schreef op vrijdag 06 mei 2016 @ 12:35:
[...]


De eerste keer doet hij het wel, maar ik ga is even wat research doen naar ssh-keys.

Ik maak gebruik van Souretree om met de git server te connecten, en te mergen, pullen en pushen enz. Als ik connect met een nieuwe repository hoef ik overigs geen wachtwoord in te voeren.


[...]


OS X 10.11.4 (Build 15E65), Server 5.1 (Build 15S5127) - Via de servertool maak ik in xcode repository in.
Daarbij deploy ik van mijn lokale machine.


[...]


Ga even nalazen, misschien heb ik iets over het hoofd gezien

Het allerbelangrijkste is dat je kan deployen zonder wachtwoord in te moeten voeren, dit kan als beste bereikt worden door een met een plubic key in te loggen.

De staging server moet ook bij je git repository kunnen en je moet dus ook de plubic key van de server in je git repository kunnen pullen.

Beste is om even met SSH in je server (staging als ik het goed had) te gaan en dan naar de root van de het project toe en daar git pull te typen.

Verder moet de computer / server waarvandaan de cap [stage] deploy wordt aangeroepen ook ssh toegang hebben tot de server waarnaar toe gedeployed wordt.

Een handige tool hiervoor is ssh-copy-id:
linux: link
mac: link

Als ik je output van van je deploy bekijk:

code:

cap staging deploy --trace

Dan lijkt het er op of de server waar naar toe gedeployed wordt geen toegang heeft tot je git repository (met public key).

ps. sourcetree is een client geen server bitbucket / gitlab / github etc zijn servers.

[ Voor 8% gewijzigd door xleeuwx op 06-05-2016 13:04 ]

[Nila]

base_ schreef op vrijdag 06 mei 2016 @ 12:49:
In het kort: een private/public key aanmaken en de public key op de server in ~/.ssh/authorized_keys zetten.
Na installatie moet ssh <user>@<server> niet meer om een password vragen omdat hij jouw key bij het verbinden gebruikt en jouw public key in authorized keys staat van de betreffende user op de server..
https://coolestguidesonth...passwords-osx-10-6-linux/

Mijn public key is toegevoegd aan ~/.ssh/authorized_keys op de stagingserver. Maar vraagt na het sluiten van de terminal en opnieuw connecten met de server naar mijn wachtwoord.

xleeuwx schreef op vrijdag 06 mei 2016 @ 13:01:
[...]

Dan lijkt het er op of de server waar naar toe gedeployed wordt geen toegang heeft tot je git repository (met public key).

Dat idee heb ik, maar de eerste keer pulled hij de develop branch en zet deze op de stagingserver. Dan verschijnt er in de release map ook een nieuwe versie en verwijst de current symlink naar de die versie.

Edit:
Ik maak gebruik van -> forward_agent: true
Dit wil toch zeggen dat mijn lokale keys moeten worden gebruikt?

[ Voor 5% gewijzigd door Nila op 06-05-2016 14:25 ]

[base_]

Nila schreef op vrijdag 06 mei 2016 @ 14:04:
[...]
Mijn public key is toegevoegd aan ~/.ssh/authorized_keys op de stagingserver. Maar vraagt na het sluiten van de terminal en opnieuw connecten met de server naar mijn wachtwoord.
[...]

gebruik je de juiste user om mee te verbinden?
staat de authorized_keys op de server ook onder die user? (username@@/.ssh
staan de rechten van de bestanden juist? (600 + user=owner meen ik)
ik ben minder doorgewinterd in osx dus exacte paden weet ik niet maar onder de userfolder van de user die je gebruikt staat de juiste .ssh/authorized_keys (meestal niet onder de root user dus)

[Nila]

base_ schreef op vrijdag 06 mei 2016 @ 14:57:
[...]

gebruik je de juiste user om mee te verbinden?
staat de authorized_keys op de server ook onder die user? (username@@/.ssh
staan de rechten van de bestanden juist? (600 + user=owner meen ik)
ik ben minder doorgewinterd in osx dus exacte paden weet ik niet maar onder de userfolder van de user die je gebruikt staat de juiste .ssh/authorized_keys (meestal niet onder de root user dus)

Rechten staan inderdaard op 600:
chmod 700 .ssh
chmod 600 .ssh/authorized_keys

Als ik SSH naar de server met user kom ik uit in:
Users/Shared Hierin bevind zicht een .ssh map inclusief een authorized_keys file met mijn public key

Verder is er admin account een guest account. Ik heb ook de authorized_keys files in het admin account voorzien van mijn public key. Maar helaas geen succes.

[ Voor 4% gewijzigd door Nila op 06-05-2016 15:24 ]

[base_]

Vreemd, volgens mij moet je via bijvoorbeeld ssh kees@<server> in /Users/kees/ terechtkomen?
Een Users/Shared is niet voor een specifieke user en lijkt me niet de juiste locatie: die key moet aan een specifieke user gekoppeld zijn.
Heeft de user wel een home of is het een ssh only user?
Wat ik ook nog wel eens doe is voor git repo user de home van die user op de git repo folder zetten (en alleen git toestaan, shell disablen), verder in de git repo een .ssh folder met de betreffende authorized_keys.

[Nila]

base_ schreef op vrijdag 06 mei 2016 @ 15:30:
Vreemd, volgens mij moet je via bijvoorbeeld ssh kees@<server> in /Users/kees/ terechtkomen?
Een Users/Shared is niet voor een specifieke user en lijkt me niet de juiste locatie: die key moet aan een specifieke user gekoppeld zijn.
Heeft de user wel een home of is het een ssh only user?
Wat ik ook nog wel eens doe is voor git repo user de home van die user op de git repo folder zetten (en alleen git toestaan, shell disablen), verder in de git repo een .ssh folder met de betreffende authorized_keys.

Het was dus een ssh only user. Had geen home map. Ik heb in de servertool van OSX de instellingen veranderd van die user. En hier .ssh/authorized_keys aangemaakt met mijn public key. Nu kan ik inloggen zonder wachtwoord prompt.

echter loopt hij nog steeds vast op:

code:

INFO [9e79d212] Running /usr/bin/env git ls-remote --heads ssh://pad-naar-git-locatie.git as [e-mail]
DEBUG [9e79d212] Command: ( export GIT_ASKPASS="/bin/echo" GIT_SSH="/pad-naar-staging-locatie/applicatienaam/tmp/applicatienaam/git-ssh.sh" ; /usr/bin/env git ls-remote --heads ssh://pad-naar-git-locatie.git )
DEBUG [9e79d212]    Password:

edit:
Zou ik dan misschien ook in .ssh/authorized_keys de public key van de git server moeten zetten?

[ Voor 4% gewijzigd door Nila op 06-05-2016 17:11 ]

[H!GHGuY]

Het probleem zit em in die 'GIT_ASKPASS="/bin/echo"'. Git zal echo uitvoeren om het paswoord te verkrijgen. Dit print gewoon een lege lijn en dan is het uit met de pret.

Ik vermoed dat deze lijn iets moet zijn als 'GIT_ASKPASS="/bin/echo password"'. Je zal dus even moeten kijken van waar het paswoord gehaald moet worden om in te vullen.

[base_]

Er hoeft geen password meer ingevuld te worden, hij gebruikt de ssh key van de user.
Heeft het misschien iets hiermee te maken: http://www.rubyfleebie.co...p-deploy-with-capistrano/ ?

[Bigs]

Heb je wel ssh agent forwarding aan staan? Zowel op je lokale systeem als op de server waar je naartoe deployt? Anders gaat het niet werken.

Je kunt dit testen door te ssh'en naar je depoy omgeving en vanuit daar te ssh'en naar je git account (bv. 'ssh [e-mail]').

Zie bvb: https://developer.github....ing-ssh-agent-forwarding/

[ Voor 12% gewijzigd door Bigs op 07-05-2016 10:54 ]

[base_]

die staat hier ook bij idd: https://snippets.aktagon....r-password-when-deploying

[Nila]

Heeft even stil gelegen vanwege het goede weer, maar denk dat het probleem ligt dat de staging server inderdaad de tweede keer om een wachtwoord vraag. Ga hier mee testen en ssh forwarding werkt nu met lokale client naar staging. Nu moet staging nog bij de git server kunnen binnen komen zonder wachtwoord.

Edit:
Ik snap er de ballen niet meer van, dit is de situatie momenteel:

Er is een aparte user aangemaakt -> gituser

Ik cd naar mijn project, en hier doe ik -> cap staging deploy --trace

Capistrano SSH't met de gebruiker gituser naar de staging server, en maakt indien nodig hier de juiste folders/bestanden aan -> Hoef geen wachtwoord in te voeren.

Capistrano SSH't met de gituser in de git server en pulled hier de juiste branch. Hoef geen wachtwoord in te voeren.

Geen vuiltje aan de lucht. Alles werkt. Wil ik 3 minuten later nog een deploy doen (nieuwe release). Hierna komt hij met onderstaande aan:

code:

INFO [9e79d212] Running /usr/bin/env git ls-remote --heads ssh://pad-naar-git-locatie.git as [e-mail]
DEBUG [9e79d212] Command: ( export GIT_ASKPASS="/bin/echo" GIT_SSH="/pad-naar-staging-locatie/applicatienaam/tmp/applicatienaam/git-ssh.sh" ; /usr/bin/env git ls-remote --heads ssh://pad-naar-git-locatie.git )
DEBUG [9e79d212]    Password:

Wacht ik een half uur tot een uur en ik doe weer een deploy dan doet alles het weer en maakt Capistrano netjes een nieuwe release aan. Maar als ik kort daarna weer een deploy wil doen dan krijg ik het zelfde....

[ Voor 66% gewijzigd door Nila op 10-05-2016 15:38 ]