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
pgpBOk5ToIPjs.pgp
Description: PGP signature
------------------------------------------------------------------------------ Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
_______________________________________________ rssh-discuss mailing list rssh-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rssh-discuss
