[Support] SSH fails with "PTY allocation request failed on channel 0"

[cridenour]

Here is my current run command:

sudo docker run --name=gitlab -v /opt/gitlab/data:/home/git/data \
--link mysql:mysql --link redis:redisio -e "DB_USER=gitlab" \ 
-e "DB_PASS=blahblah" -e "SMTP_DOMAIN=postmarkapp.com" \ 
-e "SMTP_HOST=smtp.postmarkapp.com" -e "SMTP_PORT=2525" \ 
-e "SMTP_USER=blahblah" -e "SMTP_PASS=blahblah" \ 
-e "GITLAB_HOST=git.domain.com" -e "GITLAB_EMAIL=gitlab@domain.com" \ 
-e "GITLAB_SUPPORT=gitlab@domain.com" -e "GITLAB_BACKUPS=daily" \ 
-e "GITLAB_HTTPS=True" -e "GITLAB_PORT=443" \ 
-v /opt/nginx/sites-enabled:/etc/nginx/sites-enabled \ 
-v /opt/nginx/ssl:/etc/nginx/ssl \ 
-v /opt/nginx/logs:/var/log/nginx \ 
-d -t -p 80:80 -p 443:443 -p 22:22 \ 
sameersbn/gitlab:latest

I'm running docker 0.10.0. When I try and ssh in with a valid key I get.

ssh git@git.domain.com
PTY allocation request failed on channel 0
Welcome to GitLab, Anonymous!
Connection to git.domain.com closed.

I understand this might be a docker issue but they seem to think it was fixed in 0.9.1. I've tried with and without -t. Hoping you can help.

[cridenour]

Turns out this was a configuration issue. Gitlab-shell had the gitlab_url defined as

gitlab_url: http://git.domain.com:443

due to my environment variables I was setting to get https to work. Changing this to the proper https://git.domain.com fixed the issue. I think I've seen talk of a proper SSL support pull request - but if not, let me know and I would be happy to help since I've been through the trouble already!

[sameersbn]

@cridenour sure that you be great. maybe you can work with @arnos for the ssl support addition.
If possible make sure that SSL works when the container is behind hipache/haproxy and supports self signed certificates.

[arnos]

The HTTPS is nearly there you can see my fork under the SSL branch.

The only thing not in place yet is an automatic redirect from http to https
(gitlab seems to support a single port at a time) and testing with http
behind hipache.

On Saturday, April 26, 2014, Sameer Naik notifications@github.com wrote:

@cridenour https://github.com/cridenour sure that you be great. maybe
you can work with @arnos https://github.com/arnos for the ssl support
addition.
If possible make sure that SSL works when the container is behind
hipache/haproxy and supports self signed certificates.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/53#issuecomment-41460110
.

[sameersbn]

@arnos i just started looking at working on SSL support today and surprisingly i think i got it working. I am testing with direct port redirection and also with haproxy. both seem to be working (still early to say, need to test further).

I had added the http to https redirection in the nginx config and it all worked fine with the direct host port redirections but not with haproxy.

# This server simply redirects HTTP connections to HTTPS
server {
  listen *:80 default_server;
  server_name {{YOUR_SERVER_FQDN}};
  server_tokens off;
  rewrite ^ https://$server_name$request_uri? permanent;
}

Instead I removed the above and configured nginx to also serve requests on port 80

server {
  listen *:80 default_server;         # e.g., listen 192.168.1.1:80; In most cases *:80 is a good idea
  server_name {{YOUR_SERVER_FQDN}};     # e.g., server_name source.example.com;
  server_tokens off;     # don't show the version number, a security best practice
  root /home/git/gitlab/public;

  # Increase this if you want to upload large attachments
  # Or if you want to accept large git objects over http
  client_max_body_size 20m;

  # individual nginx logs for this gitlab vhost
  access_log  /var/log/nginx/gitlab_access.log;
  error_log   /var/log/nginx/gitlab_error.log;

  location / {
    # serve static files from defined root folder;.
    # @gitlab is a named location for the upstream fallback, see below
    try_files $uri $uri/index.html $uri.html @gitlab;
  }

  # if a file, which is not found in the root folder is requested,
  # then the proxy pass the request to the upsteam (gitlab unicorn)
  location @gitlab {
    # If you use https make sure you disable gzip compression 
    # to be safe against BREACH attack
    # gzip off;

    proxy_read_timeout 300; # Some requests take more than 30 seconds.
    proxy_connect_timeout 300; # Some requests take more than 30 seconds.
    proxy_redirect     off;

    proxy_set_header   X-Forwarded-Proto $scheme;
    proxy_set_header   Host              $http_host;
    proxy_set_header   X-Real-IP         $remote_addr;
    proxy_set_header   X-Forwarded-For   $proxy_add_x_forwarded_for;

    proxy_pass http://gitlab;
  }

  # Enable gzip compression as per rails guide: http://guides.rubyonrails.org/asset_pipeline.html#gzip-compression
  location ~ ^/(assets)/  {
    root /home/git/gitlab/public;
    gzip_static on; # to serve pre-gzipped version
    expires max;
    add_header Cache-Control public;
  }

  error_page 502 /502.html;
}

And surprisingly it works in both cases and the http to https redirection somehow takes place. But maybe its because of some other fixes I have in place.

Should I pull your changes and apply my changes on top of it or should i just publish my work for you to review and test? What do you suggest?

[arnos]

You can pull my SSL branch as everything works and I rebased it yesterday
on your master.

I was just stuck because of ssh issue and trying to get https only working.

On Saturday, April 26, 2014, Sameer Naik notifications@github.com wrote:

@arnos https://github.com/arnos i just started looking at working on
SSL support today and surprisingly i think i got it working. I am testing
with direct port redirection and also with haproxy. both seem to be working
(still early to say, need to test further).

I had added the http to https redirection in the nginx config and it all
worked fine with the direct host port redirections but not with haproxy.

This server simply redirects HTTP connections to HTTPSserver {

listen *:80 default_server;
server_name {{YOUR_SERVER_FQDN}};
server_tokens off;
rewrite ^ https://$server_name$request_uri? permanent;}

Instead I removed the above and configured nginx to also serve requests on
port 80

server {
listen *:80 default_server; # e.g., listen 192.168.1.1:80; In most cases *:80 is a good idea
server_name {{YOUR_SERVER_FQDN}}; # e.g., server_name source.example.com;
server_tokens off; # don't show the version number, a security best practice
root /home/git/gitlab/public;

Increase this if you want to upload large attachments

Or if you want to accept large git objects over http

client_max_body_size 20m;

individual nginx logs for this gitlab vhost

access_log /var/log/nginx/gitlab_access.log;
error_log /var/log/nginx/gitlab_error.log;

location / {
# serve static files from defined root folder;.
# @GitLab is a named location for the upstream fallback, see below
try_files $uri $uri/index.html $uri.html @GitLab;
}

if a file, which is not found in the root folder is requested,

then the proxy pass the request to the upsteam (gitlab unicorn)

location @GitLab {
# If you use https make sure you disable gzip compression
# to be safe against BREACH attack
# gzip off;

proxy_read_timeout 300; # Some requests take more than 30 seconds.
proxy_connect_timeout 300; # Some requests take more than 30 seconds.
proxy_redirect     off;

proxy_set_header   X-Forwarded-Proto $scheme;
proxy_set_header   Host              $http_host;
proxy_set_header   X-Real-IP         $remote_addr;
proxy_set_header   X-Forwarded-For   $proxy_add_x_forwarded_for;

proxy_pass http://gitlab;

}

Enable gzip compression as per rails guide: http://guides.rubyonrails.org/asset_pipeline.html#gzip-compression

location ~ ^/(assets)/ {
root /home/git/gitlab/public;
gzip_static on; # to serve pre-gzipped version
expires max;
add_header Cache-Control public;
}

error_page 502 /502.html;}

And surprisingly it works in both cases and the http to https redirection
somehow takes place. But maybe its because of some other fixes I have in
place.

Should I pull your changes and apply my changes on top of it or should i
just publish my work for you to review and test? What do you suggest?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/53#issuecomment-41463910
.