Cygwin shells closing when launched by a telnet server client in Windows 7
I am in the process of upgrading to a new machine. This machine is used as a compute server, where users telnet to the machine, start up a Korn shell and run compute intensive programs from the Korn shell. The current machine is running Cygwin 1.5 and Windows XP 64 bit. This process has worked for years. The new machine is running Cygwin 1.7 and Windows 7 64 bit. After telneting to the new machine, mksh.exe appears to start after some pause, show it's prompt and then exits, returning to the command prompt within the telnet session. This behavior makes me think that no input stream is getting connected to the shell and the shell exits. Both machines are using Microsoft's Telnet Service. I have tried ash.exe, bash.exe, dash.exe and sh.exe. All the shell programs show their input prompt and then exit to the command prompt C:\cygwin\bin>mksh.exe -l -i user@hostname ~ $ C:\cygwin\bin> The shell commands work fine, when one is locally on the compute server. I have tried HyperTerminal, putty.exe and Microsoft's telnet client on the client machine and they all give the same result. There are no entries in the Windows 7 event log. The Korn shell is working non-interactively when telneted as demonstrated below by having the Korn shell execute a command specific to the Korn shell. C:\cygwin\bin>mksh.exe -c "whence whence" whence C:\cygwin\bin> I have tried setting the Korn shell to be terminal server aware, peflags -tsaware=true mksh.exe, with no change in the results. Clayton Evans -- 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
openSSH
I have four questions that are not clear to after reading /usr/doc/Cygwin/openssh.README. 1) When running ssh-host-config, what is the correct string to enter for the CYGWIN environment variable? 2) When running ssh-host-config, is it necessary to use "pwd" as the password for the user sshd_server? If yes, how does one change this if the password has been entered as something other than "pwd". 3) Does one run ssh-user-config on the host machine or the client machine? 4) What files from the ssh-user-config is it necessary to move to the other machine? My problem is that I am not able to successfully authenticate ssh from the client to the host. I am running sshd on a Windows 7 machine (host machine), the client machine is Windows XP. I have run ssh-host-config and ssh-user-config on the host machine. Attempting to ssh from the client has successfully moved/created ~/.ssh/known_hosts to the client. The RSA, DSA and ECDSA keys fail ssh falls into password authentication. My domain network password does not work. I have copied the .ssh directory from the host to the client and have tried running ssh-user-config on the host. And moving id_rsa.pub to the host .ssh directory as authorized_keys. $ ssh -v jti031 OpenSSH_5.8p1, OpenSSL 0.9.8r 8 Feb 2011 debug1: Reading configuration data /etc/ssh_config debug1: Connecting to jti031 [192.168.58.29] port 22. debug1: Connection established. debug1: identity file /home/cevans/.ssh/id_rsa type 1 debug1: identity file /home/cevans/.ssh/id_rsa-cert type -1 debug1: identity file /home/cevans/.ssh/id_dsa type 2 debug1: identity file /home/cevans/.ssh/id_dsa-cert type -1 debug1: identity file /home/cevans/.ssh/id_ecdsa type 3 debug1: identity file /home/cevans/.ssh/id_ecdsa-cert type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_5.8 debug1: match: OpenSSH_5.8 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_5.8 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-ctr hmac-md5 none debug1: kex: client->server aes128-ctr hmac-md5 none debug1: sending SSH2_MSG_KEX_ECDH_INIT debug1: expecting SSH2_MSG_KEX_ECDH_REPLY debug1: Server host key: ECDSA 03:5a:cf:bc:63:44:be:23:d3:a1:92:c1:df:f5:46:3b debug1: Host 'jti031' is known and matches the ECDSA host key. debug1: Found key in /home/cevans/.ssh/known_hosts:1 debug1: ssh_ecdsa_verify: signature correct debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: Roaming not allowed by server 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 RSA public key: /home/cevans/.ssh/id_rsa debug1: Authentications that can continue: publickey,password,keyboard-interactive debug1: Offering DSA public key: /home/cevans/.ssh/id_dsa debug1: Authentications that can continue: publickey,password,keyboard-interactive debug1: Offering ECDSA public key: /home/cevans/.ssh/id_ecdsa debug1: Authentications that can continue: publickey,password,keyboard-interactive debug1: Next authentication method: keyboard-interactive debug1: Authentications that can continue: publickey,password,keyboard-interactive debug1: Next authentication method: password cevans@jti031's password: debug1: Authentications that can continue: publickey,password,keyboard-interactive Permission denied, please try again. cevans@jti031's password: Received disconnect from 192.168.58.29: 2: Too many authentication failures for Cevans /etc/passwd on the client does have the following line cevans:unused:11149:10513:U-JOSHITECH\cevans,S-1-5-21-645071284-784862239-476427275-1149:/home/cevans:/bin/bash /etc/passwd on the host does have the following line. CEvans:unused:11149:544:U-JOSHITECH\cevans,S-1-5-21-645071284-784862239-476427275-1149:/cygdrive/d/home/CEvans:/bin/bash Clayton Evans -- 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
openssh authentification
2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac...@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd...@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,z...@openssh.com debug2: kex_parse_kexinit: none,z...@openssh.com debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_setup: found hmac-md5 debug1: kex: server->client aes128-ctr hmac-md5 none debug2: mac_setup: found hmac-md5 debug1: kex: client->server aes128-ctr hmac-md5 none debug1: sending SSH2_MSG_KEX_ECDH_INIT debug1: expecting SSH2_MSG_KEX_ECDH_REPLY debug1: Server host key: ECDSA 42:04:0a:2f:7e:07:06:86:79:bf:e8:28:8a:eb:6c:21 debug3: load_hostkeys: loading entries for host "jti031" from file "/home/cevans/.ssh/known_hosts" debug3: load_hostkeys: found key type ECDSA in file /home/cevans/.ssh/known_hosts:1 debug3: load_hostkeys: loaded 1 keys debug3: load_hostkeys: loading entries for host "192.168.58.29" from file "/home/cevans/.ssh/known_hosts" debug3: load_hostkeys: found key type ECDSA in file /home/cevans/.ssh/known_hosts:1 debug3: load_hostkeys: loaded 1 keys debug1: Host 'jti031' is known and matches the ECDSA host key. debug1: Found key in /home/cevans/.ssh/known_hosts:1 debug1: ssh_ecdsa_verify: signature correct debug2: kex_derive_keys debug2: set_newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug2: set_newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: Roaming not allowed by server debug1: SSH2_MSG_SERVICE_REQUEST sent debug2: service_accept: ssh-userauth debug1: SSH2_MSG_SERVICE_ACCEPT received debug2: key: /home/cevans/.ssh/id_rsa (0x4f7468) debug2: key: /home/cevans/.ssh/id_dsa (0x4f9be8) debug2: key: /home/cevans/.ssh/id_ecdsa (0x4fb328) debug1: Authentications that can continue: publickey,password,keyboard-interactive debug3: start over, passed a different list publickey,password,keyboard-interactive debug3: preferred publickey,keyboard-interactive,password debug3: authmethod_lookup publickey debug3: remaining preferred: keyboard-interactive,password debug3: authmethod_is_enabled publickey debug1: Next authentication method: publickey debug1: Offering RSA public key: /home/cevans/.ssh/id_rsa debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Authentications that can continue: publickey,password,keyboard-interactive debug1: Offering DSA public key: /home/cevans/.ssh/id_dsa debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Authentications that can continue: publickey,password,keyboard-interactive debug1: Offering ECDSA public key: /home/cevans/.ssh/id_ecdsa debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Authentications that can continue: publickey,password,keyboard-interactive debug2: we did not send a packet, disable method debug3: authmethod_lookup keyboard-interactive debug3: remaining preferred: password debug3: authmethod_is_enabled keyboard-interactive debug1: Next authentication method: keyboard-interactive debug2: userauth_kbdint debug2: we sent a keyboard-interactive packet, wait for reply debug1: Authentications that can continue: publickey,password,keyboard-interactive debug3: userauth_kbdint: disable: no info_req_seen debug2: we did not send a packet, disable method debug3: authmethod_lookup password debug3: remaining preferred: debug3: authmethod_is_enabled password debug1: Next authentication method: password cevans@jti031's password: debug3: packet_send2: adding 64 (len 59 padlen 5 extra_pad 64) debug2: we sent a password packet, wait for reply debug1: Authentications that can continue: publickey,password,keyboard-interactive Permission denied, please try again. cevans@jti031's password: debug3: packet_send2: adding 64 (len 59 padlen 5 extra_pad 64) debug2: we sent a password packet, wait for reply Received disconnect from 192.168.58.29: 2: Too many authentication failures for cevans Clayton Evans -- 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: openssh authentification
> > debug1: Next authentication method: publickey > > debug1: Offering RSA public key: /home/cevans/.ssh/id_rsa > > debug3: send_pubkey_test > > debug2: we sent a publickey packet, wait for reply > > debug1: Authentications that can continue: > > publickey,password,keyboard-interactive > > debug1: Offering DSA public key: /home/cevans/.ssh/id_dsa > > debug3: send_pubkey_test > > debug2: we sent a publickey packet, wait for reply > > debug1: Authentications that can continue: > > publickey,password,keyboard-interactive > > debug1: Offering ECDSA public key: /home/cevans/.ssh/id_ecdsa > > debug3: send_pubkey_test > > debug2: we sent a publickey packet, wait for reply > > debug1: Authentications that can continue: > > publickey,password,keyboard-interactive > > debug2: we did not send a packet, disable method > > So all three of those keys were offered, but none were accepted. Are the > public keys for those in your ~/.ssh/authorized_keys file on the > server? > > Do you by chance have any "from" restrictions on the keys in authorized_keys? > For example, > > from="localhost" ssh-rsa B3NzaC1yc... > > That could cause the server to reject the keys. > > > debug1: Next authentication method: password cevans@jti031's password: > > debug3: packet_send2: adding 64 (len 59 padlen 5 extra_pad 64) > > debug2: we sent a password packet, wait for reply > > debug1: Authentications that can continue: > > publickey,password,keyboard-interactive > > Permission denied, please try again. > > Not sure what would cause that. > > I copied the .ssh/authorized_keys file from the client to the host before the ssh -vvv jti031 was done. I have not intentionally added any "from" restrictions on the keys. From your question I infer that this would be in the authorized_keys file. The lines in the authorized_keys file begin with ssh-rsa ..., ssh-dss ..., ecdsa-sha2-nistp256 The lines all end with a white space and @, where and have my user id and client machine name, jti023. Permissions in .ssh on the client are: $ ls -l total 19 -rw-r--r-- 1 cevans Administrators 1816 Oct 13 15:24 authorized_keys -rw--- 1 cevans Administrators 668 Oct 13 15:24 id_dsa -rw-r--r-- 1 cevans Administrators 603 Oct 13 15:24 id_dsa.pub -rw--- 1 cevans Administrators 227 Oct 13 15:24 id_ecdsa -rw-r--r-- 1 cevans Administrators 175 Oct 13 15:24 id_ecdsa.pub -rw--- 1 cevans Administrators 1679 Oct 13 15:24 id_rsa -rw-r--r-- 1 cevans Administrators 395 Oct 13 15:24 id_rsa.pub -rw--- 1 cevans Administrators 978 Oct 13 15:24 identity -rw-r--r-- 1 cevans Administrators 643 Oct 13 15:24 identity.pub -rw-r--r-- 1 cevans Administrators 182 Oct 13 15:43 known_hosts $ ls -ld .ssh drwx--+ 1 cevans Administrators 0 Oct 14 09:23 .ssh Permissions on the host are: -rw---+ 1 CEvans Administrators 1679 Oct 3 15:13 id_rsa -rw-r--r--+ 1 CEvans Administrators 395 Oct 3 15:13 id_rsa.pub -rw-r--r--+ 1 CEvans Administrators 603 Oct 3 15:13 id_dsa.pub -rw---+ 1 CEvans Administrators 668 Oct 3 15:13 id_dsa -rw-r--r--+ 1 CEvans Administrators 175 Oct 3 15:14 id_ecdsa.pub -rw---+ 1 CEvans Administrators 227 Oct 3 15:14 id_ecdsa -rw---+ 1 CEvans Administrators 978 Oct 3 15:14 identity -rw-r--r--+ 1 CEvans Administrators 643 Oct 3 15:14 identity.pub -rw-r--r--+ 1 CEvans Administrators 48 Oct 4 16:36 authorization -rw---+ 1 CEvans Administrators 1816 Oct 13 15:24 authorized_keys drwxr-xr-x+ 1 CEvans Administrators 0 Oct 14 09:46 /cygdrive/d/home/cevans/.ssh Clayton Evans -- 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: openssh authentification
> > > > debug1: Next authentication method: publickey > > > > debug1: Offering RSA public key: /home/cevans/.ssh/id_rsa > > > > debug3: send_pubkey_test > > > > debug2: we sent a publickey packet, wait for reply > > > > debug1: Authentications that can continue: > > > > publickey,password,keyboard-interactive > > > > debug1: Offering DSA public key: /home/cevans/.ssh/id_dsa > > > > debug3: send_pubkey_test > > > > debug2: we sent a publickey packet, wait for reply > > > > debug1: Authentications that can continue: > > > > publickey,password,keyboard-interactive > > > > debug1: Offering ECDSA public key: /home/cevans/.ssh/id_ecdsa > > > > debug3: send_pubkey_test > > > > debug2: we sent a publickey packet, wait for reply > > > > debug1: Authentications that can continue: > > > > publickey,password,keyboard-interactive > > > > debug2: we did not send a packet, disable method > > > > > > So all three of those keys were offered, but none were accepted. Are the > > > public keys for those in your ~/.ssh/authorized_keys file on the > server? > > > > I copied the .ssh/authorized_keys file from the client to the host before > > the ssh -vvv jti031 was done. > > OK, but that's not exactly what I asked. The question is, is one of those > public keys (/home/cevans/.ssh/id_rsa.pub, /home/cevans/.ssh/id_dsa.pub, or > /home/cevans/.ssh/id_ecdsa.pub from the client) in ~/.ssh/authorized_keys on > the server? No, the id_*.pub files were not copied. I have now copied all three id_*.pub files from the client to the host. I have rerun 'ssh -vvv jti031' with identical results. (At least diff finds the results to be identical.) > > Do you by chance have any "from" restrictions on the keys in > > authorized_keys? For example, > > > > from="localhost" ssh-rsa B3NzaC1yc... > > > > That could cause the server to reject the keys. > > I have not intentionally added any "from" restrictions on the keys. > From your question I infer that this would be in the authorized_keys file. Correct, see AUTHORIZED_KEYS FILE FORMAT in sshd(8). > The lines in the authorized_keys file begin with ssh-rsa ..., ssh-dss > ..., > ecdsa-sha2-nistp256 The lines all end with a white space and > @, where and have my user id > and client machine name, jti023. OK, so the answer to that is no. -- 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: openssh authentification
> > > > > > debug1: Next authentication method: publickey > > > > > > debug1: Offering RSA public key: /home/cevans/.ssh/id_rsa > > > > > > debug3: send_pubkey_test > > > > > > debug2: we sent a publickey packet, wait for reply > > > > > > debug1: Authentications that can continue: > > > > > > publickey,password,keyboard-interactive > > > > > > debug1: Offering DSA public key: /home/cevans/.ssh/id_dsa > > > > > > debug3: send_pubkey_test > > > > > > debug2: we sent a publickey packet, wait for reply > > > > > > debug1: Authentications that can continue: > > > > > > publickey,password,keyboard-interactive > > > > > > debug1: Offering ECDSA public key: /home/cevans/.ssh/id_ecdsa > > > > > > debug3: send_pubkey_test > > > > > > debug2: we sent a publickey packet, wait for reply > > > > > > debug1: Authentications that can continue: > > > > > publickey,password,keyboard-interactive > > > > > > debug2: we did not send a packet, disable method > > > > > > > > > > So all three of those keys were offered, but none were accepted. Are > > > > > the public keys for those in your ~/.ssh/authorized_keys file on the > > > > > server? > > > > > > > > I copied the .ssh/authorized_keys file from the client to the host > > > > before the ssh -vvv jti031 was done. > > > > > > OK, but that's not exactly what I asked. The question is, is one of > > > those public keys (/home/cevans/.ssh/id_rsa.pub, > > > /home/cevans/.ssh/id_dsa.pub, or /home/cevans/.ssh/id_ecdsa.pub from the > > > client) in ~/.ssh/authorized_keys on the server? > > > > No, the id_*.pub files were not copied. > > > > I have now copied all three id_*.pub files from the client to the host. I > > have rerun 'ssh -vvv jti031' with identical results. (At least diff finds > > the results to be identical.) > > I'd double-check StrictModes and PubkeyAuthentication in sshd_config. > Also, there's no need to copy around your pub keys manually, use > ssh-copy-id(1) for that. ssh-copy-id requires that password authentication is working, which is not happening, so I tried manual moving of the files Clayton Evans -- 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: openssh authentification
> > ssh-copy-id requires that password authentication is working, which is > > not happening, so I tried manual moving of the files > > Sorry, I obviously overlooked that. > I assume sshd_config is properly configured to allow public key > authentication. > > Have you checked your /etc/passwd and /etc/group files? > > Does the user guide¹ help? > > ¹http://cygwin.com/cygwin-ug-net/ntsec.html I have the default sshd_config. Doing a ssh localhost on host works, both with password authentication and with public key authentication after running ssh-user-config on the host. So I would say that yes sshd_config is configured to do public key authentication. I have looked at /etc/passwd and /etc/group on the host and client machines. The Sid match for the group and userid that I am using. Other portions of Cygwin act correctly for my domain userid on both the host and the client machines. So I think that /etc/passwd and /etc/group are OK. Is there anything specific I should be checking in these files? I am off on vacation for a week now, so I will not be able to progress this problem until 24 October 2011. Clayton Evans -- 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
