Re: SSH login to cygwin sshd (6.7p1-1) fails with error seteuid1000: Operation not permitted when ~/.ssh/id_rsa keys available on client
Read the thread Never ending SSHD story: offering public key terminates connection, you'll find explanation and the solution there. -- 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: Never ending SSHD story: offering public key terminates connection
Hi Larry! 01/03/2015 06:44 AM, ext Larry Hall (Cygwin) wrote: use ssh-user-config The manual key creation doesn't do any harm, because the problem is obviously on the server side. To see this I did all the testing running the client on a remote machine, no difference in symptoms. Don't use 'ssh-host-config -y'. I don't quite understand: what answers should I give to the script? If there is any question which should not be answered by yes, please explain which question and what should be the answer. Drop the flag -y ... so that you get a proper password. As a matter of fact even with the -y flag the script asks for the password for the new user, xx is the proper password I'm using (there are no seciruty concerns in my setup) If you don't have a root in your '/etc/group' file... I do have it, here is the very first line from the file: root:S-1-5-32-544:0: If that doesn't work, you may have gotten caught by permissions settings as a result of having the sshd service improperly started by the SYSTEM user. It seems to me that SYSTEM user needs a security capability to call seteuid. Being a member of Administartors group doesn't seem to be enough Alas I don't know which capability needs to be added I found a UI program called Local Security Policy, but I don't know which of those properties is/are needed for seteuid call you could just wipe out your installation and start over I do it every day many times anyway, including fresh windows installation (as I described in one of the previous messages). Very frustrating the whole business. Ilya -- 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: [SOLUTION] Never ending SSHD story: offering public key terminates connection
Hello to all the SSHD users! After reading the documentation at https://cygwin.com/cygwin-ug-net/ntsec.html I learned that there are 3 methods for implementing seteuid in cygwin. The first and default method seems to be absolutely broken for now, so I switched to the 2nd method by calling the magic command cyglsa-config. Now my SSHD works (or, at least I have not found how to break it until now). So here is a short summary, how to get SSHD working on a fresh installed windows 8.1 system (windows version is probably not so important, but I only tested it with 8.1). 1) Install windows 2) Install cygwin64 with package openssh 3) Open terminal as admin 4) $ ssh-host-congig -y (will FAIL) 5) $ net localgroup Administrators sshd /ADD 6) $ net localgroup Administrators cyg_server /ADD 7) $ cygrunsrv -S sshd 8) $ ssh localhost /bin/echo BLAH (password - SUCCESS) 9) $ ssh-keygen.exe 10) $ ssh localhost /bin/echo BLAH (will FAIL now) 11) $ cyglsa-config 12) Reboot the machine now 13) $ ssh localhost /bin/echo BLAH (password - SUCCESS) 14) $ cp .ssh/id_rsa.pub .ssh/authorized_keys 15) $ ssh localhost /bin/echo BLAH (works without password, DONE) Dear CYGWIN developers! Please fix the whole system in such a way that SSHD will be installable and configurable in 5 minutes without any knowledge of windows internals, as it was years ago. Cheers, Ilya Dogolazky -- 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: Never ending SSHD story: offering public key terminates connection
A small follow up about this: I found a registry string Computer\HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\sshd\Parameters\AppArgs and changed the sshd command line parameters from -D to -d -d -d This was enough to receive the server log in /var/log/sshd.log (attached here). The interesting line in the file is in my opinion this one: seteuid 1001: Operation not permitted The number 1001 is the UID of the user ilya. Thus something seems to be wrong with permissions in the system. debug2: load_server_config: filename /etc/sshd_config debug2: load_server_config: done config len = 235 debug2: parse_server_config: config /etc/sshd_config len 235 debug3: /etc/sshd_config:54 setting AuthorizedKeysFile .ssh/authorized_keys debug3: /etc/sshd_config:110 setting UsePrivilegeSeparation yes debug3: /etc/sshd_config:126 setting Subsystem sftp /usr/sbin/sftp-server debug1: sshd version OpenSSH_6.7, OpenSSL 1.0.1j 15 Oct 2014 debug1: private host key: #0 type 1 RSA debug1: private host key: #1 type 2 DSA debug1: private host key: #2 type 3 ECDSA debug1: private host key: #3 type 4 ED25519 debug1: rexec_argv[0]='/usr/sbin/sshd' debug1: rexec_argv[1]='-d' debug1: rexec_argv[2]='-d' debug1: rexec_argv[3]='-d' debug2: fd 3 setting O_NONBLOCK debug3: sock_set_v6only: set socket 3 IPV6_V6ONLY debug1: Bind to port 22 on ::. Server listening on :: port 22. debug2: fd 4 setting O_NONBLOCK debug1: Bind to port 22 on 0.0.0.0. Server listening on 0.0.0.0 port 22. debug1: fd 5 clearing O_NONBLOCK debug1: Server will not fork when running in debugging mode. debug3: send_rexec_state: entering fd = 8 config len 235 debug3: ssh_msg_send: type 0 debug3: send_rexec_state: done debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 8 debug1: inetd sockets after dupping: 3, 3 Connection from ::1 port 49235 on ::1 port 22 debug1: Client protocol version 2.0; client software version OpenSSH_6.7 debug1: match: OpenSSH_6.7 pat OpenSSH* compat 0x0400 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_6.7 debug2: fd 3 setting O_NONBLOCK debug2: Network child is on pid 2504 debug3: preauth child monitor started debug1: list_hostkey_types: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ssh-ed25519 [preauth] debug1: SSH2_MSG_KEXINIT sent [preauth] debug1: SSH2_MSG_KEXINIT received [preauth] debug2: kex_parse_kexinit: curve25519-sha...@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1 [preauth] debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ssh-ed25519 [preauth] debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,aes128-...@openssh.com,aes256-...@openssh.com,chacha20-poly1...@openssh.com [preauth] debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,aes128-...@openssh.com,aes256-...@openssh.com,chacha20-poly1...@openssh.com [preauth] debug2: kex_parse_kexinit: umac-64-...@openssh.com,umac-128-...@openssh.com,hmac-sha2-256-...@openssh.com,hmac-sha2-512-...@openssh.com,hmac-sha1-...@openssh.com,umac...@openssh.com,umac-...@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1 [preauth] debug2: kex_parse_kexinit: umac-64-...@openssh.com,umac-128-...@openssh.com,hmac-sha2-256-...@openssh.com,hmac-sha2-512-...@openssh.com,hmac-sha1-...@openssh.com,umac...@openssh.com,umac-...@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1 [preauth] debug2: kex_parse_kexinit: none,z...@openssh.com [preauth] debug2: kex_parse_kexinit: none,z...@openssh.com [preauth] debug2: kex_parse_kexinit: [preauth] debug2: kex_parse_kexinit: [preauth] debug2: kex_parse_kexinit: first_kex_follows 0 [preauth] debug2: kex_parse_kexinit: reserved 0 [preauth] debug2: kex_parse_kexinit: curve25519-sha...@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 [preauth] debug2: kex_parse_kexinit: ecdsa-sha2-nistp256-cert-...@openssh.com,ecdsa-sha2-nistp384-cert-...@openssh.com,ecdsa-sha2-nistp521-cert-...@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519-cert-...@openssh.com,ssh-rsa-cert-...@openssh.com,ssh-dss-cert-...@openssh.com,ssh-rsa-cert-...@openssh.com,ssh-dss-cert-...@openssh.com,ssh-ed25519,ssh-rsa,ssh-dss [preauth] debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,aes128-...@openssh.com,aes256-...@openssh.com,chacha20-poly1...@openssh.com,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-...@lysator.liu.se [preauth] debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,aes128-...@openssh.com,aes256-...@openssh.com,chacha20-poly1...@openssh.com,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-...@lysator.liu.se [preauth] debug2: kex_parse_kexinit:
Never ending SSHD story: offering public key terminates connection
Hello ! Using information posted provided by PolarStorm (https://www.cygwin.com/ml/cygwin/2014-12/msg00205.html) I managed to start the SSH daemon. As usual I started with a virgin virtual machine, installed Windows OS from DVD image, downloaded setup-x86_64.exe from cygwin.com, started it, added openssh package to the default set of packages, didn't change any package version. After the installer finished, I right clicked the terminal icon and started the Admin shell. The transcript from this shell is attached as log. The output of cygcheck -s -v -r is attached as well. The SSHD kinda works now, but not properly. Let's see what does it mean. First I tried to connect to my own cygwin host: ilya@w9 ~ $ ssh localhost /bin/echo BLAH ilya@localhost's password: [ *** typing my password here *** ] BLAH ilya@w9 ~ $ So... the connection, password authentication and remote execution work fine. Now I want to create a key pair first, and later try to use this pair to log in without typing my password. So let's create it: ilya@w9 ~ $ ssh-keygen.exe Generating public/private rsa key pair. Enter file in which to save the key (/home/ilya/.ssh/id_rsa): [ *** pressing ENTER here *** ] Enter passphrase (empty for no passphrase): [ *** pressing ENTER here *** ] Enter same passphrase again: [ *** pressing ENTER here *** ] Your identification has been saved in /home/ilya/.ssh/id_rsa. Your public key has been saved in /home/ilya/.ssh/id_rsa.pub. [ *** cut away key fingerprint and randomart image *** ] Great, now we have a key pair, but the public part is not copied yet to the .ssh/autorized_keys file, therefore the next connection should first try to offer the key, the key must be rejected as not autorized and after that the next authentication method must be the password again, so let's try it: ilya@w9 ~ $ ssh localhost /bin/echo BLAH Connection closed by ::1 ilya@w9 ~ Oops, this is a surprize! Nobody asked for the password, the server just closed the connection. Let's try to be more verbose: ilya@w9 ~ $ ssh -v localhost /bin/echo BLAH OpenSSH_6.7p1, OpenSSL 1.0.1j 15 Oct 2014 [ *** I removed 37 boring lines from here, see attachment for the full transcript *** ] debug1: Authentications that can continue: publickey,password,keyboard-interactive debug1: Next authentication method: publickey debug1: Offering RSA public key: /home/ilya/.ssh/id_rsa Connection closed by ::1 ilya@w9 ~ So, now let's try to avoid key usage: ilya@w9 ~ $ ssh localhost -o PubkeyAuthentication=no /bin/echo BLAH ilya@localhost's password: BLAH ilya@w9 ~ This works perfectly. The last game is to copy the public part into the autorized_keys file: ilya@w9 ~ $ cp .ssh/id_rsa.pub .ssh/autorized_keys chmod 600 .ssh/autorized_keys ilya@w9 ~ $ ssh localhost /bin/echo BLAH Connection closed by ::1 The summary: a client offering a key is a reason enough for the server just to say goodbye and terminate the connection. The file /var/log/sshd.log is present on my system, but it is empty. I tried to increase the log level in sshd_config file, but it doesn't work: the log file is always empty, so I don't have a clue what's happening on the server side. Neither can I start the sshd manually with the '-d' flag, because of some permission error I don't understand. Any help is appreciated! Does anyone use the cygwin SSHD with a key pair nowadays? Happy new year to everyone again. Ilya Dogolazky Copying skeleton files. These files are for the users to personalise their cygwin experience. They will never be overwritten nor automatically updated. './.bashrc' - '/home/ilya//.bashrc' './.bash_profile' - '/home/ilya//.bash_profile' './.inputrc' - '/home/ilya//.inputrc' './.profile' - '/home/ilya//.profile' ilya@w9 ~ $ id uid=1001(ilya) gid=513(None) groups=513(None),0(root),544(Administrators),545(Users),1002(HomeUsers) ilya@w9 ~ $ id -G 513 0 544 545 1002 ilya@w9 ~ $ ssh-host-config -y *** Info: Generating missing SSH host keys ssh-keygen: generating new host keys: RSA1 RSA DSA ECDSA ED25519 *** Info: Creating default /etc/ssh_config file *** Info: Creating default /etc/sshd_config file *** Info: StrictModes is set to 'yes' by default. *** Info: This is the recommended setting, but it requires that the POSIX *** Info: permissions of the user's home directory, the user's .ssh *** Info: directory, and the user's ssh key files are tight so that *** Info: only the user has write permissions. *** Info: On the other hand, StrictModes don't work well with default *** Info: Windows permissions of a home directory mounted with the *** Info: 'noacl' option, and they don't work at all if the home *** Info: directory is on a FAT or FAT32 partition. *** Query: Should StrictModes be used? (yes/no) yes *** Info: Privilege separation is set to 'sandbox' by default since *** Info: OpenSSH 6.1. This is unsupported by Cygwin and has to be set *** Info: to 'yes' or 'no'. *** Info: However, using privilege separation requires
Possibly wrong Admin group ID in cygwin 1.7.34-003 (x64)
Hello ! While trying to install and run SSH daemon in cygwin I found the following strange behavior of cygwin's ID command (I did all my testing on a Windows 8 system freshly installed on a virgin virtual machine from the DVD image en_windows_8_enterprise_x64_dvd_917522.iso downloaded from MSDN). When I execute the command id -G first in a usual cygwin terminal window and then in a terminal window opened by right click - Run as administrator, the expected output is the same with the only difference: the admin output must have additional groups 0 and 544. That is exactly the case if I use cygwin package 1.7.33-1: Plain window: 197121 545 197610 Admin window: 197121 0 544 545 197610 But if I use the testing cygwin package 1.7.34-003 (available in the installer by clicking on cygwin package), then the group 544 doesn't appear anymore: Plain window: 197121 197610 545 4 66049 11 15 4095 66048 262154 401408 Admin window: 197121 197610 0 545 4 66049 11 15 4095 66048 262154 405504 Now I don't know if it's a bug, but some scripts assume that an admin shell can be identified by the number 544 in the output of id -G, so I'm sure something is very wrong here. Screenshots are available there: http://picpaste.com/win8-cygwin-1.7.33-1.png http://picpaste.com/win8-cygwin-1.7.34-003.png In both cases the first terminal is the plain one and the second is the admin one. You have to click on the pictures in order to make the text readable. Happy new year to everyone! Ilya Dogolazky -- 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: SSHd configuration problems (System error 1376)
12/29/2014 06:30 PM, ext Ken Brown пишет: If you were really running in an elevated shell, I don't know why 544 didn't show up in the output of id -G. But that's exactly what's happening with the testing version of cygwin DLL (I wrote a bug report as a new mail thread) -- 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: SSHd configuration problems (System error 1376)
Hi Ken ! 12/23/2014 05:25 PM, ext Ken Brown wrote: I'm using the test release of cygwin in case that's relevant. I would like to try this. How do I install the test release? Is it the same as to select EXP instead of CURR in the top right corner of setup.exe GUI or should I do something else? -- Ilya -- 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: SSHd configuration problems (System error 1376)
Hi Ken! I followed your advise: 1) Reinstalled windows again 2) Started setup_x86-64.exe from cygwin web site 3) Changed two things in the package list: a) Changed version of package cygwin to 1.7.34.003 b) Marked package ssh to be installed 4) After installation started terminal (icon right click - run as admin) 5) Typed ssh-host-config -y 6) Copied the output and attached to this e-mail The same problem as before: System error 1376 has occurred. The specified local group does not exist. Adding user 'cyg_server' to local group 'root' failed! :-( By the way, very first message is quite funny: it seems your account does not have these privileges. According to windows UI my account (the only one on this fresh installed machine) is an administrative one. Cheers, Ilya Dogolazky $ ssh-host-config -y *** Warning: Running this script typically requires administrator privileges! *** Warning: However, it seems your account does not have these privileges. *** Warning: Here's the list of groups in your user token: None root Users *** Warning: This usually means you're running this script from a non-admin *** Warning: desktop session, or in a non-elevated shell under UAC control. *** Warning: Make sure you have the appropriate privileges right now, *** Warning: otherwise parts of this script will probably fail! *** Query: Are you sure you want to continue? (Say no if you're not sure *** Query: you have the required privileges) (yes/no) yes *** Info: Generating missing SSH host keys ssh-keygen: generating new host keys: RSA1 RSA DSA ECDSA ED25519 *** Info: Creating default /etc/ssh_config file *** Info: Creating default /etc/sshd_config file *** Info: StrictModes is set to 'yes' by default. *** Info: This is the recommended setting, but it requires that the POSIX *** Info: permissions of the user's home directory, the user's .ssh *** Info: directory, and the user's ssh key files are tight so that *** Info: only the user has write permissions. *** Info: On the other hand, StrictModes don't work well with default *** Info: Windows permissions of a home directory mounted with the *** Info: 'noacl' option, and they don't work at all if the home *** Info: directory is on a FAT or FAT32 partition. *** Query: Should StrictModes be used? (yes/no) yes *** Info: Privilege separation is set to 'sandbox' by default since *** Info: OpenSSH 6.1. This is unsupported by Cygwin and has to be set *** Info: to 'yes' or 'no'. *** Info: However, using privilege separation requires a non-privileged account *** Info: called 'sshd'. *** Info: For more info on privilege separation read /usr/share/doc/openssh/README.privsep. *** Query: Should privilege separation be used? (yes/no) yes *** Info: Note that creating a new user requires that the current account have *** Info: Administrator privileges. Should this script attempt to create a *** Query: new local account 'sshd'? (yes/no) yes *** Info: Updating /etc/sshd_config file *** Query: Do you want to install sshd as a service? *** Query: (Say no if it is already installed as a service) (yes/no) yes *** Query: Enter the value of CYGWIN for the daemon: [] *** Info: On Windows Server 2003, Windows Vista, and above, the *** Info: SYSTEM account cannot setuid to other users -- a capability *** Info: sshd requires. You need to have or to create a privileged *** Info: account. This script will help you do so. *** Info: It's not possible to use the LocalSystem account for services *** Info: that can change the user id without an explicit password *** Info: (such as passwordless logins [e.g. public key authentication] *** Info: via sshd) when having to create the user token from scratch. *** Info: For more information on this requirement, see *** Info: https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-nopasswd1 *** Info: If you want to enable that functionality, it's required to create *** Info: a new account with special privileges (unless such an account *** Info: already exists). This account is then used to run these special *** Info: servers. *** Info: Note that creating a new user requires that the current account *** Info: have Administrator privileges itself. *** Info: No privileged account could be found. *** Info: This script plans to use 'cyg_server'. *** Info: 'cyg_server' will only be used by registered services. *** Query: Create new privileged user account 'W4\cyg_server' (Cygwin name: 'cyg_server')? (yes/no) yes *** Info: Please enter a password for new user cyg_server. Please be sure *** Info: that this password matches the password rules given on your system. *** Info: Entering no password will exit the configuration. *** Query: Please enter the password: *** Query: Reenter: *** Info: User 'cyg_server' has been created with password 'xx'. *** Info: If you change the password, please remember also to change the *** Info: password for the installed services which use (or will soon use) *** Info: the 'cyg_server' account. System error
Re: SSHd configuration problems (System error 1376)
Hi Ken !
12/13/2014 02:30 PM, ext Ken Brown пишет:
admingroup=$(/usr/bin/mkgroup -l | /usr/bin/awk -F: '{if ( $2 ==
S-1-5-32-544 ) print $1;}')
On my system this yields Administrators. Apparently it yields root
on your system. Any idea why?
I have the same error message as PolarStorm:
Adding user 'cyg_server' to local group 'root' failed!
But when I execute the mkgroup+awk (as above) command I receive
Administrators
Even more: the output of the mkgroup -l command doesn't contain the
string root at all. So I believe the statement group is obtained in
line ... can't be quite true. The script finds the word root from
somewhere, but surely not from that mkgroup+awk command.
PS I'm trying to run sshd on a fresh installed Windows 8.1 Enterprise
N system with fresh installed cygwin64.
Cheers,
Ilya
--
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
g++ returns 127 and does nothing
Hi ! I installed GCC toolchain for cygwin by selecting install near the Devel entry in the setup tool as described in [1]. G++ executable is present now, but it doesn't work (which out any error messages): $ ls -l /usr/bin/g++ -rwxr-xr-x 4 ilya None 760349 Nov 13 09:33 /usr/bin/g++ $ g++ -v ; echo $? 127 Any idea what could be wrong, somebody have seen similar symptoms ? Cheers Ilya Dogolazky [1] http://www2.warwick.ac.uk/fac/sci/moac/people/students/peter_cock/cygwin/part2/ -- 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
windows8 + cygwin + sshd
Hi ! Have someone tried to run the ssh daemon in the windows8 consumer preview? When I start it with sygrunsrv --start sshd, I see following message: Error starting a service: QueryServiceStatus: Win32 error 1062: The service has not been started. No idea what does it mean. Any help is very appreciated. And another point about sshd: is it somehow possible to start it manually, by typing /usr/sbin/sshd? I tried but it seems /var/empty is somehow involved into running sshd and it has wrong ownership+permissions. Cheers, Ilya Dogolazky -- 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: windows8 + cygwin + sshd
Hi ! 03/02/2012 07:24 PM, ext Mathew Shember пишет: Hello Ilya, You are correct on the /var/empty. I think it needs to be owned by SYSTEM. Oh, I just executed now: # mv /var/empty /var/empty-orig # mkdir /var empty # chmod 700 /var/empty # chown SYSTEM /var/empty and now sshd is starting fine! But do you have any idea, what could be the reason? On my two windows7 fresh installed machines the /var/empty looks like this: drwxr-xr-x+ 1 cyg_server root 0 Feb 25 18:51 /var/empty/ And sshd is working fine neverthless. That's why I thought about possible windows8 specific problem... You can also try the run as admin option. Yes, I always did it in a shell window started by right click - run as admin. Without it I saw permission denied error message. Thanks! -- Ilya -- 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: slow ssh login on a cygwin machine
Hi ! 02/28/2012 05:50 PM, ext Corinna Vinschen пишет: Oh, and then again... did you install the bash-completion package on the server? It's known to result in such delays sometimes. I never used it myself so I don't know what it's doing. Somebody else might know more here. That would be a surprise, because the main delay (marked by XXX in the attachment to my first e-mail) is happening after public key offer. Anyway, I removed this bash-completion package and nothing changed. By the way: what is the proper way to remove one single package? I marked it as Uninstall and the setup.exe started to reinstall all other packages. Is it really intended behaviour? Cheers, Ilya -- 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: slow ssh login on a cygwin machine
Hi Corinna ! 02/28/2012 04:49 PM, ext Corinna Vinschen пишет: This kind of delay is often a result of the process trying to access some remote filesystem. How can I investigate this (is there something like lsof in Windows)? If you're speaking about process, do you mean the sshd process? And what could be a reason for it to access any remote file system? My home directory is on the hard drive, I surely use some remote file systems sometimes (by opening file explorer and copying files), but I don't see any reason for sshd to do the same. Is there any explicit way to unmount everything remote in windows? I close all the explorer windows, but of course it could be not enough. Or, maybe you have DNS problems on the server. What kind of DNS problems could it be? I disabled reverse DNS query (if I correctly understand meaning of the option UseDNS) and see last login from xxx.xxx.xxx.xxx message now (where xxx are digits). That size is not overly surprising. The size of the lastlog file depends on the highest uid used to login into the system. In your case you seem have pretty large uids. Every uid slot in lastlog takes 276 bytes. So you had login attempts from a user with a uid 1615639. Oh, thanks! I was getting over-suspicious :) Cheers, Ilya -- 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
