Re: Unexpected behavior from cygpath command
On Nov 13, 2019, at 2:08, Frank Redeker wrote: > I think on both systems the handling of 8.3 names is configured > differently. You can check this with the Window command fsutil. (This > command requires elevated permissions) > > I get the following output on my system. > > C:\WINDOWS\system32>fsutil 8dot3name query d: > The volume state is: 0 (8dot3 name creation is enabled). > The registry state is: 2 (Per volume setting - the default). Thanks, I think this is very interesting, I did not know that such a setting existed. It was indeed disabled for my E: drive. However, after enabling it I still can’t get “cygpath -d" to work as expected. This setting also doesn’t explain why cygpath returns the correct DOS path when I pass it in a Unix style path instead of a Windows style path. Alfred -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Unexpected behavior from cygpath command
I have two almost identical build servers, but cygpath is not behaving as expected on one of them. Here is the output from the “good” build server: $ cygpath.exe —version | head -1 cygpath (cygwin) 2.11.2 $ cygpath -d 'E:\Program Files (x86)\IAR Systems' E:\PROGRA~1\IARSYS~1 Cygpath has correctly converted the given path to DOS (8.3) format as expected. Here is the output from the “bad” build server. $ cygpath.exe —version | head -1 cygpath (cygwin) 2.11.1 $ cygpath -d 'E:\Program Files (x86)\IAR Systems' E:\Program Files (x86)\IAR Systems Why is cygpath returning the same path passed in? Oh wait, it’s running a slightly older version (2.11.1 vs 2.11.2). Perhaps there was a bug in the earlier version. Let me update the Cygwin installation and try again: $ cygpath —version | head -1 cygpath (cygwin) 3.1.0 $ cygpath -d 'E:\Program Files (x86)\IAR Systems' E:\Program Files (x86)\IAR Systems WTF? Why is it still doing this? Can there be a global config setting that affects cygpath’s behavior? Hmm, let me try a different approach: $ cygpath -d "$(cygpath -u 'E:\Program Files (x86)\IAR Systems')" E:\PROGRA~1\IARSYS~1 Hey, cygpath can convert to DOS paths on this system after all, just not when it’s given a Windows path. Can anyone explain this behavior? Alfred -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Is the Perl module Net::LDAP available for Cygwin's Perl implementation?
If so, is there a way to install it from the command line? I need it on a server that I usually just ssh into and running setup.exe is a little cumbersome. If not, what is the best/easiest way to get it? I would like to run a Perl script on a Windows server under Cygwin that requires Net::LDAP functionality. Thanks, Alfred -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Strange symlink behaviour
On Mar 10, 2010, at 4:37, Thomas Wolff wrote: Actually, if the file system does not support hard links, a tar file that contains them doesn't properly extract at all, it will rather report errors for those files. (At least that's what it does on a network filesystem whose mount doesn't support hard links either.) So it's a problem to use hard links in tar for general use. That's good to know. In my limited experiments on the NAS box we use (which speaks both CIFS and NFS), extracting a tar file containing hard links from Windows via the Cygwin tar, appears to "do the right thing". It even appears that it's an actual hard link when viewed from NFS (both files have the same inode). Alfred -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Strange symlink behaviour
On Mar 9, 2010, at 13:44, Larry Hall (Cygwin) wrote: On 3/9/2010 10:11 AM, Alfred von Campe wrote: The solution was to use hard links in the tar file (which doesn't use up any more space), and when it was untar'ed on Windows, everything worked ^ On NTFS partitions. It will on any kind of FAT partition though. I meant that it didn't take more space inside the tar file. I don't mind if it takes twice the disk space once extracted. Alfred -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Strange symlink behaviour
Here is an update from my experiments (sorry for the delay). As Corinna explained, symlinks created in Cygwin are only recognized by Cygwin, so what I wanted to do wasn't really possible. However, we still wanted to be able to update the share from Windows (a GUI application was written for the operator to update the share when a new release is available), so I really wanted to figure out a way to make this work on Windows. The solution was to use hard links in the tar file (which doesn't use up any more space), and when it was untar'ed on Windows, everything worked as expected. Thanks for all the help, Alfred -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Strange symlink behaviour
Real symlinks on a remote CIFS system are not recognized by Cygwin or Windows either. Rather, they are converted to real files by the underlying CIFS server so that "dumb" Windows clients don't get confused. Ah, that makes sense and explains some behavior I was seeing. Symlinks created with and for Cygwin are not real symlinks (with an exception). They are files with special properties so that they are recognized as symlinks by Cygwin. Does that also apply to a symlink extracted from a tar file created on Linux? Bottom line is, if you create symlinks via Cygwin, they will only be recognized by Cygwin clients. If you want symlinks which work on all systems (NFS->Linux, CIFS->Windows, CIFS->Cygwin), you have to create the symlinks using a Linux client. That's what I was afraid of. My real issue is that this all works when I extract the tar ball into an empty directory, but it doesn't when the symlink already exists and a short cut is created instead. If the "rm //path/to/share/*" would simply delete the symlink I would not be having this problem. Wait, a thought just occurred to me. What if I delete the symlink first instead of deleting "*". I'll try this when I get to work today and report back with the results. Vielen Dank, Alfred -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Strange symlink behaviour
Do symbolic links work over CIFS? I'm having a really strange problem with symlinks. Here is the story. We have a small NAS box that is accessed via both NFS and CIFS. The former is needed for the actual production access of the files on the share, but the latter is used to update the contents of the share. That is, we need to access the files from Linux via NFS, but want to update the files on Windows via CIFS. The problem is that we need to create a symlink on the share, and to make it easier/possible to update the share from Windows we create a tar file that contains the three files we need: file_with_version_v1.0.3.abc file.abc -> file_with_version_v1.0.3.abc other_file.def If the share we want to populate with these files is empty, everything works fine. However, when we try to install the new release on top of an existing release, we run these commands: rn -fv //path/to/share/* tar xvf //path/to/temp/release.tar -C //path/to/share If the new version is 1.0.4, I expect the following files in the share after running those commands: file_with_version_v1.0.4.abc file.abc -> file_with_version_v1.0.4.abc other_file.def But instead, we get this (when looked at via NFS): file_with_version_v1.0.4.abc file.abc -> file_with_version_v1.0.3.abc file.abc.lnk other_file.def Note that the link is pointing to the old file and there is a shortcut added to the directory. Upon further inspection, when we run the "rm -f //path/to/share/*" command the directory appears empty when checking it on Windows or via CIFS. However, when accessing it via NFS, I can still see the symlink. So when the tar file is untar'ed, the symlink does not get overwritten and a shortcut is created instead. We are still running Cywin V1.5 on the manufacturing floor, and updating to V1.7 is not feasible at the moment. I think Cygwin uses some special tricks to get symlinks to work on Windows, but I don't quite understand how it works. Any ideas what may be going on? Thanks, Alfred -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Strange problem with running dmake via ssh
On Apr 2, 2009, at 13:30, Dave Korn wrote: Is this possibly caused by having $SHELL set in the environment in one case but not the other? We have a winner! The SHELL environment variable was set in both cases to /bin/bash. Well, doing a "echo $SHELL" returned "/bin/bash" in both cases. However, doing a "env | grep SHELL=" only returned "SHELL=/bin/bash" in the ssh window. If I unset the SHELL environment variable in the ssh window, I can get dmake to work! I don't quite understand the subtle difference of how these environment variables are set, but I am happy that I can now run our builds over ssh. So thanks for the SHELL environment variable hint which helped me find a solution, Dave. I owe you a here>. Alfred -- 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/
Re: Strange problem with running dmake via ssh
On Apr 2, 2009, at 11:23, Corinna Vinschen wrote: This chapter in the new Cygwin 1.7 User's Guide is supposed to explain what's going on when switching the user context from a service like sshd: Thanks, Corinna, I will read this as soon as I get a chance (it's waiting at the printer for me already). I'm still running Cygwin 1.5, but I guess the same principles apply. One thing I forgot to mention is that we run the Cygwin sshd service as a specific user so that we can access network shares without having to specify a password, and I am logged in as that user. I can run other Windows commands without a problem. It's just dmake that is throwing a fit. Alfred -- 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/
Re: Strange problem with running dmake via ssh
I have a strange problem when trying to compile a project under Cygwin with dmake. If I start a remote desktop connection to our Windows 2003 server, and start a Cygwin window (i.e., run Cygwin.bat), I am able to build our project just fine. This also works in a native CMD window. However, if I ssh into the same server (using the same user account), when I try to run dmake I get the following error: $ dmake flashimage dmake .\trioimage.elf LINK_FILE=trioflashimage.ld BOOTING=BOOT_FROM_FLASH dmake: Error -- \bin\bash: No such file or directory dmake.exe: Error code 255, while making 'flashimage' The dmake executable was provided by a 3rd party. What's so different about running a bash shell under ssh than running a bash shell in a CMD window that would cause dmake to behave this way? We'd like to run remote builds automatically, so getting this to work with ssh is kind of important. I tried running strace to figure out what's going on, but that doesn't work since dmake.exe is a Windows executable. I also tried running dmake like this: $ cmd /C "dmake flashimage" dmake .\trioimage.elf LINK_FILE=trioflashimage.ld BOOTING=BOOT_FROM_FLASH dmake: Error -- \bin\bash: No such file or directory dmake: Error code 255, while making 'flashimage' As you can see, it fails in the exact same way. Are there some Windows executables that just can't be run in a Cygwin ssh bash shell? I could understand if a command didn't run at all under Cygwin/bash, but I just don't understand why it runs in a local Cygwin shell window but not in an ssh Cygwin shell window. Alfred -- 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/
Strange problem with running dmake via ssh
I have a strange problem when trying to compile a project under Cygwin with dmake. If I start a remote desktop connection to our Windows 2003 server, and start a Cygwin window (i.e., run Cygwin.bat), I am able to build our project just fine. This also works in a native CMD window. However, if I ssh into the same server (using the same user account), when I try to run dmake I get the following error: $ dmake flashimage dmake .\trioimage.elf LINK_FILE=trioflashimage.ld BOOTING=BOOT_FROM_FLASH dmake: Error -- \bin\bash: No such file or directory dmake.exe: Error code 255, while making 'flashimage' The dmake executable was provided by a 3rd party. What's so different about running a bash shell under ssh than running a bash shell in a CMD window that would cause dmake to behave this way? We'd like to run remote builds automatically, so getting this to work with ssh is kind of important. Thanks, Alfred -- 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/
Re: rsync under cygwin too slow
rsync -rtuplg --stats --verbose --progress --modify-window=2 / cygdrive/c/localfolder /cygdrive/z/backups/ ... ... The local and remote folders were already synchronized, that is why 0 files were transferred. File list generation did take only 3 minutes but the whole process took more than 1.5 hours to finish and consumed a whopping 1.9 GB of downloaded bytes and 0.4 GB of uploaded bytes as per network counters. For what? Zero files, Zero bytes of file data. I'm pretty sure this is because rsync has to copy all the files locally to compare them to see if they need to be copied. Try running the rsync as a service on the system that hosts the Z: drive (or run rsync over ssh to the system that hosts the Z drive) and you will see large performance improvement. As far as I can see, rsync under cygwin is also too slow to be useful. This has nothing to do with Cygwin or rsync. If you ran ROBOCOPY under Windows using the same setup you would see the same performance penalty. Alfred -- 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/
Re: How do I run sshd as a particular user?
On Apr 11, 2008, at 11:48, I wrote: Well, I spoke a little too soon. I got this working on two systems, but can not get it to work on a third. The ssh daemon appears to start (neither cygrunsrv -S nor starting it from the Services Panel gives an error), but it really does not. I managed to solve this by rebooting the system and re-running ssh- host-config (and then changing permissions, etc.). I now have all three build systems working as expected. Thanks again for all the help, Alfred -- 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/
Re: How do I run sshd as a particular user?
On Apr 2, 2008, at 9:27, Corinna Vinschen wrote: - Did you check /var/run/sshd.log? If it's empty it's probably because the domain user has no write permission. - Does the domain user have an entry in the local /etc/passwd? sshd needs that when checking file ownership. And it allows to specify the user to cygrunsrv without the "domain\win_username" syntax. - Did you chown /etc/ssh* and /var/empty to the domain user when trying to start the service under that account? That's a must have. It's taken me a while to get to this, but changing the above mentioned permissions did the trick. I can now log on and access network shares! This will make the build engineers' lives a lot easier. Thank you for a great product and for all the help on this list! Well, I spoke a little too soon. I got this working on two systems, but can not get it to work on a third. The ssh daemon appears to start (neither cygrunsrv -S nor starting it from the Services Panel gives an error), but it really does not. The Event Viewer Application log shows the following: The description for Event ID ( 0 ) in Source ( sshd ) cannot be found. The local computer may not have the necessary registry information or message DLL files to display messages from a remote computer. You may be able to use the /AUXSOURCE= flag to retrieve this description; see Help and Support for details. The following information is part of the event: sshd: PID 2920: service `sshd' failed: signal 11 raised. Any ideas what could be raising signal 11 (SIGSEGV) and how I would go about debugging this? ssh access was working to this machine before I changed the file system permissions and the account information for the sshd service. Alfred -- 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/
Re: How do I run sshd as a particular user?
On Apr 2, 2008, at 9:27, Corinna Vinschen wrote: Did you try anything besides switching the user? For instance: - Did you check the event log? Yes, did not find anything useful. - Did you check /var/run/sshd.log? If it's empty it's probably because the domain user has no write permission. No, I did not. - Does the domain user have an entry in the local /etc/passwd? sshd needs that when checking file ownership. And it allows to specify the user to cygrunsrv without the "domain\win_username" syntax. Well, there is an entry for a user of the same name. Is that enough or is there a way to specify the fact that it's a domain user? - Did you chown /etc/ssh* and /var/empty to the domain user when trying to start the service under that account? That's a must have. No, I did not know about this either. I will try these suggestions as soon as I get a chance, but that might not be until I return to the office next week. A quick question, though. Instead of making all these changes, is there a better way to (re-)install Cygwin sshd so that it is properly set up for a domain user? Alfred -- 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/
Re: How do I run sshd as a particular user?
On Mar 28, 2008, at 11:28, Dave Korn wrote: Alfred von Campe wrote on 28 March 2008 12:30: I have tried various ways to get the sshd service started as a domain user (instead of the default local user "sshd_server") and can not get it to work. What is the correct syntax to specify a domain user with cygrunsrv? This is what I have tried: cygrunsrv -I sshd -u "DOMAINNAME\USERNAME" -w PASSWORD -d "CYGWIN sshd" -p /usr/sbin/sshd -a -D -e "CYGWIN=bin tty smbntsec" -y tcpip That's the windows domain user syntax sure enough. There aren't any shell metacharacters in the password by any chance are there? Nope, just upper and lowercase letters, numbers, and a dash. I also ensured that the user had all the user rights as described in the openssh.README file (well, all except for Increase Quota, which for some reason was not defined on this system, and must not really be required since the sshd_server account also did not have that right and it is able to start the service). The result is the same, the service starts and immediately stops. There is nothing obvious in the logs. I am not really a Windows person, so I've been working with one of our IT guys on this, but he is out today and I will be out tomorrow and Friday, so this will have to wait until next week. Again, the problem I am trying to solve is to be able to kick off builds remotely and automatically on this Windows server. To do this, we need password-less login, and to that end, we have exchanged ssh keys and have this working. However, by exchanging ssh keys the user is never fully authenticated on the domain, so there is no access to network drives. Is there any other way to have passwordless ssh access yet still be fully authenticated on the domain? I thought starting the service as a domain user would accomplish this, but alas, I have not been able to do that. So if there is any other way to achieve our goal, I'd be happy to try it. Thanks, Alfred -- 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/
Re: How do I run sshd as a particular user?
[I'm reposting this with a couple of corrections/clarifications and also to raise its visibility since I didn't get any responses last time :-)] It's been a month since Larry Hall replied to my last post on this topic (thanks, BTW), and this issue has bubbled up to the top again. I have tried various ways to get the sshd service started as a domain user (instead of the default local user "sshd_server") and can not get it to work. What is the correct syntax to specify a domain user with cygrunsrv? This is what I have tried: cygrunsrv -I sshd -u "DOMAINNAME\USERNAME" -w PASSWORD -d "CYGWIN sshd" -p /usr/sbin/sshd -a -D -e "CYGWIN=bin tty smbntsec" -y tcpip This successfully installs the service, and if I look at it in the Services control panel, it shows the correct username (DOMAIN \USERNAME), but if I try to start the service I always get the error "The Cygwin sshd service in Local Computer started and then stopped". If I substitute sshd_server for the user and supply the correct password, the sshd service starts correctly. But I want to start the service as a domain user so that I can access network shares and resolve some build issues with Visual Studio that are apparently caused by not being fully authenticated. Alfred -- 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/
Re: How do I run sshd as a particular user?
On Feb 26, 2008, at 18:29, Larry Hall (Cygwin) wrote: How did you make this change? If you removed and reinstalled the service with 'cygrunsrv' like the sshd configuration script does, then use the '-W, --passwd ' flag. Otherwise, specify the password in Control Panel->Administrative Tools->Services->Cygwin sshd Logon properties page. It's not a month since Larry posted this (thanks, BTW), and this issue has bubbled up to the top again. I have tried various ways to get the sshd service started as a domain user (instead of the local sshd_server user) and can not get it to work. What is the correct syntax to specify a domain user with cygrunsrv? This is what I have tried: cygrunsrv -I sshd -u "DOMAINNAME\USERNAME" -w PASSWORD -d "CYGWIN sshd" -p /usr/sbin/sshd -a -D -e "CYGWIN=bin tty smbntsec" -y tcpip This successfully installs the service, and if I look at it in the Services panel it shows the correct username (DOMAIN\USERNAME), but if I try to start the service I always get the error "The Cygwin sshd service in Local Computer started and then stopped". If I substitute sshd_server for the user and supply the correct password, the sshd service starts correctly. But I want to start the service as a domain user so that I can access network shares and resolve some build issues with Visual Studio that are apparently caused by not being fully authenticated. Alfred -- 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/
Re: performance issue with sshd and cygrunsrv
With regard to this performance problem, I've discovered that this is not just an sshd problem -- scripts/commands I run through cron also exhibit the same behavior. (ie. find, curl, date, etc). Is there something about the user context under which these services run that could be causing this? Or does this point to cygrunsrv? What does your PATH environment variable look like? Make sure it doesn't contain any network paths. As soon as I removed them, I got much better performance with ssh (I haven't used cron with Cygwin). Alfred -- 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/
How do I run sshd as a particular user?
I've read about the restrictions on accessing shares while logged into a Windows system with the Cygwin ssh daemon. We are interested in this to do remote builds, and it would be nice to access network shares. We only really need one user to be able to log in, so I thought I'd change the CYGWIN sshd service to run as that user. However, when I changed the service and tried to start it, I got the following error message: "The VYGWIN sshd servcice on Local COmputer started and then stopped." Any ideas what's going on? I tried to revert to having the service started by the .\sshd user, but I can't get that to work no either! I think it's because I am using the wrong password. How can I change or reset the password on that account? Alfred -- 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/
Re: Can not log in to recently enabled/configured sshd service
A quick update on the my situation (I am the original poster). After removing Cygwin and reinstalling it, re-running ssh-host-config, and making the home directory in /etc/passwd a local directory (i.e., not a network drive), I am now able to log into the Windows system from a Linux system. This is great and will help us kick off automated builds. However, in the remote ssh session, I am not able to access any network drives (home directories or otherwise), which I can easily do in a Cygwin window when accessing our build server via terminal services. Is this a restriction of how sshd is implemented, or can I reconfigure something so I can access network drives from within ssh session? Alfred -- 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/
Re: Can not log in to recently enabled/configured sshd service
On Feb 7, 2008, at 9:46, Dave Korn wrote: It all depends where you keep your home directory. For a home on your local HD, that's fine, but if you have home on a network share, you need 'smbntsec', since ntsec defaults to only cover local drives for speed. Yes, our home directories are on network drives (NetApp shares). I am seeing some very strange behavior at the moment with permissions, and will need to work with our IT department at some mutually convenient time. This may not happen for a few days, and I'll report back with my findings once I've tried various options. Alfred -- 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/
Re: Can not log in to recently enabled/configured sshd service
If you want this enabled indelibly just for the sshd service and you don't want to go skulking around in the registry, you can re-run ssh-host- config and specify 'smbntsec' as one of the settings when it asks you what you want for the service. This is a good thing to do because it allows you to be specific about the settings each service gets. Otherwise, if you want the setting globally, just set it in the CYGWIN environment variable and restart all Cygwin services. I'm getting really strange behavior now from the Cygwin sshd service. I'm going to completely redo the Cygwin installation by following these steps: 1. Stop all services (I believe I only have sshd) 2. Remove all services 3. Remove Cygwin directory 4. Remove all Cygwin Registry keys 5. Reinstall Cygwin 6. Rerun ssh-host-config Is there anything I should pay close attention to when I go through this reinstallation/reconfiguration process? Alfred -- 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/
Re: Can not log in to recently enabled/configured sshd service
On Feb 6, 2008, at 9:55, Dave Korn wrote: How do the perms on /home/av16209/.ssh/* look? How do they look with CYGWIN=smbntsec? Interesting. I had CYGWIN set to "binmode tty ntsec" according to some instructions I found by googling. Here are the relevant results: bash-3.2$ CYGWIN=ntsec /bin/ls -ld ~/.ssh drwxr-xr-x 1 av16209 Domain Users 0 Feb 6 09:28 //solid/av16209/.ssh bash-3.2$ CYGWIN=smbntsec /bin/ls -ld ~/.ssh drwx--+ 1 av16209 Domain Users 0 Feb 6 09:28 //solid/ av16209/.ssh So it appears that CYGWIN=smbntsec is what I want. How can I reconfigure the sshd service to use that setting? Alfred -- 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/
Can not log in to recently enabled/configured sshd service
I have a pretty vanilla Cygwin installation on a Windows 2003 Server (SP1) system. Yesterday, I tried to enable the sshd service by running the ssh-host-config script. Everything appeared to work fine and I let the script create the two recommended user accounts. I was also able to start the sshd service successfully. However, I can not log in to the system. With the minimal /etc/passwd file, when I try to log in via ssh using a user that is not in the /etc/passwd file, it will not take my password at all (that's to be expected). I then added my account (as well as all the other accounts in our Windows domain) to the /etc/passwd file by running the following command: mkpasswd -l -d >> /etc/passwd Now when I try to log in I get immediately disconnected as shown in this debug output output: # ssh -v [EMAIL PROTECTED] OpenSSH_3.9p1, OpenSSL 0.9.7a Feb 19 2003 debug1: Reading configuration data /home/av16209/.ssh/config debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug1: Connecting to gandalf [139.68.133.49] port 22. debug1: Connection established. debug1: identity file /home/av16209/.ssh/identity type 0 debug1: identity file /home/av16209/.ssh/id_rsa type 1 debug1: identity file /home/av16209/.ssh/id_dsa type 2 debug1: Remote protocol version 2.0, remote software version OpenSSH_4.7 debug1: match: OpenSSH_4.7 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_3.9p1 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-cbc hmac-md5 none debug1: kex: client->server aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: Host 'gandalf' is known and matches the RSA host key. debug1: Found key in /home/av16209/.ssh/known_hosts:101 debug1: ssh_rsa_verify: signature correct debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,password,keyboard-interactive debug1: Next authentication method: publickey debug1: Offering public key: /home/av16209/.ssh/id_rsa Connection closed by 139.68.133.49 The home directory defined in the Cygwin /etc/passwd file is "// nasbox/av16209" which is the same home directory used on the Linux system that I initiated the ssh connection from (only there it's mounted as "/home/av16209"). I have got passwordless ssh access working from all my Linux systems, so that part is set up correctly. Any ideas as to why this is failing on the Cygwin side? Thanks, Alfred -- 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/
