Re: Connection closed by server with exitcode 1

[Derek M. <co...@pi...>]

On Sun, Dec 25, 2011 at 11:03:24AM -0500, Nico Kadel-Garcia wrote:
> Private keys can be stored however the heck you want them. SSH clients
> *do not care*, and they can be anywhere you want with whatever
> permissions you want, including $HOME/.ssh/privatekey with permissions
> 7777 if you feel like it.

Since we're being so flamboyantly and aggressively pedantic, I guess
I'll point out that this is utterly false.

$ chmod 777 ident
$ ssh-add  ident
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0777 for 'ident' are too open.
It is recommended that your private key files are NOT accessible by others.
This private key will be ignored.

IIRC it's possible to force ssh to ignore this problem with an option,
however doing so is fairly asinine in most instances.  Having writable
private keys is not a good idea, to put it mildly.  Though, very
rarely, it might be useful/necessary.

> > There is no problem with that.  But why doesn't sshd tell me in its log
> > the reason for closing the connection? Why do I have to resort to "ssh
> > -vvv" to discover it?
> 
> Because some sone of a !@#$ can overwhelm your SSH log files with
> failed connections if it's too verbose, and the balance between useful
> information and log spew is a tricky one.

Also false, though there be a kernel of truth there.  

First, just to be clear, ssh -vvv has no impact whatsoever on the log
files.  It only controls how much information *the client* reports to
the user.  

More to the point, the reason why you need to see it in the client, in
this case, is because only the client knows that it was ignoring
particular files, and why it did that.  The server doesn't and can't
know that.  All the server knows is that no key was presented that
matches anything in authorized_keys.  It could reasonably log that,
but that information alone is only marginally useful, at best.  You
still need to see what the client is doing to figure out *why*.

However, when debugging a tricky issue, you can run a stand-alone sshd
on a separate port and enable copious debugging when you run it, also
having it send the output to stderr instead of the system logs, so as
not to clutter them up (you can still capture stderr to a file).  When
you connect to that port, sshd will log detailed info, which may or
may not help, depending on what the problem actually is.  Often
enough, you really do need both the server side debugging AND the
client side debugging turned on in order to figure out what went
wrong.  And that's just the way it is.

For what it's worth, I have no guesses as to what's wrong with the
OP's setup (Zachary Burnham).  Well actually I do have one: he's using
a chroot jail, and didn't rebuild the jail after updating his system.
The fact that rssh didn't log *anything* is curious, and would seem to
suggest that something else is wrong.

-- 
Derek D. Martin
http://www.pizzashack.org/
GPG Key ID: 0x81CFE75D