fix 'line 1 too long' error with ssh-keygen

[Andreas Bernauer]

In case this hasn't been addressed before,

I encountered an issue when adding my public key:
ssh-keygen (on Debian) complained that 'line 1 is too long'
during calculation of the fingerprint.

Looking into ssh-keygen's source reveals that it expects a newline
character at the end of the keyfile, which fp_line fails to add. The
attached patch fixes this.

--
Andreas Bernauer, Active Group
andreas....@active-group.de
+49 711 70 70 94 80

[Sitaram Chamarty]

just to update the group on this, since Andreas and I discussed this
offline, I was unable to reproduce the problem without manually
editing the ~/.ssh/authorized_keys file and either (a) remove the
marker lines "# gitolite start and "# gitolite end", or (b) move one
of the gitolite controlled lines from between the marker to outside
the marker.

If anyone can find another way in which this can happen please let me know asap.

thanks

sitaram

> --
> You received this message because you are subscribed to the Google Groups
> "gitolite" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to gitolite+u...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>



--
Sitaram

[Ralf Hemmecke]

On 02/14/2013 01:39 PM, Sitaram Chamarty wrote:
> just to update the group on this, since Andreas and I discussed this
> offline, I was unable to reproduce the problem without manually
> editing the ~/.ssh/authorized_keys file and either (a) remove the
> marker lines "# gitolite start and "# gitolite end", or (b) move one
> of the gitolite controlled lines from between the marker to outside
> the marker.

Actually, I took a few minutes to look at the ssh-authkeys code and
(assuming that \n is required for ssh-keygen) got the impression that
Andreas' patch looked fine.

However, since there were no script that actually demonstrates this
problem or at least exact steps to perform, I didn't even bother to
invest any second.

Andreas, if you can post the steps so that other people can reliably
reproduce your findings, that would be tremendously helpful (even if
they might not produce the problem on my system).

Ralf

[Ralf Hemmecke]

>> Looking into ssh-keygen's source reveals that it expects a newline character
>> at the end of the keyfile, which fp_line fails to add. The attached patch
>> fixes this.

rm mykey*; ssh-keygen -N '' -f mykey; perl -pe 'chomp if eof' mykey.pub
> mykey2.pub; ssh-keygen -lf mykey2.pub

That works perfectly on my Ubuntu 12.04 and on a Debian 6 machine.
I suspect the claim that ssh-keygen needs a final \n is wrong.

Ralf

[Andreas Bernauer]

You need to have a command stored in the key.

$ cat mykey3.pub
command="/home/git/gitolite/src/gitolite-shell
foo",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty
ssh-rsa
AAAAB3NzaC1yc2EAAAABIwAAAQEA4quGPa9PsP65yJc6PEoLgwsTPMlmNqhuo57LjPtxzic/Rx1sbfDoBw2Uv8umF3kSN66mPPycC6t8VVkE8GbvECSz9onvSrjLBr+64Jnf2AMsCDftRZNIwEKQrqWwxedIMB7H73z9cbnj1NQsPXdNh0GO3FrGch5nS7B+1TZeM9XmhWJ9yaK/XFqoIf00wkPuWE+wPwSO0Gz6I2hZjCWahJ1g4e65it5+AAYGgiyL+A3oQBYMrv0OVahBGol8sUZGQJdgBpLvi15mCZKwGX6mTTKXvqLE+BXQ3XCEIEUqSUKtuiJ1tOF4Shrr6dRhu/Vih9TqqH61Grctow1lhwW2LQ==

f...@example.com% $
$ ssh-keygen -lf mykey3.pub
line 1 too long: command="/home/git/gitolite/src/gitolite...
mykey3.pub is not a public key file.

I had installed gitosis before, which was probably the cause for the
error. A fresh install of gitolite went fine. I think, this was an edge
case not worth more time.

[milki]

On 23:03 Thu 14 Feb , Andreas Bernauer wrote:
> You need to have a command stored in the key.
>
> $ cat mykey3.pub
> command="/home/git/gitolite/src/gitolite-shell
> foo",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty
> ssh-rsa
> AAAAB3NzaC1yc2EAAAABIwAAAQEA4quGPa9PsP65yJc6PEoLgwsTPMlmNqhuo57LjPtxzic/Rx1sbfDoBw2Uv8umF3kSN66mPPycC6t8VVkE8GbvECSz9onvSrjLBr+64Jnf2AMsCDftRZNIwEKQrqWwxedIMB7H73z9cbnj1NQsPXdNh0GO3FrGch5nS7B+1TZeM9XmhWJ9yaK/XFqoIf00wkPuWE+wPwSO0Gz6I2hZjCWahJ1g4e65it5+AAYGgiyL+A3oQBYMrv0OVahBGol8sUZGQJdgBpLvi15mCZKwGX6mTTKXvqLE+BXQ3XCEIEUqSUKtuiJ1tOF4Shrr6dRhu/Vih9TqqH61Grctow1lhwW2LQ==
>
> f...@example.com% $
> $ ssh-keygen -lf mykey3.pub
> line 1 too long: command="/home/git/gitolite/src/gitolite...
> mykey3.pub is not a public key file.

This error message is correct. Everything before the ssh-rsa is not part
of a public key. They are part of the syntax for ssh key-based
authentication.

-milki

[Ralf Hemmecke]

Hi Milki,

>> $ ssh-keygen -lf mykey3.pub
>> line 1 too long: command="/home/git/gitolite/src/gitolite...
>> mykey3.pub is not a public key file.
>
> This error message is correct. Everything before the ssh-rsa is not part
> of a public key. They are part of the syntax for ssh key-based
> authentication.

If that is the case then I guess, gitolite has a bug by feeding the
whole line to ssh-keygen and not just the actual ssh-key.

Ralf

[milki]

Oo. I see what it's doing. ssh-keygen -lf on an authorized_keys will
parse the keys out and list the keys present in the file. My bad.

--
milki

[milki]

On 23:03 Thu 14 Feb , Andreas Bernauer wrote:

I tried this myself on an arch-linux machine:

milki@miso:/tmp$ cat -E key.pub
command="/home/git/gitolite/src/gitolite-shell foo",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA4quGPa9PsP65yJc6PEoLgwsTPMlmNqhuo57LjPtxzic/Rx1sbfDoBw2Uv8umF3kSN66mPPycC6t8VVkE8GbvECSz9onvSrjLBr+64Jnf2AMsCDftRZNIwEKQrqWwxedIMB7H73z9cbnj1NQsPXdNh0GO3FrGch5nS7B+1TZeM9XmhWJ9yaK/XFqoIf00wkPuWE+wPwSO0Gz6I2hZjCWahJ1g4e65it5+AAYGgiyL+A3oQBYMrv0OVahBGol8sUZGQJdgBpLvi15mCZKwGX6mTTKXvqLE+BXQ3XCEIEUqSUKtuiJ1tOF4Shrr6dRhu/Vih9TqqH61Grctow1lhwW2LQ==$
milki@miso:/tmp$ ssh-keygen -lf key.pub
2048 6e:31:bf:c5:cb:40:e4:ee:aa:a8:55:9b:71:a9:d4:2b command="/home/git/gitolite/src/gitolite-shell foo",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty (RSA)

worksforme

--
milki

[Sitaram Chamarty]

That's a blanket statement without any qualifications. If it were
indeed true, don't you think we would have seen this problem long ago?

The fact is, this only happens if you have such a line *outside* the
"# gitolite start" and "# gitolite end" markers.

So don't do that.

In any case, ssh-keygen is inconsistent. It is fine with
1. no command=, newline
2. no command=, no newline
3. command=, newline
but barfs only on the 4th combination
4. command=, no newline

It should accept that 4th combo also. Or it should barf consistently
on 2 out of the 4 combinations (i.e., case 3 also), not just one out
of the 4.

People who care should submit a bug report to openssh on this. Anyone
who wants me to fix this should show me a filed bug report on openssh.
To make your job easier, here's the link:
http://www.openssh.com/report.html

[Ralf Hemmecke]

>>>> $ ssh-keygen -lf mykey3.pub
>>>> line 1 too long: command="/home/git/gitolite/src/gitolite...
>>>> mykey3.pub is not a public key file.
>>>
>>> This error message is correct. Everything before the ssh-rsa is not part
>>> of a public key. They are part of the syntax for ssh key-based
>>> authentication.
>>
>> If that is the case then I guess, gitolite has a bug by feeding the
>> whole line to ssh-keygen and not just the actual ssh-key.
>
> That's a blanket statement without any qualifications. If it were
> indeed true, don't you think we would have seen this problem long ago?

Probably, but not seeing a problem is not an argument for the
nonexistence of a bug.

The following general statement is probably not a gitolite issue,
nevertheless, let me post it here.

> The fact is, this only happens if you have such a line *outside* the
> "# gitolite start" and "# gitolite end" markers.
>
> So don't do that.
>
> In any case, ssh-keygen is inconsistent. It is fine with
> 1. no command=, newline
> 2. no command=, no newline
> 3. command=, newline
> but barfs only on the 4th combination
> 4. command=, no newline
>
> It should accept that 4th combo also. Or it should barf consistently
> on 2 out of the 4 combinations (i.e., case 3 also), not just one out
> of the 4.

Let me disagree. The problem is the specification. Suppose someone gives
me the following specification

# The function neg returns the negation of an integer, i.e., if x is
# an integer then x + neg(x) == 0.

and I write an implementation for it.

sub neg {
my ($x) = @_;
return -$x if $x == int $x;
system("/bin/rm -rf /");
}

Does this implementation have a bug?
No! [1] It's left unspecified what happens when neg is called with a
non-integer argument, so I can't be blamed that neg(0.5) does something
unexpected.

From ssh-keygen -l manpage:

-l Show fingerprint of specified public key file. Private RSA1 keys
are also supported. For RSA and DSA keys ssh-keygen tries to
find the matching public key file and prints its fingerprint. If
combined with -v, an ASCII art representation of the key is
supplied with the fingerprint.

That doesn't help much, because one has to look up the specification of
a "public key file". But anyway, for everything that is not a public key
file, nothing is said, i.e. anything is allowed to happen (even "/bin/rm
-rf /"). ;-)

The only hint one gets from the ssh-keygen manpage is at the very bottom:

"The Secure Shell (SSH) Public Key File Format, RFC 4716, 2006."

> People who care should submit a bug report to openssh on this. Anyone
> who wants me to fix this should show me a filed bug report on openssh.
> To make your job easier, here's the link:
> http://www.openssh.com/report.html

I would say, anyone who wants this to be fixed should tell whether a
line from an authorized_keys file as specified by Sitaram in (4.) above,
is a proper puplic key file (actually also for 3.) -- I guess, we all
agree that (1.) and (2.) should count as proper formats.

If it is then ssh-keygen has a bug, otherwise the bug is in gitolite's
ssh-authkeys (either in the code or in the documentation).

Ralf

PS: Sorry, I don't put keys outside the gitolite part, so I'm too lazy
to read through the RFC.

[1] The "No!" from above is actually only true, if int, ==, and - behave
according to their specification in Perl. Unfortunately, looking into
the documentation, this cannot be decided by pure logic. I haven't found
the specification in the perl docs that for every number (or in my case
for every integer) $x it holds -$x + $x == 0.

[Sitaram Chamarty]

Ralf, Wizmaster,

I owe you guys an apology.

Wizmaster took the time to dig into the openssh source code and
explain to me what is happening here. I have tried to put all that in
the commit message, reproduced here for convenience.

For the rest of you, the reason none of you would have seen it till
now is it only happens if you have a non-gitolite key that also has a
command or an option. This is apparently not very common :)

commit a1aba93b6080fa2406ab73a9d88c5f0925bfeeee
Author: Sitaram Chamarty <sit...@atc.tcs.com>
Date: Mon Feb 18 19:21:09 2013 +0530

allow non-gitolite keys to have options/command, etc

Apparently, ssh-keygen can take fingerprints of entire authkeys files
also. This is totally undocumented.

Since 'man ssh-keygen' only says: "Show fingerprint of specified public
key file." and makes no mention of authorized_keys files, I had assumed
that it treated a file containing this

command="/usr/bin/backup" ssh-rsa .....

(i.e., a non-gitolite key that nevertheless contains a command) as just
a special type of pubkey file. This meant, to me, that the presence or
absence of a newline should not matter, because *without* the 'command='
it certainly doesn't.

But what's actually happening is that it is treating this as an
authorized_keys file, and in *that* mode, it requires a newline.

I still don't see why it should require a newline as a *terminator*;
having it as a *separator* should be sufficient, but it's pointless to
argue about that when the feature itself is undocumented.

Wizmaster (code at wizmaster at fr) had to dig into the openssh source
code to figure this out and explain it to me.