Mam publiczne i prywatne klucze ssh na wszystkich moich trzech serwerach (programistycznym, UAT i produkcyjnym), dzięki czemu mogę logować się zdalnie lub z jednego do drugiego. Wszystko działa idealnie dla poleceń sshi scp.
Nie działa to jednak w przypadku Drusha. drush @dev statusNa przykład, jeśli wykonam z UAT, dostaję sztandar serwera z informacją, że system ma być „używany tylko przez autoryzowanych użytkowników bla bla bla ”
Odmowa dostępu (klucz publiczny, hasło, klawiatura interaktywna).
Mój ~/.drush/aliases.drushrc.phpplik zawiera:
# Development #
$aliases['dev'] = array(
'uri' => 'http://default',
'root' => '/var/www/vhosts/dev.www.company.com/current/',
'remote-host' => 'companya0.company.com',
'remote-user' => 'myusername'
);
# UAT #
$aliases['uat'] = array(
'uri' => 'http://default',
'root' => '/var/www/vhosts/uat.www.company.com/current/',
'remote-host' => 'companyc6.company.com',
'remote-user' => 'myusername'
);
# Production #
$aliases['prod'] = array(
'uri' => 'http://default',
'root' => '/var/www/vhosts/www.company.com/current/',
'remote-host' => 'companyc1.company.com',
'remote-user' => 'myusername'
);TYLKO Drush ma problem z używaniem moich kluczy ssh. Co może przeszkadzać w jego działaniu?
Uruchom polecenia drush z opcją -v lub -s, aby zobaczyć dokładne polecenie ssh generowane przez Drusha. Powinno być jasne, jaka jest różnica między wywołaniem Drsh przez ssh a twoim testem cli tego samego.
—
greg_1_anderson
@Chapabu: Tak, muszę użyć
—
iconoclast
sudowcześniej drushi wydaje się, że wszystko działa jako root (dziura w zabezpieczeniach, o której powiadomiłem sysadmin). Wygląda na to, że to jest problem. Obecnie szukam rozwiązania , czekając na sysadmin ...
www-data(na przykład), twoje klucze SSH mogą być niepoprawne / zabronione / nie umieszczone na białej liście.