From p.pan48711 at gmail.com Thu Sep 1 03:14:43 2016 From: p.pan48711 at gmail.com (Peter P.) Date: Wed, 31 Aug 2016 13:14:43 -0400 Subject: Unit test failure when configured using --with-ssl-dir Message-ID: Hi all, I've configured and built OpenSSH 6.6p1 using a private install of OpenSSL 1.0.2h specified with --with-ssl-dir on a Centos 7.2 machine and when I run make tests I encounter the following failure in the agent.sh test case: run test agent.sh ... ssh-add -l via agent fwd proto 1 failed (exit code 127) /home/testuser/workspace/OpenSSH/platform/centos_7_x64/ssh: error while loading shared libraries: libcrypto.so.1.0.0: cannot open shared object file: No such file or directory agent fwd proto 1 failed (exit code 127) ssh-add -l via agent fwd proto 2 failed (exit code 127) /home/testuser/workspace/OpenSSH/platform/centos_7_x64/ssh: error while loading shared libraries: libcrypto.so.1.0.0: cannot open shared object file: No such file or directory agent fwd proto 2 failed (exit code 127) failed simple agent test Any ideas about what could be causing this failure? Is there an issue about how the test shell scripts pass the PATH and LD_LIBRARY_PATH environment variables down to the wrapper shell scripts? Thank you, Peter From dtucker at zip.com.au Thu Sep 1 21:00:15 2016 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 1 Sep 2016 21:00:15 +1000 Subject: Unit test failure when configured using --with-ssl-dir In-Reply-To: References: Message-ID: On Thu, Sep 1, 2016 at 3:14 AM, Peter P. wrote: > I've configured and built OpenSSH 6.6p1 using a private install of OpenSSL > 1.0.2h specified with --with-ssl-dir on a Centos 7.2 machine and when I run > make tests I encounter the following failure in the agent.sh test case: > > run test agent.sh ... > ssh-add -l via agent fwd proto 1 failed (exit code 127) > /home/testuser/workspace/OpenSSH/platform/centos_7_x64/ssh: error > while loading shared libraries: libcrypto.so.1.0.0: cannot open shared [...] > Any ideas about what could be causing this failure? Is there an issue > about how the test shell scripts pass the PATH and LD_LIBRARY_PATH > environment variables down to the wrapper shell scripts? ssh-agent is setgid and thus the runtime linker will ignore any LD_LIBRARY_PATH in the environment (doing otherwise would be a security problem). You need to add your new directory to /etc/ld.so.conf (or maybe /etc/ld.so.conf.d/, depending on your system) or use static linking. -- Darren Tucker (dtucker at zip.com.au) GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new) Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From dwfreed at mtu.edu Sat Sep 3 15:18:58 2016 From: dwfreed at mtu.edu (Doug Freed) Date: Sat, 3 Sep 2016 01:18:58 -0400 Subject: Separate Makefile targets for tests Message-ID: Hi, I'm playing around with a bug in the HPN patch where it deadlocks in their MT-CTR implementation during the integrity tests, but it's annoying to have to wait for the entire test suite to finish, which takes almost 15 minutes on my machine. It would be nice if each of the tests had its own target in the Makefile, so I could just issue something like 'make test-integrity' or whatever to run just that test, rather than having to wait for the whole suite each time, or edit the Makefile to only run that test. Thanks, Doug Freed From djm at mindrot.org Mon Sep 5 10:44:18 2016 From: djm at mindrot.org (Damien Miller) Date: Mon, 5 Sep 2016 10:44:18 +1000 (AEST) Subject: Separate Makefile targets for tests In-Reply-To: References: Message-ID: On Sat, 3 Sep 2016, Doug Freed wrote: > Hi, > > I'm playing around with a bug in the HPN patch where it deadlocks in > their MT-CTR implementation during the integrity tests, but it's > annoying to have to wait for the entire test suite to finish, which > takes almost 15 minutes on my machine. It would be nice if each of > the tests had its own target in the Makefile, so I could just issue > something like 'make test-integrity' or whatever to run just that > test, rather than having to wait for the whole suite each time, or > edit the Makefile to only run that test. You can do this already. Skip the unit tests: make SKIP_UNIT=1 tests Run a particular test: make SKIP_UNIT=1 LTESTS="integrity" tests You can run multiple tests too: make SKIP_UNIT=1 LTESTS="connect integrity" tests -d From djm at mindrot.org Mon Sep 5 10:46:24 2016 From: djm at mindrot.org (Damien Miller) Date: Mon, 5 Sep 2016 10:46:24 +1000 (AEST) Subject: GSSAPI monitor hardening Message-ID: Hi, Could someone who uses GSSAPI user authentication help test the following patch? This improves the restrictions in the privilege separation monitor to be a bit more stict. There should be no change in behaviour. If the patch breaks something then it should be immediately apparent - the server will drop connections during user-authentication. -d diff --git a/monitor.c b/monitor.c index fc006eb..ee76516 100644 --- a/monitor.c +++ b/monitor.c @@ -228,9 +228,9 @@ struct mon_table mon_dispatch_proto20[] = { {MONITOR_REQ_KEYVERIFY, MON_AUTH, mm_answer_keyverify}, #ifdef GSSAPI {MONITOR_REQ_GSSSETUP, MON_ISAUTH, mm_answer_gss_setup_ctx}, - {MONITOR_REQ_GSSSTEP, MON_ISAUTH, mm_answer_gss_accept_ctx}, - {MONITOR_REQ_GSSUSEROK, MON_AUTH, mm_answer_gss_userok}, - {MONITOR_REQ_GSSCHECKMIC, MON_ISAUTH, mm_answer_gss_checkmic}, + {MONITOR_REQ_GSSSTEP, 0, mm_answer_gss_accept_ctx}, + {MONITOR_REQ_GSSUSEROK, MON_ONCE|MON_AUTHDECIDE, mm_answer_gss_userok}, + {MONITOR_REQ_GSSCHECKMIC, MON_ONCE, mm_answer_gss_checkmic}, #endif {0, 0, NULL} }; From jjelen at redhat.com Mon Sep 5 17:44:29 2016 From: jjelen at redhat.com (Jakub Jelen) Date: Mon, 5 Sep 2016 09:44:29 +0200 Subject: GSSAPI monitor hardening In-Reply-To: References: Message-ID: <72c73970-5282-bcd0-41da-b7d85b9634df@redhat.com> On 09/05/2016 02:46 AM, Damien Miller wrote: > Hi, > > Could someone who uses GSSAPI user authentication help test the > following patch? This improves the restrictions in the privilege > separation monitor to be a bit more stict. There should be no > change in behaviour. > > If the patch breaks something then it should be immediately apparent - > the server will drop connections during user-authentication. I ran our GSSAPI tests on the code with this patch and did not notice any problems. Works as expected. Regards, -- Jakub Jelen Security Technologies Red Hat From mfriedl at gmail.com Tue Sep 6 03:23:11 2016 From: mfriedl at gmail.com (Markus Friedl) Date: Mon, 5 Sep 2016 19:23:11 +0200 Subject: kex protocol error: type 7 seq xxx error message In-Reply-To: References: Message-ID: thanks for analyzing the issue. this should fix it: --- kex.c +++ kex.c @@ -753,10 +753,8 @@ kex_choose_conf(struct ssh *ssh) char *ext; ext = match_list("ext-info-c", peer[PROPOSAL_KEX_ALGS], NULL); - if (ext) { - kex->ext_info_c = 1; - free(ext); - } + kex->ext_info_c = (ext != NULL); + free(ext); } /* Algorithm Negotiation */ -- 2016-08-24 19:06 GMT+02:00 Aris Adamantiadis : > Hi, > > mancha and me debugged a problem with OpenSSH 7.3p1 that was reported on > the #openssh freenode channel. Symptoms were that this message was > popping on the console during a busy X11 session: > kex protocol error: type 7 seq 1234 > > I managed to reproduce the problem, it is related to the SSH_EXT_INFO > packet that is send by the server every time it is sending an > SSH_NEWKEYS packet, hence after every rekeying. I reproduced it on my > system with OpenSSH 7.3p1 and manually rekeying with escape R > http://pastebin.com/Xk0dF0mc > > on the client side: > sshconnect2.c: > void > ssh_userauth2(const char *local_user, const char *server_user, char *host, > Sensitive *sensitive) > { > ... > ssh_dispatch_set(ssh, SSH2_MSG_EXT_INFO, &input_userauth_ext_info); > ssh_dispatch_set(ssh, SSH2_MSG_SERVICE_ACCEPT, > &input_userauth_service_accept); > ssh_dispatch_run(ssh, DISPATCH_BLOCK, &authctxt.success, > &authctxt); /* loop until success */ > > pubkey_cleanup(&authctxt); > ssh_dispatch_range(ssh, SSH2_MSG_USERAUTH_MIN, > SSH2_MSG_USERAUTH_MAX, NULL); > > debug("Authentication succeeded (%s).", authctxt.method->name); > } > > Is the only place where the dispatch for that packet is set. However in > kex.c: > int > kex_input_ext_info(int type, u_int32_t seq, void *ctxt) > { > ... > debug("SSH2_MSG_EXT_INFO received"); > ssh_dispatch_set(ssh, SSH2_MSG_EXT_INFO, &kex_protocol_error); > ... > } > > Ensuring this packet will only be accepted before authentication. > However the server side is different: > int > kex_send_newkeys(struct ssh *ssh) > { > ... > debug("SSH2_MSG_NEWKEYS sent"); > debug("expecting SSH2_MSG_NEWKEYS"); > ssh_dispatch_set(ssh, SSH2_MSG_NEWKEYS, &kex_input_newkeys); > if (ssh->kex->ext_info_c) > if ((r = kex_send_ext_info(ssh)) != 0) > return r; > return 0; > } > > There doesn't seem to have any logic in the client side that restricts > sending ext-info-c in the list of kex algorithms after the first key > exchange. However I couldn't find it in my kexinit proposal (even the > first one): > debug2: local client KEXINIT proposal > debug2: KEX algorithms: > curve25519-sha256 at libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1 > debug2: host key algorithms: > ecdsa-sha2-nistp256-cert-v01 at openssh.com,ecdsa-sha2-nistp384-cert-v01 at openssh.com,ecdsa-sha2-nistp521-cert-v01 at openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519-cert-v01 at openssh.com,ssh-rsa-cert-v01 at openssh.com,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa > debug2: ciphers ctos: > chacha20-poly1305 at openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm at openssh.com,aes256-gcm at openssh.com,aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc > debug2: ciphers stoc: > chacha20-poly1305 at openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm at openssh.com,aes256-gcm at openssh.com,aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc > debug2: MACs ctos: > umac-64-etm at openssh.com,umac-128-etm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-64 at openssh.com,umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1 > debug2: MACs stoc: > umac-64-etm at openssh.com,umac-128-etm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-64 at openssh.com,umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1 > debug2: compression ctos: none,zlib at openssh.com,zlib > debug2: compression stoc: none,zlib at openssh.com,zlib > debug2: languages ctos: > debug2: languages stoc: > > Mancha couldn't reproduce the issue, despite running both OpenSSH 7.3p1 > client & server from upstream, with an empty configuration file. At this > point I don't know why he's not affected. > > This bug is not very important anyway because the packet is simply > dropped with no consequence. > > Aris > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From djm at mindrot.org Tue Sep 6 11:21:02 2016 From: djm at mindrot.org (Damien Miller) Date: Tue, 6 Sep 2016 11:21:02 +1000 (AEST) Subject: GSSAPI monitor hardening In-Reply-To: <72c73970-5282-bcd0-41da-b7d85b9634df@redhat.com> References: <72c73970-5282-bcd0-41da-b7d85b9634df@redhat.com> Message-ID: On Mon, 5 Sep 2016, Jakub Jelen wrote: > I ran our GSSAPI tests on the code with this patch and did not notice any > problems. Works as expected. Thanks a heap for testing this, it has been committed now. -d From mahodardev at gmail.com Wed Sep 7 13:59:57 2016 From: mahodardev at gmail.com (Mahoda Ratnayaka) Date: Wed, 7 Sep 2016 15:59:57 +1200 Subject: Question regarding Host keys. Message-ID: Hi, I'm having a problem when I add "HostKeyAlgorithms +ssh-dss" to the ssh_config file the host key will always negotiate to a wrong one. In my case it will negotiate to "ecdsa-sha2-nistp256". The client was already configured with the servers rsa public key, before the change I added to the ssh_config file I could see from the debug that server and client will negotiate to use ssh-rsa as expected. After change unfortunately the client and server will negotiate to use ecdsa-sha2-nistp256, then later will complain "REMOTE HOST IDENTIFICATION HAS CHANGED" and fail. I got around this by adding the ecdsa public key to the know hosts. After some instigation I noticed that before my change the host keys will reorder to use the rsa based ones first and the others after, but not after my change. So, I would like to know is there a reason for not allowing the keys to reorder after specifying them in the ssh_config file, and will this behaviour be changed in an upcoming release. I think it would be nice to reorder the host keys even when they from the config file. Thanks, Mahoda From dtucker at zip.com.au Wed Sep 7 14:53:01 2016 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 7 Sep 2016 14:53:01 +1000 Subject: Question regarding Host keys. In-Reply-To: References: Message-ID: On Wed, Sep 7, 2016 at 1:59 PM, Mahoda Ratnayaka wrote: > I'm having a problem when I add "HostKeyAlgorithms +ssh-dss" to the > ssh_config file the host key will always negotiate to a wrong one. In my > case it will negotiate to "ecdsa-sha2-nistp256". The client was already > configured with the servers rsa public key, before the change I added to > the ssh_config file I could see from the debug that server and client will > negotiate to use ssh-rsa as expected. After change unfortunately the client > and server will negotiate to use ecdsa-sha2-nistp256, then later will > complain "REMOTE HOST IDENTIFICATION HAS CHANGED" and fail. I got around > this by adding the ecdsa public key to the know hosts. What version of OpenSSH is this? Can you post debug output (ssh -vvv) with and without the +ssh-dss option? -- Darren Tucker (dtucker at zip.com.au) GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new) Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From mahodardev at gmail.com Thu Sep 8 07:47:36 2016 From: mahodardev at gmail.com (Mahoda Ratnayaka) Date: Thu, 8 Sep 2016 09:47:36 +1200 Subject: Question regarding Host keys. In-Reply-To: References: Message-ID: Thanks for the reply, the client is using 7.2 and the server is on 6.6 version. And, here are the debug files attached. Thanks, Mahoda With Change: ========================================================================================= OpenSSH_7.2p2, OpenSSL 1.0.2h 3 May 2016 debug1: Reading configuration data /etc/ssh/ssh_config debug2: resolving "192.168.1.1" port 22 debug2: ssh_connect_direct: needpriv 0 debug1: Connecting to 192.168.1.1 [192.168.1.1] port 22. debug1: Connection established. debug1: permanently_set_uid: 0/0 debug1: key_load_public: No such file or directory debug1: identity file /flash/.home/root/.ssh/identity type -1 debug1: key_load_public: No such file or directory debug1: identity file /flash/.home/root/.ssh/identity-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /flash/.home/root/.ssh/id_rsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /flash/.home/root/.ssh/id_rsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /flash/.home/root/.ssh/id_dsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /flash/.home/root/.ssh/id_dsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /flash/.home/root/.ssh/id_ecdsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /flash/.home/root/.ssh/id_ecdsa-cert type -1 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-AtiSSH_2.0 debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.8 debug1: match: OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.8 pat OpenSSH_6.6.1* compat 0x04000000 debug2: fd 3 setting O_NONBLOCK debug3: send packet: type 20 debug1: SSH2_MSG_KEXINIT sent debug3: receive packet: type 20 debug1: SSH2_MSG_KEXINIT received debug2: local client KEXINIT proposal debug2: KEX algorithms: curve25519-sha256 at libssh.org ,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,ext-info-c debug2: host key algorithms: ecdsa-sha2-nistp256-cert-v01 at openssh.com, ecdsa-sha2-nistp384-cert-v01 at openssh.com, ecdsa-sha2-nistp521-cert-v01 at openssh.com,ssh-ed25519-cert-v01 at openssh.com, ssh-rsa-cert-v01 at openssh.com ,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa,ssh-dss debug2: ciphers ctos: chacha20-poly1305 at openssh.com ,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm at openssh.com, aes256-gcm at openssh.com,aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc debug2: ciphers stoc: chacha20-poly1305 at openssh.com ,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm at openssh.com, aes256-gcm at openssh.com,aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc debug2: MACs ctos: umac-64-etm at openssh.com,umac-128-etm at openssh.com, hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com, hmac-sha1-etm at openssh.com,umac-64 at openssh.com,umac-128 at openssh.com ,hmac-sha2-256,hmac-sha2-512,hmac-sha1 debug2: MACs stoc: umac-64-etm at openssh.com,umac-128-etm at openssh.com, hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com, hmac-sha1-etm at openssh.com,umac-64 at openssh.com,umac-128 at openssh.com ,hmac-sha2-256,hmac-sha2-512,hmac-sha1 debug2: compression ctos: none,zlib at openssh.com,zlib debug2: compression stoc: none,zlib at openssh.com,zlib debug2: languages ctos: debug2: languages stoc: debug2: first_kex_follows 0 debug2: reserved 0 debug2: peer server KEXINIT proposal debug2: KEX algorithms: curve25519-sha256 at libssh.org ,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: host key algorithms: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ssh-ed25519 debug2: ciphers ctos: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128, aes128-gcm at openssh.com,aes256-gcm at openssh.com,chacha20-poly1305 at openssh.com ,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour, rijndael-cbc at lysator.liu.se debug2: ciphers stoc: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128, aes128-gcm at openssh.com,aes256-gcm at openssh.com,chacha20-poly1305 at openssh.com ,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour, rijndael-cbc at lysator.liu.se debug2: MACs ctos: hmac-md5-etm at openssh.com,hmac-sha1-etm at openssh.com, umac-64-etm at openssh.com,umac-128-etm at openssh.com, hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com, hmac-ripemd160-etm at openssh.com,hmac-sha1-96-etm at openssh.com, hmac-md5-96-etm at openssh.com,hmac-md5,hmac-sha1,umac-64 at openssh.com, umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160, hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: MACs stoc: hmac-md5-etm at openssh.com,hmac-sha1-etm at openssh.com, umac-64-etm at openssh.com,umac-128-etm at openssh.com, hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com, hmac-ripemd160-etm at openssh.com,hmac-sha1-96-etm at openssh.com, hmac-md5-96-etm at openssh.com,hmac-md5,hmac-sha1,umac-64 at openssh.com, umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160, hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: compression ctos: none,zlib at openssh.com debug2: compression stoc: none,zlib at openssh.com debug2: languages ctos: debug2: languages stoc: debug2: first_kex_follows 0 debug2: reserved 0 debug1: kex: algorithm: curve25519-sha256 at libssh.org debug1: kex: host key algorithm: ecdsa-sha2-nistp256 debug1: kex: server->client cipher: chacha20-poly1305 at openssh.com MAC: compression: none debug1: kex: client->server cipher: chacha20-poly1305 at openssh.com MAC: compression: none debug3: send packet: type 30 debug1: expecting SSH2_MSG_KEX_ECDH_REPLY debug3: receive packet: type 31 debug1: Server host key: ecdsa-sha2-nistp256 SHA256:IwZ3AJCkBnQypTalkkezSSXShPg/+1eEDgHS65R8dN0 debug3: hostkeys_foreach: reading file "/flash/.home/root/.ssh/known_hosts" debug3: hostkeys_foreach: reading file "/flash/.configs/ssh/ssh_known_hosts" debug3: record_hostkey: found key type RSA in file /flash/.configs/ssh/ssh_known_hosts:2 debug3: load_hostkeys: loaded 1 keys from 192.168.1.1 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that a host key has just been changed. The fingerprint for the ECDSA key sent by the remote host is SHA256:IwZ3AJCkBnQypTalkkezSSXShPg/+1eEDgHS65R8dN0. Please contact your system administrator. ECDSA host key for 192.168.1.1 has changed and you have requested strict checking. Host key verification failed. ============================================================================================================================================= Without change: ============================================================================================================================================= OpenSSH_7.2p2, OpenSSL 1.0.2h 3 May 2016 debug1: Reading configuration data /etc/ssh/ssh_config debug2: resolving "192.168.1.1" port 22 debug2: ssh_connect_direct: needpriv 0 debug1: Connecting to 192.168.1.1 [192.168.1.1] port 22. debug1: Connection established. debug1: permanently_set_uid: 0/0 debug1: key_load_public: No such file or directory debug1: identity file /flash/.home/root/.ssh/identity type -1 debug1: key_load_public: No such file or directory debug1: identity file /flash/.home/root/.ssh/identity-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /flash/.home/root/.ssh/id_rsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /flash/.home/root/.ssh/id_rsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /flash/.home/root/.ssh/id_dsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /flash/.home/root/.ssh/id_dsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /flash/.home/root/.ssh/id_ecdsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /flash/.home/root/.ssh/id_ecdsa-cert type -1 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-AtiSSH_2.0 debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.8 debug1: match: OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.8 pat OpenSSH_6.6.1* compat 0x04000000 debug2: fd 3 setting O_NONBLOCK debug3: hostkeys_foreach: reading file "/flash/.home/root/.ssh/known_hosts" debug3: hostkeys_foreach: reading file "/flash/.configs/ssh/ssh_known_hosts" debug3: record_hostkey: found key type RSA in file /flash/.configs/ssh/ssh_known_hosts:2 debug3: load_hostkeys: loaded 1 keys from 192.168.1.1 debug3: order_hostkeyalgs: prefer hostkeyalgs: ssh-rsa-cert-v01 at openssh.com ,rsa-sha2-512,rsa-sha2-256,ssh-rsa debug3: send packet: type 20 debug1: SSH2_MSG_KEXINIT sent debug3: receive packet: type 20 debug1: SSH2_MSG_KEXINIT received debug2: local client KEXINIT proposal debug2: KEX algorithms: curve25519-sha256 at libssh.org ,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,ext-info-c debug2: host key algorithms: ssh-rsa-cert-v01 at openssh.com ,rsa-sha2-512,rsa-sha2-256,ssh-rsa,ecdsa-sha2-nistp256-cert-v01 at openssh.com, ecdsa-sha2-nistp384-cert-v01 at openssh.com, ecdsa-sha2-nistp521-cert-v01 at openssh.com,ssh-ed25519-cert-v01 at openssh.com ,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519 debug2: ciphers ctos: chacha20-poly1305 at openssh.com ,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm at openssh.com, aes256-gcm at openssh.com,aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc debug2: ciphers stoc: chacha20-poly1305 at openssh.com ,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm at openssh.com, aes256-gcm at openssh.com,aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc debug2: MACs ctos: umac-64-etm at openssh.com,umac-128-etm at openssh.com, hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com, hmac-sha1-etm at openssh.com,umac-64 at openssh.com,umac-128 at openssh.com ,hmac-sha2-256,hmac-sha2-512,hmac-sha1 debug2: MACs stoc: umac-64-etm at openssh.com,umac-128-etm at openssh.com, hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com, hmac-sha1-etm at openssh.com,umac-64 at openssh.com,umac-128 at openssh.com ,hmac-sha2-256,hmac-sha2-512,hmac-sha1 debug2: compression ctos: none,zlib at openssh.com,zlib debug2: compression stoc: none,zlib at openssh.com,zlib debug2: languages ctos: debug2: languages stoc: debug2: first_kex_follows 0 debug2: reserved 0 debug2: peer server KEXINIT proposal debug2: KEX algorithms: curve25519-sha256 at libssh.org ,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: host key algorithms: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ssh-ed25519 debug2: ciphers ctos: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128, aes128-gcm at openssh.com,aes256-gcm at openssh.com,chacha20-poly1305 at openssh.com ,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour, rijndael-cbc at lysator.liu.se debug2: ciphers stoc: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128, aes128-gcm at openssh.com,aes256-gcm at openssh.com,chacha20-poly1305 at openssh.com ,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour, rijndael-cbc at lysator.liu.se debug2: MACs ctos: hmac-md5-etm at openssh.com,hmac-sha1-etm at openssh.com, umac-64-etm at openssh.com,umac-128-etm at openssh.com, hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com, hmac-ripemd160-etm at openssh.com,hmac-sha1-96-etm at openssh.com, hmac-md5-96-etm at openssh.com,hmac-md5,hmac-sha1,umac-64 at openssh.com, umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160, hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: MACs stoc: hmac-md5-etm at openssh.com,hmac-sha1-etm at openssh.com, umac-64-etm at openssh.com,umac-128-etm at openssh.com, hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com, hmac-ripemd160-etm at openssh.com,hmac-sha1-96-etm at openssh.com, hmac-md5-96-etm at openssh.com,hmac-md5,hmac-sha1,umac-64 at openssh.com, umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160, hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: compression ctos: none,zlib at openssh.com debug2: compression stoc: none,zlib at openssh.com debug2: languages ctos: debug2: languages stoc: debug2: first_kex_follows 0 debug2: reserved 0 debug1: kex: algorithm: curve25519-sha256 at libssh.org debug1: kex: host key algorithm: ssh-rsa debug1: kex: server->client cipher: chacha20-poly1305 at openssh.com MAC: compression: none debug1: kex: client->server cipher: chacha20-poly1305 at openssh.com MAC: compression: none debug3: send packet: type 30 debug1: expecting SSH2_MSG_KEX_ECDH_REPLY debug3: receive packet: type 31 debug1: Server host key: ssh-rsa SHA256:UWb75G/DzMWOCH4KNR4As0lYcpI1POgD7TEX9iXYSLA debug3: hostkeys_foreach: reading file "/flash/.home/root/.ssh/known_hosts" debug3: hostkeys_foreach: reading file "/flash/.configs/ssh/ssh_known_hosts" debug3: record_hostkey: found key type RSA in file /flash/.configs/ssh/ssh_known_hosts:2 debug3: load_hostkeys: loaded 1 keys from 192.168.1.1 debug1: Host '192.168.1.1' is known and matches the RSA host key. debug1: Found key in /flash/.configs/ssh/ssh_known_hosts:2 debug3: send packet: type 21 debug2: set_newkeys: mode 1 debug1: rekey after 134217728 blocks debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug3: receive packet: type 21 debug2: set_newkeys: mode 0 debug1: rekey after 134217728 blocks debug1: SSH2_MSG_NEWKEYS received debug2: key: /flash/.home/root/.ssh/identity ((nil)) debug2: key: /flash/.home/root/.ssh/id_rsa ((nil)) debug2: key: /flash/.home/root/.ssh/id_dsa ((nil)) debug2: key: /flash/.home/root/.ssh/id_ecdsa ((nil)) debug3: send packet: type 5 debug3: receive packet: type 6 debug2: service_accept: ssh-userauth debug1: SSH2_MSG_SERVICE_ACCEPT received debug3: send packet: type 50 debug3: receive packet: type 51 debug1: Authentications that can continue: publickey,password debug3: start over, passed a different list publickey,password 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: Trying private key: /flash/.home/root/.ssh/identity debug3: no such identity: /flash/.home/root/.ssh/identity: No such file or directory debug1: Trying private key: /flash/.home/root/.ssh/id_rsa debug3: no such identity: /flash/.home/root/.ssh/id_rsa: No such file or directory debug1: Trying private key: /flash/.home/root/.ssh/id_dsa debug3: no such identity: /flash/.home/root/.ssh/id_dsa: No such file or directory debug1: Trying private key: /flash/.home/root/.ssh/id_ecdsa debug3: no such identity: /flash/.home/root/.ssh/id_ecdsa: No such file or directory debug2: we did not send a packet, disable method debug3: authmethod_lookup password debug3: remaining preferred: ,password debug3: authmethod_is_enabled password debug1: Next authentication method: password =========================================================================================================================================== On 7 September 2016 at 16:53, Darren Tucker wrote: > On Wed, Sep 7, 2016 at 1:59 PM, Mahoda Ratnayaka > wrote: > > I'm having a problem when I add "HostKeyAlgorithms +ssh-dss" to the > > ssh_config file the host key will always negotiate to a wrong one. In my > > case it will negotiate to "ecdsa-sha2-nistp256". The client was already > > configured with the servers rsa public key, before the change I added to > > the ssh_config file I could see from the debug that server and client > will > > negotiate to use ssh-rsa as expected. After change unfortunately the > client > > and server will negotiate to use ecdsa-sha2-nistp256, then later will > > complain "REMOTE HOST IDENTIFICATION HAS CHANGED" and fail. I got around > > this by adding the ecdsa public key to the know hosts. > > What version of OpenSSH is this? Can you post debug output (ssh -vvv) > with and without the +ssh-dss option? > > -- > Darren Tucker (dtucker at zip.com.au) > GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new) > Good judgement comes with experience. Unfortunately, the experience > usually comes from bad judgement. > From steffen at sdaoden.eu Fri Sep 9 23:15:50 2016 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Fri, 09 Sep 2016 15:15:50 +0200 Subject: fyi: agent forwarding fails (with enabled ControlMaster) after time shift on client Message-ID: <20160909131550.0S8l9-dfB%steffen@sdaoden.eu> Hello. Yes, i think that was the cause why agent forwarding wasn't performed at all, i had to rm(1) the control socket and the next ssh(1) connection forwarded the agent normally again. (It was a huge timeshift by several hours.) I.e., just in case this is something you didn't have on your radar yet. Ciao. --steffen From djm at mindrot.org Sun Sep 11 14:18:28 2016 From: djm at mindrot.org (Damien Miller) Date: Sun, 11 Sep 2016 14:18:28 +1000 (AEST) Subject: fyi: agent forwarding fails (with enabled ControlMaster) after time shift on client In-Reply-To: <20160909131550.0S8l9-dfB%steffen@sdaoden.eu> References: <20160909131550.0S8l9-dfB%steffen@sdaoden.eu> Message-ID: On Fri, 9 Sep 2016, Steffen Nurpmeso wrote: > Hello. > > Yes, i think that was the cause why agent forwarding wasn't > performed at all, i had to rm(1) the control socket and the next > ssh(1) connection forwarded the agent normally again. (It was > a huge timeshift by several hours.) I.e., just in case this is > something you didn't have on your radar yet. Do you know whether the agent was still running or if it has terminated? Did you load your keys with a timeout set? -d From steffen at sdaoden.eu Mon Sep 12 21:06:08 2016 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Mon, 12 Sep 2016 13:06:08 +0200 Subject: fyi: agent forwarding fails (with enabled ControlMaster) after time shift on client In-Reply-To: References: <20160909131550.0S8l9-dfB%steffen@sdaoden.eu> Message-ID: <20160912110608.2LksTtWX9%steffen@sdaoden.eu> Good morning and happy Monday. Damien Miller wrote: |On Fri, 9 Sep 2016, Steffen Nurpmeso wrote: |> Yes, i think that was the cause why agent forwarding wasn't |> performed at all, i had to rm(1) the control socket and the next |> ssh(1) connection forwarded the agent normally again. (It was |> a huge timeshift by several hours.) I.e., just in case this is |> something you didn't have on your radar yet. | |Do you know whether the agent was still running or if it has terminated? It is running from Monday to Saturday (supervising a terminal multiplexer, from within which everything happens (and itself supervised by ssh session without agent forwarding, on hardware)). |Did you load your keys with a timeout set? No. The only timeouts i have are ControlPersist, RekeyLimit, and ServerAliveInterval. The server is default AlpineLinux less some access methods, with only one KexAlgorithm and set ClientAlive*. --steffen From ogniemi-drbd at yahoo.com Tue Sep 13 16:48:17 2016 From: ogniemi-drbd at yahoo.com (M.G.) Date: Tue, 13 Sep 2016 06:48:17 +0000 (UTC) Subject: proxy command in user's config References: <822960944.137426.1473749297863.ref@mail.yahoo.com> Message-ID: <822960944.137426.1473749297863@mail.yahoo.com> hello, OpenSSH_7.1p2, OpenSSL 1.0.1g 7 Apr 2014 in my ~/.ssh/config I have configured two Hosts: Host gatehost ???? ProxyCommand ssh -2 -i ~/.ssh/gkey -q -x user at jumphost -W %h:22 Host myhmc ???? Hostname gatehost ???? LocalForward 11443 the-hmc:443 ???? GatewayPorts yes The first one works perfect (configured password less) but when I want to user this Host in next Host myhmc config to establish tunnel through it, I get error: $ ssh bruhmc _ssh: Could not resolve hostname myhmc: Name or service not known Why? As far as I remember it stopped working from some newer release of openssh. Could this functionality be "blocked" intentionally? mark From djm at mindrot.org Wed Sep 14 03:38:08 2016 From: djm at mindrot.org (Damien Miller) Date: Wed, 14 Sep 2016 03:38:08 +1000 (AEST) Subject: proxy command in user's config In-Reply-To: <822960944.137426.1473749297863@mail.yahoo.com> References: <822960944.137426.1473749297863.ref@mail.yahoo.com> <822960944.137426.1473749297863@mail.yahoo.com> Message-ID: On Tue, 13 Sep 2016, M.G. wrote: > hello, > OpenSSH_7.1p2, OpenSSL 1.0.1g 7 Apr 2014 > > in my ~/.ssh/config I have configured two Hosts: > Host gatehost > ???? ProxyCommand ssh -2 -i ~/.ssh/gkey -q -x user at jumphost -W %h:22 > > Host myhmc > ???? Hostname gatehost > ???? LocalForward 11443 the-hmc:443 > ???? GatewayPorts yes > > The first one works perfect (configured password less) > but when I want to user this Host in next Host myhmc config to establish tunnel through it, I get error: > $ ssh bruhmc > _ssh: Could not resolve hostname myhmc: Name or service not known > Why? As far as I remember it stopped working from some newer release > of openssh. Could this functionality be "blocked" intentionally? We can't say - you haven't included enough information. Mostly a log of a failing connection. Also what's bruhmc? It isn't mentioned in your config. What I guess is happening is that myhmc is being resolved on jumphost for some reason. It's possible that something has changed in the ordering of DNS resolution and how ProxyCommand arguments are constructed, but I can't tell. -d From mahodardev at gmail.com Wed Sep 14 09:39:10 2016 From: mahodardev at gmail.com (Mahoda Ratnayaka) Date: Wed, 14 Sep 2016 11:39:10 +1200 Subject: Question regarding Host keys. In-Reply-To: References: Message-ID: Hi, Quick update, I did a bit of digging around and found when nothing added to HostKeyAlgorithms the list will reorder: "debug3: order_hostkeyalgs: prefer hostkeyalgs: ssh-rsa-cert-v01 at openssh.com,rsa-sha2-512,rsa-sha2-256,ssh-rsa". This doesn't happen in the case when HostKeyAlgorithms has something defined. Looking at the code I see that this is deliberate, just curious is there a reason for implementing like this. Also, I forgot to mention I have strict check on. Any helpful information will be much appreciated. Thanks, Mahoda On 8 September 2016 at 09:47, Mahoda Ratnayaka wrote: > Thanks for the reply, the client is using 7.2 and the server is on 6.6 > version. And, here are the debug files attached. > > Thanks, > Mahoda > > With Change: > ============================================================ > ============================= > OpenSSH_7.2p2, OpenSSL 1.0.2h 3 May 2016 > debug1: Reading configuration data /etc/ssh/ssh_config > debug2: resolving "192.168.1.1" port 22 > debug2: ssh_connect_direct: needpriv 0 > debug1: Connecting to 192.168.1.1 [192.168.1.1] port 22. > debug1: Connection established. > debug1: permanently_set_uid: 0/0 > debug1: key_load_public: No such file or directory > debug1: identity file /flash/.home/root/.ssh/identity type -1 > debug1: key_load_public: No such file or directory > debug1: identity file /flash/.home/root/.ssh/identity-cert type -1 > debug1: key_load_public: No such file or directory > debug1: identity file /flash/.home/root/.ssh/id_rsa type -1 > debug1: key_load_public: No such file or directory > debug1: identity file /flash/.home/root/.ssh/id_rsa-cert type -1 > debug1: key_load_public: No such file or directory > debug1: identity file /flash/.home/root/.ssh/id_dsa type -1 > debug1: key_load_public: No such file or directory > debug1: identity file /flash/.home/root/.ssh/id_dsa-cert type -1 > debug1: key_load_public: No such file or directory > debug1: identity file /flash/.home/root/.ssh/id_ecdsa type -1 > debug1: key_load_public: No such file or directory > debug1: identity file /flash/.home/root/.ssh/id_ecdsa-cert type -1 > debug1: Enabling compatibility mode for protocol 2.0 > debug1: Local version string SSH-2.0-AtiSSH_2.0 > debug1: Remote protocol version 2.0, remote software version > OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.8 > debug1: match: OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.8 pat OpenSSH_6.6.1* compat > 0x04000000 > debug2: fd 3 setting O_NONBLOCK > debug3: send packet: type 20 > debug1: SSH2_MSG_KEXINIT sent > debug3: receive packet: type 20 > debug1: SSH2_MSG_KEXINIT received > debug2: local client KEXINIT proposal > debug2: KEX algorithms: curve25519-sha256 at libssh.org, > ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521, > diffie-hellman-group-exchange-sha256,diffie-hellman-group- > exchange-sha1,diffie-hellman-group14-sha1,ext-info-c > debug2: host key algorithms: ecdsa-sha2-nistp256-cert-v01 at openssh.com, > ecdsa-sha2-nistp384-cert-v01 at openssh.com,ecdsa-sha2-nistp521-cert-v01@ > openssh.com,ssh-ed25519-cert-v01 at openssh.com,ssh-rsa-cert-v01 at openssh.com > ,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh- > ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa,ssh-dss > debug2: ciphers ctos: chacha20-poly1305 at openssh.com, > aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm at openssh.com,aes > 256-gcm at openssh.com,aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc > debug2: ciphers stoc: chacha20-poly1305 at openssh.com, > aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm at openssh.com,aes > 256-gcm at openssh.com,aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc > debug2: MACs ctos: umac-64-etm at openssh.com,umac-128-etm at openssh.com, > hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com,hmac-sha1- > etm at openssh.com,umac-64 at openssh.com,umac-128 at openssh.com > ,hmac-sha2-256,hmac-sha2-512,hmac-sha1 > debug2: MACs stoc: umac-64-etm at openssh.com,umac-128-etm at openssh.com, > hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com,hmac-sha1- > etm at openssh.com,umac-64 at openssh.com,umac-128 at openssh.com > ,hmac-sha2-256,hmac-sha2-512,hmac-sha1 > debug2: compression ctos: none,zlib at openssh.com,zlib > debug2: compression stoc: none,zlib at openssh.com,zlib > debug2: languages ctos: > debug2: languages stoc: > debug2: first_kex_follows 0 > debug2: reserved 0 > debug2: peer server KEXINIT proposal > debug2: KEX algorithms: curve25519-sha256 at libssh.org, > ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521, > diffie-hellman-group-exchange-sha256,diffie-hellman-group- > exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 > debug2: host key algorithms: ssh-rsa,ssh-dss,ecdsa-sha2- > nistp256,ssh-ed25519 > debug2: ciphers ctos: aes128-ctr,aes192-ctr,aes256- > ctr,arcfour256,arcfour128,aes128-gcm at openssh.com,aes256-gcm at openssh.com, > chacha20-poly1305 at openssh.com,aes128-cbc,3des- > cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour, > rijndael-cbc at lysator.liu.se > debug2: ciphers stoc: aes128-ctr,aes192-ctr,aes256- > ctr,arcfour256,arcfour128,aes128-gcm at openssh.com,aes256-gcm at openssh.com, > chacha20-poly1305 at openssh.com,aes128-cbc,3des- > cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour, > rijndael-cbc at lysator.liu.se > debug2: MACs ctos: hmac-md5-etm at openssh.com,hmac-sha1-etm at openssh.com, > umac-64-etm at openssh.com,umac-128-etm at openssh.com,hmac-sha2-256-etm@ > openssh.com,hmac-sha2-512-etm at openssh.com,hmac-ripemd160-etm at openssh.com, > hmac-sha1-96-etm at openssh.com,hmac-md5-96-etm at openssh.com,hmac-md5,hmac- > sha1,umac-64 at openssh.com,umac-128 at openssh.com,hmac-sha2-256, > hmac-sha2-512,hmac-ripemd160,hmac-ripemd160 at openssh.com, > hmac-sha1-96,hmac-md5-96 > debug2: MACs stoc: hmac-md5-etm at openssh.com,hmac-sha1-etm at openssh.com, > umac-64-etm at openssh.com,umac-128-etm at openssh.com,hmac-sha2-256-etm@ > openssh.com,hmac-sha2-512-etm at openssh.com,hmac-ripemd160-etm at openssh.com, > hmac-sha1-96-etm at openssh.com,hmac-md5-96-etm at openssh.com,hmac-md5,hmac- > sha1,umac-64 at openssh.com,umac-128 at openssh.com,hmac-sha2-256, > hmac-sha2-512,hmac-ripemd160,hmac-ripemd160 at openssh.com, > hmac-sha1-96,hmac-md5-96 > debug2: compression ctos: none,zlib at openssh.com > debug2: compression stoc: none,zlib at openssh.com > debug2: languages ctos: > debug2: languages stoc: > debug2: first_kex_follows 0 > debug2: reserved 0 > debug1: kex: algorithm: curve25519-sha256 at libssh.org > debug1: kex: host key algorithm: ecdsa-sha2-nistp256 > debug1: kex: server->client cipher: chacha20-poly1305 at openssh.com MAC: > compression: none > debug1: kex: client->server cipher: chacha20-poly1305 at openssh.com MAC: > compression: none > debug3: send packet: type 30 > debug1: expecting SSH2_MSG_KEX_ECDH_REPLY > debug3: receive packet: type 31 > debug1: Server host key: ecdsa-sha2-nistp256 SHA256: > IwZ3AJCkBnQypTalkkezSSXShPg/+1eEDgHS65R8dN0 > debug3: hostkeys_foreach: reading file "/flash/.home/root/.ssh/known_ > hosts" > debug3: hostkeys_foreach: reading file "/flash/.configs/ssh/ssh_ > known_hosts" > debug3: record_hostkey: found key type RSA in file > /flash/.configs/ssh/ssh_known_hosts:2 > debug3: load_hostkeys: loaded 1 keys from 192.168.1.1 > @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ > @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ > @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ > IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! > Someone could be eavesdropping on you right now (man-in-the-middle attack)! > It is also possible that a host key has just been changed. > The fingerprint for the ECDSA key sent by the remote host is > SHA256:IwZ3AJCkBnQypTalkkezSSXShPg/+1eEDgHS65R8dN0. > Please contact your system administrator. > ECDSA host key for 192.168.1.1 has changed and you have requested strict > checking. > Host key verification failed. > ============================================================ > ============================================================ > ===================== > > Without change: > ============================================================ > ============================================================ > ===================== > OpenSSH_7.2p2, OpenSSL 1.0.2h 3 May 2016 > debug1: Reading configuration data /etc/ssh/ssh_config > debug2: resolving "192.168.1.1" port 22 > debug2: ssh_connect_direct: needpriv 0 > debug1: Connecting to 192.168.1.1 [192.168.1.1] port 22. > debug1: Connection established. > debug1: permanently_set_uid: 0/0 > debug1: key_load_public: No such file or directory > debug1: identity file /flash/.home/root/.ssh/identity type -1 > debug1: key_load_public: No such file or directory > debug1: identity file /flash/.home/root/.ssh/identity-cert type -1 > debug1: key_load_public: No such file or directory > debug1: identity file /flash/.home/root/.ssh/id_rsa type -1 > debug1: key_load_public: No such file or directory > debug1: identity file /flash/.home/root/.ssh/id_rsa-cert type -1 > debug1: key_load_public: No such file or directory > debug1: identity file /flash/.home/root/.ssh/id_dsa type -1 > debug1: key_load_public: No such file or directory > debug1: identity file /flash/.home/root/.ssh/id_dsa-cert type -1 > debug1: key_load_public: No such file or directory > debug1: identity file /flash/.home/root/.ssh/id_ecdsa type -1 > debug1: key_load_public: No such file or directory > debug1: identity file /flash/.home/root/.ssh/id_ecdsa-cert type -1 > debug1: Enabling compatibility mode for protocol 2.0 > debug1: Local version string SSH-2.0-AtiSSH_2.0 > debug1: Remote protocol version 2.0, remote software version > OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.8 > debug1: match: OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.8 pat OpenSSH_6.6.1* compat > 0x04000000 > debug2: fd 3 setting O_NONBLOCK > debug3: hostkeys_foreach: reading file "/flash/.home/root/.ssh/known_ > hosts" > debug3: hostkeys_foreach: reading file "/flash/.configs/ssh/ssh_ > known_hosts" > debug3: record_hostkey: found key type RSA in file > /flash/.configs/ssh/ssh_known_hosts:2 > debug3: load_hostkeys: loaded 1 keys from 192.168.1.1 > debug3: order_hostkeyalgs: prefer hostkeyalgs: > ssh-rsa-cert-v01 at openssh.com,rsa-sha2-512,rsa-sha2-256,ssh-rsa > debug3: send packet: type 20 > debug1: SSH2_MSG_KEXINIT sent > debug3: receive packet: type 20 > debug1: SSH2_MSG_KEXINIT received > debug2: local client KEXINIT proposal > debug2: KEX algorithms: curve25519-sha256 at libssh.org, > ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521, > diffie-hellman-group-exchange-sha256,diffie-hellman-group- > exchange-sha1,diffie-hellman-group14-sha1,ext-info-c > debug2: host key algorithms: ssh-rsa-cert-v01 at openssh.com, > rsa-sha2-512,rsa-sha2-256,ssh-rsa,ecdsa-sha2-nistp256-cert-v01 at openssh.com > ,ecdsa-sha2-nistp384-cert-v01 at openssh.com,ecdsa-sha2-nistp521-cert-v01@ > openssh.com,ssh-ed25519-cert-v01 at openssh.com,ecdsa-sha2- > nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519 > debug2: ciphers ctos: chacha20-poly1305 at openssh.com, > aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm at openssh.com,aes > 256-gcm at openssh.com,aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc > debug2: ciphers stoc: chacha20-poly1305 at openssh.com, > aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm at openssh.com,aes > 256-gcm at openssh.com,aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc > debug2: MACs ctos: umac-64-etm at openssh.com,umac-128-etm at openssh.com, > hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com,hmac-sha1- > etm at openssh.com,umac-64 at openssh.com,umac-128 at openssh.com > ,hmac-sha2-256,hmac-sha2-512,hmac-sha1 > debug2: MACs stoc: umac-64-etm at openssh.com,umac-128-etm at openssh.com, > hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com,hmac-sha1- > etm at openssh.com,umac-64 at openssh.com,umac-128 at openssh.com > ,hmac-sha2-256,hmac-sha2-512,hmac-sha1 > debug2: compression ctos: none,zlib at openssh.com,zlib > debug2: compression stoc: none,zlib at openssh.com,zlib > debug2: languages ctos: > debug2: languages stoc: > debug2: first_kex_follows 0 > debug2: reserved 0 > debug2: peer server KEXINIT proposal > debug2: KEX algorithms: curve25519-sha256 at libssh.org, > ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521, > diffie-hellman-group-exchange-sha256,diffie-hellman-group- > exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 > debug2: host key algorithms: ssh-rsa,ssh-dss,ecdsa-sha2- > nistp256,ssh-ed25519 > debug2: ciphers ctos: aes128-ctr,aes192-ctr,aes256- > ctr,arcfour256,arcfour128,aes128-gcm at openssh.com,aes256-gcm at openssh.com, > chacha20-poly1305 at openssh.com,aes128-cbc,3des- > cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour, > rijndael-cbc at lysator.liu.se > debug2: ciphers stoc: aes128-ctr,aes192-ctr,aes256- > ctr,arcfour256,arcfour128,aes128-gcm at openssh.com,aes256-gcm at openssh.com, > chacha20-poly1305 at openssh.com,aes128-cbc,3des- > cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour, > rijndael-cbc at lysator.liu.se > debug2: MACs ctos: hmac-md5-etm at openssh.com,hmac-sha1-etm at openssh.com, > umac-64-etm at openssh.com,umac-128-etm at openssh.com,hmac-sha2-256-etm@ > openssh.com,hmac-sha2-512-etm at openssh.com,hmac-ripemd160-etm at openssh.com, > hmac-sha1-96-etm at openssh.com,hmac-md5-96-etm at openssh.com,hmac-md5,hmac- > sha1,umac-64 at openssh.com,umac-128 at openssh.com,hmac-sha2-256, > hmac-sha2-512,hmac-ripemd160,hmac-ripemd160 at openssh.com, > hmac-sha1-96,hmac-md5-96 > debug2: MACs stoc: hmac-md5-etm at openssh.com,hmac-sha1-etm at openssh.com, > umac-64-etm at openssh.com,umac-128-etm at openssh.com,hmac-sha2-256-etm@ > openssh.com,hmac-sha2-512-etm at openssh.com,hmac-ripemd160-etm at openssh.com, > hmac-sha1-96-etm at openssh.com,hmac-md5-96-etm at openssh.com,hmac-md5,hmac- > sha1,umac-64 at openssh.com,umac-128 at openssh.com,hmac-sha2-256, > hmac-sha2-512,hmac-ripemd160,hmac-ripemd160 at openssh.com, > hmac-sha1-96,hmac-md5-96 > debug2: compression ctos: none,zlib at openssh.com > debug2: compression stoc: none,zlib at openssh.com > debug2: languages ctos: > debug2: languages stoc: > debug2: first_kex_follows 0 > debug2: reserved 0 > debug1: kex: algorithm: curve25519-sha256 at libssh.org > debug1: kex: host key algorithm: ssh-rsa > debug1: kex: server->client cipher: chacha20-poly1305 at openssh.com MAC: > compression: none > debug1: kex: client->server cipher: chacha20-poly1305 at openssh.com MAC: > compression: none > debug3: send packet: type 30 > debug1: expecting SSH2_MSG_KEX_ECDH_REPLY > debug3: receive packet: type 31 > debug1: Server host key: ssh-rsa SHA256:UWb75G/ > DzMWOCH4KNR4As0lYcpI1POgD7TEX9iXYSLA > debug3: hostkeys_foreach: reading file "/flash/.home/root/.ssh/known_ > hosts" > debug3: hostkeys_foreach: reading file "/flash/.configs/ssh/ssh_ > known_hosts" > debug3: record_hostkey: found key type RSA in file > /flash/.configs/ssh/ssh_known_hosts:2 > debug3: load_hostkeys: loaded 1 keys from 192.168.1.1 > debug1: Host '192.168.1.1' is known and matches the RSA host key. > debug1: Found key in /flash/.configs/ssh/ssh_known_hosts:2 > debug3: send packet: type 21 > debug2: set_newkeys: mode 1 > debug1: rekey after 134217728 blocks > debug1: SSH2_MSG_NEWKEYS sent > debug1: expecting SSH2_MSG_NEWKEYS > debug3: receive packet: type 21 > debug2: set_newkeys: mode 0 > debug1: rekey after 134217728 blocks > debug1: SSH2_MSG_NEWKEYS received > debug2: key: /flash/.home/root/.ssh/identity ((nil)) > debug2: key: /flash/.home/root/.ssh/id_rsa ((nil)) > debug2: key: /flash/.home/root/.ssh/id_dsa ((nil)) > debug2: key: /flash/.home/root/.ssh/id_ecdsa ((nil)) > debug3: send packet: type 5 > debug3: receive packet: type 6 > debug2: service_accept: ssh-userauth > debug1: SSH2_MSG_SERVICE_ACCEPT received > debug3: send packet: type 50 > debug3: receive packet: type 51 > debug1: Authentications that can continue: publickey,password > debug3: start over, passed a different list publickey,password > 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: Trying private key: /flash/.home/root/.ssh/identity > debug3: no such identity: /flash/.home/root/.ssh/identity: No such file > or directory > debug1: Trying private key: /flash/.home/root/.ssh/id_rsa > debug3: no such identity: /flash/.home/root/.ssh/id_rsa: No such file or > directory > debug1: Trying private key: /flash/.home/root/.ssh/id_dsa > debug3: no such identity: /flash/.home/root/.ssh/id_dsa: No such file or > directory > debug1: Trying private key: /flash/.home/root/.ssh/id_ecdsa > debug3: no such identity: /flash/.home/root/.ssh/id_ecdsa: No such file > or directory > debug2: we did not send a packet, disable method > debug3: authmethod_lookup password > debug3: remaining preferred: ,password > debug3: authmethod_is_enabled password > debug1: Next authentication method: password > ============================================================ > ============================================================ > =================== > > > On 7 September 2016 at 16:53, Darren Tucker wrote: > >> On Wed, Sep 7, 2016 at 1:59 PM, Mahoda Ratnayaka >> wrote: >> > I'm having a problem when I add "HostKeyAlgorithms +ssh-dss" to the >> > ssh_config file the host key will always negotiate to a wrong one. In my >> > case it will negotiate to "ecdsa-sha2-nistp256". The client was already >> > configured with the servers rsa public key, before the change I added to >> > the ssh_config file I could see from the debug that server and client >> will >> > negotiate to use ssh-rsa as expected. After change unfortunately the >> client >> > and server will negotiate to use ecdsa-sha2-nistp256, then later will >> > complain "REMOTE HOST IDENTIFICATION HAS CHANGED" and fail. I got around >> > this by adding the ecdsa public key to the know hosts. >> >> What version of OpenSSH is this? Can you post debug output (ssh -vvv) >> with and without the +ssh-dss option? >> >> -- >> Darren Tucker (dtucker at zip.com.au) >> GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA >> (new) >> Good judgement comes with experience. Unfortunately, the experience >> usually comes from bad judgement. >> > > From lists at nerdbynature.de Thu Sep 15 05:05:40 2016 From: lists at nerdbynature.de (Christian Kujau) Date: Wed, 14 Sep 2016 12:05:40 -0700 (PDT) Subject: com.jcraft.jsch.JSchException: Auth fail Message-ID: Hi, I've come across some messages from sshd (OpenSSH 6.7) in my auth.log that I hadn't noticed before: sshd[32008]: error: Received disconnect from x.x.x.x: 3: \ com.jcraft.jsch.JSchException: Auth fail [preauth] I was kinda puzzled why sshd would emit some JCraft[0] messages and the best explanation I found was this Serverfault[1] answer, quoting a snippet from packet.c:1965 and adding: > It looks like openssh server passes through the last message from the > client in its "Received disconnect" error message, so it appears that > this is a zombie login attempt from a botnet that is authored in Java. So, while this explains the log message, I'm wondering if there are some security implications in "passing messages from the client through the server and into the auth.log", i.e. could this be exploited somehow or is the function handling these strings in packet.c "strong" enough not to pass through or interpret malign strings? IOW, has this particular function been audited yet? Thanks, Christian. [0] http://www.jcraft.com/jsch/ [1] https://serverfault.com/questions/650303/auth-log-indicates-error-with-jschexception/661616#661616 -- BOFH excuse #318: Your EMAIL is now being delivered by the USPS. From djm at mindrot.org Thu Sep 15 06:23:44 2016 From: djm at mindrot.org (Damien Miller) Date: Thu, 15 Sep 2016 06:23:44 +1000 (AEST) Subject: com.jcraft.jsch.JSchException: Auth fail In-Reply-To: References: Message-ID: On Wed, 14 Sep 2016, Christian Kujau wrote: > Hi, > > I've come across some messages from sshd (OpenSSH 6.7) in my auth.log that > I hadn't noticed before: > > sshd[32008]: error: Received disconnect from x.x.x.x: 3: \ > com.jcraft.jsch.JSchException: Auth fail [preauth] > > I was kinda puzzled why sshd would emit some JCraft[0] messages and the > best explanation I found was this Serverfault[1] answer, quoting a snippet > from packet.c:1965 and adding: It's logging the reason the client gave for disconnecting. > > It looks like openssh server passes through the last message from the > > client in its "Received disconnect" error message, so it appears that > > this is a zombie login attempt from a botnet that is authored in Java. > > So, while this explains the log message, I'm wondering if there are some > security implications in "passing messages from the client through the > server and into the auth.log", i.e. could this be exploited somehow or is > the function handling these strings in packet.c "strong" enough not to > pass through or interpret malign strings? I'm not seeing a problem here. It's logging a string, and we escape any non-ASCII characters in log.c. If anything it's probably too strict (wrt escaping valid UTF-8 from logs on systems that support it). -d From djm at mindrot.org Thu Sep 15 06:51:52 2016 From: djm at mindrot.org (Damien Miller) Date: Thu, 15 Sep 2016 06:51:52 +1000 (AEST) Subject: sftp fails with error Received message too long 140013605 In-Reply-To: References: Message-ID: On Tue, 23 Aug 2016, Jeff Silverman wrote: > Hi. When I try to sftp to a client, which is an embedded Internet of > Thing (IoT) system, I get the following error: [snip] > I did some googling, and I found > http://askubuntu.com/questions/369830/sftp-connection-failed-strange-e > rror-messsage which says that I should look at > http://www.openssh.org/faq.html#2.9), which now 404s. I > looked through the wayback machine. On April 23rd 2016, > it did a 302 redirect which failed. I did find it at > https://web.archive.org/web/20160203202936/http://www.openssh.com/faq. > html faq.html> I followed the instructions and got some text, which I > assume is the source of my problems. > > Please bring the FAQ back - it is useful! I'd like to, but most of it was so rotted by the passage of time as to make the document useless. If someone wanted to collect a good set of FAQs that are current and relevant then I'll see about getting it committed to the website. -d PS. sorry for delay in responding From lists at nerdbynature.de Thu Sep 15 07:57:41 2016 From: lists at nerdbynature.de (Christian Kujau) Date: Wed, 14 Sep 2016 14:57:41 -0700 (PDT) Subject: com.jcraft.jsch.JSchException: Auth fail In-Reply-To: References: Message-ID: On Thu, 15 Sep 2016, Damien Miller wrote: > I'm not seeing a problem here. It's logging a string, and we escape any > non-ASCII characters in log.c. If anything it's probably too strict > (wrt escaping valid UTF-8 from logs on systems that support it). Great, thanks for confirming. That's the answer I was hoping for! :-) Thanks for the fast response. Christian. -- BOFH excuse #398: Data for intranet got routed through the extranet and landed on the internet. From Roman.Fiedler at ait.ac.at Thu Sep 15 19:10:58 2016 From: Roman.Fiedler at ait.ac.at (Fiedler Roman) Date: Thu, 15 Sep 2016 09:10:58 +0000 Subject: AW: com.jcraft.jsch.JSchException: Auth fail In-Reply-To: References: Message-ID: <2ECE9D9EEF1F524185270138AE23265954FF14CB@S0MSMAIL112.arc.local> > Von: openssh-unix-dev [mailto:openssh-unix-dev- > > On Thu, 15 Sep 2016, Damien Miller wrote: > > I'm not seeing a problem here. It's logging a string, and we escape any > > non-ASCII characters in log.c. If anything it's probably too strict > > (wrt escaping valid UTF-8 from logs on systems that support it). > > Great, thanks for confirming. That's the answer I was hoping for! :-) I did similar testing some years ago. The escaping is fine (was already back than). It also seems, that issues with limiting the line length were not/never affecting OpenSSH or are already fixed - I do not remember the products/versions tested any more. So line splitting with remote syslog when reaching the 1024 byte limit is also impossible. Only thing that remains seems to be, that the '[preauth]' tag is lost when limiting the line length. This might fool some IDS system mixing up pre/post auth disconnects for some kind of analysis (do not know if any system on the market might have such rules). The anomaly detection algorithms we are experimenting with could generate rules sensitive to that in the learning phase but I have not tested, if that would really happen. Sep 15 08:59:52 localhost sshd[2693]: error: Received disconnect from 127.0.0.1 port 47886:3: \\373\\336'\\273\\017\\254]s\\243\\306\\030\\321\\210y\\223b\\006\\031w\\363 \\251(\\343\\264t\\226\\016 \\306.\\324\\217\\a\\020np\\220\\323\\220\\024\\001V\\0378x^\\2733\\247\\006 \\312\\226\\177\\217~V>m\\330Qv\\322\\344\\274\\210\\341\\325\\001F\\313|/\\ 374)@\\234X|s*^|\\272\\252\\254\\342\\340\\244\\t\\016\\216{\\313&WR\\246\\3 11te^\\264\\356\\206#.a\\267\\375d\\245\\327\\r#H\\372\\177\\333+\\304\\243@ \\342\\001\\303:Y'|\\272v\\036 [prea Testclient (base64 -d |tar -xj): QlpoOTFBWSZTWcfIXoUAASJ/hMgQAEBr///TP2+fLv/v32AAAIAYQAJdrdzNy13YSoEp/qk2keU8 1PUxJoeoNDQwgAAxGmgBoIE0KMyhp6T0NRoAMJoDTQAAASRRR5T0niT00IHqeoANDQMmRoADQaBJ JTAm0o2p6E0eUAaAAADQANqD1Pr8vutQBFChIK6pCuqWIeyQDlSWPcGpfnuMQtChb6BGGj08Vkj8 tEZfiasqJEUT56meTUJs6qYTzUFV7MD+iDOfd0w2bMIxiHWcxwkczMyxg7KEtkBlw/q4sGlqDsbZ O+4PfRv5ZGlctVS1aSMQQYOYLYXxc6MsHm4YKIwyatOFhs6lmTMMhmnYHJpLtHRJIGVg56zQD9Iy F314yYARmCtucAVkAOiyarCHyyzqPZRGjNme54iYmZgiTOaBih2GQNRKYab5eK9XgumFO0iX9jXG ca/nylWaxXnM+L0yHvOHzlTtgsIM6VDWtbZ2JY8z7WNzZnUiv67QjqE29GIvHFEo4RgDBYL2jed8 P0R30p/Q2fZTBU3P63UEYq1hT66gjWWgvI0UjP/pmBiGnSZ1gU7oJyacUKZZNpBegGxFGApVaAti ujLfAxnmkQYYnpUIGQEioQEyTdU9KLYJhRlefgSUieKnnivwr6VSryEVkZqQzVoeJ1oK4QpQICEd PanVwLyha7asD5oFMBUCcSQ1hWoD/wQtw1WWJorwXYm2a6JS3uSxxK2olaN79nLIqUVPL9pngBhh 77BmYJUwVeottLlM5EKVMBBMx4dUIBDI+sOFqF65YDAsVjAycF5wmIcUgri3EBgjeighRTKiotjl exsIRzIZlBVOrCT1JAf4u5IpwoSGPkL0KA== Kind regards, Roman -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6320 bytes Desc: not available URL: From mjtrangoni at gmail.com Sun Sep 18 01:17:09 2016 From: mjtrangoni at gmail.com (Mario Trangoni) Date: Sat, 17 Sep 2016 17:17:09 +0200 Subject: openssh.spec fixes reported by 'rpmlint' Message-ID: Hi, I have fixed some time ago errors and warnings reported by rpmlint[0]. Are you interested in having this fixed? See: https://github.com/openssh/openssh-portable/pull/40 Best regards, Mario Trangoni [0] https://github.com/rpm-software-management/rpmlint From kurt at roeckx.be Mon Sep 19 04:22:31 2016 From: kurt at roeckx.be (Kurt Roeckx) Date: Sun, 18 Sep 2016 20:22:31 +0200 Subject: OpenSSL 1.1.0 support Message-ID: <20160918182230.tflkxar45vc6xmyf@roeckx.be> Hi, Attached is a patch that add supports for building against OpenSSL 1.1.0. I also made a github pull request for it at: https://github.com/openssh/openssh-portable/pull/48 It has the same regression tests failures as the master branch, and it has been tested with both 1.0.2 and 1.1.0. Some comments about the patch: - I've included an libcrypto-compat.c to add new functions from OpenSSL that are needed with 1.1.0 but didn't exist in 1.0.2. Since they are copied from the OpenSSL source code, I also added the OpenSSL license to it. If this is a problem we can probably agree to put that file under a different license. - I've replaced the 2 EVP_CipherInit() calls in cipher_init() with 1. OpenSSL now clears everything when you call EVP_CipherInit() again, so what was passed in the first but not in the second call, and what the function calls between them did, was lost. - The test suite was insitng that things like rsa->n where not NULL in sshkey/test_sshkey.c. sshkey_add_private was also doing something like that for the private parts. I don't agree that it should just have BN members that are not set to a real value. So I removed that code and the checks. I'm not even sure why this was done. But sshkey_add_private() ends up as a rather useless function now. - In sshkey_private_deserialize() there was a KEY_RSA_CERT case. I'm not sure what it's about and I guess the test suite also doesn't check it. But it seems that it only has the private key in that case and OpenSSL now seems to insist that an RSA needs to have the public key information too. PS: I didn't subscribe to the list. Kurt -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Make-it-build-using-OpenSSL-1.1.0.patch Type: text/x-diff Size: 76297 bytes Desc: not available URL: From emily.miller181 at gmail.com Tue Sep 20 17:21:10 2016 From: emily.miller181 at gmail.com (Emily Miller) Date: Tue, 20 Sep 2016 10:21:10 +0300 Subject: How ro support you Message-ID: Hi, I am currently representing a binary options company and I would like to know which is the minimum amount of money we need to donate to http://www.openssh.com in order to appear as a supporter/sponsor/friend on your site (name of the company and a link)? Waiting for your rwply. Best, Emily From dtucker at zip.com.au Tue Sep 20 18:51:36 2016 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 20 Sep 2016 18:51:36 +1000 Subject: How ro support you In-Reply-To: References: Message-ID: On Tue, Sep 20, 2016 at 5:21 PM, Emily Miller wrote: > I am currently representing a binary options company and I would like to > know which is the minimum amount of money we need to donate to > http://www.openssh.com in order to appear as a supporter/sponsor/friend on > your site (name of the company and a link)? Hi. We don't handle this kind of thing here, but the right place to ask is via http://www.openbsdfoundation.org/ -- Darren Tucker (dtucker at zip.com.au) GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new) Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From sam at hocevar.net Tue Sep 20 19:20:19 2016 From: sam at hocevar.net (Sam Hocevar) Date: Tue, 20 Sep 2016 11:20:19 +0200 Subject: [PATCH] Allow scp to copy files that start with a Windows drive name. Message-ID: <20160920092019.GA44000@hocevar.net> On Windows, ?scp C:/foo/bar remotehost:? will attempt to connect to a remote host ?C? and access file ?/foo/bar?. There is currently no syntax or flag to allow copying files that start with a drive name. This patch changes the behaviour (only on Cygwin) by considering that a single letter followed by a colon is a Windows drive name and thus an absolute path. This is also more consistent with the manual page that recommends to use absolute pathnames ?to avoid scp treating file names containing ?:? as host specifiers?. It is still possible to access files on a machine ?C? by using square brackets, e.g. ?scp [C]:/foo/bar remotehost:?. There are countless user reports indicating that this behaviour is desirable: - http://stackoverflow.com/q/8975798/111461 - http://serverfault.com/q/582048/73723 - http://superuser.com/q/291840/71253 - https://www.reddit.com/r/commandline/comments/371q5i - http://stackoverflow.com/q/21587036/111461 - http://askubuntu.com/q/354330/12301 - http://superuser.com/q/338075/71253 - https://ubuntuforums.org/archive/index.php/t-1131655.html - http://www.linuxquestions.org/questions/linux-newbie-8/transfer-files-from-linux-to-windows-pscp-4175530524/ --- misc.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/misc.c b/misc.c index 9421b4d..cd10287 100644 --- a/misc.c +++ b/misc.c @@ -435,6 +435,10 @@ colon(char *cp) if (*cp == ':') /* Leading colon is part of file name. */ return NULL; +#ifdef HAVE_CYGWIN + if (isalpha(*cp) && *(cp+1) == ':') /* Do not split at drive name. */ + return NULL; +#endif if (*cp == '[') flag = 1; -- 2.1.4 From scott_n at xypro.com Wed Sep 21 01:35:23 2016 From: scott_n at xypro.com (Scott Neugroschl) Date: Tue, 20 Sep 2016 15:35:23 +0000 Subject: [PATCH] Allow scp to copy files that start with a Windows drive name. In-Reply-To: <20160920092019.GA44000@hocevar.net> References: <20160920092019.GA44000@hocevar.net> Message-ID: Quoth Sam: On Windows, ?scp C:/foo/bar remotehost:? will attempt to connect to a remote host ?C? and access file ?/foo/bar?. There is currently no syntax or flag to allow copying files that start with a drive name. This patch changes the behaviour (only on Cygwin) by considering that a single letter followed by a colon is a Windows drive name and thus an absolute path. This is also more consistent with the manual page that recommends to use absolute pathnames ?to avoid scp treating file names containing ?:? as host specifiers?. ----------------------- Is this really necessary? Especially since it's a Cygwin specific patch, what is wrong with simply using /cygdrive/C/foo/bar? From cedric.blancher at gmail.com Wed Sep 21 02:28:49 2016 From: cedric.blancher at gmail.com (Cedric Blancher) Date: Tue, 20 Sep 2016 18:28:49 +0200 Subject: [PATCH] Allow scp to copy files that start with a Windows drive name. In-Reply-To: References: <20160920092019.GA44000@hocevar.net> Message-ID: It should work if you quote the ':' character with a '\' ... no need for the patch. Ced On 20 September 2016 at 17:35, Scott Neugroschl wrote: > Quoth Sam: > On Windows, ?scp C:/foo/bar remotehost:? will attempt to connect to a remote host ?C? > and access file ?/foo/bar?. There is currently no syntax or flag to allow copying files that start with a drive name. > > This patch changes the behaviour (only on Cygwin) by considering that a single letter followed by a colon is a Windows drive name and thus an absolute path. This is also more consistent with the manual page that recommends to use absolute pathnames ?to avoid scp treating file names containing ?:? as host specifiers?. > ----------------------- > > Is this really necessary? Especially since it's a Cygwin specific patch, what is wrong with simply using /cygdrive/C/foo/bar? > > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev -- Cedric Blancher [https://plus.google.com/u/0/+CedricBlancher/] Institute Pasteur From sam at hocevar.net Wed Sep 21 02:37:33 2016 From: sam at hocevar.net (Sam Hocevar) Date: Tue, 20 Sep 2016 18:37:33 +0200 Subject: [PATCH] Allow scp to copy files that start with a Windows drive name. In-Reply-To: References: <20160920092019.GA44000@hocevar.net> Message-ID: <20160920163733.GD3322@hocevar.net> On Tue, Sep 20, 2016, Cedric Blancher wrote: > It should work if you quote the ':' character with a '\' ... Nope, it doesn?t. There is nothing in colon() that handles such syntax. Escaping ?:? with a ?\? will just cause scp to try to connect to hostname ?c\? instead of ?c?. > no need for the patch. I humbly disagree. Cheers, -- Sam. From sam at hocevar.net Wed Sep 21 02:56:10 2016 From: sam at hocevar.net (Sam Hocevar) Date: Tue, 20 Sep 2016 18:56:10 +0200 Subject: [PATCH] Allow scp to copy files that start with a Windows drive name. In-Reply-To: References: <20160920092019.GA44000@hocevar.net> Message-ID: <20160920165610.GE3322@hocevar.net> On Tue, Sep 20, 2016, Scott Neugroschl wrote: > This patch changes the behaviour (only on Cygwin) by considering that a > single letter followed by a colon is a Windows drive name and thus an > absolute path. This is also more consistent with the manual page that > recommends to use absolute pathnames ?to avoid scp treating file names > containing ?:? as host specifiers?. > > ----------------------- > > Is this really necessary? Especially since it's a Cygwin specific patch, what is wrong with simply using /cygdrive/C/foo/bar? The patch uses HAVE_CYGWIN but is not Cygwin-specific, it also applies to MSYS2 which is a modern Cygwin fork and does not have /cygdrive/C/ (it uses /c/ directly instead). Also an interactive user may immediately correct the error by changing the path to a Unix-like one instead, but sometimes the arguments are not user-controlled, or scp is used together with non-Cygwin applications, or is embedded into a larger script that expects scp to behave as documented for absolute paths. From a least surprise perspective, I believe the correct place to fix this is indeed in scp. Finally, drives in /cygdrive/ (or in MSYS2 /c/) are not immediately accessible; a newly mounted network device or thumb drive will fail to appear unless the terminal is closed and a new one is opened. If the shell is a child of sshd.exe it would even require a restart of the SSH server. Regards, -- Sam. From john.delisle at ceridian.com Thu Sep 22 01:48:39 2016 From: john.delisle at ceridian.com (Delisle, John) Date: Wed, 21 Sep 2016 15:48:39 +0000 Subject: Where to look next? Message-ID: Hello, I'm looking for your insight about the log below. We have an SFTP server (IBM Sterling File Gateway) and we're connecting from an OpenSSH SFTP client but something fails during KEX. Complete client-side debug output is below, but I believe the relevant part is: debug1: kex: server->client cipher: aes192-cbc MAC: hmac-sha1 compression: none debug1: kex: client->server cipher: aes192-cbc MAC: hmac-sha1 compression: none debug3: send packet: type 30 debug1: sending SSH2_MSG_KEX_ECDH_INIT debug1: expecting SSH2_MSG_KEX_ECDH_REPLY debug3: receive packet: type 1 Received disconnect from 1.2.3.4 port 32:2: Failed to read binary packet data! Any suggestions about what's failing, and what the cause might be? We're trying to figure out where to go in our troubleshooting, and do not understand the meaning of this debug output. Thanks! Complete debug output (obfuscated to remove confidential data): [root at client ~]# sftp -vvvv -oport=32 SOMEUSER at some.server.we.have OpenSSH_7.2p2, OpenSSL 1.0.2h 3 May 2016 debug1: Reading configuration data /etc/ssh/ssh_config debug2: resolving "some.server.we.have" port 32 debug2: ssh_connect_direct: needpriv 0 debug1: Connecting to some.server.we.have [1.2.3.4] port 32. debug1: Connection established. debug1: permanently_set_uid: 0/0 debug1: identity file /root/.ssh/id_rsa type 1 debug1: key_load_public: No such file or directory debug1: identity file /root/.ssh/id_rsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /root/.ssh/id_dsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /root/.ssh/id_dsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /root/.ssh/id_ecdsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /root/.ssh/id_ecdsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /root/.ssh/id_ed25519 type -1 debug1: key_load_public: No such file or directory debug1: identity file /root/.ssh/id_ed25519-cert type -1 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_7.2 debug1: Remote protocol version 2.0, remote software version Welcome To Ceridian debug1: no match: Welcome To Ceridian debug2: fd 3 setting O_NONBLOCK debug1: Authenticating to some.server.we.have:32 as 'SOMEUSER' debug3: put_host_port: [some.server.we.have]:32 debug3: hostkeys_foreach: reading file "/root/.ssh/known_hosts" debug3: send packet: type 20 debug1: SSH2_MSG_KEXINIT sent debug3: receive packet: type 20 debug1: SSH2_MSG_KEXINIT received debug2: local client KEXINIT proposal debug2: KEX algorithms: curve25519-sha256 at libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,ext-info-c debug2: host key algorithms: ecdsa-sha2-nistp256-cert-v01 at openssh.com,ecdsa-sha2-nistp384-cert-v01 at openssh.com,ecdsa-sha2-nistp521-cert-v01 at openssh.com,ssh-ed25519-cert-v01 at openssh.com,ssh-rsa-cert-v01 at openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa debug2: ciphers ctos: chacha20-poly1305 at openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm at openssh.com,aes256-gcm at openssh.com,aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc debug2: ciphers stoc: chacha20-poly1305 at openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm at openssh.com,aes256-gcm at openssh.com,aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc debug2: MACs ctos: umac-64-etm at openssh.com,umac-128-etm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-64 at openssh.com,umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1 debug2: MACs stoc: umac-64-etm at openssh.com,umac-128-etm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-64 at openssh.com,umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1 debug2: compression ctos: none,zlib at openssh.com,zlib debug2: compression stoc: none,zlib at openssh.com,zlib debug2: languages ctos: debug2: languages stoc: debug2: first_kex_follows 0 debug2: reserved 0 debug2: peer server KEXINIT proposal debug2: KEX algorithms: diffie-hellman-group1-sha1,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1,diffie-hellman-group-exchange-sha256,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521 debug2: host key algorithms: ssh-rsa debug2: ciphers ctos: aes256-cbc,aes192-cbc debug2: ciphers stoc: aes256-cbc,aes192-cbc debug2: MACs ctos: hmac-sha1 debug2: MACs stoc: hmac-sha1 debug2: compression ctos: none debug2: compression stoc: none debug2: languages ctos: debug2: languages stoc: debug2: first_kex_follows 0 debug2: reserved 0 debug1: kex: algorithm: ecdh-sha2-nistp256 debug1: kex: host key algorithm: ssh-rsa debug1: kex: server->client cipher: aes192-cbc MAC: hmac-sha1 compression: none debug1: kex: client->server cipher: aes192-cbc MAC: hmac-sha1 compression: none debug3: send packet: type 30 debug1: sending SSH2_MSG_KEX_ECDH_INIT debug1: expecting SSH2_MSG_KEX_ECDH_REPLY debug3: receive packet: type 1 Received disconnect from 1.2.3.4 port 32:2: Failed to read binary packet data! Disconnected from 1.2.3.4 port 32 Couldn't read packet: Connection reset by peer John Delisle | Solution Architecture | Ceridian HCM | w: 204.975.5909 / 204.414.1285 |c: 204.294.5529 Ceridian. Makes Work Life Better(tm) From djm at mindrot.org Thu Sep 22 02:02:52 2016 From: djm at mindrot.org (Damien Miller) Date: Thu, 22 Sep 2016 02:02:52 +1000 (AEST) Subject: Where to look next? In-Reply-To: References: Message-ID: On Wed, 21 Sep 2016, Delisle, John wrote: > Hello, > > I'm looking for your insight about the log below. We have an SFTP > server (IBM Sterling File Gateway) and we're connecting from an > OpenSSH SFTP client but something fails during KEX. > > Complete client-side debug output is below, but I believe the relevant > part is: > > debug1: kex: server->client cipher: aes192-cbc MAC: hmac-sha1 compression: none > debug1: kex: client->server cipher: aes192-cbc MAC: hmac-sha1 compression: none > debug3: send packet: type 30 > debug1: sending SSH2_MSG_KEX_ECDH_INIT > debug1: expecting SSH2_MSG_KEX_ECDH_REPLY > debug3: receive packet: type 1 > Received disconnect from 1.2.3.4 port 32:2: Failed to read binary packet data! > > Any suggestions about what's failing, and what the cause might be? > We're trying to figure out where to go in our troubleshooting, and do > not understand the meaning of this debug output. It's failing during key exchange (KEX). You could try explicitly selecting a different key exchange method e.g. sftp -oKEXAlgorithms=diffie-hellman-group14-sha1 ... If that works then it's highly likely that the IBM server has implemented the ecdh-sha2-nistp256 method incorrectly. -d From john.delisle at ceridian.com Thu Sep 22 02:28:21 2016 From: john.delisle at ceridian.com (Delisle, John) Date: Wed, 21 Sep 2016 16:28:21 +0000 Subject: Where to look next? In-Reply-To: References: Message-ID: Thanks for your suggestion! It seems to have gone a little further this time, but isn't accepting the key and is failing back on password-based auth. We're double-checking that the public key was correctly configured with the account, and also trying a DSA key to see if it behaves differently. Is there anything you'd suggest we look at or try at this point, and thank you very much for your input. [root at client ~]# sftp -vvv -oKEXAlgorithms=diffie-hellman-group14-sha1 -oport=32 SOMEUSER at IBM.SFG.SFTP.server OpenSSH_7.2p2, OpenSSL 1.0.2h 3 May 2016 debug1: Reading configuration data /etc/ssh/ssh_config debug2: resolving "IBM.SFG.SFTP.server" port 32 debug2: ssh_connect_direct: needpriv 0 debug1: Connecting to IBM.SFG.SFTP.server [1.2.3.4] port 32. debug1: Connection established. debug1: permanently_set_uid: 0/0 debug1: identity file /root/.ssh/id_rsa type 1 debug1: key_load_public: No such file or directory debug1: identity file /root/.ssh/id_rsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /root/.ssh/id_dsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /root/.ssh/id_dsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /root/.ssh/id_ecdsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /root/.ssh/id_ecdsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /root/.ssh/id_ed25519 type -1 debug1: key_load_public: No such file or directory debug1: identity file /root/.ssh/id_ed25519-cert type -1 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_7.2 debug1: Remote protocol version 2.0, remote software version Welcome To Ceridian debug1: no match: Welcome To Ceridian debug2: fd 3 setting O_NONBLOCK debug1: Authenticating to IBM.SFG.SFTP.server:32 as 'SOMEUSER' debug3: put_host_port: [IBM.SFG.SFTP.server]:32 debug3: hostkeys_foreach: reading file "/root/.ssh/known_hosts" debug3: record_hostkey: found key type RSA in file /root/.ssh/known_hosts:57 debug3: load_hostkeys: loaded 1 keys from [IBM.SFG.SFTP.server]:32 debug3: order_hostkeyalgs: prefer hostkeyalgs: ssh-rsa-cert-v01 at openssh.com,rsa-sha2-512,rsa-sha2-256,ssh-rsa debug3: send packet: type 20 debug1: SSH2_MSG_KEXINIT sent debug3: receive packet: type 20 debug1: SSH2_MSG_KEXINIT received debug2: local client KEXINIT proposal debug2: KEX algorithms: diffie-hellman-group14-sha1,ext-info-c debug2: host key algorithms: ssh-rsa-cert-v01 at openssh.com,rsa-sha2-512,rsa-sha2-256,ssh-rsa,ecdsa-sha2-nistp256-cert-v01 at openssh.com,ecdsa-sha2-nistp384-cert-v01 at openssh.com,ecdsa-sha2-nistp521-cert-v01 at openssh.com,ssh-ed25519-cert-v01 at openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519 debug2: ciphers ctos: chacha20-poly1305 at openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm at openssh.com,aes256-gcm at openssh.com,aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc debug2: ciphers stoc: chacha20-poly1305 at openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm at openssh.com,aes256-gcm at openssh.com,aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc debug2: MACs ctos: umac-64-etm at openssh.com,umac-128-etm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-64 at openssh.com,umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1 debug2: MACs stoc: umac-64-etm at openssh.com,umac-128-etm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-64 at openssh.com,umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1 debug2: compression ctos: none,zlib at openssh.com,zlib debug2: compression stoc: none,zlib at openssh.com,zlib debug2: languages ctos: debug2: languages stoc: debug2: first_kex_follows 0 debug2: reserved 0 debug2: peer server KEXINIT proposal debug2: KEX algorithms: diffie-hellman-group1-sha1,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1,diffie-hellman-group-exchange-sha256,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521 debug2: host key algorithms: ssh-rsa debug2: ciphers ctos: aes256-cbc,aes192-cbc debug2: ciphers stoc: aes256-cbc,aes192-cbc debug2: MACs ctos: hmac-sha1 debug2: MACs stoc: hmac-sha1 debug2: compression ctos: none debug2: compression stoc: none debug2: languages ctos: debug2: languages stoc: debug2: first_kex_follows 0 debug2: reserved 0 debug1: kex: algorithm: diffie-hellman-group14-sha1 debug1: kex: host key algorithm: ssh-rsa debug1: kex: server->client cipher: aes192-cbc MAC: hmac-sha1 compression: none debug1: kex: client->server cipher: aes192-cbc MAC: hmac-sha1 compression: none debug1: sending SSH2_MSG_KEXDH_INIT debug2: bits set: 1015/2048 debug3: send packet: type 30 debug1: expecting SSH2_MSG_KEXDH_REPLY debug3: receive packet: type 31 debug1: Server host key: ssh-rsa SHA256:0oLfkrEjIEDItjZDXCt+5EJuVSLzjNuO0apIZtrFnXA debug3: put_host_port: [1.2.3.4]:32 debug3: put_host_port: [IBM.SFG.SFTP.server]:32 debug3: hostkeys_foreach: reading file "/root/.ssh/known_hosts" debug3: record_hostkey: found key type RSA in file /root/.ssh/known_hosts:57 debug3: load_hostkeys: loaded 1 keys from [IBM.SFG.SFTP.server]:32 debug3: hostkeys_foreach: reading file "/root/.ssh/known_hosts" debug3: record_hostkey: found key type RSA in file /root/.ssh/known_hosts:57 debug3: load_hostkeys: loaded 1 keys from [1.2.3.4]:32 debug1: Host '[IBM.SFG.SFTP.server]:32' is known and matches the RSA host key. debug1: Found key in /root/.ssh/known_hosts:57 debug2: bits set: 1022/2048 debug3: send packet: type 21 debug2: set_newkeys: mode 1 debug1: rekey after 4294967296 blocks debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug3: receive packet: type 21 debug2: set_newkeys: mode 0 debug1: rekey after 4294967296 blocks debug1: SSH2_MSG_NEWKEYS received debug2: key: /root/.ssh/id_rsa (0x5590b459ff30) debug2: key: /root/.ssh/id_dsa ((nil)) debug2: key: /root/.ssh/id_ecdsa ((nil)) debug2: key: /root/.ssh/id_ed25519 ((nil)) debug3: send packet: type 5 debug3: receive packet: type 6 debug2: service_accept: ssh-userauth debug1: SSH2_MSG_SERVICE_ACCEPT received debug3: send packet: type 50 debug3: receive packet: type 53 debug3: input_userauth_banner Thank You debug3: receive packet: type 51 debug1: Authentications that can continue: keyboard-interactive,publickey,password debug3: start over, passed a different list keyboard-interactive,publickey,password 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: /root/.ssh/id_rsa debug3: send_pubkey_test debug3: send packet: type 50 debug2: we sent a publickey packet, wait for reply debug3: receive packet: type 51 debug1: Authentications that can continue: keyboard-interactive,publickey,password debug1: Trying private key: /root/.ssh/id_dsa debug3: no such identity: /root/.ssh/id_dsa: No such file or directory debug1: Trying private key: /root/.ssh/id_ecdsa debug3: no such identity: /root/.ssh/id_ecdsa: No such file or directory debug1: Trying private key: /root/.ssh/id_ed25519 debug3: no such identity: /root/.ssh/id_ed25519: No such file or directory 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 debug3: send packet: type 50 debug2: we sent a keyboard-interactive packet, wait for reply debug3: receive packet: type 51 debug1: Authentications that can continue: keyboard-interactive,publickey,password 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 SOMEUSER at IBM.SFG.SFTP.server's password: debug3: send packet: type 50 debug2: we sent a password packet, wait for reply debug3: receive packet: type 2 debug3: Received SSH2_MSG_IGNORE debug3: receive packet: type 51 debug1: Authentications that can continue: keyboard-interactive,publickey,password Permission denied, please try again. SOMEUSER at IBM.SFG.SFTP.server's password: debug3: send packet: type 50 debug2: we sent a password packet, wait for reply debug3: receive packet: type 51 debug1: Authentications that can continue: keyboard-interactive,publickey,password Permission denied, please try again. SOMEUSER at IBM.SFG.SFTP.server's password: debug3: send packet: type 50 debug2: we sent a password packet, wait for reply debug3: receive packet: type 1 Received disconnect from 1.2.3.4 port 32:11: Too many bad authentication attempts! debug1: Authentication succeeded (password). Authenticated to IBM.SFG.SFTP.server ([1.2.3.4]:32). debug2: fd 4 setting O_NONBLOCK debug3: fd 5 is O_NONBLOCK debug1: channel 0: new [client-session] debug3: ssh_session2_open: channel_new: 0 debug2: channel 0: send open debug3: send packet: type 90 debug1: Entering interactive session. debug1: pledge: network debug3: send packet: type 1 debug1: channel 0: free: client-session, nchannels 1 debug3: channel 0: status: The following connections are open: #0 client-session (t3 r-1 i0/0 o0/0 fd 4/5 cc -1) debug1: fd 0 clearing O_NONBLOCK debug3: fd 1 is not O_NONBLOCK Connection to IBM.SFG.SFTP.server closed by remote host. Transferred: sent 2480, received 1744 bytes, in 0.0 seconds Bytes per second: sent 6393284.5, received 4495922.7 debug1: Exit status -1 Couldn't read packet: Connection reset by peer -----Original Message----- From: Damien Miller [mailto:djm at mindrot.org] Sent: Wednesday, September 21, 2016 11:03 AM To: Delisle, John Cc: openssh-unix-dev at mindrot.org; Babcock, Peter ; Olbruck, Eric Subject: Re: Where to look next? On Wed, 21 Sep 2016, Delisle, John wrote: > Hello, > > I'm looking for your insight about the log below. We have an SFTP > server (IBM Sterling File Gateway) and we're connecting from an > OpenSSH SFTP client but something fails during KEX. > > Complete client-side debug output is below, but I believe the relevant > part is: > > debug1: kex: server->client cipher: aes192-cbc MAC: hmac-sha1 > compression: none > debug1: kex: client->server cipher: aes192-cbc MAC: hmac-sha1 > compression: none > debug3: send packet: type 30 > debug1: sending SSH2_MSG_KEX_ECDH_INIT > debug1: expecting SSH2_MSG_KEX_ECDH_REPLY > debug3: receive packet: type 1 > Received disconnect from 1.2.3.4 port 32:2: Failed to read binary packet data! > > Any suggestions about what's failing, and what the cause might be? > We're trying to figure out where to go in our troubleshooting, and do > not understand the meaning of this debug output. It's failing during key exchange (KEX). You could try explicitly selecting a different key exchange method e.g. sftp -oKEXAlgorithms=diffie-hellman-group14-sha1 ... If that works then it's highly likely that the IBM server has implemented the ecdh-sha2-nistp256 method incorrectly. -d From nkadel at gmail.com Thu Sep 22 09:40:44 2016 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Wed, 21 Sep 2016 19:40:44 -0400 Subject: Where to look next? In-Reply-To: References: Message-ID: On Wed, Sep 21, 2016 at 12:28 PM, Delisle, John wrote: > Thanks for your suggestion! It seems to have gone a little further this time, but isn't accepting the key and is failing back on password-based auth. > > We're double-checking that the public key was correctly configured with the account, and also trying a DSA key to see if it behaves differently. > > Is there anything you'd suggest we look at or try at this point, and thank you very much for your input. Ask the people on the *server* side to share their logs? > [root at client ~]# sftp -vvv -oKEXAlgorithms=diffie-hellman-group14-sha1 -oport=32 SOMEUSER at IBM.SFG.SFTP.server > OpenSSH_7.2p2, OpenSSL 1.0.2h 3 May 2016 > debug1: Reading configuration data /etc/ssh/ssh_config > debug2: resolving "IBM.SFG.SFTP.server" port 32 > debug2: ssh_connect_direct: needpriv 0 > debug1: Connecting to IBM.SFG.SFTP.server [1.2.3.4] port 32. > debug1: Connection established. > debug1: permanently_set_uid: 0/0 > debug1: identity file /root/.ssh/id_rsa type 1 > debug1: key_load_public: No such file or directory > debug1: identity file /root/.ssh/id_rsa-cert type -1 > debug1: key_load_public: No such file or directory > debug1: identity file /root/.ssh/id_dsa type -1 > debug1: key_load_public: No such file or directory > debug1: identity file /root/.ssh/id_dsa-cert type -1 > debug1: key_load_public: No such file or directory > debug1: identity file /root/.ssh/id_ecdsa type -1 > debug1: key_load_public: No such file or directory > debug1: identity file /root/.ssh/id_ecdsa-cert type -1 > debug1: key_load_public: No such file or directory > debug1: identity file /root/.ssh/id_ed25519 type -1 > debug1: key_load_public: No such file or directory > debug1: identity file /root/.ssh/id_ed25519-cert type -1 > debug1: Enabling compatibility mode for protocol 2.0 > debug1: Local version string SSH-2.0-OpenSSH_7.2 > debug1: Remote protocol version 2.0, remote software version Welcome To Ceridian > debug1: no match: Welcome To Ceridian > debug2: fd 3 setting O_NONBLOCK > debug1: Authenticating to IBM.SFG.SFTP.server:32 as 'SOMEUSER' > debug3: put_host_port: [IBM.SFG.SFTP.server]:32 > debug3: hostkeys_foreach: reading file "/root/.ssh/known_hosts" > debug3: record_hostkey: found key type RSA in file /root/.ssh/known_hosts:57 > debug3: load_hostkeys: loaded 1 keys from [IBM.SFG.SFTP.server]:32 > debug3: order_hostkeyalgs: prefer hostkeyalgs: ssh-rsa-cert-v01 at openssh.com,rsa-sha2-512,rsa-sha2-256,ssh-rsa > debug3: send packet: type 20 > debug1: SSH2_MSG_KEXINIT sent > debug3: receive packet: type 20 > debug1: SSH2_MSG_KEXINIT received > debug2: local client KEXINIT proposal > debug2: KEX algorithms: diffie-hellman-group14-sha1,ext-info-c > debug2: host key algorithms: ssh-rsa-cert-v01 at openssh.com,rsa-sha2-512,rsa-sha2-256,ssh-rsa,ecdsa-sha2-nistp256-cert-v01 at openssh.com,ecdsa-sha2-nistp384-cert-v01 at openssh.com,ecdsa-sha2-nistp521-cert-v01 at openssh.com,ssh-ed25519-cert-v01 at openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519 > debug2: ciphers ctos: chacha20-poly1305 at openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm at openssh.com,aes256-gcm at openssh.com,aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc > debug2: ciphers stoc: chacha20-poly1305 at openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm at openssh.com,aes256-gcm at openssh.com,aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc > debug2: MACs ctos: umac-64-etm at openssh.com,umac-128-etm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-64 at openssh.com,umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1 > debug2: MACs stoc: umac-64-etm at openssh.com,umac-128-etm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-64 at openssh.com,umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1 > debug2: compression ctos: none,zlib at openssh.com,zlib > debug2: compression stoc: none,zlib at openssh.com,zlib > debug2: languages ctos: > debug2: languages stoc: > debug2: first_kex_follows 0 > debug2: reserved 0 > debug2: peer server KEXINIT proposal > debug2: KEX algorithms: diffie-hellman-group1-sha1,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1,diffie-hellman-group-exchange-sha256,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521 > debug2: host key algorithms: ssh-rsa > debug2: ciphers ctos: aes256-cbc,aes192-cbc > debug2: ciphers stoc: aes256-cbc,aes192-cbc > debug2: MACs ctos: hmac-sha1 > debug2: MACs stoc: hmac-sha1 > debug2: compression ctos: none > debug2: compression stoc: none > debug2: languages ctos: > debug2: languages stoc: > debug2: first_kex_follows 0 > debug2: reserved 0 > debug1: kex: algorithm: diffie-hellman-group14-sha1 > debug1: kex: host key algorithm: ssh-rsa > debug1: kex: server->client cipher: aes192-cbc MAC: hmac-sha1 compression: none > debug1: kex: client->server cipher: aes192-cbc MAC: hmac-sha1 compression: none > debug1: sending SSH2_MSG_KEXDH_INIT > debug2: bits set: 1015/2048 > debug3: send packet: type 30 > debug1: expecting SSH2_MSG_KEXDH_REPLY > debug3: receive packet: type 31 > debug1: Server host key: ssh-rsa SHA256:0oLfkrEjIEDItjZDXCt+5EJuVSLzjNuO0apIZtrFnXA > debug3: put_host_port: [1.2.3.4]:32 > debug3: put_host_port: [IBM.SFG.SFTP.server]:32 > debug3: hostkeys_foreach: reading file "/root/.ssh/known_hosts" > debug3: record_hostkey: found key type RSA in file /root/.ssh/known_hosts:57 > debug3: load_hostkeys: loaded 1 keys from [IBM.SFG.SFTP.server]:32 > debug3: hostkeys_foreach: reading file "/root/.ssh/known_hosts" > debug3: record_hostkey: found key type RSA in file /root/.ssh/known_hosts:57 > debug3: load_hostkeys: loaded 1 keys from [1.2.3.4]:32 > debug1: Host '[IBM.SFG.SFTP.server]:32' is known and matches the RSA host key. > debug1: Found key in /root/.ssh/known_hosts:57 > debug2: bits set: 1022/2048 > debug3: send packet: type 21 > debug2: set_newkeys: mode 1 > debug1: rekey after 4294967296 blocks > debug1: SSH2_MSG_NEWKEYS sent > debug1: expecting SSH2_MSG_NEWKEYS > debug3: receive packet: type 21 > debug2: set_newkeys: mode 0 > debug1: rekey after 4294967296 blocks > debug1: SSH2_MSG_NEWKEYS received > debug2: key: /root/.ssh/id_rsa (0x5590b459ff30) > debug2: key: /root/.ssh/id_dsa ((nil)) > debug2: key: /root/.ssh/id_ecdsa ((nil)) > debug2: key: /root/.ssh/id_ed25519 ((nil)) > debug3: send packet: type 5 > debug3: receive packet: type 6 > debug2: service_accept: ssh-userauth > debug1: SSH2_MSG_SERVICE_ACCEPT received > debug3: send packet: type 50 > debug3: receive packet: type 53 > debug3: input_userauth_banner > Thank You > debug3: receive packet: type 51 > debug1: Authentications that can continue: keyboard-interactive,publickey,password > debug3: start over, passed a different list keyboard-interactive,publickey,password > 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: /root/.ssh/id_rsa > debug3: send_pubkey_test > debug3: send packet: type 50 > debug2: we sent a publickey packet, wait for reply > debug3: receive packet: type 51 > debug1: Authentications that can continue: keyboard-interactive,publickey,password > debug1: Trying private key: /root/.ssh/id_dsa > debug3: no such identity: /root/.ssh/id_dsa: No such file or directory > debug1: Trying private key: /root/.ssh/id_ecdsa > debug3: no such identity: /root/.ssh/id_ecdsa: No such file or directory > debug1: Trying private key: /root/.ssh/id_ed25519 > debug3: no such identity: /root/.ssh/id_ed25519: No such file or directory > 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 > debug3: send packet: type 50 > debug2: we sent a keyboard-interactive packet, wait for reply > debug3: receive packet: type 51 > debug1: Authentications that can continue: keyboard-interactive,publickey,password > 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 > SOMEUSER at IBM.SFG.SFTP.server's password: > debug3: send packet: type 50 > debug2: we sent a password packet, wait for reply > debug3: receive packet: type 2 > debug3: Received SSH2_MSG_IGNORE > debug3: receive packet: type 51 > debug1: Authentications that can continue: keyboard-interactive,publickey,password > Permission denied, please try again. > SOMEUSER at IBM.SFG.SFTP.server's password: > debug3: send packet: type 50 > debug2: we sent a password packet, wait for reply > debug3: receive packet: type 51 > debug1: Authentications that can continue: keyboard-interactive,publickey,password > Permission denied, please try again. > SOMEUSER at IBM.SFG.SFTP.server's password: > debug3: send packet: type 50 > debug2: we sent a password packet, wait for reply > debug3: receive packet: type 1 > Received disconnect from 1.2.3.4 port 32:11: Too many bad authentication attempts! > debug1: Authentication succeeded (password). > Authenticated to IBM.SFG.SFTP.server ([1.2.3.4]:32). > debug2: fd 4 setting O_NONBLOCK > debug3: fd 5 is O_NONBLOCK > debug1: channel 0: new [client-session] > debug3: ssh_session2_open: channel_new: 0 > debug2: channel 0: send open > debug3: send packet: type 90 > debug1: Entering interactive session. > debug1: pledge: network > debug3: send packet: type 1 > debug1: channel 0: free: client-session, nchannels 1 > debug3: channel 0: status: The following connections are open: > #0 client-session (t3 r-1 i0/0 o0/0 fd 4/5 cc -1) > > debug1: fd 0 clearing O_NONBLOCK > debug3: fd 1 is not O_NONBLOCK > Connection to IBM.SFG.SFTP.server closed by remote host. > Transferred: sent 2480, received 1744 bytes, in 0.0 seconds > Bytes per second: sent 6393284.5, received 4495922.7 > debug1: Exit status -1 > Couldn't read packet: Connection reset by peer > > > > > -----Original Message----- > From: Damien Miller [mailto:djm at mindrot.org] > Sent: Wednesday, September 21, 2016 11:03 AM > To: Delisle, John > Cc: openssh-unix-dev at mindrot.org; Babcock, Peter ; Olbruck, Eric > Subject: Re: Where to look next? > > On Wed, 21 Sep 2016, Delisle, John wrote: > >> Hello, >> >> I'm looking for your insight about the log below. We have an SFTP >> server (IBM Sterling File Gateway) and we're connecting from an >> OpenSSH SFTP client but something fails during KEX. >> >> Complete client-side debug output is below, but I believe the relevant >> part is: >> >> debug1: kex: server->client cipher: aes192-cbc MAC: hmac-sha1 >> compression: none >> debug1: kex: client->server cipher: aes192-cbc MAC: hmac-sha1 >> compression: none >> debug3: send packet: type 30 >> debug1: sending SSH2_MSG_KEX_ECDH_INIT >> debug1: expecting SSH2_MSG_KEX_ECDH_REPLY >> debug3: receive packet: type 1 >> Received disconnect from 1.2.3.4 port 32:2: Failed to read binary packet data! >> >> Any suggestions about what's failing, and what the cause might be? >> We're trying to figure out where to go in our troubleshooting, and do >> not understand the meaning of this debug output. > > It's failing during key exchange (KEX). You could try explicitly selecting a different key exchange method e.g. > > sftp -oKEXAlgorithms=diffie-hellman-group14-sha1 ... > > If that works then it's highly likely that the IBM server has implemented the ecdh-sha2-nistp256 method incorrectly. > > -d > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From dtucker at zip.com.au Thu Sep 22 09:51:11 2016 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 22 Sep 2016 09:51:11 +1000 Subject: Where to look next? In-Reply-To: References: Message-ID: On Thu, Sep 22, 2016 at 2:28 AM, Delisle, John wrote: [...] > debug1: Remote protocol version 2.0, remote software version Welcome To Ceridian OpenSSH should probably log it better, but this banner is weird. According to RFC 4253 section 4.2 the format is: SSH-protoversion-softwareversion SP comments CR LF so this server is claiming that its software version is "Welcome" with a comment of "To Ceridian". [...] > debug3: receive packet: type 1 > Received disconnect from 1.2.3.4 port 32:11: Too many bad authentication attempts! The server sends a disconnect. > debug1: Authentication succeeded (password). > Authenticated to IBM.SFG.SFTP.server ([1.2.3.4]:32). The client thinks the session is authenticated, though. I think that's actually a bug in the OpenSSH client: ssh_userauth2() calls ssh_dispatch_run() with DISPATCH_BLOCK blocking on authctxt.success. It assumes that if it exits then it's authenticated. ssh_packet_read_poll_seqnr(), however, will return SSH_ERR_DISCONNECTED in that case, which will cause ssh_dispatch_run() to return. I don't think this is relevant to your problem, though. -- Darren Tucker (dtucker at zip.com.au) GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new) Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From dtucker at zip.com.au Thu Sep 22 09:58:24 2016 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 22 Sep 2016 09:58:24 +1000 Subject: Where to look next? In-Reply-To: References: Message-ID: <20160921235824.GA23354@gate.dtucker.net> On Thu, Sep 22, 2016 at 09:51:11AM +1000, Darren Tucker wrote: > The client thinks the session is authenticated, though. I think > that's actually a bug in the OpenSSH client: ssh_userauth2() calls > ssh_dispatch_run() with DISPATCH_BLOCK blocking on authctxt.success. > It assumes that if it exits then it's authenticated. > > ssh_packet_read_poll_seqnr(), however, will return > SSH_ERR_DISCONNECTED in that case, which will cause ssh_dispatch_run() > to return. This should handle this case. diff --git a/sshconnect2.c b/sshconnect2.c index fae8b0f..ae77243 100644 --- a/sshconnect2.c +++ b/sshconnect2.c @@ -404,6 +404,8 @@ ssh_userauth2(const char *local_user, const char *server_user, char *host, pubkey_cleanup(&authctxt); ssh_dispatch_range(ssh, SSH2_MSG_USERAUTH_MIN, SSH2_MSG_USERAUTH_MAX, NULL); + if (!authctxt.success) + fatal("Authentication failed."); debug("Authentication succeeded (%s).", authctxt.method->name); } -- Darren Tucker (dtucker at zip.com.au) GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new) Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From rogan at dawes.za.net Fri Sep 23 19:16:08 2016 From: rogan at dawes.za.net (Rogan Dawes) Date: Fri, 23 Sep 2016 09:16:08 +0000 Subject: SSH Enhancements - Delete StreamLocal forwards on disconnect, and bind to interface Message-ID: Hi folks, I'm using OpenSSH to set up a rendezvous for a number of OpenWRT devices. Central server has the following configuration in sshd_config: # This is to work around a bug only fixed in OpenSSH 7.3 (most likely) StreamLocalBindUnlink yes Match User sshvpn ChrootDirectory /var/sshvpn/ AllowTCPForwarding no AllowStreamLocalForwarding yes StreamLocalBindUnlink yes Clients connect to the server using the following invocation, via autossh: /usr/bin/ssh -o CheckHostIP=yes -o LogLevel=INFO -o ServerAliveCountMax=2 -o ServerAliveInterval=120 -o StrictHostKeyChecking=yes -o TCPKeepAlive=yes -o StreamLocalBindUnlink=yes -o ExitOnForwardFailure=no -o BatchMode=yes -nN -R /sshvpn/gateway-78a3510e3b38:127.0.0.1:22 sshvpn at myserver I can then connect to the device from my central server using the following: ssh -o ?StrictHostKeyChecking=no? -o Proxycommand=?socat UNIX:/var/sshvpn/sshvpn/gateway-78a3510e3b38 -? -D 1085 root at gateway-78a3510e3b38 and subsequently access the device itself or any other hosts it can reach. This works pretty well! There are a couple of small things that would make this perfect: 1. sshd should be configurable to delete the StreamLocal file when the client disconnects. Otherwise it can be tricky to figure out which clients have an active,usable connection. Most times, I just get "the other end has disconnected" because socat cannot open the domain socket. 2. The devices are intended to be deployed into a customer environment, and may have wifi or ethernet uplink as well as 3G. I want to keep the 3G link up and accessible in case the ethernet or wifi uplinks fail for whatever reason. It seems to me that one way to achieve this is to have multiple autossh sessions running, each bound to the IP address of the ethernet/wifi/3g interfaces. This will ensure that each autossh instance will be routed via that interface, rather than the defaul troute. While this is doable with a bit of scripting, the addresses can change as the interfaces go up and down, and it seems to me that this is something that could be reasonably implemented in OpenSSH itself. e.g. with a -B eth0 option (analogous to -b ). Any comments on these suggestions? Would patches to implement these be considered? Rogan From remi.paulmier at gmail.com Fri Sep 23 20:48:04 2016 From: remi.paulmier at gmail.com (Remi Paulmier) Date: Fri, 23 Sep 2016 10:48:04 +0000 Subject: possibility of a RemoteCommand option in the ssh config file Message-ID: Hi, About one year ago, someone (Simon Zack) asked about a RemoteCommand option. His question did not encounter a large amount of answers, maybe because Simon himself did not answer to a question from Darren Tucker about his use case ? However, I think I have a use case pretty close to Simon's one: Let's imagine a host named 'lxc.host.example.org', hosting many LXC containers named '.lxc.host.example.org'. With a RemoteCommand option, working pretty much the same as the ProxyCommand one, we could write something like: $ cat ~/.ssh/config Host host.lxc.example.org RequestTTY force Host *.host.lxc.example.org Hostname host.lxc.example.org RemoteCommand lxc-attach -n %h -- That way, we would be able to attach to containers, without the need to run sshd inside each container, by running: $ ssh mycontainer.host.lxc.example.org A bit of difference with the ProxyCommand behaviour, though: the %h macro should expand to the host that was requested on the cli; not the one specified with Hostname. I know I can specify the command on the cli, or even make an alias, but it would introduce an interface difference for the end-user between regular hosts and lxc containers. Any opinion ? Kind regards, r?mi From openssh at mzpqnxow.com Sun Sep 25 07:04:11 2016 From: openssh at mzpqnxow.com (AG) Date: Sat, 24 Sep 2016 17:04:11 -0400 Subject: [PATCH] X11MaxDisplays for multi-factor X11 gateways Message-ID: Hello, Please accept this as my quarterly nag regarding the possibility of merging the patch submitted back in June to the mindrot Bugzilla @ https://bugzilla.mindrot.org/show_bug.cgi?id=2580 upstream. It has already been reviewed and cleaned up slightly by Jakub Jelen, and documentation has been added. To summarize, this removes the arbitrary limit in channels.c: channels.c:155:#define MAX_DISPLAYS 1000 It instead makes it an option in sshd_config, X11MaxDisplays, which keeps the defaults at 1000, in order to avoid any impact for users not needing to tune it. This feature allows a sysadmin to make an educated decision on what is required for their particular system, whether it is higher or lower than 1000. Additionally, style-wise, it takes a completely arbitrary number out of the source code. Admittedly, 1000 is plenty for the majority of cases- but it is still completely arbitrary. It might be too high for some cases (I hadn't thought about that) but it is certainly too low for my use case. The use case for the patch: systems that are using OpenSSH as a mulit-factor authenticated X11 gateway into a trusted network. Currently, the hardcoded value causes there to be an effective maximum of (1000-X11DisplayOffset) displays forwarded, assuming no other applications are binding the loopback TCP ports between 6000+X11DisplayOffset and 6000+MAX_DISPLAYS on the system. We aren't talking about a box that provides interactive shells here- this infrastructure is purely an X11 gateway providing a strong PAM stack- so it can handle well beyond 1000 displays (I hand compile it today with this patch) and I support well over 5000 users, who utilize multiple forwards simultaneously- so it's a must for my environment. The patch also "corrects" the logic a bit by changing the logic to try bind() across the range from (6000+X11DisplayOffset) through (6000+X11DisplayOffset+MAX_DISPLAYS[1]) as well as changing the integer 6000 (which is the minimum X11 display offset port, well known to technical users) from a magic number in the loop to a #define that is a bit more descriptive than the integer value alone in the source code, for readability. In any event, I'd appreciate an eyeball on this before the next OpenSSH release if someone has the time. The patch is not large, but it is not tiny. It is however VERY boilerplate. It seems to be one of the few _arbitrary_ magic numbers in the OpenSSH code and seems like it should be configurable- and for my own selfish reasons (use in my own infrastructure) I would love to see this merged sooner rather than later. It's been in use in a production environment for 3+ years, and could be a quick review and merge for someone will to take the time. Thanks folks, sorry for the nudge, I know everyone's busy. AG (No patch attached, please see patch @ https://bugzilla.mindrot.org/show_bug.cgi?id=2580) From gdg at zplane.com Tue Sep 27 06:55:08 2016 From: gdg at zplane.com (Glenn Golden) Date: Mon, 26 Sep 2016 14:55:08 -0600 Subject: Possible formatting bug in ssh-agent.1 man page Message-ID: <20160926205507.GA31052@huh.zplane.com> Version info: OpenSSH_7.3p1, OpenSSL 1.0.2i 22 Sep 2016, Arch linux The ssh-agent.1 man page seems to have an indentation oddity, at least, as formatted with recent Arch linux manpage toolset. Here's what appears in the formatted output just after the description of the the "-t" option: ---------- Begin formatted output ------------------------------------- -t life Set a default value for the maximum lifetime of identities added to the agent. The lifetime may be specified in seconds or in a time format specified in sshd_config(5). A lifetime specified for an identity with ssh-add(1) overrides this value. Without this option the default maximum lifetime is forever. If a command line is given, this is executed as a subprocess of the agent. When the command dies, so does the agent. The idea is that the agent is run in the user's local PC, lap . . . ------------ End formatted output ------------------------------------- Seems to me like all the paragraphs after the one immediately below "-t life" (starting with "If a command line..." and thereafter) are meant to be outdented to the main indentation level so that they do not appear be associated with the description of the -t option. From jjelen at redhat.com Tue Sep 27 17:19:50 2016 From: jjelen at redhat.com (Jakub Jelen) Date: Tue, 27 Sep 2016 09:19:50 +0200 Subject: Possible formatting bug in ssh-agent.1 man page In-Reply-To: <20160926205507.GA31052@huh.zplane.com> References: <20160926205507.GA31052@huh.zplane.com> Message-ID: <77250a68-8e27-b399-5e13-7a1e3912a3eb@redhat.com> On 09/26/2016 10:55 PM, Glenn Golden wrote: > Version info: OpenSSH_7.3p1, OpenSSL 1.0.2i 22 Sep 2016, Arch linux > > The ssh-agent.1 man page seems to have an indentation oddity, at least, as > formatted with recent Arch linux manpage toolset. Here's what appears in > the formatted output just after the description of the the "-t" option: > > ---------- Begin formatted output ------------------------------------- > -t life > Set a default value for the maximum lifetime of identities added > to the agent. The lifetime may be specified in seconds or in a > time format specified in sshd_config(5). A lifetime specified > for an identity with ssh-add(1) overrides this value. Without > this option the default maximum lifetime is forever. > > If a command line is given, this is executed as a subprocess of > the agent. When the command dies, so does the agent. > > The idea is that the agent is run in the user's local PC, lap > . > . > . > ------------ End formatted output ------------------------------------- > > Seems to me like all the paragraphs after the one immediately below "-t life" > (starting with "If a command line..." and thereafter) are meant to be outdented > to the main indentation level so that they do not appear be associated with the > description of the -t option. The Fedora gets it correctly, both from 7.3p1 tarball and from upstream git. Tested with man-db-2.7.5-3.fc24.x86_64 (not sure what other tools might involved in formatting). -- Jakub Jelen Associate Software Engineer Security Technologies Red Hat From schwarze at usta.de Wed Sep 28 02:52:52 2016 From: schwarze at usta.de (Ingo Schwarze) Date: Tue, 27 Sep 2016 18:52:52 +0200 Subject: Possible formatting bug in ssh-agent.1 man page In-Reply-To: <20160926205507.GA31052@huh.zplane.com> References: <20160926205507.GA31052@huh.zplane.com> Message-ID: <20160927165252.GA10764@athene.usta.de> Hi Glenn, Glenn Golden wrote on Mon, Sep 26, 2016 at 02:55:08PM -0600: > Version info: OpenSSH_7.3p1, OpenSSL 1.0.2i 22 Sep 2016, Arch linux > > The ssh-agent.1 man page seems to have an indentation oddity, at least, as > formatted with recent Arch linux manpage toolset. Here's what appears in > the formatted output just after the description of the the "-t" option: > > ---------- Begin formatted output ------------------------------------- > -t life > Set a default value for the maximum lifetime of identities added > to the agent. The lifetime may be specified in seconds or in a > time format specified in sshd_config(5). A lifetime specified > for an identity with ssh-add(1) overrides this value. Without > this option the default maximum lifetime is forever. > > If a command line is given, this is executed as a subprocess of > the agent. When the command dies, so does the agent. > > The idea is that the agent is run in the user's local PC, lap > . > . > . > ------------ End formatted output ------------------------------------- > > Seems to me like all the paragraphs after the one immediately > below "-t life" (starting with "If a command line..." and thereafter) > are meant to be outdented to the main indentation level so that they > do not appear be associated with the description of the -t option. To debug this, we have to decide whether the problem is in the manual page sources used (for example due to bogus patches), in the build system, in the man(1) command on Arch, or in the formatter (likely groff) on Arch. As a first step, can you provide the file that gets installed on Arch? You can probably find the name and path of that file with $ man -w ssh-agent More is likely required after that, but what is needed depends on the contents of that file. You should also say up front which man(1) implementation you are using, which roff formatter you are using, whether you have enabled any caching of preformatted manuals, whether you have any man.conf or manpath.config files in use, and what they contain. This is likely to be some simple user oder packager error; yet again, it could also be a yet unknown mdoc(7) or man(7) compat issue, which is why i'm interested. Yours, Ingo From gdg at zplane.com Wed Sep 28 03:30:39 2016 From: gdg at zplane.com (Glenn Golden) Date: Tue, 27 Sep 2016 11:30:39 -0600 Subject: Possible formatting bug in ssh-agent.1 man page In-Reply-To: <20160927165252.GA10764@athene.usta.de> References: <20160926205507.GA31052@huh.zplane.com> <20160927165252.GA10764@athene.usta.de> Message-ID: <20160927173039.GC747@huh.zplane.com> Hi Ingo, Inline below describes what I found, per your queries: Ingo Schwarze [2016-09-27 18:52:52 +0200]: > Hi Glenn, > > Glenn Golden wrote on Mon, Sep 26, 2016 at 02:55:08PM -0600: > > > Version info: OpenSSH_7.3p1, OpenSSL 1.0.2i 22 Sep 2016, Arch linux > > > > The ssh-agent.1 man page seems to have an indentation oddity, at least, as > > formatted with recent Arch linux manpage toolset. Here's what appears in > > the formatted output just after the description of the the "-t" option: > > > > ---------- Begin formatted output ------------------------------------- > > -t life > > Set a default value for the maximum lifetime of identities added > > to the agent. The lifetime may be specified in seconds or in a > > time format specified in sshd_config(5). A lifetime specified > > for an identity with ssh-add(1) overrides this value. Without > > this option the default maximum lifetime is forever. > > > > If a command line is given, this is executed as a subprocess of > > the agent. When the command dies, so does the agent. > > > > The idea is that the agent is run in the user's local PC, lap > > . > > . > > . > > ------------ End formatted output ------------------------------------- > > > > Seems to me like all the paragraphs after the one immediately > > below "-t life" (starting with "If a command line..." and thereafter) > > are meant to be outdented to the main indentation level so that they > > do not appear be associated with the description of the -t option. > > To debug this, we have to decide whether the problem is in the manual > page sources used (for example due to bogus patches), in the build > system, in the man(1) command on Arch, or in the formatter (likely > groff) on Arch. > > As a first step, can you provide the file that gets installed on > Arch? You can probably find the name and path of that file with > > $ man -w ssh-agent > > More is likely required after that, but what is needed depends on > the contents of that file. > The target file is /usr/share/man/man1/ssh-agent.1.gz. The first few lines are .TH SSH-AGENT 1 "November 15 2015 " "" .SH NAME \fBssh-agent\fP \- authentication agent .SH SYNOPSIS The md5sums are $ md5sum /usr/share/man/man1/ssh-agent.1.gz 30f21b3dc30d5c081dda5482c28bee40 /usr/share/man/man1/ssh-agent.1.gz $ zcat /usr/share/man/man1/ssh-agent.1.gz | md5sum 3bcf66fe367ed5df9c5d209b291b09cb (Didn't want to attach the actual ssh-agent.1.gz file, figuring it would probably get kicked out by the list handler, but it you want it, just let me know, will send it directly to you.) > > You should also say up front which man(1) implementation you are > using, which roff formatter you are using, > $ man --version man 2.7.5 $ groff --version GNU groff version 1.22.3 called subprograms: GNU grops (groff) version 1.22.3 GNU troff (groff) version 1.22.3 > > whether you have enabled any caching of preformatted manuals, > Not that I am aware of. But in any case, "man -w -W" reports only the roff source page (the one mentioned above) but does not report any "cat" version: $ man -w -W ssh-agent /usr/share/man/man1/ssh-agent.1.gz So I think that implies that the page that gets rendered when I do "man ssh-agent" really is from that .gz file, processed at that time by man(1), not a cached version. I also did this: $ cd /tmp $ cp /usr/share/man/man1/ssh-agent.1.gz foo.gz $ man ./foo.gz and the rendered result is identical to "man ssh-agent" (i.e. the indentation oddity is present.) > > whether you have any man.conf or manpath.config files in use, and what > they contain. > My entire fileystem contains no file of either of those names, as verified using slocate(1). > > This is likely to be some simple user oder packager error; yet again, > it could also be a yet unknown mdoc(7) or man(7) compat issue, which > is why i'm interested. > Hope the above helps. Let me know if there's anything else you need. Glenn From schwarze at usta.de Wed Sep 28 07:10:35 2016 From: schwarze at usta.de (Ingo Schwarze) Date: Tue, 27 Sep 2016 23:10:35 +0200 Subject: Possible formatting bug in ssh-agent.1 man page In-Reply-To: <20160926205507.GA31052@huh.zplane.com> References: <20160926205507.GA31052@huh.zplane.com> Message-ID: <20160927211035.GB3454@athene.usta.de> Hi, Glenn Golden wrote on Mon, Sep 26, 2016 at 02:55:08PM -0600: > Version info: OpenSSH_7.3p1, OpenSSL 1.0.2i 22 Sep 2016, Arch linux > > The ssh-agent.1 man page seems to have an indentation oddity, at least, as > formatted with recent Arch linux manpage toolset. Here's what appears in > the formatted output just after the description of the the "-t" option: > > ---------- Begin formatted output ------------------------------------- > -t life > Set a default value for the maximum lifetime of identities added > to the agent. The lifetime may be specified in seconds or in a > time format specified in sshd_config(5). A lifetime specified > for an identity with ssh-add(1) overrides this value. Without > this option the default maximum lifetime is forever. > > If a command line is given, this is executed as a subprocess of > the agent. When the command dies, so does the agent. > > The idea is that the agent is run in the user's local PC, lap > . > . > . > ------------ End formatted output ------------------------------------- > > Seems to me like all the paragraphs after the one immediately > below "-t life" (starting with "If a command line..." and thereafter) > are meant to be outdented to the main indentation level so that they > do not appear be associated with the description of the -t option. Glenn sent some additional information to me in private. It turned out the problem is caused by a bug in the script mdoc2man.awk. The bug is not platform-specific. With the information Glenn provided, i can easily reproduce the problem from git master on OpenBSD-current if i use $ ./configure --with-mantype=man The problem is that the awk script neglects terminating top level lists, resulting in bogus indentation unless the indentation gets cancelled for some other reason like .SH. The following patch fixes the problem. It improves the following manuals when using --with-mantype=man: sftp-server(8) after -u umask ssh-add(1) after FILES ~/.ssh/id_rsa ssh-agent(1) after -t life ssh_config(5) after 3. system-wide configuration file (.../ssh_config) sshd(8) after X11-forwarding The patch also inserts a few needless .PP before .SH, but that does no harm. mdoc2man.awk is a terrible hack and not a proper parser in the first place, so we shouldn't expect beauty in its output. If the output is correct and portable, that's good enough. At some point, we should replace mdoc2man.awk with mandoc -Tman anyway. The last time i tried, there was still some work to do, so that won't be instantaneous. So, for now, i think the following patch should be committed to git master. Yours, Ingo diff --git a/mdoc2man.awk b/mdoc2man.awk index 80e8d5f..cf210ba 100644 --- a/mdoc2man.awk +++ b/mdoc2man.awk @@ -321,6 +321,8 @@ function add(str) { w=nwords } else if(match(words[w],"^El$")) { optlist=oldoptlist + if(!optlist) + add(".PP") } else if(match(words[w],"^Bk$")) { if(match(words[w+1],"-words")) { w++ From djm at mindrot.org Wed Sep 28 07:41:47 2016 From: djm at mindrot.org (Damien Miller) Date: Wed, 28 Sep 2016 07:41:47 +1000 (AEST) Subject: Possible formatting bug in ssh-agent.1 man page In-Reply-To: <20160927211035.GB3454@athene.usta.de> References: <20160926205507.GA31052@huh.zplane.com> <20160927211035.GB3454@athene.usta.de> Message-ID: On Tue, 27 Sep 2016, Ingo Schwarze wrote: > The patch also inserts a few needless .PP before .SH, but that does > no harm. mdoc2man.awk is a terrible hack and not a proper parser > in the first place, so we shouldn't expect beauty in its output. > If the output is correct and portable, that's good enough. At some > point, we should replace mdoc2man.awk with mandoc -Tman anyway. > The last time i tried, there was still some work to do, so that > won't be instantaneous. > > So, for now, i think the following patch should be committed to > git master. Done - thanks! From cofdsi at gmail.com Wed Sep 28 23:04:10 2016 From: cofdsi at gmail.com (Luc Ferran) Date: Wed, 28 Sep 2016 15:04:10 +0200 Subject: Chanel never close Message-ID: Hi Guys, First, thanks for your job with openssh ! My environnement is openssh 7.3 using cygwin installed on Windows 10. With defferents clients, i'm able to connect to the serveur with: ssh -p port -l user remoteip In this situation I have a shell that I can use normally. Exiting the shell shuts de channel normaly and I'm back to the local machine. Now, if I use the following command : ssh -p port -l user remoteip echo "ok" Then ok is well writen, but never ends. With verbosity I have : ok debug2: tcpwinsz: 87380 for connection: 4 debug1: client_input_channel_req: channel 0 rtype exit-status reply 0 debug1: client_input_channel_req: channel 0 rtype eow at openssh.com reply 0 debug2: channel 0: rcvd eow debug2: channel 0: close_read debug2: channel 0: input open -> closed debug2: tcpwinsz: 87380 for connection: 4 And this never ends. Using ssh -p port -l user -t remoteip echo "ok" It works. Unfortuneatly, when I try to use ssh with rsync,it doesn't work rsync -e "ssh -t -l user -p port" .... Is this a configuration error I've made ? Could it be a bug ? Thanks for your answers regards -- From grawity at gmail.com Thu Sep 29 01:51:18 2016 From: grawity at gmail.com (=?UTF-8?Q?Mantas_Mikul=c4=97nas?=) Date: Wed, 28 Sep 2016 18:51:18 +0300 Subject: Possible formatting bug in ssh-agent.1 man page In-Reply-To: <20160927211035.GB3454@athene.usta.de> References: <20160926205507.GA31052@huh.zplane.com> <20160927211035.GB3454@athene.usta.de> Message-ID: <7e93831e-b311-3be5-262a-bbfc31235660@gmail.com> On 2016-09-28 00:10, Ingo Schwarze wrote: > The patch also inserts a few needless .PP before .SH, but that does > no harm. mdoc2man.awk is a terrible hack and not a proper parser > in the first place, so we shouldn't expect beauty in its output. > If the output is correct and portable, that's good enough. At some > point, we should replace mdoc2man.awk with mandoc -Tman anyway. > The last time i tried, there was still some work to do, so that > won't be instantaneous. At least on Linux systems, wouldn't using man/groff's built-in mdoc support also be good enough? -- Mantas Mikul?nas From grawity at gmail.com Thu Sep 29 01:51:18 2016 From: grawity at gmail.com (=?UTF-8?Q?Mantas_Mikul=c4=97nas?=) Date: Wed, 28 Sep 2016 18:51:18 +0300 Subject: Possible formatting bug in ssh-agent.1 man page In-Reply-To: <20160927211035.GB3454@athene.usta.de> References: <20160926205507.GA31052@huh.zplane.com> <20160927211035.GB3454@athene.usta.de> Message-ID: <7e93831e-b311-3be5-262a-bbfc31235660@gmail.com> On 2016-09-28 00:10, Ingo Schwarze wrote: > The patch also inserts a few needless .PP before .SH, but that does > no harm. mdoc2man.awk is a terrible hack and not a proper parser > in the first place, so we shouldn't expect beauty in its output. > If the output is correct and portable, that's good enough. At some > point, we should replace mdoc2man.awk with mandoc -Tman anyway. > The last time i tried, there was still some work to do, so that > won't be instantaneous. At least on Linux systems, wouldn't using man/groff's built-in mdoc support also be good enough? -- Mantas Mikul?nas From schwarze at usta.de Thu Sep 29 03:03:27 2016 From: schwarze at usta.de (Ingo Schwarze) Date: Wed, 28 Sep 2016 19:03:27 +0200 Subject: Possible formatting bug in ssh-agent.1 man page In-Reply-To: <7e93831e-b311-3be5-262a-bbfc31235660@gmail.com> References: <20160926205507.GA31052@huh.zplane.com> <20160927211035.GB3454@athene.usta.de> <7e93831e-b311-3be5-262a-bbfc31235660@gmail.com> Message-ID: <20160928170327.GE22342@athene.usta.de> Hi, Mantas Mikul??nas wrote on Wed, Sep 28, 2016 at 06:51:18PM +0300: > At least on Linux systems, wouldn't using man/groff's built-in mdoc > support also be good enough? Yes. Jakub Jelen of Redhat reported that the bug didn't affect Fedora. I don't know for sure, but i guess that was because they install mdoc(7) rather than man(7) versions of the manuals. In any case, installing mdoc(7) versions would seem reasonable to me on any Linux distribution. However, i have seen at least one case where a senior developer of a major Linux distro insisted on installing man(7) rather than mdoc(7) versions even though the mdoc(7) versions are the master and the man(7) versions autogenerated from them: Bdale Garbee when packaging sudo(8) for Debian. I don't know why, though; preferring man(7) doesn't seem to make sense to me. Also, it doesn't appear to be a strict policy there; on a Debian system i have access to, i see many mdoc(7) manuals in /usr/share/man/. That said, the mdoc2man conversion tool in the OpenSSH build system ought to be maintained because there are archaic operating systems out there (for example commercial Solaris 11) that still don't have mdoc(7) support in man(1) by default. Yours, Ingo From djm at mindrot.org Thu Sep 29 04:25:15 2016 From: djm at mindrot.org (Damien Miller) Date: Thu, 29 Sep 2016 04:25:15 +1000 (AEST) Subject: Chanel never close In-Reply-To: References: Message-ID: On Wed, 28 Sep 2016, Luc Ferran wrote: > Hi Guys, > > First, thanks for your job with openssh ! > My environnement is openssh 7.3 using cygwin installed on Windows 10. > > With defferents clients, i'm able to connect to the serveur with: > > ssh -p port -l user remoteip > > In this situation I have a shell that I can use normally. Exiting the shell > shuts de channel normaly and I'm back to the local machine. > > Now, if I use the following command : > > ssh -p port -l user remoteip echo "ok" > > Then ok is well writen, but never ends. With verbosity I have : > > ok > debug2: tcpwinsz: 87380 for connection: 4 OpenSSH doesn't print this message. You are using 3rd-party patches. Please try to reproduce your problem with vanilla OpenSSH. -d From steffen at sdaoden.eu Thu Sep 29 05:55:57 2016 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Wed, 28 Sep 2016 21:55:57 +0200 Subject: Fyi: a ControlMaster started by scp doesn't forward agent Message-ID: <20160928195557.xdrIvkri7%steffen@sdaoden.eu> Hello, i am really sorry that i send this as a mail message, but i forgot my bugtracker password and just can't seem to get a valid token to update the password (the first attempt failed because during token validation -- i have seen the input form --, 1&1, my web provider, cut the connection, which happens frequently ?0[steffen at wales ]$ scp ... ... ... ?0[steffen at wales ]$ ssh ... ... * [steffen at ...]$ ssh-add -l Could not open a connection to your authentication agent. * [steffen at sdaoden]$ logout Shared connection to ... closed. ?0[steffen at wales ]$ ll /tmp/.ssh_...-steffen srw------- 1 steffen steffen 0 Sep 28 20:57 /tmp/.ssh_...-steffen= ?0[steffen at wales ]$ date Wed Sep 28 20:57:59 CEST 2016 This is OpenSSH_7.3p1 on client and OpenSSH_7.2p2-hpn14v4 on server, and the configuration includes "ControlMaster auto" and "ForwardAgent yes". This could be related to "Allow agent forwarding in sftp & scp"[1], but, like i said. (I would wonder how, though, since the control master creates the connection, i'd assume.) I happily do the web stuff, but i won't try to reset my password again before -10-02, said the python thing. [1] https://bugzilla.mindrot.org/show_bug.cgi?id=831 Ciao. --steffen From keisial at gmail.com Thu Sep 29 07:19:19 2016 From: keisial at gmail.com (=?UTF-8?B?w4FuZ2VsIEdvbnrDoWxleg==?=) Date: Wed, 28 Sep 2016 23:19:19 +0200 Subject: possibility of a RemoteCommand option in the ssh config file In-Reply-To: References: Message-ID: <57EC33D7.8050904@gmail.com> Paulmier wrote: > Hi, > > About one year ago, someone (Simon Zack) asked about a RemoteCommand > option. > > His question did not encounter a large amount of answers, maybe because > Simon himself did not answer to a question from Darren Tucker about his use > case ? However, I think I have a use case pretty close to Simon's one: > > Let's imagine a host named 'lxc.host.example.org', hosting many LXC > containers named '.lxc.host.example.org'. > With a RemoteCommand option, working pretty much the same as the > ProxyCommand one, we could write something like: > > $ cat ~/.ssh/config > Host host.lxc.example.org > RequestTTY force > > Host *.host.lxc.example.org > Hostname host.lxc.example.org > RemoteCommand lxc-attach -n %h -- > > That way, we would be able to attach to containers, without the need to run > sshd inside each container, by running: > > $ ssh mycontainer.host.lxc.example.org > > A bit of difference with the ProxyCommand behaviour, though: the %h macro > should expand to the host that was requested on the cli; not the one > specified with Hostname. You should use %n for that. I like your use case, although you could the same thing (in a more convoluted configuration) using ForceCommand on the ssh key at the authorized_keys of host.lxc.example.org Cheers From cjwatson at debian.org Thu Sep 29 21:57:01 2016 From: cjwatson at debian.org (Colin Watson) Date: Thu, 29 Sep 2016 12:57:01 +0100 Subject: Possible formatting bug in ssh-agent.1 man page In-Reply-To: <20160928170327.GE22342@athene.usta.de> References: <20160926205507.GA31052@huh.zplane.com> <20160927211035.GB3454@athene.usta.de> <7e93831e-b311-3be5-262a-bbfc31235660@gmail.com> <20160928170327.GE22342@athene.usta.de> Message-ID: <20160929115701.GE8411@riva.ucam.org> On Wed, Sep 28, 2016 at 07:03:27PM +0200, Ingo Schwarze wrote: > However, i have seen at least one case where a senior developer > of a major Linux distro insisted on installing man(7) rather than > mdoc(7) versions even though the mdoc(7) versions are the master > and the man(7) versions autogenerated from them: Bdale Garbee > when packaging sudo(8) for Debian. I don't know why, though; > preferring man(7) doesn't seem to make sense to me. Also, it > doesn't appear to be a strict policy there; on a Debian system > i have access to, i see many mdoc(7) manuals in /usr/share/man/. The Debian OpenSSH packages just install mdoc(7). I have no idea why Bdale did that; I would guess it to be a response to some particular difficulty or other rather than a distribution policy, the latter of which it certainly is not. In any case, the current sudo packages in Debian unstable install mdoc(7) pages. -- Colin Watson [cjwatson at debian.org]