X-Spam-Check-By: sourceware.org Message-ID: <467A9BA5.7000709@cygwin.com> Date: Thu, 21 Jun 2007 11:39:17 -0400 From: "Larry Hall (Cygwin)" Reply-To: cygwin AT cygwin DOT com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.3) Gecko/20070505 Remi/2.0.0.0-3.fc4.remi Thunderbird/2.0.0.0 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: cygwin AT cygwin DOT com Subject: Re: ssh configuration References: <467A518D DOT 5040400 AT advancedsl DOT com DOT ar> <467A7116 DOT 2060402 AT cygwin DOT com> <467A8456 DOT 6030402 AT advancedsl DOT com DOT ar> In-Reply-To: <467A8456.6030402@advancedsl.com.ar> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com gga wrote: > Larry Hall (Cygwin) wrote: >>> Here's the full info: >>> >>>> /usr/sbin/sshd.exe -d -d -d -D >> Running 'sshd.exe' as anyone other than SYSTEM (on WinXP and earlier > O/S's) >> is not recommended. See the email archives for a recipe about how to get >> a SYSTEM-owned shell to run 'sshd.exe' from if you want to run it from a >> shell. > > Well, this is mainly just a test to see the output of sshd. sshd will > still get started by a service (presumably running under root) using > cygrunsrv. Right but running 'sshd.exe' as different users can compromise your attempts to run it. Typically, 'sshd.exe' will complain or refuse to work if various files (most under various branches in '/var') don't have the right owners/permissions. This may be part of your problem now. Or maybe not, given that you're working on a FAT formatted partition that doesn't have any partitions. >> You certainly need to ru ssh-user-config to log through the 'sshd' >> server, so this is the correct thing to do. > > Ok... so, I've done it. Here's the new log (with ugly errors), from ssh. > > > OpenSSH_4.6p1, OpenSSL 0.9.8e 23 Feb 2007 > debug1: Reading configuration data /etc/ssh_config > debug1: Applying options for * > debug2: ssh_connect: needpriv 0 > debug1: Connecting to localhost [127.0.0.1] port 22. > debug1: Connection established. > debug1: identity file /home/gga/.ssh/identity type 0 > debug3: Not a RSA1 key file /home/gga/.ssh/id_rsa. > debug2: key_type_from_name: unknown key type '-----BEGIN' > debug3: key_read: missing keytype > debug2: key_type_from_name: unknown key type 'Proc-Type:' > debug3: key_read: missing keytype > debug2: key_type_from_name: unknown key type 'DEK-Info:' > debug3: key_read: missing keytype > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug2: key_type_from_name: unknown key type '-----END' > debug3: key_read: missing keytype > debug1: identity file /home/gga/.ssh/id_rsa type 1 > debug3: Not a RSA1 key file /home/gga/.ssh/id_dsa. > debug2: key_type_from_name: unknown key type '-----BEGIN' > debug3: key_read: missing keytype > debug2: key_type_from_name: unknown key type 'Proc-Type:' > debug3: key_read: missing keytype > debug2: key_type_from_name: unknown key type 'DEK-Info:' > debug3: key_read: missing keytype > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug2: key_type_from_name: unknown key type '-----END' > debug3: key_read: missing keytype > debug1: identity file /home/gga/.ssh/id_dsa type 2 > ssh_exchange_identification: read: Software caused connection abort > >>> More info: >>> - cygwin is installed on a FAT partition of a WinXP (SP1) box, with >>> latest patches. >> Ugh! You'll need to turn off 'StrictModes' in '/etc/sshd_config' for >> this to work. And that disables a large part of the security you get >> from OpenSSH. You should really consider switching to NTFS if you plan >> to use OpenSSH as any kind of security mechanism. >> > > It was already off in the log I sent. Why does it affect security so > badly (other than of course allowing any intruder to change the .ssh > dotfiles for any account if he logs in)? > My idea is to have openssh working only within my lan with this box (ie. > ignore outside connections thanks to my firewall/hosts.deny file). > It checked ownership and permissions if it's on, which have little meaning with FAT. >>> - I have at least one user without a password. I've also gone and >>> modified the ssh configuration file to add in sshd_config: >>> PermitEmptyPasswords no >> Perhaps this answers the question about whether you're looking for >> security from OpenSSH. ;-) > > Hopefully not. I really cannot ask the user to login with a password > (he is too old a person) and I don't care too much about the security > within the LAN. > However, I do care about the security exposed to the net, and I want to > make sure this account without a password does not compromise security. > Under linux, PermitEmptyPasswords should do that for ssh connections. > I'm hoping this is the same for cygwin. I'd recommend using public key authentication then and creating an RSA key with an empty password. That's more secure than just plain old password authentication. Of course, if the account in question needs authenticated access to shared resources (network drives, etc.), you may have to make do with password authentication. >> 'Off' for some firewalls is the same as 'On'. They can be buggy. Try >> opening port 22 (assuming you didn't change this) for OpenSSH or >> uninstalling the firewall as a test. >> > > Port 22 is already open, but I'm testing without the firewall just in > case, too. I'm using Filseclab Free Firewall, btw. > I haven't heard any problems reported on this list against that product. You can search the email archives for Dave Korn's list of "dodgy" apps that trip up Cygwin. It's probably worth a review. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _____________________________________________________________________ A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting annoying in email? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/