Backup restore fails when non-ascii character in ssh-key

Rake task gitlab:backup:restore fails when user has added ssh-key containg non-ascii character in comment: ssh-rsa AAAA... grzegżółka@localhost.

Confirmed in versions

• 8.2 omnibus (ubuntu/trusty, debian/jessie)
• 7.11 omnibus (ubuntu/trusty)

Workaround

1. Before creating backup find and edit or remove offending keys.
2. Let restore task fail, and check in log which key is causing problem Here you can see that key 201 was added, which means that 202 failed

   $ tail /var/log/gitlab/gitlab-shell/gitlab-shell.log
   [...]
   I, [2015-12... #14170]  INFO -- : Adding key key-201 => "ssh-rsa AAA... ThisCommentIsOk"

3. If you need to restore from backup, when This will rebuild an authorized_keys [...] Do you want to continue (yes/no)? yes is asked, connect to database and manually modify keys:

   sudo -u gitlab-psql /opt/gitlab/embedded/bin/psql gitlabhq_production
   select id,user_id,created_at,title,key from keys where id = 202;
   202 |     30 | 2015-12... | key2  | ssh-rsa AAA... grzegżółka
   update keys set key='ssh-rsa AAA... CommendtRemovedByAdmin' where id=202;

If multiple keys are causing issue, you'll need to manually check database dump and keys that need to be fixed, as this method finds only first problematic key.

Steps to reproduce:

1. Install 8.2 from omnibus package
2. Add ssh-key to any user. Ssh-key comment mus contain non-ascii character: ssh-rsa AAAA...sk3d grzegżółka
3. Create backup /opt/gitlab/bin/gitlab-rake gitlab:backup:create
4. Try restoring created backup gitlab-rake gitlab:backup:restore BACKUP=1449137147

Restore will fail with following message:

[...]
This will rebuild an authorized_keys file.
You will lose any data stored in authorized_keys file.
Do you want to continue (yes/no)? yes

./opt/gitlab/embedded/service/gitlab-shell/lib/gitlab_keys.rb:58:in `split': invalid byte sequence in US-ASCII (ArgumentError)
	from /opt/gitlab/embedded/service/gitlab-shell/lib/gitlab_keys.rb:58:in `block (3 levels) in batch_add_keys'
	from /opt/gitlab/embedded/service/gitlab-shell/lib/gitlab_keys.rb:57:in `each_line'
	from /opt/gitlab/embedded/service/gitlab-shell/lib/gitlab_keys.rb:57:in `block (2 levels) in batch_add_keys'
	from /opt/gitlab/embedded/service/gitlab-shell/lib/gitlab_keys.rb:56:in `open'
	from /opt/gitlab/embedded/service/gitlab-shell/lib/gitlab_keys.rb:56:in `block in batch_add_keys'
	from /opt/gitlab/embedded/service/gitlab-shell/lib/gitlab_keys.rb:107:in `block (2 levels) in lock'
	from /opt/gitlab/embedded/lib/ruby/2.1.0/timeout.rb:90:in `block in timeout'
	from /opt/gitlab/embedded/lib/ruby/2.1.0/timeout.rb:33:in `block in catch'
	from /opt/gitlab/embedded/lib/ruby/2.1.0/timeout.rb:33:in `catch'
	from /opt/gitlab/embedded/lib/ruby/2.1.0/timeout.rb:33:in `catch'
	from /opt/gitlab/embedded/lib/ruby/2.1.0/timeout.rb:105:in `timeout'
	from /opt/gitlab/embedded/service/gitlab-shell/lib/gitlab_keys.rb:107:in `block in lock'
	from /opt/gitlab/embedded/service/gitlab-shell/lib/gitlab_keys.rb:104:in `open'
	from /opt/gitlab/embedded/service/gitlab-shell/lib/gitlab_keys.rb:104:in `lock'
	from /opt/gitlab/embedded/service/gitlab-shell/lib/gitlab_keys.rb:55:in `batch_add_keys'
	from /opt/gitlab/embedded/service/gitlab-shell/lib/gitlab_keys.rb:19:in `exec'
	from /opt/gitlab/embedded/service/gitlab-shell//bin/gitlab-keys:27:in `<main>'