From fortezza at mechanicalism.net Mon May 1 06:07:59 2006 From: fortezza at mechanicalism.net (Jason Fortezzo) Date: Sun, 30 Apr 2006 15:07:59 -0500 Subject: Disconnecting: Bad packet length In-Reply-To: References: Message-ID: <20060430200759.GA83191@alderaan.mechanicalism.net> On Fri, Apr 28, 2006 at 07:19:45PM +0200, olle ollesson wrote: > I'm trying to get OpenSSH to work on Solaris 10 wich Sun C 5.8 compiler > (SUNWspro 11). I've compiled OpenSSL 0.9.8a without problem and OpenSSH > 4.3p2 as well. > > [user at compilationserver ~/openssh-4.3p2] ./ssh -V > OpenSSH_4.3p2, OpenSSL 0.9.8a 11 Oct 2005 > > My problem is that I cannot connect to anything. When I try I always get an > error > > [user at compilationserver ~/openssh-4.3p2] ./ssh localhost > Disconnecting: Bad packet length 872800259. I had the same problem with SUN Studio 11 too; installing the latest patches compiler patches seemed to fix the problem. -- Jason Fortezzo fortezza at mechanicalism.net From dtucker at zip.com.au Tue May 2 10:09:59 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 2 May 2006 10:09:59 +1000 Subject: OpenSSH DNS resolution failure on IRIX 5.3: request to fix In-Reply-To: References: Message-ID: <20060502000959.GA25589@gate.dtucker.net> On Fri, Apr 21, 2006 at 09:29:36PM +0200, Georg Schwarz wrote: > as reported earlier, recent versions of OpenSSH (4.3p1, 4.3p2 as well > as the current CVS) on IRIX 5.3 exhibit a DNS resolution failure. > Even for perfectly valid hostnames they return "no address associated > with name". > After some digging through the code I found what is causing this > strange behaviour. Basically it was introduced with the following > change: > > revision 1.3954 > date: 2005/11/05 05:56:52; author: djm; state: Exp; lines: +4 -1 > - (djm) [openbsd-compat/getrrsetbyname.c] Sync to latest OpenBSD > version, > resolving memory leak bz#1111 reported by kremenek AT > cs.stanford.edu; > ok dtucker@ > > > When I take out the line > > struct __res_state _res; After some off-list discussion, it looks like the correct thing to do for this is to check for the presence of _res as an extern and use that in preference. The attached patch (against -current) seems to resolve the problem on IRIX, but can anyone see any reason this might be a bad idea on some other platform? Thanks. Index: configure.ac =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/configure.ac,v retrieving revision 1.339 diff -u -p -r1.339 configure.ac --- configure.ac 22 Apr 2006 11:26:08 -0000 1.339 +++ configure.ac 1 May 2006 00:53:37 -0000 @@ -3000,6 +3000,25 @@ int main() [#include ]) ]) +AC_MSG_CHECKING(if struct __res_state _res is an extern) +AC_LINK_IFELSE([ +#include +#if HAVE_SYS_TYPES_H +# include +#endif +#include +#include +#include +extern struct __res_state _res; +int main() { return 0; } + ], + [AC_MSG_RESULT(yes) + AC_DEFINE(HAVE__RES_EXTERN, 1, + [Define if you have struct __res_state _res as an extern]) + ], + [ AC_MSG_RESULT(no) ] +) + # Check whether user wants SELinux support SELINUX_MSG="no" LIBSELINUX="" Index: openbsd-compat/getrrsetbyname.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/openbsd-compat/getrrsetbyname.c,v retrieving revision 1.17 diff -u -p -r1.17 getrrsetbyname.c --- openbsd-compat/getrrsetbyname.c 12 Nov 2005 03:06:29 -0000 1.17 +++ openbsd-compat/getrrsetbyname.c 1 May 2006 00:41:21 -0000 @@ -60,7 +60,10 @@ extern int h_errno; # undef _THREAD_PRIVATE #endif #define _THREAD_PRIVATE(a,b,c) (c) + +#ifndef HAVE__RES_EXTERN struct __res_state _res; +#endif /* Necessary functions and macros */ -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From rick.jones2 at hp.com Tue May 2 10:15:45 2006 From: rick.jones2 at hp.com (Rick Jones) Date: Mon, 01 May 2006 17:15:45 -0700 Subject: OpenSSH DNS resolution failure on IRIX 5.3: request to fix In-Reply-To: <20060502000959.GA25589@gate.dtucker.net> References: <20060502000959.GA25589@gate.dtucker.net> Message-ID: <4456A4B1.7050509@hp.com> I cannot speak to the specifics of this situation, but my past experience with netperf DNS tests and trying to use _res directly was: "There be dragons there!" And IIRC I try not to do that in netperf4. Different platforms may handle _res differently depending on the app being threaded or not, etc. Some platforms may have resolver libraries based on particularly old versions of BIND. So, I would wonder the purpose to which _res was being accessed directly and ask if perhaps there might be a different way to serve that purpose. rick jones From dtucker at zip.com.au Tue May 2 11:01:30 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 2 May 2006 11:01:30 +1000 Subject: OpenSSH DNS resolution failure on IRIX 5.3: request to fix In-Reply-To: <4456A4B1.7050509@hp.com> References: <20060502000959.GA25589@gate.dtucker.net> <4456A4B1.7050509@hp.com> Message-ID: <20060502010130.GA26249@gate.dtucker.net> On Mon, May 01, 2006 at 05:15:45PM -0700, Rick Jones wrote: > I cannot speak to the specifics of this situation, but my past > experience with netperf DNS tests and trying to use _res directly was: > > "There be dragons there!" > > And IIRC I try not to do that in netperf4. Different platforms may > handle _res differently depending on the app being threaded or not, etc. > Some platforms may have resolver libraries based on particularly old > versions of BIND. > > So, I would wonder the purpose to which _res was being accessed directly > and ask if perhaps there might be a different way to serve that purpose. It's in the getrrsetbyname implementation, but afaict it's not accessed directly elsewhere. Maybe we can avoid the problem by just renaming it to something else. (This is a #define since sooner or later we will need to sync the code again.) Georg, does doing this instead still resolve the problem? Index: openbsd-compat/getrrsetbyname.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/openbsd-compat/getrrsetbyname.c,v retrieving revision 1.17 diff -u -p -r1.17 getrrsetbyname.c --- openbsd-compat/getrrsetbyname.c 12 Nov 2005 03:06:29 -0000 1.17 +++ openbsd-compat/getrrsetbyname.c 2 May 2006 00:51:49 -0000 @@ -60,6 +60,10 @@ extern int h_errno; # undef _THREAD_PRIVATE #endif #define _THREAD_PRIVATE(a,b,c) (c) + +/* to avoid conflicts where a platform already has _res */ +#define _res _compat_res + struct __res_state _res; /* Necessary functions and macros */ -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From william at 25thandClement.com Tue May 2 15:40:30 2006 From: william at 25thandClement.com (William Ahern) Date: Mon, 1 May 2006 22:40:30 -0700 Subject: OpenSSH Domain Socket Forwarding Message-ID: <20060502054030.GA7431@orville.25thandClement.com> I'll be maintaining the streamlocal patch(s)--which teach(es) OpenSSH to forward local and remote domain sockets--here: http://www.25thandclement.com/~william/projects/streamlocal.html - Bill From bpsr77 at hotmail.com Wed May 3 00:19:23 2006 From: bpsr77 at hotmail.com (olle ollesson) Date: Tue, 02 May 2006 16:19:23 +0200 Subject: Disconnecting: Bad packet length In-Reply-To: <20060430200759.GA83191@alderaan.mechanicalism.net> Message-ID: Hi All, Thanks for the tip. I can confirm that after applying the following Sun Studio 11 patches: 120760-04 121015-02 121017-01 it now works beautifully! Case closed. Thanks again! /Olle >From: Jason Fortezzo >To: olle ollesson >CC: openssh-unix-dev at mindrot.org >Subject: Re: Disconnecting: Bad packet length >Date: Sun, 30 Apr 2006 15:07:59 -0500 > >On Fri, Apr 28, 2006 at 07:19:45PM +0200, olle ollesson wrote: > > I'm trying to get OpenSSH to work on Solaris 10 wich Sun C 5.8 compiler > > (SUNWspro 11). I've compiled OpenSSL 0.9.8a without problem and OpenSSH > > 4.3p2 as well. > > > > [user at compilationserver ~/openssh-4.3p2] ./ssh -V > > OpenSSH_4.3p2, OpenSSL 0.9.8a 11 Oct 2005 > > > > My problem is that I cannot connect to anything. When I try I always get >an > > error > > > > [user at compilationserver ~/openssh-4.3p2] ./ssh localhost > > Disconnecting: Bad packet length 872800259. > >I had the same problem with SUN Studio 11 too; installing the latest >patches compiler >patches seemed to fix the problem. > >-- >Jason Fortezzo >fortezza at mechanicalism.net > >_______________________________________________ >openssh-unix-dev mailing list >openssh-unix-dev at mindrot.org >http://www.mindrot.org/mailman/listinfo/openssh-unix-dev _________________________________________________________________ Don't just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/ From dtucker at zip.com.au Thu May 4 00:14:25 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 04 May 2006 00:14:25 +1000 Subject: Memory Usage with openSSH 4.0 In-Reply-To: <80d7e4090604282120u8170fdch691b330365d920c5@mail.gmail.com> References: <20060425235239.45447.qmail@web34310.mail.mud.yahoo.com> <80d7e4090604282120u8170fdch691b330365d920c5@mail.gmail.com> Message-ID: <4458BAC1.4050605@zip.com.au> Stephen John Smoogen wrote: > On 4/25/06, J D wrote: >> I have friends running sshd on their emebedded ppc >> linux systems at two universities. Normally sshd takes >> about 3M of memory and they have about 16M freemem >> showed in /proc/meminfo. But occationally (every 1 or >> 2 weeks) they see free memory goes down really fast >> and they lose 10M in 1 minute. If they disable sshd by >> blocking the port access, this does not happen any >> more. >> >> The device is not behind any firewall and sshd version >> is 4.0. >> >> I've done a lot search on the web and have not found >> any report of similar issues. I was hoping experts on >> this mailing list can help shed some light on this >> problem. Thanks. > > That is an old version.. so I am not sure much help here.. but there > needs to be some info on the type of configuration, also what is the > OS, etc. My off-the-wall guess is that the box gets one of the weekly > very large dictionary attack during those times and may not be able to > log as quickly as it wants to (depending on how the embedded libc is > dealing with logging). It could also be related by the client-side behaviour. Since sshd forks immediately after accepting the connection, if the client(s) makes a bunch of connections in parallel then you will probably see a spike in memory usage. If that's the cause you can mitigate it with MaxStartups in sshd_config. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From mikhail.manuilov at gmail.com Thu May 4 03:16:58 2006 From: mikhail.manuilov at gmail.com (Mikhail Manuylov) Date: Wed, 3 May 2006 21:16:58 +0400 Subject: Solaris 8 x86 rsa pubkey auth problem In-Reply-To: <7ec6def90604210335s5ad03dc4s811fe4a66a8a32c4@mail.gmail.com> References: <7ec6def90604210335s5ad03dc4s811fe4a66a8a32c4@mail.gmail.com> Message-ID: <7ec6def90605031016y23176fadr8fdd59461b235a0c@mail.gmail.com> Hi there, Actually I've solved my "bug" last friday, but I'm not shure it was a bug in openssh behaviour. But I really think (in my cryptography knowledge) is somewhat wrong. 1) ssh.c: 768: 'load_public_identity_files' function is called eventually calling 2) ssh.c: 1208: ' key_load_public' function with my -i key supplied filename as parameter and returns ponter to 'Key' structure 3) Here is sourcecode for that function: I'll insert my own comments starting with '#': /* load public key from ssh v1 private or any pubkey file */ Key * key_load_public(const char *filename, char **commentp) { Key *pub; char file[MAXPATHLEN]; /* try rsa1 private key */ pub = key_load_public_type(KEY_RSA1, filename, commentp); # fails here with RSA private key if (pub != NULL) return pub; /* try rsa1 public key */ pub = key_new(KEY_RSA1); if (key_try_load_public(pub, filename, commentp) == 1) # fails here obviously return pub; key_free(pub); /* try ssh2 public key */ pub = key_new(KEY_UNSPEC); if (key_try_load_public(pub, filename, commentp) == 1) # fails here too return pub; if ((strlcpy(file, filename, sizeof file) < sizeof(file)) && (strlcat(file, ".pub", sizeof file) < sizeof(file)) && (key_try_load_public(pub, file, commentp) == 1)) >>> # Here it actually finds "auditor_id_rsa.pub" file ( i've left old ssh-dss public key here ) # And then it's used to authenticate to remote sshd, authentication with public key???? # And sshd at auth2-pubkey.c:77 recieves ssh-dss (not ssh-rsa it founds in authorized_keys) and fails # In debug output it was never mentioned that ssh used "auditor_id_rsa.pub" only "auditor_id_rsa" without "pub" # extension, so have been digging not so obvious sources of openssh for about a week =( return pub; key_free(pub); return NULL; } What is the reason of trying to find public key and offering it to authenticate? This somewhat ridicule, i suppose... On 4/21/06, Mikhail Manuylov wrote: > Hello, > > I got some weird problem with public key authentication using rsa key pair. > > Let me first of all explain my setup. > > 1) I got two Solaris 8 x86 boxes > uname -a > SunOS 5.8 Generic_117351-24 i86pc i386 i86pc > > <---> > > 2) They're running absolutely identical openssh installations > I'm using pkgsrc, so I've builded all necessary packages from two days > old pkgsrc sources > on one of the boxes and installed the same binaries on second > OpenSSH_4.3p1, OpenSSL 0.9.7i 14 Oct 2005 > > 3) The only differense in their setup is that 'kdc' is a intel p4 boxm > and module is p3 box. > > I've generated rsa key pair via ssh-keygen, and placed public part of > it into /home/root/.ssh/authorized_keys > on both computers. > > The problem: > > I can't log into any (not only to module) computer running the same > version of sshd (and of course user holding the same public key) > using 'kdc', pubkey athentication fails and ssh pops password prompt > up. Pubkey athentication with that key works flawlessly with any > other direction even when 'module' connecting to 'kdc'. > > How I can help debugging this problem: > > I've supplied debug output of both ssh and sshd from two cases: > 1) 'module' authenticating on 'kdc' ( works ok ) > 2) 'kdc' authenticating on 'module' ( pubkey failed ) > > I've already compiled gdb and openssh with debug info. I've also > started two debug sshd yesterday, but due two my not so cool knowledge > of > openssh sources and maybe schema of forking and privelege separation I > still can't reach user_key_allowed function. > > Thank you for your great work. And thanks for help beforehand. > > Here's debug output: > > 1) kdc# ssh -vvv -i ~/.ssh/auditor_rsa_id root at 192.168.10.10 > OpenSSH_4.3p1, OpenSSL 0.9.7i 14 Oct 2005 > debug1: Reading configuration data /usr/pkg/etc/ssh/ssh_config > debug2: ssh_connect: needpriv 0 > debug1: Connecting to 192.168.10.10 [ 192.168.10.10] port 22. > debug1: Connection established. > debug1: permanently_set_uid: 0/1 > debug3: Not a RSA1 key file auditor_id_rsa. > debug2: key_type_from_name: unknown key type '-----BEGIN' > debug3: key_read: missing keytype > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug2: key_type_from_name: unknown key type '-----END' > debug3: key_read: missing keytype > debug1: identity file auditor_id_rsa type 2 > debug1: Remote protocol version 2.0 , remote software version OpenSSH_4.3 > debug1: match: OpenSSH_4.3 pat OpenSSH* > debug1: Enabling compatibility mode for protocol 2.0 > debug1: Local version string SSH-2.0-OpenSSH_4.3 > debug2: fd 3 setting O_NONBLOCK > debug1: SSH2_MSG_KEXINIT sent > debug1: SSH2_MSG_KEXINIT received > debug2: kex_parse_kexinit: > diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 > debug2: kex_parse_kexinit: ssh-rsa,ssh-dss > debug2: kex_parse_kexinit: > aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se,aes12 > 8-ctr,aes192-ctr,aes256-ctr > debug2: kex_parse_kexinit: > aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se,aes12 > 8-ctr,aes192-ctr,aes256-ctr > debug2: kex_parse_kexinit: > hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 > debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160, > hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 > debug2: kex_parse_kexinit: none,zlib at openssh.com,zlib > debug2: kex_parse_kexinit: none, zlib at openssh.com,zlib > debug2: kex_parse_kexinit: > debug2: kex_parse_kexinit: > debug2: kex_parse_kexinit: first_kex_follows 0 > debug2: kex_parse_kexinit: reserved 0 > debug2: kex_parse_kexinit: > diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 > debug2: kex_parse_kexinit: ssh-rsa,ssh-dss > debug2: kex_parse_kexinit: > aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se > ,aes12 > 8-ctr,aes192-ctr,aes256-ctr > debug2: kex_parse_kexinit: > aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se > ,aes12 > 8-ctr,aes192-ctr,aes256-ctr > debug2: kex_parse_kexinit: > hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 > debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160, > hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 > debug2: kex_parse_kexinit: none,zlib at openssh.com > debug2: kex_parse_kexinit: none, zlib at openssh.com > debug2: kex_parse_kexinit: > debug2: kex_parse_kexinit: > debug2: kex_parse_kexinit: first_kex_follows 0 > debug2: kex_parse_kexinit: reserved 0 > debug2: mac_init: found hmac-md5 > debug1: kex: server->client aes128-cbc hmac-md5 none > debug2: mac_init: found hmac-md5 > debug1: kex: client->server aes128-cbc hmac-md5 none > debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent > debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP > debug2: dh_gen_key: priv key bits set: 115/256 > debug2: bits set: 513/1024 > debug1: SSH2_MSG_KEX_DH_GEX_INIT sent > debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY > debug3: check_host_in_hostfile: filename /home/root/.ssh/known_hosts > debug3: check_host_in_hostfile: match line 4 > debug1: Host '192.168.10.10' is known and matches the RSA host key. > debug1: Found key in /home/root/.ssh/known_hosts:4 > debug2: bits set: 516/1024 > debug1: ssh_rsa_verify: signature correct > debug2: kex_derive_keys > debug2: set_newkeys: mode 1 > debug1: SSH2_MSG_NEWKEYS sent > debug1: expecting SSH2_MSG_NEWKEYS > debug2: set_newkeys: mode 0 > debug1: SSH2_MSG_NEWKEYS received > debug1: SSH2_MSG_SERVICE_REQUEST sent > debug2: service_accept: ssh-userauth > debug1: SSH2_MSG_SERVICE_ACCEPT received > debug2: key: auditor_id_rsa (80b2d48) > debug1: Authentications that can continue: > publickey,password,keyboard-interactive > debug3: start over, passed a different list > publickey,password,keyboard-interactive > debug3: preferred publickey,keyboard-interactive,password > debug3: authmethod_lookup publickey > debug3: remaining preferred: keyboard-interactive,password > debug3: authmethod_is_enabled publickey > debug1: Next authentication method: publickey > debug1: Offering public key: auditor_id_rsa > debug3: send_pubkey_test > debug2: we sent a publickey packet, wait for reply > debug1: Authentications that can continue: > publickey,password,keyboard-interactive > debug2: we did not send a packet, disable method > debug3: authmethod_lookup keyboard-interactive > debug3: remaining preferred: password > debug3: authmethod_is_enabled keyboard-interactive > debug1: Next authentication method: keyboard-interactive > debug2: userauth_kbdint > debug2: we sent a keyboard-interactive packet, wait for reply > debug1: Authentications that can continue: > publickey,password,keyboard-interactive > debug3: userauth_kbdint: disable: no info_req_seen > debug2: we did not send a packet, disable method > debug3: authmethod_lookup password > debug3: remaining preferred: > debug3: authmethod_is_enabled password > debug1: Next authentication method: password > > 2) module# /usr/pkg/sbin/sshd -D -d -d -d -e > debug2: load_server_config: filename /usr/pkg/etc/ssh/sshd_config > debug2: load_server_config: done config len = 226 > debug2: parse_server_config: config /usr/pkg/etc/ssh/sshd_config len 226 > debug1: sshd version OpenSSH_4.3p1 > debug3: Not a RSA1 key file /usr/pkg/etc/ssh/ssh_host_rsa_key. > debug1: read PEM private key done: type RSA > debug1: private host key: #0 type 1 RSA > debug3: Not a RSA1 key file /usr/pkg/etc/ssh/ssh_host_dsa_key. > debug1: read PEM private key done: type DSA > debug1: private host key: #1 type 2 DSA > debug1: rexec_argv[0]='/usr/pkg/sbin/sshd' > debug1: rexec_argv[1]='-D' > debug1: rexec_argv[2]='-d' > debug1: rexec_argv[3]='-d' > debug1: rexec_argv[4]='-d' > debug1: rexec_argv[5]='-e' > debug2: fd 3 setting O_NONBLOCK > debug1: Bind to port 22 on 192.168.132.15. > Server listening on 192.168.132.15 port 22. > debug2: fd 4 setting O_NONBLOCK > debug1: Bind to port 22 on 192.168.10.10. > Server listening on 192.168.10.10 port 22. > debug1: fd 5 clearing O_NONBLOCK > debug1: Server will not fork when running in debugging mode. > debug3: send_rexec_state: entering fd = 10 config len 226 > debug3: ssh_msg_send: type 0 > debug3: send_rexec_state: done > debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 10 > debug3: recv_rexec_state: entering fd = 5 > debug3: ssh_msg_recv entering > debug3: recv_rexec_state: done > debug2: parse_server_config: config rexec len 226 > debug1: sshd version OpenSSH_4.3p1 > debug3: Not a RSA1 key file /usr/pkg/etc/ssh/ssh_host_rsa_key. > debug1: read PEM private key done: type RSA > debug1: private host key: #0 type 1 RSA > debug3: Not a RSA1 key file /usr/pkg/etc/ssh/ssh_host_dsa_key. > debug1: read PEM private key done: type DSA > debug1: private host key: #1 type 2 DSA > debug1: inetd sockets after dupping: 3, 3 > Connection from 192.168.10.11 port 8759 > debug1: Client protocol version 2.0; client software version OpenSSH_4.3 > debug1: match: OpenSSH_4.3 pat OpenSSH* > debug1: Enabling compatibility mode for protocol 2.0 > debug1: Local version string SSH-2.0-OpenSSH_4.3 > debug2: fd 3 setting O_NONBLOCK > debug3: privsep user:group 100:100 > debug1: permanently_set_uid: 100/100 > debug1: list_hostkey_types: ssh-rsa,ssh-dss > debug1: SSH2_MSG_KEXINIT sent > debug1: SSH2_MSG_KEXINIT received > debug2: kex_parse_kexinit: > diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 > debug2: kex_parse_kexinit: ssh-rsa,ssh-dss > debug2: kex_parse_kexinit: > aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc, > rijndael-cbc at lysator.liu.se,aes12 > 8-ctr,aes192-ctr,aes256-ctr > debug2: kex_parse_kexinit: > aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc, > rijndael-cbc at lysator.liu.se,aes12 > 8-ctr,aes192-ctr,aes256-ctr > debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160, > hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 > debug2: kex_parse_kexinit: > hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 > debug2: kex_parse_kexinit: none,zlib at openssh.com > debug2: kex_parse_kexinit: none,zlib at openssh.com > debug2: kex_parse_kexinit: > debug2: kex_parse_kexinit: > debug2: kex_parse_kexinit: first_kex_follows 0 > debug2: kex_parse_kexinit: reserved 0 > debug2: kex_parse_kexinit: > diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 > debug2: kex_parse_kexinit: ssh-rsa,ssh-dss > debug2: kex_parse_kexinit: > aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se,aes12 > 8-ctr,aes192-ctr,aes256-ctr > debug2: kex_parse_kexinit: > aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se,aes12 > 8-ctr,aes192-ctr,aes256-ctr > debug2: kex_parse_kexinit: > hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 > debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160, > hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 > debug2: kex_parse_kexinit: none,zlib at openssh.com,zlib > debug2: kex_parse_kexinit: none, zlib at openssh.com,zlib > debug2: kex_parse_kexinit: > debug2: kex_parse_kexinit: > debug2: kex_parse_kexinit: first_kex_follows 0 > debug2: kex_parse_kexinit: reserved 0 > debug2: mac_init: found hmac-md5 > debug1: kex: client->server aes128-cbc hmac-md5 none > debug2: mac_init: found hmac-md5 > debug1: kex: server->client aes128-cbc hmac-md5 none > debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received > debug3: mm_request_send entering: type 0 > debug3: mm_choose_dh: waiting for MONITOR_ANS_MODULI > debug3: mm_request_receive_expect entering: type 1 > debug3: mm_request_receive entering > debug2: Network child is on pid 3358 > debug3: preauth child monitor started > debug3: mm_request_receive entering > debug3: monitor_read: checking request 0 > debug3: mm_answer_moduli: got parameters: 1024 1024 8192 > debug3: mm_request_send entering: type 1 > debug3: mm_choose_dh: remaining 0 > debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent > debug2: dh_gen_key: priv key bits set: 129/256 > debug2: bits set: 524/1024 > debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT > debug2: bits set: 495/1024 > debug3: mm_key_sign entering > debug3: mm_request_send entering: type 4 > debug3: mm_key_sign: waiting for MONITOR_ANS_SIGN > debug3: mm_request_receive_expect entering: type 5 > debug3: mm_request_receive entering > debug2: monitor_read: 0 used once, disabling now > debug3: mm_request_receive entering > debug3: monitor_read: checking request 4 > debug3: mm_answer_sign > debug3: mm_answer_sign: signature 80c7850(271) > debug3: mm_request_send entering: type 5 > debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent > debug2: monitor_read: 4 used once, disabling now > debug3: mm_request_receive entering > debug2: kex_derive_keys > debug2: set_newkeys: mode 1 > debug1: SSH2_MSG_NEWKEYS sent > debug1: expecting SSH2_MSG_NEWKEYS > debug2: set_newkeys: mode 0 > debug1: SSH2_MSG_NEWKEYS received > debug1: KEX done > debug1: userauth-request for user root service ssh-connection method none > debug1: attempt 0 failures 0 > debug3: mm_getpwnamallow entering > debug3: mm_request_send entering: type 6 > debug3: mm_getpwnamallow: waiting for MONITOR_ANS_PWNAM > debug3: mm_request_receive_expect entering: type 7 > debug3: mm_request_receive entering > debug3: monitor_read: checking request 6 > debug3: mm_answer_pwnamallow > debug3: auth_shadow_acctexpired: today 13256 sp_expire -1 days left -13257 > debug3: account expiration disabled > debug3: mm_answer_pwnamallow: sending MONITOR_ANS_PWNAM: 1 > debug3: mm_request_send entering: type 7 > debug2: monitor_read: 6 used once, disabling now > debug3: mm_request_receive entering > debug2: input_userauth_request: setting up authctxt for root > debug3: mm_inform_authserv entering > debug3: mm_request_send entering: type 3 > debug2: input_userauth_request: try method none > debug3: mm_auth_password entering > debug3: mm_request_send entering: type 10 > debug3: mm_auth_password: waiting for MONITOR_ANS_AUTHPASSWORD > debug3: mm_request_receive_expect entering: type 11 > debug3: mm_request_receive entering > debug3: monitor_read: checking request 3 > debug3: mm_answer_authserv: service=ssh-connection, style= > debug2: monitor_read: 3 used once, disabling now > debug3: mm_request_receive entering > debug3: monitor_read: checking request 10 > debug3: mm_answer_authpassword: sending result 0 > debug3: mm_request_send entering: type 11 > Failed none for root from 192.168.10.11 port 8759 ssh2 > debug3: mm_request_receive entering > debug3: mm_auth_password: user not authenticated > Failed none for root from 192.168.10.11 port 8759 ssh2 > debug1: userauth-request for user root service ssh-connection method publickey > debug1: attempt 1 failures 1 > debug2: input_userauth_request: try method publickey > debug1: test whether pkalg/pkblob are acceptable > debug3: mm_key_allowed entering > debug3: mm_request_send entering: type 20 > debug3: mm_key_allowed: waiting for MONITOR_ANS_KEYALLOWED > debug3: mm_request_receive_expect entering: type 21 > debug3: mm_request_receive entering > debug3: monitor_read: checking request 20 > debug3: mm_answer_keyallowed entering > debug3: mm_answer_keyallowed: key_from_blob: 80c04e8 > debug1: temporarily_use_uid: 0/1 (e=0/1) > debug1: trying public key file /home/root/.ssh/authorized_keys > debug3: secure_filename: checking '/usr/home/root/.ssh' > debug3: secure_filename: checking '/usr/home/root' > debug3: secure_filename: terminating check at '/usr/home/root' > debug3: key_read: type mismatch > debug2: user_key_allowed: check options: 'ssh-rsa > AAAAB3NzaC1yc2EAAAABIwAAAQEA5SXtHW7fmMWxkvjUKkB3pEygK6MkzOUejT8DCucnLJ2NT/lDdsWUR1Bz+nFmzFrcHEnP1H0+zlTEEEr > T1StBaiWmMO1mqD/AXh7XjVylsV+7E9qcQ6OHjfYaNjSffk1hAzLokrXti0qeBbZpz8yAy4LsscxNdX97aDtDB2S9AJYoWSNVsnJJKDGYlQpHL1sK+rfezYOHfeCyBh/Ui07sF2RbPz3k59QFok5VY1EUwvM0 > LMjXOAuTl0m7PyouuU3JSr7NRu52nsyNxPLwFvK1wvqX+5dJCIJ8Z9J1peWj4o51ERvKvx7rQSG7N/q10J41IU9koPsi/sr0usLmx3ROsw== > root at kgc > ' > debug2: key_type_from_name: unknown key type > 'AAAAB3NzaC1yc2EAAAABIwAAAQEA5SXtHW7fmMWxkvjUKkB3pEygK6MkzOUejT8DCucnLJ2NT/lDdsWUR1Bz+nFmzFrcHEnP1H0+zlTEEErT1St > BaiWmMO1mqD/AXh7XjVylsV+7E9qcQ6OHjfYaNjSffk1hAzLokrXti0qeBbZpz8yAy4LsscxNdX97aDtDB2S9AJYoWSNVsnJJKDGYlQpHL1sK+rfezYOHfeCyBh/Ui07sF2RbPz3k59QFok5VY1EUwvM0LMjX > OAuTl0m7PyouuU3JSr7NRu52nsyNxPLwFvK1wvqX+5dJCIJ8Z9J1peWj4o51ERvKvx7rQSG7N/q10J41IU9koPsi/sr0usLmx3ROsw==' > debug3: key_read: missing keytype > debug2: user_key_allowed: advance: > 'AAAAB3NzaC1yc2EAAAABIwAAAQEA5SXtHW7fmMWxkvjUKkB3pEygK6MkzOUejT8DCucnLJ2NT/lDdsWUR1Bz+nFmzFrcHEnP1H0+zlTEEErT1StBaiWmMO1mq > D/AXh7XjVylsV+7E9qcQ6OHjfYaNjSffk1hAzLokrXti0qeBbZpz8yAy4LsscxNdX97aDtDB2S9AJYoWSNVsnJJKDGYlQpHL1sK+rfezYOHfeCyBh/Ui07sF2RbPz3k59QFok5VY1EUwvM0LMjXOAuTl0m7Py > ouuU3JSr7NRu52nsyNxPLwFvK1wvqX+5dJCIJ8Z9J1peWj4o51ERvKvx7rQSG7N/q10J41IU9koPsi/sr0usLmx3ROsw== > root at kgc > ' > debug1: restore_uid: 0/1 > debug2: key not found > debug1: temporarily_use_uid: 0/1 (e=0/1) > debug1: trying public key file /home/root/.ssh/authorized_keys2 > debug1: restore_uid: 0/1 > debug3: mm_answer_keyallowed: key 80c04e8 is disallowed > debug3: mm_request_send entering: type 21 > debug3: mm_request_receive entering > debug2: userauth_pubkey: authenticated 0 pkalg ssh-dss > Failed publickey for root from 192.168.10.11 port 8759 ssh2 > debug1: userauth-request for user root service ssh-connection method > keyboard-interactive > debug1: attempt 2 failures 2 > debug2: input_userauth_request: try method keyboard-interactive > debug1: keyboard-interactive devs > debug1: auth2_challenge: user=root devs= > debug1: kbdint_alloc: devices 'skey' > debug2: auth2_challenge_start: devices skey > debug2: kbdint_next_device: devices > debug1: auth2_challenge_start: trying authentication method 'skey' > debug3: mm_skey_query: entering > debug3: mm_request_send entering: type 16 > debug3: mm_request_receive_expect entering: type 17 > debug3: mm_request_receive entering > debug3: monitor_read: checking request 16 > debug3: mm_answer_skeyquery: sending challenge success: 0 > debug3: mm_request_send entering: type 17 > debug3: mm_request_receive entering > debug3: mm_skey_query: no challenge > Failed keyboard-interactive for root from 192.168.10.11 port 8759 ssh2 > Connection closed by 192.168.10.11 > debug1: do_cleanup > debug1: do_cleanup > > 3) module# ssh -vvv -i ~/.ssh/auditor_rsa_id root at 192.168.10.11 > OpenSSH_4.3p1, OpenSSL 0.9.7i 14 Oct 2005 > debug1: Reading configuration data /usr/pkg/etc/ssh/ssh_config > debug2: ssh_connect: needpriv 0 > debug1: Connecting to 192.168.10.11 [192.168.10.11] port 22. > debug1: Connection established. > debug1: permanently_set_uid: 0/1 > debug3: Not a RSA1 key file auditor_id_rsa. > debug2: key_type_from_name: unknown key type '-----BEGIN' > debug3: key_read: missing keytype > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug2: key_type_from_name: unknown key type '-----END' > debug3: key_read: missing keytype > debug1: identity file auditor_id_rsa type -1 > debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3 > debug1: match: OpenSSH_4.3 pat OpenSSH* > debug1: Enabling compatibility mode for protocol 2.0 > debug1: Local version string SSH-2.0-OpenSSH_4.3 > debug2: fd 3 setting O_NONBLOCK > debug1: SSH2_MSG_KEXINIT sent > debug1: SSH2_MSG_KEXINIT received > debug2: kex_parse_kexinit: > diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 > debug2: kex_parse_kexinit: ssh-rsa,ssh-dss > debug2: kex_parse_kexinit: > aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se > ,aes12 > 8-ctr,aes192-ctr,aes256-ctr > debug2: kex_parse_kexinit: > aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se > ,aes12 > 8-ctr,aes192-ctr,aes256-ctr > debug2: kex_parse_kexinit: > hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 > debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160, > hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 > debug2: kex_parse_kexinit: none,zlib at openssh.com,zlib > debug2: kex_parse_kexinit: none, zlib at openssh.com,zlib > debug2: kex_parse_kexinit: > debug2: kex_parse_kexinit: > debug2: kex_parse_kexinit: first_kex_follows 0 > debug2: kex_parse_kexinit: reserved 0 > debug2: kex_parse_kexinit: > diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 > debug2: kex_parse_kexinit: ssh-rsa,ssh-dss > debug2: kex_parse_kexinit: > aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se > ,aes12 > 8-ctr,aes192-ctr,aes256-ctr > debug2: kex_parse_kexinit: > aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se > ,aes12 > 8-ctr,aes192-ctr,aes256-ctr > debug2: kex_parse_kexinit: > hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 > debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160, > hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 > debug2: kex_parse_kexinit: none,zlib at openssh.com > debug2: kex_parse_kexinit: none, zlib at openssh.com > debug2: kex_parse_kexinit: > debug2: kex_parse_kexinit: > debug2: kex_parse_kexinit: first_kex_follows 0 > debug2: kex_parse_kexinit: reserved 0 > debug2: mac_init: found hmac-md5 > debug1: kex: server->client aes128-cbc hmac-md5 none > debug2: mac_init: found hmac-md5 > debug1: kex: client->server aes128-cbc hmac-md5 none > debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent > debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP > debug2: dh_gen_key: priv key bits set: 143/256 > debug2: bits set: 522/1024 > debug1: SSH2_MSG_KEX_DH_GEX_INIT sent > debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY > debug3: check_host_in_hostfile: filename /home/root/.ssh/known_hosts > debug3: check_host_in_hostfile: match line 15 > debug1: Host '192.168.10.11' is known and matches the RSA host key. > debug1: Found key in /home/root/.ssh/known_hosts:15 > debug2: bits set: 483/1024 > debug1: ssh_rsa_verify: signature correct > debug2: kex_derive_keys > debug2: set_newkeys: mode 1 > debug1: SSH2_MSG_NEWKEYS sent > debug1: expecting SSH2_MSG_NEWKEYS > debug2: set_newkeys: mode 0 > debug1: SSH2_MSG_NEWKEYS received > debug1: SSH2_MSG_SERVICE_REQUEST sent > debug2: service_accept: ssh-userauth > debug1: SSH2_MSG_SERVICE_ACCEPT received > debug2: key: auditor_id_rsa (0) > debug1: Authentications that can continue: > publickey,password,keyboard-interactive > debug3: start over, passed a different list > publickey,password,keyboard-interactive > debug3: preferred publickey,keyboard-interactive,password > debug3: authmethod_lookup publickey > debug3: remaining preferred: keyboard-interactive,password > debug3: authmethod_is_enabled publickey > debug1: Next authentication method: publickey > debug1: Trying private key: auditor_id_rsa > debug1: read PEM private key done: type RSA > debug3: sign_and_send_pubkey > debug2: we sent a publickey packet, wait for reply > debug1: Authentication succeeded (publickey). > debug2: fd 5 setting O_NONBLOCK > debug3: fd 6 is O_NONBLOCK > debug1: channel 0: new [client-session] > debug3: ssh_session2_open: channel_new: 0 > debug2: channel 0: send open > debug1: Entering interactive session. > debug2: callback start > debug2: client_session2_setup: id 0 > debug2: channel 0: request pty-req confirm 0 > debug3: tty_make_modes: ospeed 38400 > debug3: tty_make_modes: ispeed 38400 > debug3: tty_make_modes: 1 3 > debug3: tty_make_modes: 2 28 > debug3: tty_make_modes: 3 127 > debug3: tty_make_modes: 4 21 > debug3: tty_make_modes: 5 4 > debug3: tty_make_modes: 6 0 > debug3: tty_make_modes: 7 0 > debug3: tty_make_modes: 8 17 > debug3: tty_make_modes: 9 19 > debug3: tty_make_modes: 10 26 > debug3: tty_make_modes: 11 25 > debug3: tty_make_modes: 12 18 > debug3: tty_make_modes: 13 23 > debug3: tty_make_modes: 14 22 > debug3: tty_make_modes: 16 0 > debug3: tty_make_modes: 18 15 > debug3: tty_make_modes: 30 1 > debug3: tty_make_modes: 31 0 > debug3: tty_make_modes: 32 0 > debug3: tty_make_modes: 33 0 > debug3: tty_make_modes: 34 0 > debug3: tty_make_modes: 35 0 > debug3: tty_make_modes: 36 1 > debug3: tty_make_modes: 37 0 > debug3: tty_make_modes: 38 1 > debug3: tty_make_modes: 39 0 > debug3: tty_make_modes: 40 0 > debug3: tty_make_modes: 41 1 > debug3: tty_make_modes: 50 1 > debug3: tty_make_modes: 51 1 > debug3: tty_make_modes: 52 0 > debug3: tty_make_modes: 53 1 > debug3: tty_make_modes: 54 1 > debug3: tty_make_modes: 55 1 > debug3: tty_make_modes: 56 0 > debug3: tty_make_modes: 57 0 > debug3: tty_make_modes: 58 0 > debug3: tty_make_modes: 59 1 > debug3: tty_make_modes: 60 1 > debug3: tty_make_modes: 61 1 > debug3: tty_make_modes: 62 0 > debug3: tty_make_modes: 70 1 > debug3: tty_make_modes: 71 0 > debug3: tty_make_modes: 72 1 > debug3: tty_make_modes: 73 0 > debug3: tty_make_modes: 74 0 > debug3: tty_make_modes: 75 0 > debug3: tty_make_modes: 90 1 > debug3: tty_make_modes: 91 1 > debug3: tty_make_modes: 92 0 > debug3: tty_make_modes: 93 0 > debug2: channel 0: request shell confirm 0 > debug2: fd 3 setting TCP_NODELAY > debug2: callback done > debug2: channel 0: open confirm rwindow 0 rmax 32768 > debug2: channel 0: rcvd adjust 131072 > Last login: Tue Apr 18 17:44:32 2006 from 192.168.10.10 > > 4) kdc# /usr/pkg/sbin/sshd -D -d -d -d -e > debug2: load_server_config: filename /usr/pkg/etc/ssh/sshd_config > debug2: load_server_config: done config len = 247 > debug2: parse_server_config: config /usr/pkg/etc/ssh/sshd_config len 247 > debug1: sshd version OpenSSH_4.3p1 > debug3: Not a RSA1 key file /usr/pkg/etc/ssh/ssh_host_rsa_key. > debug1: read PEM private key done: type RSA > debug1: private host key: #0 type 1 RSA > debug3: Not a RSA1 key file /usr/pkg/etc/ssh/ssh_host_dsa_key. > debug1: read PEM private key done: type DSA > debug1: private host key: #1 type 2 DSA > debug1: rexec_argv[0]='/usr/pkg/sbin/sshd' > debug1: rexec_argv[1]='-D' > debug1: rexec_argv[2]='-d' > debug1: rexec_argv[3]='-d' > debug1: rexec_argv[4]='-d' > debug1: rexec_argv[5]='-e' > debug2: fd 3 setting O_NONBLOCK > debug1: Bind to port 22 on 172.16.2.11. > Server listening on 172.16.2.11 port 22. > debug2: fd 4 setting O_NONBLOCK > debug1: Bind to port 22 on 10.1.1.11. > Server listening on 10.1.1.11 port 22. > debug2: fd 5 setting O_NONBLOCK > debug1: Bind to port 22 on 192.168.10.11. > Server listening on 192.168.10.11 port 22. > debug1: fd 6 clearing O_NONBLOCK > debug1: Server will not fork when running in debugging mode. > debug3: send_rexec_state: entering fd = 11 config len 247 > debug3: ssh_msg_send: type 0 > debug3: send_rexec_state: done > debug1: rexec start in 6 out 6 newsock 6 pipe -1 sock 11 > debug3: recv_rexec_state: entering fd = 5 > debug3: ssh_msg_recv entering > debug3: recv_rexec_state: done > debug2: parse_server_config: config rexec len 247 > debug1: sshd version OpenSSH_4.3p1 > debug3: Not a RSA1 key file /usr/pkg/etc/ssh/ssh_host_rsa_key. > debug1: read PEM private key done: type RSA > debug1: private host key: #0 type 1 RSA > debug3: Not a RSA1 key file /usr/pkg/etc/ssh/ssh_host_dsa_key. > debug1: read PEM private key done: type DSA > debug1: private host key: #1 type 2 DSA > debug1: inetd sockets after dupping: 3, 3 > Connection from 192.168.10.10 port 8302 > debug1: Client protocol version 2.0; client software version OpenSSH_4.3 > debug1: match: OpenSSH_4.3 pat OpenSSH* > debug1: Enabling compatibility mode for protocol 2.0 > debug1: Local version string SSH-2.0-OpenSSH_4.3 > debug2: fd 3 setting O_NONBLOCK > debug3: privsep user:group 22:22 > debug1: permanently_set_uid: 22/22 > debug1: list_hostkey_types: ssh-rsa,ssh-dss > debug1: SSH2_MSG_KEXINIT sent > debug1: SSH2_MSG_KEXINIT received > debug2: kex_parse_kexinit: > diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 > debug2: kex_parse_kexinit: ssh-rsa,ssh-dss > debug2: kex_parse_kexinit: > aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc, > rijndael-cbc at lysator.liu.se,aes12 > 8-ctr,aes192-ctr,aes256-ctr > debug2: kex_parse_kexinit: > aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc, > rijndael-cbc at lysator.liu.se,aes12 > 8-ctr,aes192-ctr,aes256-ctr > debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160, > hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 > debug2: kex_parse_kexinit: > hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 > debug2: kex_parse_kexinit: none,zlib at openssh.com > debug2: kex_parse_kexinit: none,zlib at openssh.com > debug2: kex_parse_kexinit: > debug2: kex_parse_kexinit: > debug2: kex_parse_kexinit: first_kex_follows 0 > debug2: kex_parse_kexinit: reserved 0 > debug2: kex_parse_kexinit: > diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 > debug2: kex_parse_kexinit: ssh-rsa,ssh-dss > debug2: kex_parse_kexinit: > aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se,aes12 > 8-ctr,aes192-ctr,aes256-ctr > debug2: kex_parse_kexinit: > aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se,aes12 > 8-ctr,aes192-ctr,aes256-ctr > debug2: kex_parse_kexinit: > hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 > debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160, > hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 > debug2: kex_parse_kexinit: none,zlib at openssh.com,zlib > debug2: kex_parse_kexinit: none, zlib at openssh.com,zlib > debug2: kex_parse_kexinit: > debug2: kex_parse_kexinit: > debug2: kex_parse_kexinit: first_kex_follows 0 > debug2: kex_parse_kexinit: reserved 0 > debug2: mac_init: found hmac-md5 > debug1: kex: client->server aes128-cbc hmac-md5 none > debug2: mac_init: found hmac-md5 > debug1: kex: server->client aes128-cbc hmac-md5 none > debug2: Network child is on pid 16691 > debug3: preauth child monitor started > debug3: mm_request_receive entering > debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received > debug3: mm_request_send entering: type 0 > debug3: mm_choose_dh: waiting for MONITOR_ANS_MODULI > debug3: mm_request_receive_expect entering: type 1 > debug3: mm_request_receive entering > debug3: monitor_read: checking request 0 > debug3: mm_answer_moduli: got parameters: 1024 1024 8192 > debug3: mm_request_send entering: type 1 > debug3: mm_choose_dh: remaining 0 > debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent > debug2: dh_gen_key: priv key bits set: 135/256 > debug2: bits set: 518/1024 > debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT > debug2: monitor_read: 0 used once, disabling now > debug3: mm_request_receive entering > debug2: bits set: 547/1024 > debug3: mm_key_sign entering > debug3: mm_request_send entering: type 4 > debug3: mm_key_sign: waiting for MONITOR_ANS_SIGN > debug3: mm_request_receive_expect entering: type 5 > debug3: mm_request_receive entering > debug3: monitor_read: checking request 4 > debug3: mm_answer_sign > debug3: mm_answer_sign: signature 80c7860(271) > debug3: mm_request_send entering: type 5 > debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent > debug2: kex_derive_keys > debug2: set_newkeys: mode 1 > debug1: SSH2_MSG_NEWKEYS sent > debug1: expecting SSH2_MSG_NEWKEYS > debug2: monitor_read: 4 used once, disabling now > debug3: mm_request_receive entering > debug2: set_newkeys: mode 0 > debug1: SSH2_MSG_NEWKEYS received > debug1: KEX done > debug1: userauth-request for user root service ssh-connection method none > debug1: attempt 0 failures 0 > debug3: mm_getpwnamallow entering > debug3: mm_request_send entering: type 6 > debug3: mm_getpwnamallow: waiting for MONITOR_ANS_PWNAM > debug3: mm_request_receive_expect entering: type 7 > debug3: mm_request_receive entering > debug3: monitor_read: checking request 6 > debug3: mm_answer_pwnamallow > debug3: auth_shadow_acctexpired: today 13256 sp_expire -1 days left -13257 > debug3: account expiration disabled > debug3: mm_answer_pwnamallow: sending MONITOR_ANS_PWNAM: 1 > debug3: mm_request_send entering: type 7 > debug2: input_userauth_request: setting up authctxt for root > debug3: mm_inform_authserv entering > debug3: mm_request_send entering: type 3 > debug2: input_userauth_request: try method none > debug3: mm_auth_password entering > debug3: mm_request_send entering: type 10 > debug3: mm_auth_password: waiting for MONITOR_ANS_AUTHPASSWORD > debug3: mm_request_receive_expect entering: type 11 > debug3: mm_request_receive entering > debug2: monitor_read: 6 used once, disabling now > debug3: mm_request_receive entering > debug3: monitor_read: checking request 3 > debug3: mm_answer_authserv: service=ssh-connection, style= > debug2: monitor_read: 3 used once, disabling now > debug3: mm_request_receive entering > debug3: monitor_read: checking request 10 > debug3: mm_answer_authpassword: sending result 0 > debug3: mm_request_send entering: type 11 > debug3: mm_auth_password: user not authenticated > Failed none for root from 192.168.10.10 port 8302 ssh2 > Failed none for root from 192.168.10.10 port 8302 ssh2 > debug3: mm_request_receive entering > debug1: userauth-request for user root service ssh-connection method publickey > debug1: attempt 1 failures 1 > debug2: input_userauth_request: try method publickey > debug3: mm_key_allowed entering > debug3: mm_request_send entering: type 20 > debug3: mm_key_allowed: waiting for MONITOR_ANS_KEYALLOWED > debug3: mm_request_receive_expect entering: type 21 > debug3: mm_request_receive entering > debug3: monitor_read: checking request 20 > debug3: mm_answer_keyallowed entering > debug3: mm_answer_keyallowed: key_from_blob: 80c0510 > debug1: temporarily_use_uid: 0/1 (e=0/1) > debug1: trying public key file /home/root/.ssh/authorized_keys > debug3: secure_filename: checking '/home/root/.ssh' > debug3: secure_filename: checking '/home/root' > debug3: secure_filename: terminating check at '/home/root' > debug1: matching key found: file /home/root/.ssh/authorized_keys, line 1 > Found matching RSA key: 36:55:cf:41:48:e0:d5:71:f4:34:95:b9:da:72:65:a6 > debug1: restore_uid: 0/1 > debug3: mm_answer_keyallowed: key 80c0510 is allowed > debug3: mm_request_send entering: type 21 > debug3: mm_key_verify entering > debug3: mm_request_send entering: type 22 > debug3: mm_key_verify: waiting for MONITOR_ANS_KEYVERIFY > debug3: mm_request_receive_expect entering: type 23 > debug3: mm_request_receive entering > debug3: mm_request_receive entering > debug3: monitor_read: checking request 22 > debug1: ssh_rsa_verify: signature correct > debug3: mm_answer_keyverify: key 80c04b0 signature verified > debug3: mm_request_send entering: type 23 > debug2: userauth_pubkey: authenticated 1 pkalg ssh-rsa > Accepted publickey for root from 192.168.10.10 port 8302 ssh2 > debug3: mm_send_keystate: Sending new keys: 80be778 80c7a88 > debug3: mm_newkeys_to_blob: converting 80be778 > debug3: mm_newkeys_to_blob: converting 80c7a88 > debug3: mm_send_keystate: New keys have been sent > debug3: mm_send_keystate: Sending compression state > debug3: mm_request_send entering: type 24 > debug3: mm_send_keystate: Finished sending state > Accepted publickey for root from 192.168.10.10 port 8302 ssh2 > debug1: monitor_child_preauth: root has been authenticated by privileged process > debug3: mm_get_keystate: Waiting for new keys > debug3: mm_request_receive_expect entering: type 24 > debug3: mm_request_receive entering > debug3: mm_newkeys_from_blob: 80c7860(118) > debug2: mac_init: found hmac-md5 > debug3: mm_get_keystate: Waiting for second key > debug3: mm_newkeys_from_blob: 80c7860(118) > debug2: mac_init: found hmac-md5 > debug3: mm_get_keystate: Getting compression state > debug3: mm_get_keystate: Getting Network I/O buffers > debug3: mm_share_sync: Share sync > debug3: mm_share_sync: Share sync end > debug2: set_newkeys: mode 0 > debug2: set_newkeys: mode 1 > debug1: Entering interactive session for SSH2. > debug2: fd 4 setting O_NONBLOCK > debug2: fd 5 setting O_NONBLOCK > debug1: server_init_dispatch_20 > debug1: server_input_channel_open: ctype session rchan 0 win 65536 max 16384 > debug1: input_session_request > debug1: channel 0: new [server-session] > debug1: session_new: init > debug1: session_new: session 0 > debug1: session_open: channel 0 > debug1: session_open: session 0: link with channel 0 > debug1: server_input_channel_open: confirm session > debug1: server_input_channel_req: channel 0 request pty-req reply 0 > debug1: session_by_channel: session 0 channel 0 > debug1: session_input_channel_req: session 0 req pty-req > debug1: Allocating pty. > debug1: session_pty_req: session 0 alloc /dev/pts/1 > debug3: tty_parse_modes: SSH2 n_bytes 266 > debug3: tty_parse_modes: ospeed 38400 > debug3: tty_parse_modes: ispeed 38400 > debug3: tty_parse_modes: 1 3 > debug3: tty_parse_modes: 2 28 > debug3: tty_parse_modes: 3 127 > debug3: tty_parse_modes: 4 21 > debug3: tty_parse_modes: 5 4 > debug3: tty_parse_modes: 6 0 > debug3: tty_parse_modes: 7 0 > debug3: tty_parse_modes: 8 17 > debug3: tty_parse_modes: 9 19 > debug3: tty_parse_modes: 10 26 > debug3: tty_parse_modes: 11 25 > debug3: tty_parse_modes: 12 18 > debug3: tty_parse_modes: 13 23 > debug3: tty_parse_modes: 14 22 > debug3: tty_parse_modes: 16 0 > debug3: tty_parse_modes: 18 15 > debug3: tty_parse_modes: 30 1 > debug3: tty_parse_modes: 31 0 > debug3: tty_parse_modes: 32 0 > debug3: tty_parse_modes: 33 0 > debug3: tty_parse_modes: 34 0 > debug3: tty_parse_modes: 35 0 > debug3: tty_parse_modes: 36 1 > debug3: tty_parse_modes: 37 0 > debug3: tty_parse_modes: 38 1 > debug3: tty_parse_modes: 39 0 > debug3: tty_parse_modes: 40 0 > debug3: tty_parse_modes: 41 1 > debug3: tty_parse_modes: 50 1 > debug3: tty_parse_modes: 51 1 > debug3: tty_parse_modes: 52 0 > debug3: tty_parse_modes: 53 1 > debug3: tty_parse_modes: 54 1 > debug3: tty_parse_modes: 55 1 > debug3: tty_parse_modes: 56 0 > debug3: tty_parse_modes: 57 0 > debug3: tty_parse_modes: 58 0 > debug3: tty_parse_modes: 59 1 > debug3: tty_parse_modes: 60 1 > debug3: tty_parse_modes: 61 1 > debug3: tty_parse_modes: 62 0 > debug3: tty_parse_modes: 70 1 > debug3: tty_parse_modes: 71 0 > debug3: tty_parse_modes: 72 1 > debug3: tty_parse_modes: 73 0 > debug3: tty_parse_modes: 74 0 > debug3: tty_parse_modes: 75 0 > debug3: tty_parse_modes: 90 1 > debug3: tty_parse_modes: 91 1 > debug3: tty_parse_modes: 92 0 > debug3: tty_parse_modes: 93 0 > debug1: server_input_channel_req: channel 0 request shell reply 0 > debug1: session_by_channel: session 0 channel 0 > debug1: session_input_channel_req: session 0 req shell > debug2: fd 3 setting TCP_NODELAY > debug2: fd 7 setting O_NONBLOCK > debug3: fd 6 is O_NONBLOCK > debug1: Received SIGCHLD. > debug1: session_by_pid: pid 16693 > debug1: session_exit_message: session 0 channel 0 pid 16693 > debug2: channel 0: request exit-status confirm 0 > debug1: session_exit_message: release channel 0 > debug2: channel 0: write failed > debug2: channel 0: close_write > debug2: channel 0: output open -> closed > debug1: session_pty_cleanup: session 0 release /dev/pts/1 > debug2: notify_done: reading > debug2: channel 0: read<=0 rfd 7 len 0 > debug2: channel 0: read failed > debug2: channel 0: close_read > debug2: channel 0: input open -> drain > debug2: channel 0: ibuf empty > debug2: channel 0: send eof > debug2: channel 0: input drain -> closed > debug2: channel 0: send close > debug3: channel 0: will not send data after close > debug2: channel 0: rcvd close > debug3: channel 0: will not send data after close > debug2: channel 0: is dead > debug2: channel 0: gc: notify user > debug1: session_by_channel: session 0 channel 0 > debug1: session_close_by_channel: channel 0 child 0 > debug1: session_close: session 0 pid 0 > debug2: channel 0: gc: user detached > debug2: channel 0: is dead > debug2: channel 0: garbage collecting > debug1: channel 0: free: server-session, nchannels 1 > debug3: channel 0: status: The following connections are open: > #0 server-session (t4 r0 i3/0 o3/0 fd -1/-1 cfd -1) > > debug3: channel 0: close_fds r -1 w -1 e -1 c -1 > Connection closed by 192.168.10.10 > debug1: do_cleanup > Closing connection to 192.168.10.10 > > > -- > Truly yours, Mikhail Manuilov > > Reply Forward > > > > TMDA daemon > This message was created automatically by mail > delivery software (TMDA). Your... > 1:55 pm (37 minutes ago) > > Mikhail Manuylov > ---------- Forwarded message ---------- From: "Mikhail Manuylov" 2:20 pm (12 minutes ago) > > TMDA daemon > Your confirmation was accepted, and so your original message has been delivered. > 2:20 pm (12 minutes ago) > > Mail Delivery System > to me > More options 2:21 pm (12 minutes ago) > This is the Postfix program at host mail.mindrot.org. > > I'm sorry to have to inform you that your message could not > be delivered to one or more recipients. It's attached below. > > For further assistance, please send mail to > > If you do so, please include this problem report. You can > delete your own text from the attached returned message. > > The Postfix program > > (expanded from ): > permission denied. Command output: The message that you sent to > openssh-unix-dev looks like HTML. HTML mail to openssh-unix-dev is not > permitted. Please resend your message as plain text. procmail: Error while > writing to "/etc/postfix/htmltrap.sh" > > > Final-Recipient: rfc822; openssh-unix-dev-tmda at mindrot.org > Original-Recipient: rfc822; openssh-unix-dev-tmda > Action: failed > Status: 5.0.0 > Diagnostic-Code: X-Postfix; permission denied. Command output: The message > that you sent to openssh-unix-dev looks like HTML. HTML mail to > openssh-unix-dev is not permitted. Please resend your message as plain > text. procmail: Error while writing to "/etc/postfix/htmltrap.sh" > > > > ---------- Forwarded message ---------- > From: "Mikhail Manuylov" > To: openssh-unix-dev at mindrot.org > Date: Fri, 21 Apr 2006 13:55:34 +0400 > Subject: Solaris 8 x86 rsa pubkey auth problem > Hello, > > I got some weird problem with public key authentication using rsa key pair. > > Let me first of all explain my setup. > > 1) I got two Solaris 8 x86 boxes > uname -a > SunOS 5.8 Generic_117351-24 i86pc i386 i86pc > > <---> > > 2) They're running absolutely identical openssh installations > I'm using pkgsrc, so I've builded all necessary packages from two days > old pkgsrc sources > on one of the boxes and installed the same binaries on second > OpenSSH_4.3p1, OpenSSL 0.9.7i 14 Oct 2005 > > 3) The only differense in their setup is that 'kdc' is a intel p4 boxm > and module is p3 box. > > I've generated rsa key pair via ssh-keygen, and placed public part of > it into /home/root/.ssh/authorized_keys > on both computers. > > The problem: > > I can't log into any (not only to module) computer running the same > version of sshd (and of course user holding the same public key) > using 'kdc', pubkey athentication fails and ssh pops password prompt > up. Pubkey athentication with that key works flawlessly with any > other direction even when 'module' connecting to 'kdc'. > > How I can help debugging this problem: > > I've supplied debug output of both ssh and sshd from two cases: > 1) 'module' authenticating on 'kdc' ( works ok ) > 2) 'kdc' authenticating on 'module' ( pubkey failed ) > > I've already compiled gdb and openssh with debug info. I've also > started two debug sshd yesterday, but due two my not so cool knowledge > of > openssh sources and maybe schema of forking and privelege separation I > still can't reach user_key_allowed function. > > Thank you for your great work. And thanks for help beforehand. > > Here's debug output: > > 1) kdc# ssh -vvv -i ~/.ssh/auditor_rsa_id root at 192.168.10.10 > OpenSSH_4.3p1, OpenSSL 0.9.7i 14 Oct 2005 > debug1: Reading configuration data /usr/pkg/etc/ssh/ssh_config > debug2: ssh_connect: needpriv 0 > debug1: Connecting to 192.168.10.10 [ 192.168.10.10] port 22. > debug1: Connection established. > debug1: permanently_set_uid: 0/1 > debug3: Not a RSA1 key file auditor_id_rsa. > debug2: key_type_from_name: unknown key type '-----BEGIN' > debug3: key_read: missing keytype > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug2: key_type_from_name: unknown key type '-----END' > debug3: key_read: missing keytype > debug1: identity file auditor_id_rsa type 2 > debug1: Remote protocol version 2.0 , remote software version OpenSSH_4.3 > debug1: match: OpenSSH_4.3 pat OpenSSH* > debug1: Enabling compatibility mode for protocol 2.0 > debug1: Local version string SSH-2.0-OpenSSH_4.3 > debug2: fd 3 setting O_NONBLOCK > debug1: SSH2_MSG_KEXINIT sent > debug1: SSH2_MSG_KEXINIT received > debug2: kex_parse_kexinit: > diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 > debug2: kex_parse_kexinit: ssh-rsa,ssh-dss > debug2: kex_parse_kexinit: > aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se,aes12 > 8-ctr,aes192-ctr,aes256-ctr > debug2: kex_parse_kexinit: > aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se,aes12 > 8-ctr,aes192-ctr,aes256-ctr > debug2: kex_parse_kexinit: > hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 > debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160, > hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 > debug2: kex_parse_kexinit: none,zlib at openssh.com,zlib > debug2: kex_parse_kexinit: none, zlib at openssh.com,zlib > debug2: kex_parse_kexinit: > debug2: kex_parse_kexinit: > debug2: kex_parse_kexinit: first_kex_follows 0 > debug2: kex_parse_kexinit: reserved 0 > debug2: kex_parse_kexinit: > diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 > debug2: kex_parse_kexinit: ssh-rsa,ssh-dss > debug2: kex_parse_kexinit: > aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se > ,aes12 > 8-ctr,aes192-ctr,aes256-ctr > debug2: kex_parse_kexinit: > aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes > > -- > Truly yours, Mikhail Manuilov > -- Truly yours, Mikhail Manuilov From markus.r.friedl at arcor.de Thu May 4 05:14:37 2006 From: markus.r.friedl at arcor.de (Markus Friedl) Date: Wed, 3 May 2006 21:14:37 +0200 Subject: Solaris 8 x86 rsa pubkey auth problem In-Reply-To: <7ec6def90605031016y23176fadr8fdd59461b235a0c@mail.gmail.com> References: <7ec6def90604210335s5ad03dc4s811fe4a66a8a32c4@mail.gmail.com> <7ec6def90605031016y23176fadr8fdd59461b235a0c@mail.gmail.com> Message-ID: <20060503191436.GA14907@folly> On Wed, May 03, 2006 at 09:16:58PM +0400, Mikhail Manuylov wrote: > What is the reason of trying to find public key and offering it to > authenticate? This somewhat ridicule, i suppose... the private key is encrypted, so you would have to enter the passphrase even if the key will not be allowed. From jbug at ednixon.com Thu May 4 05:41:35 2006 From: jbug at ednixon.com (jbug at ednixon.com) Date: Wed, 3 May 2006 12:41:35 -0700 (PDT) Subject: BUG: opens all interfaces. Message-ID: <200605031941.k43JfZ1t044533@idiom.com> Summary: the newish fourth forwarding argument does not correctly specify the interface on the remote machine for a tunnel in -R On OpenSSH_4.3p2 OpenSSL 0.9.7g 11 Apr 2005, on Kanotix 2.9 kernel 2.6.16.2 and Cygwin 1.5.19(0.150/4/2) and (old) FreeBSD 4.6-RELEASE sshd_config file: AllowTcpForwarding yes GatewayPorts yes Set up a forwarding tunnel: From a Kanotix box inside my firewall: ssh me at public.com -R public.com:3120:localhost:22 From other.com ssh -o 'UserKnownHostsFile /home/me/.ssh/alt1' -p 3120 gus at public.com note that "gus" is a user on my Kanotix box. The host key does not come from public.com, so I have to specify an alternate knownhosts file. sshd or ssh is still broken, you can't specify other than localhost or everyone in the universe for the receiving address; the -R public.com works as what's documented to be '*', all interfaces on the machine. (lsof) sshd 73447 root 4u IPv4 0xd5b3c280 0t0 TCP *:rsh-spx (LISTEN) and connecting from other.com ssh -o 'UserKnownHostsFile /home/me/.ssh/alt1' -p 3120 gus at public-second-ip.com succeeds, where only public.com was specified in the initial tunnel, and not the documented '*'. General comment: The histrionics about "consult all documentation before reporting a bug" could be remedied by accepting a mid-grade level of volunteers who preen through bug reports for the ones that are truly new and valid. They can request reporters to do further tests, and so on, before actually contacting the first line developers. More bugs will get reported more quickly, even if with a bit of redundancy, if you remove the emotional insularity toward reporting; while the first-line developers don't get overloaded, by using intermediaries. BTW, building this on FreeBSD 4.6-RELEASE resulted in several complaints of the form: (though, it built, and appears to work.) checking net/if_tap.h usability... no checking net/if_tap.h presence... yes configure: WARNING: net/if_tap.h: present but cannot be compiled configure: WARNING: net/if_tap.h: check for missing prerequisite headers? configure: WARNING: net/if_tap.h: see the Autoconf documentation configure: WARNING: net/if_tap.h: section "Present But Cannot Be Compiled" configure: WARNING: net/if_tap.h: proceeding with the preprocessor's result configure: WARNING: net/if_tap.h: in the future, the compiler will take preceden ce configure: WARNING: ## ------------------------------------------- ## configure: WARNING: ## Report this to openssh-unix-dev at mindrot.org ## configure: WARNING: ## ------------------------------------------- ## checking for net/if_tap.h... yes checking login_cap.h usability... no checking login_cap.h presence... yes configure: WARNING: login_cap.h: present but cannot be compiled configure: WARNING: login_cap.h: check for missing prerequisite headers? configure: WARNING: login_cap.h: see the Autoconf documentation configure: WARNING: login_cap.h: section "Present But Cannot Be Compiled" configure: WARNING: login_cap.h: proceeding with the preprocessor's result configure: WARNING: login_cap.h: in the future, the compiler will take precedenc e configure: WARNING: ## ------------------------------------------- ## configure: WARNING: ## Report this to openssh-unix-dev at mindrot.org ## configure: WARNING: ## ------------------------------------------- ## checking for login_cap.h... yes checking sys/mman.h usability... no checking sys/mman.h presence... yes configure: WARNING: sys/mman.h: present but cannot be compiled configure: WARNING: sys/mman.h: check for missing prerequisite headers? configure: WARNING: sys/mman.h: see the Autoconf documentation configure: WARNING: sys/mman.h: section "Present But Cannot Be Compiled" configure: WARNING: sys/mman.h: proceeding with the preprocessor's result configure: WARNING: sys/mman.h: in the future, the compiler will take precedence configure: WARNING: ## ------------------------------------------- ## configure: WARNING: ## Report this to openssh-unix-dev at mindrot.org ## configure: WARNING: ## ------------------------------------------- ## checking for sys/mman.h... yes checking sys/select.h usability... no checking sys/select.h presence... yes configure: WARNING: sys/select.h: present but cannot be compiled configure: WARNING: sys/select.h: check for missing prerequisite headers? configure: WARNING: sys/select.h: see the Autoconf documentation configure: WARNING: sys/select.h: section "Present But Cannot Be Compiled" configure: WARNING: sys/select.h: proceeding with the preprocessor's result configure: WARNING: sys/select.h: in the future, the compiler will take preceden ce configure: WARNING: ## ------------------------------------------- ## configure: WARNING: ## Report this to openssh-unix-dev at mindrot.org ## configure: WARNING: ## ------------------------------------------- ## checking for sys/select.h... yes From djm at mindrot.org Thu May 4 08:21:46 2006 From: djm at mindrot.org (Damien Miller) Date: Thu, 4 May 2006 08:21:46 +1000 (EST) Subject: BUG: opens all interfaces. In-Reply-To: <200605031941.k43JfZ1t044533@idiom.com> References: <200605031941.k43JfZ1t044533@idiom.com> Message-ID: On Wed, 3 May 2006, jbug at ednixon.com wrote: > Summary: the newish fourth forwarding argument does not correctly > specify the interface on the remote machine for a tunnel in -R > > On OpenSSH_4.3p2 OpenSSL 0.9.7g 11 Apr 2005, > on Kanotix 2.9 kernel 2.6.16.2 > and Cygwin 1.5.19(0.150/4/2) > and (old) FreeBSD 4.6-RELEASE > > sshd_config file: > AllowTcpForwarding yes > GatewayPorts yes This is wrong. From the manual: > GatewayPorts > Specifies whether remote hosts are allowed to connect to ports > forwarded for the client. By default, sshd(8) binds remote port > forwardings to the loopback address. This prevents other remote > hosts from connecting to forwarded ports. GatewayPorts can be > used to specify that sshd should allow remote port forwardings to > bind to non-loopback addresses, thus allowing other hosts to con- > nect. The argument may be ``no'' to force remote port forward- > ings to be available to the local host only, ``yes'' to force re- > mote port forwardings to bind to the wildcard address, or > ``clientspecified'' to allow the client to select the address to > which the forwarding is bound. The default is ``no''. So you should set: GatewayPorts clientspecified in sshd_config. > General comment: The histrionics about "consult all documentation > before reporting a bug" could be remedied by accepting a mid-grade > level of volunteers who preen through bug reports for the ones > that are truly new and valid. I think you have just proved why those "histrionics" are necessary. -d From dtucker at zip.com.au Thu May 4 12:18:57 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 4 May 2006 12:18:57 +1000 Subject: xmalloc(foo*bar) -> xcalloc(foo, bar) for Portable Message-ID: <20060504021857.GA6236@gate.dtucker.net> Hi All. While wandering in auth-pam.c I noticed that there's a few Portable-specific escapees from the xmalloc(foo * bar) cleanup. There's also a "probably can't happen" integer overflow in ssh-rand-helper.c with the memset: num_cmds = 64; - entcmd = xmalloc(num_cmds * sizeof(entropy_cmd_t)); + entcmd = xcalloc(num_cmds, sizeof(entropy_cmd_t)); memset(entcmd, '\0', num_cmds * sizeof(entropy_cmd_t)); Unless sizeof(entropy_cmd_t) is *really* big, it ought to safe :-) Index: auth-pam.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/auth-pam.c,v retrieving revision 1.132 diff -u -p -r1.132 auth-pam.c --- auth-pam.c 26 Mar 2006 03:22:48 -0000 1.132 +++ auth-pam.c 4 May 2006 01:51:57 -0000 @@ -288,7 +288,7 @@ import_environments(Buffer *b) /* Import environment from subprocess */ num_env = buffer_get_int(b); - sshpam_env = xmalloc((num_env + 1) * sizeof(*sshpam_env)); + sshpam_env = xcalloc(num_env + 1, sizeof(*sshpam_env)); debug3("PAM: num env strings %d", num_env); for(i = 0; i < num_env; i++) sshpam_env[i] = buffer_get_string(b, NULL); Index: groupaccess.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/groupaccess.c,v retrieving revision 1.10 diff -u -p -r1.10 groupaccess.c --- groupaccess.c 26 Mar 2006 03:24:49 -0000 1.10 +++ groupaccess.c 4 May 2006 01:56:11 -0000 @@ -52,8 +52,8 @@ ga_init(const char *user, gid_t base) ngroups = MAX(NGROUPS_MAX, sysconf(_SC_NGROUPS_MAX)); #endif - groups_bygid = xmalloc(ngroups * sizeof(*groups_bygid)); - groups_byname = xmalloc(ngroups * sizeof(*groups_byname)); + groups_bygid = xcalloc(ngroups, sizeof(*groups_bygid)); + groups_byname = xcalloc(ngroups, sizeof(*groups_byname)); if (getgrouplist(user, base, groups_bygid, &ngroups) == -1) logit("getgrouplist: groups list too small"); Index: monitor.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/monitor.c,v retrieving revision 1.102 diff -u -p -r1.102 monitor.c --- monitor.c 31 Mar 2006 12:14:24 -0000 1.102 +++ monitor.c 4 May 2006 01:56:40 -0000 @@ -924,7 +924,7 @@ mm_answer_pam_respond(int sock, Buffer * sshpam_authok = NULL; num = buffer_get_int(m); if (num > 0) { - resp = xmalloc(num * sizeof(char *)); + resp = xcalloc(num, sizeof(char *)); for (i = 0; i < num; ++i) resp[i] = buffer_get_string(m, NULL); ret = (sshpam_device.respond)(sshpam_ctxt, num, resp); Index: monitor_wrap.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/monitor_wrap.c,v retrieving revision 1.59 diff -u -p -r1.59 monitor_wrap.c --- monitor_wrap.c 31 Mar 2006 12:13:02 -0000 1.59 +++ monitor_wrap.c 4 May 2006 01:57:46 -0000 @@ -776,8 +776,8 @@ mm_sshpam_query(void *ctx, char **name, *name = buffer_get_string(&m, NULL); *info = buffer_get_string(&m, NULL); *num = buffer_get_int(&m); - *prompts = xmalloc((*num + 1) * sizeof(char *)); - *echo_on = xmalloc((*num + 1) * sizeof(u_int)); + *prompts = xcalloc((*num + 1), sizeof(char *)); + *echo_on = xcalloc((*num + 1), sizeof(u_int)); for (i = 0; i < *num; ++i) { (*prompts)[i] = buffer_get_string(&m, NULL); (*echo_on)[i] = buffer_get_int(&m); Index: scard-opensc.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/scard-opensc.c,v retrieving revision 1.15 diff -u -p -r1.15 scard-opensc.c --- scard-opensc.c 13 May 2004 07:29:35 -0000 1.15 +++ scard-opensc.c 4 May 2006 01:58:41 -0000 @@ -455,7 +455,7 @@ sc_get_keys(const char *id, const char * } key_count = r; } - keys = xmalloc(sizeof(Key *) * (key_count*2+1)); + keys = xcalloc(key_count * 2 + 1, sizeof(Key *)); for (i = 0; i < key_count; i++) { sc_pkcs15_object_t *tmp_obj = NULL; cert_id = ((sc_pkcs15_cert_info_t *)(certs[i]->data))->id; Index: session.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/session.c,v retrieving revision 1.327 diff -u -p -r1.327 session.c --- session.c 23 Apr 2006 02:10:49 -0000 1.327 +++ session.c 4 May 2006 01:59:13 -0000 @@ -984,7 +984,7 @@ do_setup_env(Session *s, const char *she /* Initialize the environment. */ envsize = 100; - env = xmalloc(envsize * sizeof(char *)); + env = xcalloc(envsize, sizeof(char *)); env[0] = NULL; #ifdef HAVE_CYGWIN Index: ssh-rand-helper.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/ssh-rand-helper.c,v retrieving revision 1.29 diff -u -p -r1.29 ssh-rand-helper.c --- ssh-rand-helper.c 26 Mar 2006 03:22:48 -0000 1.29 +++ ssh-rand-helper.c 4 May 2006 02:01:13 -0000 @@ -674,7 +674,7 @@ prng_read_commands(char *cmdfilename) } num_cmds = 64; - entcmd = xmalloc(num_cmds * sizeof(entropy_cmd_t)); + entcmd = xcalloc(num_cmds, sizeof(entropy_cmd_t)); memset(entcmd, '\0', num_cmds * sizeof(entropy_cmd_t)); /* Read in file */ Index: sshd.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/sshd.c,v retrieving revision 1.333 diff -u -p -r1.333 sshd.c --- sshd.c 26 Mar 2006 03:24:50 -0000 1.333 +++ sshd.c 4 May 2006 02:01:50 -0000 @@ -921,7 +921,7 @@ main(int ac, char **av) /* Save argv. Duplicate so setproctitle emulation doesn't clobber it */ saved_argc = ac; rexec_argc = ac; - saved_argv = xmalloc(sizeof(*saved_argv) * (ac + 1)); + saved_argv = xcalloc(ac + 1, sizeof(*saved_argv)); for (i = 0; i < ac; i++) saved_argv[i] = xstrdup(av[i]); saved_argv[i] = NULL; Index: openbsd-compat/bsd-cygwin_util.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/openbsd-compat/bsd-cygwin_util.c,v retrieving revision 1.16 diff -u -p -r1.16 bsd-cygwin_util.c --- openbsd-compat/bsd-cygwin_util.c 25 Mar 2006 13:03:24 -0000 1.16 +++ openbsd-compat/bsd-cygwin_util.c 4 May 2006 02:02:57 -0000 @@ -268,7 +268,7 @@ fetch_windows_environment(void) char **e, **p; unsigned int i, idx = 0; - p = xmalloc((WENV_SIZ + 1) * sizeof(char *)); + p = xcalloc(WENV_SIZ + 1, sizeof(char *)); for (e = environ; *e != NULL; ++e) { for (i = 0; i < WENV_SIZ; ++i) { if (!strncmp(*e, wenv_arr[i].name, wenv_arr[i].namelen)) -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From dtucker at zip.com.au Thu May 4 12:35:39 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 4 May 2006 12:35:39 +1000 Subject: xmalloc(foo*bar) -> xcalloc(foo, bar) for Portable In-Reply-To: <20060504021857.GA6236@gate.dtucker.net> References: <20060504021857.GA6236@gate.dtucker.net> Message-ID: <20060504023539.GA17041@gate.dtucker.net> On Thu, May 04, 2006 at 12:18:57PM +1000, Darren Tucker wrote: > While wandering in auth-pam.c I noticed that there's a few Portable-specific > escapees from the xmalloc(foo * bar) cleanup. My grep for xmalloc missed a couple of bare mallocs, new patch below. > There's also a "probably can't happen" integer overflow in > ssh-rand-helper.c with the memset: > > num_cmds = 64; > - entcmd = xmalloc(num_cmds * sizeof(entropy_cmd_t)); > + entcmd = xcalloc(num_cmds, sizeof(entropy_cmd_t)); > memset(entcmd, '\0', num_cmds * sizeof(entropy_cmd_t)); > > Unless sizeof(entropy_cmd_t) is *really* big, it ought to safe :-) Looking at xcalloc I see it's always safe since it will abort on overflow. The memset is redundant, though, since calloc zeros and there's a few similar. Zap 'em? Index: auth-pam.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/auth-pam.c,v retrieving revision 1.132 diff -u -p -r1.132 auth-pam.c --- auth-pam.c 26 Mar 2006 03:22:48 -0000 1.132 +++ auth-pam.c 4 May 2006 02:26:39 -0000 @@ -288,7 +288,7 @@ import_environments(Buffer *b) /* Import environment from subprocess */ num_env = buffer_get_int(b); - sshpam_env = xmalloc((num_env + 1) * sizeof(*sshpam_env)); + sshpam_env = xcalloc(num_env + 1, sizeof(*sshpam_env)); debug3("PAM: num env strings %d", num_env); for(i = 0; i < num_env; i++) sshpam_env[i] = buffer_get_string(b, NULL); @@ -335,7 +335,7 @@ sshpam_thread_conv(int n, sshpam_const s if (n <= 0 || n > PAM_MAX_NUM_MSG) return (PAM_CONV_ERR); - if ((reply = malloc(n * sizeof(*reply))) == NULL) + if ((reply = calloc(n, sizeof(*reply))) == NULL) return (PAM_CONV_ERR); memset(reply, 0, n * sizeof(*reply)); @@ -533,7 +533,7 @@ sshpam_store_conv(int n, sshpam_const st if (n <= 0 || n > PAM_MAX_NUM_MSG) return (PAM_CONV_ERR); - if ((reply = malloc(n * sizeof(*reply))) == NULL) + if ((reply = calloc(n, sizeof(*reply))) == NULL) return (PAM_CONV_ERR); memset(reply, 0, n * sizeof(*reply)); @@ -935,7 +935,7 @@ sshpam_tty_conv(int n, sshpam_const stru if (n <= 0 || n > PAM_MAX_NUM_MSG || !isatty(STDIN_FILENO)) return (PAM_CONV_ERR); - if ((reply = malloc(n * sizeof(*reply))) == NULL) + if ((reply = calloc(n, sizeof(*reply))) == NULL) return (PAM_CONV_ERR); memset(reply, 0, n * sizeof(*reply)); Index: groupaccess.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/groupaccess.c,v retrieving revision 1.10 diff -u -p -r1.10 groupaccess.c --- groupaccess.c 26 Mar 2006 03:24:49 -0000 1.10 +++ groupaccess.c 4 May 2006 01:56:11 -0000 @@ -52,8 +52,8 @@ ga_init(const char *user, gid_t base) ngroups = MAX(NGROUPS_MAX, sysconf(_SC_NGROUPS_MAX)); #endif - groups_bygid = xmalloc(ngroups * sizeof(*groups_bygid)); - groups_byname = xmalloc(ngroups * sizeof(*groups_byname)); + groups_bygid = xcalloc(ngroups, sizeof(*groups_bygid)); + groups_byname = xcalloc(ngroups, sizeof(*groups_byname)); if (getgrouplist(user, base, groups_bygid, &ngroups) == -1) logit("getgrouplist: groups list too small"); Index: monitor.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/monitor.c,v retrieving revision 1.102 diff -u -p -r1.102 monitor.c --- monitor.c 31 Mar 2006 12:14:24 -0000 1.102 +++ monitor.c 4 May 2006 01:56:40 -0000 @@ -924,7 +924,7 @@ mm_answer_pam_respond(int sock, Buffer * sshpam_authok = NULL; num = buffer_get_int(m); if (num > 0) { - resp = xmalloc(num * sizeof(char *)); + resp = xcalloc(num, sizeof(char *)); for (i = 0; i < num; ++i) resp[i] = buffer_get_string(m, NULL); ret = (sshpam_device.respond)(sshpam_ctxt, num, resp); Index: monitor_wrap.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/monitor_wrap.c,v retrieving revision 1.59 diff -u -p -r1.59 monitor_wrap.c --- monitor_wrap.c 31 Mar 2006 12:13:02 -0000 1.59 +++ monitor_wrap.c 4 May 2006 01:57:46 -0000 @@ -776,8 +776,8 @@ mm_sshpam_query(void *ctx, char **name, *name = buffer_get_string(&m, NULL); *info = buffer_get_string(&m, NULL); *num = buffer_get_int(&m); - *prompts = xmalloc((*num + 1) * sizeof(char *)); - *echo_on = xmalloc((*num + 1) * sizeof(u_int)); + *prompts = xcalloc((*num + 1), sizeof(char *)); + *echo_on = xcalloc((*num + 1), sizeof(u_int)); for (i = 0; i < *num; ++i) { (*prompts)[i] = buffer_get_string(&m, NULL); (*echo_on)[i] = buffer_get_int(&m); Index: scard-opensc.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/scard-opensc.c,v retrieving revision 1.15 diff -u -p -r1.15 scard-opensc.c --- scard-opensc.c 13 May 2004 07:29:35 -0000 1.15 +++ scard-opensc.c 4 May 2006 01:58:41 -0000 @@ -455,7 +455,7 @@ sc_get_keys(const char *id, const char * } key_count = r; } - keys = xmalloc(sizeof(Key *) * (key_count*2+1)); + keys = xcalloc(key_count * 2 + 1, sizeof(Key *)); for (i = 0; i < key_count; i++) { sc_pkcs15_object_t *tmp_obj = NULL; cert_id = ((sc_pkcs15_cert_info_t *)(certs[i]->data))->id; Index: session.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/session.c,v retrieving revision 1.327 diff -u -p -r1.327 session.c --- session.c 23 Apr 2006 02:10:49 -0000 1.327 +++ session.c 4 May 2006 01:59:13 -0000 @@ -984,7 +984,7 @@ do_setup_env(Session *s, const char *she /* Initialize the environment. */ envsize = 100; - env = xmalloc(envsize * sizeof(char *)); + env = xcalloc(envsize, sizeof(char *)); env[0] = NULL; #ifdef HAVE_CYGWIN Index: ssh-rand-helper.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/ssh-rand-helper.c,v retrieving revision 1.29 diff -u -p -r1.29 ssh-rand-helper.c --- ssh-rand-helper.c 26 Mar 2006 03:22:48 -0000 1.29 +++ ssh-rand-helper.c 4 May 2006 02:01:13 -0000 @@ -674,7 +674,7 @@ prng_read_commands(char *cmdfilename) } num_cmds = 64; - entcmd = xmalloc(num_cmds * sizeof(entropy_cmd_t)); + entcmd = xcalloc(num_cmds, sizeof(entropy_cmd_t)); memset(entcmd, '\0', num_cmds * sizeof(entropy_cmd_t)); /* Read in file */ Index: sshd.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/sshd.c,v retrieving revision 1.333 diff -u -p -r1.333 sshd.c --- sshd.c 26 Mar 2006 03:24:50 -0000 1.333 +++ sshd.c 4 May 2006 02:01:50 -0000 @@ -921,7 +921,7 @@ main(int ac, char **av) /* Save argv. Duplicate so setproctitle emulation doesn't clobber it */ saved_argc = ac; rexec_argc = ac; - saved_argv = xmalloc(sizeof(*saved_argv) * (ac + 1)); + saved_argv = xcalloc(ac + 1, sizeof(*saved_argv)); for (i = 0; i < ac; i++) saved_argv[i] = xstrdup(av[i]); saved_argv[i] = NULL; Index: openbsd-compat/bsd-cygwin_util.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/openbsd-compat/bsd-cygwin_util.c,v retrieving revision 1.16 diff -u -p -r1.16 bsd-cygwin_util.c --- openbsd-compat/bsd-cygwin_util.c 25 Mar 2006 13:03:24 -0000 1.16 +++ openbsd-compat/bsd-cygwin_util.c 4 May 2006 02:02:57 -0000 @@ -268,7 +268,7 @@ fetch_windows_environment(void) char **e, **p; unsigned int i, idx = 0; - p = xmalloc((WENV_SIZ + 1) * sizeof(char *)); + p = xcalloc(WENV_SIZ + 1, sizeof(char *)); for (e = environ; *e != NULL; ++e) { for (i = 0; i < WENV_SIZ; ++i) { if (!strncmp(*e, wenv_arr[i].name, wenv_arr[i].namelen)) Index: openbsd-compat/fake-rfc2553.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/openbsd-compat/fake-rfc2553.c,v retrieving revision 1.6 diff -u -p -r1.6 fake-rfc2553.c --- openbsd-compat/fake-rfc2553.c 25 Mar 2006 13:03:24 -0000 1.6 +++ openbsd-compat/fake-rfc2553.c 4 May 2006 02:28:30 -0000 @@ -115,7 +115,7 @@ addrinfo *malloc_ai(int port, u_long add { struct addrinfo *ai; - ai = malloc(sizeof(*ai) + sizeof(struct sockaddr_in)); + ai = calloc(sizeof(*ai), sizeof(struct sockaddr_in)); if (ai == NULL) return (NULL); Index: openbsd-compat/setproctitle.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/openbsd-compat/setproctitle.c,v retrieving revision 1.9 diff -u -p -r1.9 setproctitle.c --- openbsd-compat/setproctitle.c 20 Feb 2004 09:38:17 -0000 1.9 +++ openbsd-compat/setproctitle.c 4 May 2006 02:29:03 -0000 @@ -80,7 +80,7 @@ compat_init_setproctitle(int argc, char /* Fail if we can't allocate room for the new environment */ for (i = 0; envp[i] != NULL; i++) ; - if ((environ = malloc(sizeof(*environ) * (i + 1))) == NULL) { + if ((environ = calloc(i + 1, sizeof(*environ))) == NULL) { environ = envp; /* put it back */ return; } -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From dtucker at zip.com.au Thu May 4 13:28:38 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 4 May 2006 13:28:38 +1000 Subject: bug & patch in ServerAliveInterval (openssh 4.3-p2) In-Reply-To: References: Message-ID: <20060504032838.GA2921@gate.dtucker.net> On Sat, Apr 22, 2006 at 08:02:47PM +0300, catamus wrote: > > I have found that ServerAliveInterval & ServerAliveCountMax have > some bug. Basically the ssh-alive check function (that verify the > peer is alive) is called only if no data at all gets into ssh (when it > should work only for server channel).I am pretty sure developers know > about this ..anyway I have tried to fix this issue. Here is the patch: Could you please give an example of the circumstances under which this might happen? Repeatedly banging on the keyboard generating traffic on stdin? I'm not sure the patch is quite right, though. > + if(FD_ISSET(connection_out, *readsetp)) { > + tv.tv_sec = 0; > + tv.tv_usec = 0; This doesn't look right... it's checking if the connection out is readable? Maybe that should be this? if (FD_ISSET(connection_in, *readsetp) || FD_ISSET(connection_out, *writesetp)) -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From mikhail.manuilov at gmail.com Thu May 4 17:11:45 2006 From: mikhail.manuilov at gmail.com (Mikhail Manuylov) Date: Thu, 4 May 2006 11:11:45 +0400 Subject: Solaris 8 x86 rsa pubkey auth problem In-Reply-To: <20060503191436.GA14907@folly> References: <7ec6def90604210335s5ad03dc4s811fe4a66a8a32c4@mail.gmail.com> <7ec6def90605031016y23176fadr8fdd59461b235a0c@mail.gmail.com> <20060503191436.GA14907@folly> Message-ID: <7ec6def90605040011j66fdb749nb87ad4c6f20cdfcd@mail.gmail.com> On 5/3/06, Markus Friedl wrote: > On Wed, May 03, 2006 at 09:16:58PM +0400, Mikhail Manuylov wrote: > > What is the reason of trying to find public key and offering it to > > authenticate? This somewhat ridicule, i suppose... > > the private key is encrypted, so you would have to enter > the passphrase even if the key will not be allowed. > -- Truly yours, Mikhail Manuilov From mikhail.manuilov at gmail.com Thu May 4 17:12:35 2006 From: mikhail.manuilov at gmail.com (Mikhail Manuylov) Date: Thu, 4 May 2006 11:12:35 +0400 Subject: Solaris 8 x86 rsa pubkey auth problem In-Reply-To: <20060503191436.GA14907@folly> References: <7ec6def90604210335s5ad03dc4s811fe4a66a8a32c4@mail.gmail.com> <7ec6def90605031016y23176fadr8fdd59461b235a0c@mail.gmail.com> <20060503191436.GA14907@folly> Message-ID: <7ec6def90605040012g2617168fi45c43286a9477db0@mail.gmail.com> On 5/3/06, Markus Friedl wrote: > On Wed, May 03, 2006 at 09:16:58PM +0400, Mikhail Manuylov wrote: > > What is the reason of trying to find public key and offering it to > > authenticate? This somewhat ridicule, i suppose... > > the private key is encrypted, so you would have to enter > the passphrase even if the key will not be allowed. > Mmm, shure, I know this, but what about public key? I mean I still can't get the idea. -- Truly yours, Mikhail Manuilov From mark.ennis at acm.org Thu May 4 17:22:33 2006 From: mark.ennis at acm.org (Mark Ennis) Date: Thu, 04 May 2006 17:22:33 +1000 Subject: X11 forwarding to IPv6 enabled host not working. Message-ID: <4459ABB9.6000604@acm.org> I have been experiencing a problem with using X11 forwarding on an IPv6 enabled host (both CentOS 4.3 and Feddora Core 5 in x86) when X11UseLocalhost is off. Having looked at the code and the previous discussion regarding http://bugzilla.mindrot.org/show_bug.cgi?id=164 I think the problem is due to the IPV6_V6ONLY code interacting poorly with the DONT_TRY_OTHER_AF hack. Basically, on current Linux systems which support the IPV6_V6ONLY socket option, the forwarded socket is created for IPV6 only and then the DONT_TRY_OTHER_AF prevents an IPV4 listen socket from also being created. Thus, only forwarding X11 connections over IPV6 are then supported. I would recommend addressing this by changing the DONT_TRY_OTHER_AF hack to apply only where the the IPV6_V6ONLY socket option is not supported. For example: diff -r openssh-4.3p2/channels.c openssh-4.3p2-modified/channels.c 2816c2816 < #ifndef DONT_TRY_OTHER_AF --- > #if defined(IPV6_V6ONLY) || !defined(DONT_TRY_OTHER_AF) - Mark. From stuge-openssh-unix-dev at cdy.org Thu May 4 17:48:57 2006 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Thu, 4 May 2006 09:48:57 +0200 Subject: Solaris 8 x86 rsa pubkey auth problem In-Reply-To: <7ec6def90605040012g2617168fi45c43286a9477db0@mail.gmail.com> References: <7ec6def90604210335s5ad03dc4s811fe4a66a8a32c4@mail.gmail.com> <7ec6def90605031016y23176fadr8fdd59461b235a0c@mail.gmail.com> <20060503191436.GA14907@folly> <7ec6def90605040012g2617168fi45c43286a9477db0@mail.gmail.com> Message-ID: <20060504074858.10644.qmail@cdy.org> On Thu, May 04, 2006 at 11:12:35AM +0400, Mikhail Manuylov wrote: > On 5/3/06, Markus Friedl wrote: > > > > the private key is encrypted, so you would have to enter > > the passphrase even if the key will not be allowed. > > Mmm, shure, I know this, but what about public key? I mean I still > can't get the idea. 1. sshd has a list of approved public keys. 2. ssh sends one public key to the server at a time. 3. sshd tells ssh that a key is usable for authentication. 4. ssh now needs access to the corresponding private key and the user has to enter the passphrase. If ssh didn't read the public key in (2) the user would have to enter the passphrase for any and all private keys available to ssh, not just the one that would be used for actually authenticating the user. Check out ssh -vvv when authenticating with keys. grep for publickey. //Peter From gogu at l.route666.net Thu May 4 17:59:48 2006 From: gogu at l.route666.net (catamus) Date: Thu, 4 May 2006 10:59:48 +0300 (EEST) Subject: bug & patch in ServerAliveInterval (openssh 4.3-p2) In-Reply-To: <20060504032838.GA2921@gate.dtucker.net> References: <20060504032838.GA2921@gate.dtucker.net> Message-ID: On Thu, 4 May 2006, Darren Tucker wrote: > On Sat, Apr 22, 2006 at 08:02:47PM +0300, catamus wrote: >> >> I have found that ServerAliveInterval & ServerAliveCountMax have >> some bug. Basically the ssh-alive check function (that verify the >> peer is alive) is called only if no data at all gets into ssh (when it >> should work only for server channel).I am pretty sure developers know >> about this ..anyway I have tried to fix this issue. Here is the patch: > > Could you please give an example of the circumstances under which this > might happen? Repeatedly banging on the keyboard generating traffic > on stdin? Well, yes keyboard is one, forwarded tcp is other.. (anything that make select return before timeout expire) > > I'm not sure the patch is quite right, though. > >> + if(FD_ISSET(connection_out, *readsetp)) { >> + tv.tv_sec = 0; >> + tv.tv_usec = 0; > > This doesn't look right... it's checking if the connection out is readable? > > Maybe that should be this? > > if (FD_ISSET(connection_in, *readsetp) || > FD_ISSET(connection_out, *writesetp)) > > I think only if(FD_ISSET(connection_in, *readsetp)) we reset the timer when we have data from remote peer.. catam From dtucker at zip.com.au Thu May 4 18:11:35 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 4 May 2006 18:11:35 +1000 Subject: Solaris 8 x86 rsa pubkey auth problem In-Reply-To: <20060504074858.10644.qmail@cdy.org> References: <7ec6def90604210335s5ad03dc4s811fe4a66a8a32c4@mail.gmail.com> <7ec6def90605031016y23176fadr8fdd59461b235a0c@mail.gmail.com> <20060503191436.GA14907@folly> <7ec6def90605040012g2617168fi45c43286a9477db0@mail.gmail.com> <20060504074858.10644.qmail@cdy.org> Message-ID: <20060504081135.GA17635@gate.dtucker.net> On Thu, May 04, 2006 at 09:48:57AM +0200, Peter Stuge wrote: > If ssh didn't read the public key in (2) the user would have to enter > the passphrase for any and all private keys available to ssh, not > just the one that would be used for actually authenticating the user. It's faster, too. Without it, you would also have to perform a sign (on the client) and verify (on the server) which is relatively expensive. The "will you accept the key with this fingerprint?" operation is a lot cheaper than sign+verify (remember, the client might try a number of keys). -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From dtucker at zip.com.au Thu May 4 18:26:42 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 4 May 2006 18:26:42 +1000 Subject: bug & patch in ServerAliveInterval (openssh 4.3-p2) In-Reply-To: References: <20060504032838.GA2921@gate.dtucker.net> Message-ID: <20060504082642.GA18163@gate.dtucker.net> On Thu, May 04, 2006 at 10:59:48AM +0300, catamus wrote: > On Thu, 4 May 2006, Darren Tucker wrote: > >Could you please give an example of the circumstances under which this > >might happen? Repeatedly banging on the keyboard generating traffic > >on stdin? > > Well, yes keyboard is one, forwarded tcp is other.. (anything that > make select return before timeout expire) Makes sense, thanks. > I think only > if(FD_ISSET(connection_in, *readsetp)) > > we reset the timer when we have data from remote peer.. Yeah that seems reasonable. The other thing is that the diff sets a select timeout even with Protocol 1 (not a big deal but not necessary). Index: clientloop.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/clientloop.c,v retrieving revision 1.162 diff -u -p -r1.162 clientloop.c --- clientloop.c 2006/04/20 09:27:09 1.162 +++ clientloop.c 2006/05/04 08:23:09 @@ -465,7 +465,8 @@ static void client_wait_until_can_do_something(fd_set **readsetp, fd_set **writesetp, int *maxfdp, u_int *nallocp, int rekeying) { - struct timeval tv, *tvp; + static struct timeval tv; + struct timeval *tvp = NULL; int ret; /* Add any selections by the channel mechanism. */ @@ -515,14 +516,21 @@ client_wait_until_can_do_something(fd_se * event pending. */ - if (options.server_alive_interval == 0 || !compat20) - tvp = NULL; - else { + if (options.server_alive_interval != 0 && compat20 && + tv.tv_sec == 0 && tv.tv_usec == 0) { tv.tv_sec = options.server_alive_interval; tv.tv_usec = 0; tvp = &tv; } + ret = select((*maxfdp)+1, *readsetp, *writesetp, NULL, tvp); + + if (options.server_alive_interval != 0 && compat20 && + FD_ISSET(connection_in, *readsetp)) { + tv.tv_sec = 0; + tv.tv_usec = 0; + } + if (ret < 0) { char buf[100]; -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From mikhail.manuilov at gmail.com Thu May 4 19:40:06 2006 From: mikhail.manuilov at gmail.com (Mikhail Manuylov) Date: Thu, 4 May 2006 13:40:06 +0400 Subject: Solaris 8 x86 rsa pubkey auth problem In-Reply-To: <20060504081135.GA17635@gate.dtucker.net> References: <7ec6def90604210335s5ad03dc4s811fe4a66a8a32c4@mail.gmail.com> <7ec6def90605031016y23176fadr8fdd59461b235a0c@mail.gmail.com> <20060503191436.GA14907@folly> <7ec6def90605040012g2617168fi45c43286a9477db0@mail.gmail.com> <20060504074858.10644.qmail@cdy.org> <20060504081135.GA17635@gate.dtucker.net> Message-ID: <7ec6def90605040240r1f7f31bdpd80e1c9d0c0e10d2@mail.gmail.com> On 5/4/06, Darren Tucker wrote: > On Thu, May 04, 2006 at 09:48:57AM +0200, Peter Stuge wrote: > > If ssh didn't read the public key in (2) the user would have to enter > > the passphrase for any and all private keys available to ssh, not > > just the one that would be used for actually authenticating the user. > > It's faster, too. > > Without it, you would also have to perform a sign (on the client) and > verify (on the server) which is relatively expensive. The "will you > accept the key with this fingerprint?" operation is a lot cheaper than > sign+verify (remember, the client might try a number of keys). I look to diff of successfull and failed output of 'ssh -vvv' : "-debug1: Offering public key: auditor_id_rsa -debug3: send_pubkey_test +debug1: Trying private key: auditor_id_rsa +debug1: read PEM private key done: type RSA +debug3: sign_and_send_pubkey" Now with your comments I got it ( i just have no more time to dig sources). Ok it's faster, but: 1) I can't find where in ssh(1) this feature is mentioned. 2) Is there method to check if particular public key is from one pair with user (-i option) supplied private key. Cause 100% guessing .pub for corresponding pubkey file is somewhat naive. > > -- > Darren Tucker (dtucker at zip.com.au) > GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 > Good judgement comes with experience. Unfortunately, the experience > usually comes from bad judgement. > BTW, please CC me, cause I'm not subscribed to the list. -- Truly yours, Mikhail Manuilov From stuge-openssh-unix-dev at cdy.org Thu May 4 20:31:42 2006 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Thu, 4 May 2006 12:31:42 +0200 Subject: Solaris 8 x86 rsa pubkey auth problem In-Reply-To: <7ec6def90605040240r1f7f31bdpd80e1c9d0c0e10d2@mail.gmail.com> References: <7ec6def90604210335s5ad03dc4s811fe4a66a8a32c4@mail.gmail.com> <7ec6def90605031016y23176fadr8fdd59461b235a0c@mail.gmail.com> <20060503191436.GA14907@folly> <7ec6def90605040012g2617168fi45c43286a9477db0@mail.gmail.com> <20060504074858.10644.qmail@cdy.org> <20060504081135.GA17635@gate.dtucker.net> <7ec6def90605040240r1f7f31bdpd80e1c9d0c0e10d2@mail.gmail.com> Message-ID: <20060504103143.30168.qmail@cdy.org> On Thu, May 04, 2006 at 01:40:06PM +0400, Mikhail Manuylov wrote: > 1) I can't find where in ssh(1) this feature is mentioned. Look under FILES. > 2) Is there method to check if particular public key is from one > pair with user (-i option) supplied private key. Not without decrypting the private key, which requires the user to type the passphrase. > Cause 100% guessing .pub for corresponding > pubkey file is somewhat naive. The server decides if the chosen privat key authenticates the user. The user (or administrator) controls filenames. ssh can't do much to change either.. > BTW, please CC me, cause I'm not subscribed to the list. Sorry, didn't know that - otherwise I would've done so before too. //Peter From mikhail.manuilov at gmail.com Thu May 4 20:53:18 2006 From: mikhail.manuilov at gmail.com (Mikhail Manuylov) Date: Thu, 4 May 2006 14:53:18 +0400 Subject: Solaris 8 x86 rsa pubkey auth problem In-Reply-To: <20060504103143.30168.qmail@cdy.org> References: <7ec6def90604210335s5ad03dc4s811fe4a66a8a32c4@mail.gmail.com> <7ec6def90605031016y23176fadr8fdd59461b235a0c@mail.gmail.com> <20060503191436.GA14907@folly> <7ec6def90605040012g2617168fi45c43286a9477db0@mail.gmail.com> <20060504074858.10644.qmail@cdy.org> <20060504081135.GA17635@gate.dtucker.net> <7ec6def90605040240r1f7f31bdpd80e1c9d0c0e10d2@mail.gmail.com> <20060504103143.30168.qmail@cdy.org> Message-ID: <7ec6def90605040353t7e7e9629nfeaa3d2ab0d0b5fb@mail.gmail.com> On 5/4/06, Peter Stuge wrote: > On Thu, May 04, 2006 at 01:40:06PM +0400, Mikhail Manuylov wrote: > > 1) I can't find where in ssh(1) this feature is mentioned. > > Look under FILES. I see only files description. But there's no mention that keeping public key among with private on authenticating side will make things simplier and faster if you use non empty passphrase. > > > > 2) Is there method to check if particular public key is from one > > pair with user (-i option) supplied private key. > > Not without decrypting the private key, which requires the user to > type the passphrase. But what if passphrase is empty? Now we can that check public key. Yes I'm trying to develop a crock, but if someone will shoot himself in a foot like me? > > > > Cause 100% guessing .pub for corresponding > > pubkey file is somewhat naive. > > The server decides if the chosen privat key authenticates the user. > > The user (or administrator) controls filenames. > > ssh can't do much to change either.. Ok ssh can't but if after pubkey and signature stuff fails we can offer client a try with sign and send of private key? > > > > BTW, please CC me, cause I'm not subscribed to the list. > > Sorry, didn't know that - otherwise I would've done so before too. That's ok, it was my fault. > > > //Peter > -- Truly yours, Mikhail Manuilov From mikhail.manuilov at gmail.com Thu May 4 21:01:55 2006 From: mikhail.manuilov at gmail.com (Mikhail Manuylov) Date: Thu, 4 May 2006 15:01:55 +0400 Subject: Solaris 8 x86 rsa pubkey auth problem In-Reply-To: <7ec6def90605040240r1f7f31bdpd80e1c9d0c0e10d2@mail.gmail.com> References: <7ec6def90604210335s5ad03dc4s811fe4a66a8a32c4@mail.gmail.com> <7ec6def90605031016y23176fadr8fdd59461b235a0c@mail.gmail.com> <20060503191436.GA14907@folly> <7ec6def90605040012g2617168fi45c43286a9477db0@mail.gmail.com> <20060504074858.10644.qmail@cdy.org> <20060504081135.GA17635@gate.dtucker.net> <7ec6def90605040240r1f7f31bdpd80e1c9d0c0e10d2@mail.gmail.com> Message-ID: <7ec6def90605040401w766c5834wd51b372dda08ef1f@mail.gmail.com> On 5/4/06, Mikhail Manuylov wrote: > On 5/4/06, Darren Tucker wrote: > > On Thu, May 04, 2006 at 09:48:57AM +0200, Peter Stuge wrote: > > > If ssh didn't read the public key in (2) the user would have to enter > > > the passphrase for any and all private keys available to ssh, not > > > just the one that would be used for actually authenticating the user. > > > > It's faster, too. > > > > Without it, you would also have to perform a sign (on the client) and > > verify (on the server) which is relatively expensive. The "will you > > accept the key with this fingerprint?" operation is a lot cheaper than > > sign+verify (remember, the client might try a number of keys). > > I look to diff of successfull and failed output of 'ssh -vvv' : > "-debug1: Offering public key: auditor_id_rsa > -debug3: send_pubkey_test > +debug1: Trying private key: auditor_id_rsa > +debug1: read PEM private key done: type RSA > +debug3: sign_and_send_pubkey" I think here should be a fix, cause as I've said before, nowhere in the debug output you can find real filename "auditor_id_rsa.pub", only private key prefix: ----->debug1: Offering public key: auditor_id_rsa".pub" > > Now with your comments I got it ( i just have no more time to dig sources). > > Ok it's faster, but: > > 1) I can't find where in ssh(1) this feature is mentioned. > 2) Is there method to check if particular public key is from one pair > with user (-i option) supplied private key. > Cause 100% guessing .pub for corresponding > pubkey file is somewhat naive. > > > > > -- > > Darren Tucker (dtucker at zip.com.au) > > GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 > > Good judgement comes with experience. Unfortunately, the experience > > usually comes from bad judgement. > > > > BTW, please CC me, cause I'm not subscribed to the list. > > -- > Truly yours, Mikhail Manuilov > -- Truly yours, Mikhail Manuilov From openssh at roumenpetrov.info Fri May 5 06:57:14 2006 From: openssh at roumenpetrov.info (Roumen Petrov) Date: Thu, 04 May 2006 23:57:14 +0300 Subject: xmalloc(foo*bar) -> xcalloc(foo, bar) for Portable In-Reply-To: <20060504023539.GA17041@gate.dtucker.net> References: <20060504021857.GA6236@gate.dtucker.net> <20060504023539.GA17041@gate.dtucker.net> Message-ID: <445A6AAA.5040908@roumenpetrov.info> Darren Tucker wrote: > =================================================================== > RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/openbsd-compat/fake-rfc2553.c,v > retrieving revision 1.6 > diff -u -p -r1.6 fake-rfc2553.c > --- openbsd-compat/fake-rfc2553.c 25 Mar 2006 13:03:24 -0000 1.6 > +++ openbsd-compat/fake-rfc2553.c 4 May 2006 02:28:30 -0000 > @@ -115,7 +115,7 @@ addrinfo *malloc_ai(int port, u_long add > { > struct addrinfo *ai; > > - ai = malloc(sizeof(*ai) + sizeof(struct sockaddr_in)); > + ai = calloc(sizeof(*ai), sizeof(struct sockaddr_in)); Not sure From dtucker at zip.com.au Fri May 5 08:28:13 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 05 May 2006 08:28:13 +1000 Subject: xmalloc(foo*bar) -> xcalloc(foo, bar) for Portable In-Reply-To: <445A6AAA.5040908@roumenpetrov.info> References: <20060504021857.GA6236@gate.dtucker.net> <20060504023539.GA17041@gate.dtucker.net> <445A6AAA.5040908@roumenpetrov.info> Message-ID: <445A7FFD.7080905@zip.com.au> Roumen Petrov wrote: >> - ai = malloc(sizeof(*ai) + sizeof(struct sockaddr_in)); >> + ai = calloc(sizeof(*ai), sizeof(struct sockaddr_in)); > > Not sure Yeah, that's definitely wrong. I dropped that one but the rest have been applied. Thanks. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From Jason.C.Burns at wellsfargo.com Sat May 6 04:26:48 2006 From: Jason.C.Burns at wellsfargo.com (Jason.C.Burns at wellsfargo.com) Date: Fri, 5 May 2006 13:26:48 -0500 Subject: Problems with input and AIX Message-ID: I noticed an odd side effect of the different implementations of backspace (erase) through clients such as PuTTY and SecureCRT and the input functions like fgets (I noticed this originally in ssh-keygen). On our AIX system, if the option to use ^? as the backspace key is chosen, fgets will actually put the control code for 'DEL' in the buffer (0x7f) instead of deleting the last character input. The scenario I noticed is that someone creates a key pair, types in a path, then decides to just accept the default, so they erase whatever they put in there. The buffer actually contains what they wrote plus all the DEL codes, and so the strcmp call against "" fails. So let's say someone wants to create a key in the current dir called "mykey", then deletes it to accept the defaults. The buffer then actually contains {'m', 'y', 'k', 'e', 'y', '^?', '^?', '^?', '^?', '^?'}. This then creates the problem that ls is smart enough to erase these characters when printing to the terminal, thus making users think they have a file with no filename in their current dir! When using the ^h option, the buffer is updated correctly, but the terminal is not when entering a key path. I looked for a possible fix in the libc (BOS) imps for AIX, but found nothing. Since we can't rely on our users choosing the correct backspace option, I was just planning on writing a wrapper for fgets that cleans up any DEL cntl codes found in the buffer before returning to the caller. I figured I'd ping the list first though, to see if anyone else has seen this problem, or might have a better idea then writing another function to replace the fgets calls. Thanks! Jason From stuge-openssh-unix-dev at cdy.org Sat May 6 09:10:25 2006 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Sat, 6 May 2006 01:10:25 +0200 Subject: Problems with input and AIX In-Reply-To: References: Message-ID: <20060505231025.10396.qmail@cdy.org> On Fri, May 05, 2006 at 01:26:48PM -0500, Jason.C.Burns at wellsfargo.com wrote: > This then creates the problem that ls is smart enough to erase > these characters when printing to the terminal, thus making users > think they have a file with no filename in their current dir! I think ls just prints the filename, with DEL characters and all. > I figured I'd ping the list first though, to see if anyone else has > seen this problem, or might have a better idea then writing another > function to replace the fgets calls. I believe this is a problem with the termcap or terminfo database on the server - the server doesn't recognize the user's terminal type and/or the terminal emulator is configured incorrectly. One of the many things defined in the database is the erase character, if this is incorrect what you describe will happen. Try Ctrl-Backspace in the client, does that give different results? //Peter From tryponraj at gmail.com Sat May 6 14:32:49 2006 From: tryponraj at gmail.com (ponraj) Date: Sat, 6 May 2006 10:02:49 +0530 Subject: "ls -l" command and performance of sftp Message-ID: <012801c670c6$255b3e10$180110ac@pomco> Hi all, I am using OpenSSH4.3p2. User database is stored in LDAP server.When I tried to list about 400 files using "ls -l" command in ftp and sftp, I observed that sftp took considerable amount of time greater than ftp. I suspect sftp does not cache the username and groupname lookups and makes fresh calls to getpwuid(), getgrgid() functions for each file that makes its performance worse. Any comments ? -- M.P From dtucker at zip.com.au Sat May 6 15:10:26 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 6 May 2006 15:10:26 +1000 Subject: bug & patch in ServerAliveInterval (openssh 4.3-p2) In-Reply-To: <20060504082642.GA18163@gate.dtucker.net> References: <20060504032838.GA2921@gate.dtucker.net> <20060504082642.GA18163@gate.dtucker.net> Message-ID: <20060506051026.GA12870@gate.dtucker.net> Hi All. Markus pointed out that the same problem applies to sshd and that the earlier change when applied to sshd could still be fooled under some conditions. Below is a slightly different method that seems to work OK for both client and server. Index: clientloop.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/clientloop.c,v retrieving revision 1.162 diff -u -p -r1.162 clientloop.c --- clientloop.c 2006/04/20 09:27:09 1.162 +++ clientloop.c 2006/05/06 05:05:47 @@ -466,6 +466,8 @@ client_wait_until_can_do_something(fd_se int *maxfdp, u_int *nallocp, int rekeying) { struct timeval tv, *tvp; + static time_t lastalive; + time_t now; int ret; /* Add any selections by the channel mechanism. */ @@ -540,8 +542,15 @@ client_wait_until_can_do_something(fd_se snprintf(buf, sizeof buf, "select: %s\r\n", strerror(errno)); buffer_append(&stderr_buffer, buf, strlen(buf)); quit_pending = 1; - } else if (ret == 0) - server_alive_check(); + } else if (compat20 && options.server_alive_interval) { + now = time(NULL); + if (lastalive == 0 || FD_ISSET(connection_in, *readsetp)) { + lastalive = now; + } else if (lastalive + options.server_alive_interval <= now) { + lastalive = now; + server_alive_check(); + } + } } static void Index: serverloop.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/serverloop.c,v retrieving revision 1.135 diff -u -p -r1.135 serverloop.c --- serverloop.c 2006/03/25 18:30:55 1.135 +++ serverloop.c 2006/05/06 05:05:47 @@ -258,6 +258,8 @@ wait_until_can_do_something(fd_set **rea u_int *nallocp, u_int max_time_milliseconds) { struct timeval tv, *tvp; + static time_t lastalive; + time_t now; int ret; int client_alive_scheduled = 0; @@ -342,8 +344,15 @@ wait_until_can_do_something(fd_set **rea memset(*writesetp, 0, *nallocp); if (errno != EINTR) error("select: %.100s", strerror(errno)); - } else if (ret == 0 && client_alive_scheduled) - client_alive_check(); + } else if (compat20 && options.client_alive_interval) { + now = time(NULL); + if (lastalive == 0 || FD_ISSET(connection_in, *readsetp)) { + lastalive = now; + } else if (lastalive + options.client_alive_interval <= now) { + lastalive = now; + client_alive_check(); + } + } notify_done(*readsetp); } -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From sxw at inf.ed.ac.uk Sat May 6 20:18:29 2006 From: sxw at inf.ed.ac.uk (Simon Wilkinson) Date: Sat, 6 May 2006 11:18:29 +0100 (BST) Subject: GSSAPI Key Exchange Message-ID: Now that RFC 4462 has been published, I was wondering if there would be any interest in looking again at integrating the key exchange portions of my GSSAPI patch into the OpenSSH tree? As I've mentioned before, key exchange has significant benefits for large sites as it allows them to use Kerberos to authenticate ssh hosts, and removes the need to maintain and distribute ssh known_hosts files. Many vendors are already shipping patched versions of OpenSSH with GSSAPI key exchange support. Thanks, Simon. From smooge at gmail.com Sun May 7 03:16:03 2006 From: smooge at gmail.com (Stephen John Smoogen) Date: Sat, 6 May 2006 11:16:03 -0600 Subject: GSSAPI Key Exchange In-Reply-To: References: Message-ID: <80d7e4090605061016m63a4e8b2q31a98f94777409d8@mail.gmail.com> On 5/6/06, Simon Wilkinson wrote: > > Now that RFC 4462 has been published, I was wondering if there would be > any interest in looking again at integrating the key exchange portions of > my GSSAPI patch into the OpenSSH tree? > > As I've mentioned before, key exchange has significant benefits for large > sites as it allows them to use Kerberos to authenticate ssh hosts, and > removes the need to maintain and distribute ssh known_hosts files. Many > vendors are already shipping patched versions of OpenSSH with GSSAPI key > exchange support. > I know that it has a big interest where I work. I would be available to help test this under a couple of scenarios. -- Stephen J Smoogen. CSIRT/Linux System Administrator From deengert at anl.gov Tue May 9 00:33:45 2006 From: deengert at anl.gov (Douglas E. Engert) Date: Mon, 08 May 2006 09:33:45 -0500 Subject: GSSAPI Key Exchange In-Reply-To: References: Message-ID: <445F56C9.4010208@anl.gov> Simon Wilkinson wrote: > Now that RFC 4462 has been published, I was wondering if there would be > any interest in looking again at integrating the key exchange portions of > my GSSAPI patch into the OpenSSH tree? > > As I've mentioned before, key exchange has significant benefits for large > sites as it allows them to use Kerberos to authenticate ssh hosts, and > removes the need to maintain and distribute ssh known_hosts files. Many > vendors are already shipping patched versions of OpenSSH with GSSAPI key > exchange support. Yes, we would also be very interested in having this in OpenSSH. > > Thanks, > > Simon. > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > > -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From Einar.Mykletun at quest.com Tue May 9 07:41:11 2006 From: Einar.Mykletun at quest.com (Einar Mykletun) Date: Mon, 8 May 2006 14:41:11 -0700 Subject: OpenSSH fips compliance Message-ID: <78CD474EB76D9C4C9E8F03720184A36B0BD2913C@ALVMBXW02.prod.quest.corp> Senthil, I just came across your thread about OpenSSH and FIPS 140 OpenSSL. I have played around with compiling my OpenSSL applications to become FIPS 140 compliant, and after finding out about fipsld (used to link your app to the library), I got this working. I'm also now looking for a version of OpenSSH, as well as Apache Web Server, that has been compiled with the OpenSSL FIPS 140 Cryptographic Module. I will post another email if I find these versions. Thomass From djm at mindrot.org Tue May 9 10:28:39 2006 From: djm at mindrot.org (Damien Miller) Date: Tue, 9 May 2006 10:28:39 +1000 (EST) Subject: OpenSSH fips compliance In-Reply-To: <78CD474EB76D9C4C9E8F03720184A36B0BD2913C@ALVMBXW02.prod.quest.corp> References: <78CD474EB76D9C4C9E8F03720184A36B0BD2913C@ALVMBXW02.prod.quest.corp> Message-ID: On Mon, 8 May 2006, Einar Mykletun wrote: > Senthil, > > I just came across your thread about OpenSSH and FIPS 140 OpenSSL. I > have played around with compiling my OpenSSL applications to become FIPS > 140 compliant, and after finding out about fipsld (used to link your app > to the library), I got this working. > > I'm also now looking for a version of OpenSSH, as well as Apache Web > Server, that has been compiled with the OpenSSL FIPS 140 Cryptographic > Module. I will post another email if I find these versions. there was a patch posted to this mailing list a while ago, but it will probably need some further work. -d From Jerel.Crosland at 21st.com Tue May 9 10:52:44 2006 From: Jerel.Crosland at 21st.com (Crosland, Jerel) Date: Mon, 8 May 2006 17:52:44 -0700 Subject: scp logging Message-ID: The ability to log even just the names of the files being transferred, and possibly their sizes, has been a requested feature since early 2000 (over six years!!) and I've yet to see any of the developers on this list respond directly. I've found a patch from V?clav Tomec here: http://sweb.cz/v_t_m/ but it includes lots of other stuff (SecureID implementation and a tweak for being able to select allow/deny users for each kind of authentication) which I don't need and don't want to "support". Every file manipulation utility available for the Unix/Linux world provides the ability to log what it is doing, except for scp and sftp. This is crazy!! It displays the "progress meter" as long as the output is directed to a screen, but if you redirect stdout to a file, it disables all output, except errors! Is there really only about 10 of us in the entire world that want to use scp in a script, and want a log of what it did? I find that hard to believe!!! Is this planned as a feature in some future release, or is it just being ignored? It's insane that there's no way to log the output! You can't use -o LOGLEVEL=something and if you use -v or the debug logging level, tons of stuff spews out, but not one single line that contains the file name, it's size, and an indication of the status of the transfer. Am I just nuts for expecting this? Jerel Crosland Technical Specialist 21st Century Insurance *********************************************************************** This e-mail and any files transmitted with it are intended solely for the use of the addressee. This e-mail may contain confidential and/or legally privileged information. Any review, transmission, disclosure, copying, or any action taken or not taken, by other than the intended recipient, in reliance on the information, is prohibited. If you received this e-mail in error, notify the sender and delete this e-mail (and any accompanying material) from your computer and network. In addition, please be advised that 21st Century Insurance Group reserves the right to monitor, access and review all messages, data and images transmitted through our electronic mail system. By using our e-mail system, you consent to this monitoring. *********************************************************************** From dtucker at zip.com.au Tue May 9 16:46:18 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 9 May 2006 16:46:18 +1000 Subject: X11 forwarding to IPv6 enabled host not working. In-Reply-To: <4459ABB9.6000604@acm.org> References: <4459ABB9.6000604@acm.org> Message-ID: <20060509064618.GA29049@gate.dtucker.net> On Thu, May 04, 2006 at 05:22:33PM +1000, Mark Ennis wrote: > I have been experiencing a problem with using X11 forwarding on an IPv6 > enabled host (both CentOS 4.3 and Feddora Core 5 in x86) when > X11UseLocalhost is off. > > Having looked at the code and the previous discussion regarding > http://bugzilla.mindrot.org/show_bug.cgi?id=164 I think the problem is > due to the IPV6_V6ONLY code interacting poorly with the > DONT_TRY_OTHER_AF hack. Basically, on current Linux systems which > support the IPV6_V6ONLY socket option, the forwarded socket is created > for IPV6 only and then the DONT_TRY_OTHER_AF prevents an IPV4 listen > socket from also being created. Thus, only forwarding X11 connections > over IPV6 are then supported. > > I would recommend addressing this by changing the DONT_TRY_OTHER_AF hack > to apply only where the the IPV6_V6ONLY socket option is not supported. > For example: Seems reasonable to me, but I don't use IPv6 (for X11 or otherwise). A unified diff for the same patch is below (easier to read). Another alternative would be unsetting DONT_TRY_OTHER_AF if IPV6_V6ONLY is defined. Index: channels.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/channels.c,v retrieving revision 1.229 diff -u -p -r1.229 channels.c --- channels.c 23 Apr 2006 02:06:03 -0000 1.229 +++ channels.c 9 May 2006 06:40:04 -0000 @@ -2825,7 +2825,7 @@ x11_create_display_inet(int x11_display_ break; } socks[num_socks++] = sock; -#ifndef DONT_TRY_OTHER_AF +#if defined(IPV6_V6ONLY) || !defined(DONT_TRY_OTHER_AF) if (num_socks == NUM_SOCKS) break; #else -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From mark.ennis at acm.org Tue May 9 17:12:57 2006 From: mark.ennis at acm.org (Mark Ennis) Date: Tue, 09 May 2006 17:12:57 +1000 Subject: X11 forwarding to IPv6 enabled host not working. In-Reply-To: <20060509064618.GA29049@gate.dtucker.net> References: <4459ABB9.6000604@acm.org> <20060509064618.GA29049@gate.dtucker.net> Message-ID: <446040F9.5080204@acm.org> Darren Tucker wrote: > On Thu, May 04, 2006 at 05:22:33PM +1000, Mark Ennis wrote: >> I have been experiencing a problem with using X11 forwarding on an IPv6 >> enabled host (both CentOS 4.3 and Feddora Core 5 in x86) when >> X11UseLocalhost is off. >> >> Having looked at the code and the previous discussion regarding >> http://bugzilla.mindrot.org/show_bug.cgi?id=164 I think the problem is >> due to the IPV6_V6ONLY code interacting poorly with the >> DONT_TRY_OTHER_AF hack. Basically, on current Linux systems which >> support the IPV6_V6ONLY socket option, the forwarded socket is created >> for IPV6 only and then the DONT_TRY_OTHER_AF prevents an IPV4 listen >> socket from also being created. Thus, only forwarding X11 connections >> over IPV6 are then supported. >> >> I would recommend addressing this by changing the DONT_TRY_OTHER_AF hack >> to apply only where the the IPV6_V6ONLY socket option is not supported. >> For example: > > Seems reasonable to me, but I don't use IPv6 (for X11 or otherwise). A > unified diff for the same patch is below (easier to read). > I don't use IPv6 much either, but the default on the newer RedHat based distros seems to enable IPv6 link-local addressing on interfaces automatically. > Another alternative would be unsetting DONT_TRY_OTHER_AF if IPV6_V6ONLY > is defined. If configure can work that out then I agree that would probably be better. In fact, I would be inclined to argue that, if a reasonable assumption is that systems supporting IPV6_V6ONLY will listen on both IPv4 and IPv6 automatically, it would be better not using IPV6_V6ONLY and DONT_TRY_OTHER_AF at all and defaulting to the same behaviour as is used for setting up port 22 listening, including respecting the -4 and -6 command line arguments to sshd. - Mark. From jeremie at le-hen.org Wed May 10 05:10:03 2006 From: jeremie at le-hen.org (Jeremie Le Hen) Date: Tue, 9 May 2006 21:10:03 +0200 Subject: xmalloc symbol in libssh Message-ID: <20060509191003.GF84148@obiwan.tataz.chchile.org> Hi list, (Please Cc: me in your replies because I'm not subscribed to this list.) While trying to build lukemftpd staticaly on FreeBSD, I got a link-time error. Libssh.a indeed provides the "xmalloc" symbol (I suppose there are more). I wonder if this is whether intentional or not. It is a very common function name, and I think it would be worth renaming it to something like ssh_xmalloc() or openssh_xmalloc(). I can provide a patch on request. %%% % cc -O2 -fno-strict-aliasing -pipe -march=pentium-m -include nbsd2fbsd.h -I/usr/src/libexec/lukemftpd -I/usr/src/libexec/lukemftpd/../../contrib/lukemftpd -I/usr/src/libexec/lukemftpd/../../contrib/lukemftpd/src -I/usr/src/libexec/lukemftpd/../../lib/libc/stdtime -I/usr/src/libexec/lukemftpd/../../bin/ls -DUSE_OPIE -DLOGIN_CAP -DUSE_PAM -fstack-protector -static -o lukemftpd cmds.o conf.o ftpd.o ftpcmd.o popen.o strsuftoll.o ls-unmain.o cmp.o print.o util.o -lcrypt -lutil -lm -lopie -lmd -lpam -lkrb5 -lasn1 -lcrypto -lcrypt -lroken -lcom_err -lradius -ltacplus -lcrypt -lutil -lopie -lmd -lssh -lcrypto -lcrypt -lypclnt % /usr/obj/usr/src/tmp/usr/lib/libssh.a(xmalloc.o)(.text+0xd0): In function `xstrdup': % : multiple definition of `xstrdup' % ftpd.o(.text+0x1460): first defined here % /usr/obj/usr/src/tmp/usr/bin/ld: Warning: size of symbol `xstrdup' changed from 44 in ftpd.o to 70 in /usr/obj/usr/src/tmp/usr/lib/libssh.a(xmalloc.o) %%% Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From markus.r.friedl at arcor.de Wed May 10 05:18:13 2006 From: markus.r.friedl at arcor.de (Markus Friedl) Date: Tue, 9 May 2006 21:18:13 +0200 Subject: xmalloc symbol in libssh In-Reply-To: <20060509191003.GF84148@obiwan.tataz.chchile.org> References: <20060509191003.GF84148@obiwan.tataz.chchile.org> Message-ID: <20060509191813.GA9912@folly> there's no need to install libssh.a On Tue, May 09, 2006 at 09:10:03PM +0200, Jeremie Le Hen wrote: > Hi list, > > (Please Cc: me in your replies because I'm not subscribed to this list.) > > While trying to build lukemftpd staticaly on FreeBSD, I got a link-time > error. Libssh.a indeed provides the "xmalloc" symbol (I suppose there > are more). I wonder if this is whether intentional or not. It is a > very common function name, and I think it would be worth renaming > it to something like ssh_xmalloc() or openssh_xmalloc(). > > I can provide a patch on request. > > %%% > % cc -O2 -fno-strict-aliasing -pipe -march=pentium-m -include nbsd2fbsd.h -I/usr/src/libexec/lukemftpd -I/usr/src/libexec/lukemftpd/../../contrib/lukemftpd -I/usr/src/libexec/lukemftpd/../../contrib/lukemftpd/src -I/usr/src/libexec/lukemftpd/../../lib/libc/stdtime -I/usr/src/libexec/lukemftpd/../../bin/ls -DUSE_OPIE -DLOGIN_CAP -DUSE_PAM -fstack-protector -static -o lukemftpd cmds.o conf.o ftpd.o ftpcmd.o popen.o strsuftoll.o ls-unmain.o cmp.o print.o util.o -lcrypt -lutil -lm -lopie -lmd -lpam -lkrb5 -lasn1 -lcrypto -lcrypt -lroken -lcom_err -lradius -ltacplus -lcrypt -lutil -lopie -lmd -lssh -lcrypto -lcrypt -lypclnt > % /usr/obj/usr/src/tmp/usr/lib/libssh.a(xmalloc.o)(.text+0xd0): In function `xstrdup': > % : multiple definition of `xstrdup' > % ftpd.o(.text+0x1460): first defined here > % /usr/obj/usr/src/tmp/usr/bin/ld: Warning: size of symbol `xstrdup' changed from 44 in ftpd.o to 70 in /usr/obj/usr/src/tmp/usr/lib/libssh.a(xmalloc.o) > %%% > > Regards, > -- > Jeremie Le Hen > < jeremie at le-hen dot org >< ttz at chchile dot org > > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev From jeremie at le-hen.org Wed May 10 07:28:05 2006 From: jeremie at le-hen.org (Jeremie Le Hen) Date: Tue, 9 May 2006 23:28:05 +0200 Subject: xmalloc symbol in libssh In-Reply-To: <20060509191813.GA9912@folly> References: <20060509191003.GF84148@obiwan.tataz.chchile.org> <20060509191813.GA9912@folly> Message-ID: <20060509212805.GG84148@obiwan.tataz.chchile.org> Hi Markus, On Tue, May 09, 2006 at 09:18:13PM +0200, Markus Friedl wrote: > there's no need to install libssh.a Do you mean that libssh is an internal lib and thus no other application should use it ? Thank you. Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From djm at mindrot.org Wed May 10 07:52:37 2006 From: djm at mindrot.org (Damien Miller) Date: Wed, 10 May 2006 07:52:37 +1000 (EST) Subject: xmalloc symbol in libssh In-Reply-To: <20060509212805.GG84148@obiwan.tataz.chchile.org> References: <20060509191003.GF84148@obiwan.tataz.chchile.org> <20060509191813.GA9912@folly> <20060509212805.GG84148@obiwan.tataz.chchile.org> Message-ID: On Tue, 9 May 2006, Jeremie Le Hen wrote: > Hi Markus, > > On Tue, May 09, 2006 at 09:18:13PM +0200, Markus Friedl wrote: > > there's no need to install libssh.a > > Do you mean that libssh is an internal lib and thus no other application > should use it ? exactly From roy.butler at jpl.nasa.gov Wed May 10 08:49:00 2006 From: roy.butler at jpl.nasa.gov (Roy L Butler) Date: Tue, 09 May 2006 15:49:00 -0700 Subject: scp logging In-Reply-To: References: Message-ID: <44611C5C.8070707@jpl.nasa.gov> Jerel, Crosland, Jerel wrote: > The ability to log even just the names of the files being transferred, and possibly their sizes, has been a requested feature since early 2000 (over six years!!) and I've yet to see any of the developers on this list respond directly. I've found a patch from V?clav Tomec here: http://sweb.cz/v_t_m/ but it includes lots of other stuff (SecureID implementation and a tweak for being able to select allow/deny users for each kind of authentication) which I don't need and don't want to "support". > > Every file manipulation utility available for the Unix/Linux world provides the ability to log what it is doing, except for scp and sftp. This is crazy!! It displays the "progress meter" as long as the output is directed to a screen, but if you redirect stdout to a file, it disables all output, except errors! Is there really only about 10 of us in the entire world that want to use scp in a script, and want a log of what it did? I find that hard to believe!!! Is this planned as a feature in some future release, or is it just being ignored? It's insane that there's no way to log the output! You can't use -o LOGLEVEL=something and if you use -v or the debug logging level, tons of stuff spews out, but not one single line that contains the file name, it's size, and an indication of the status of the transfer. > > Am I just nuts for expecting this? At first, I thought you meant logging on the server, and thought "Yeah, that would be cool". It follows along the lines of web and FTP servers usually logging uploads, but I can see how it doesn't necessarily fall within sshd's needed facilities (who knows, maybe it is there and I just don't know it). But from reading further, it sounds like what you're complaining about, is the lack of logging on the client side. If that's the case, I have two comments for you, one about open source, and one that is a technical solution to your wish, if you'll allow it to be so: - If you want something from an open source project, you usually need to step up to the plate with code. If it's accepted, great. If not, fork. People who aren't getting paid to do something for you aren't going to deal with a bad attitude. - Use rsync over ssh. It will provide you all of the logging you like, as well as the ability to perform incremental pushes depending on source/destination contents. Hope this helps. If not, you could also probably pay a commercial vendor to implement your requests... Roy From girish1729 at gmail.com Wed May 10 17:10:55 2006 From: girish1729 at gmail.com (Girish Venkatachalam) Date: Wed, 10 May 2006 12:40:55 +0530 Subject: Patch to add resume feature to scp Message-ID: Dear all, I have enhanced scp to do the following. 1) Check the SHA1 checksums of the file fragments at the source and destination and resume file transfer from where it left off last time 2) If the file checksums match and size also matches, then the file is assumed to be identical and skipped, the user is also informed of the same 3) If the destination file size is larger than the source, it is overwritten(conforms to prev behavior, the enhancement here being that checksum computation is short circuited) 4) If the checksums do not match for the fragment, then the file is overwritten 5) All the above works well in recursive mode also, the identical files are skipped, broken transfers resumed and all other times files are transferred like before 6) One important feature of this enhancement is that if the same file is not found at the destination , then the previous wire protocol is preserved, thus there would be no version mismatch problem for fresh transfers. However these changes do necessitate a bump in the version number IMHO. I could not think of any other way to solve this problem. I will only be too glad to make whatever changes are necessary to apply this patch to HEAD. Hope you like this work. :-) regards, Girish From Jerel.Crosland at 21st.com Wed May 10 18:42:17 2006 From: Jerel.Crosland at 21st.com (Crosland, Jerel) Date: Wed, 10 May 2006 01:42:17 -0700 Subject: scp logging Message-ID: Please accept my most fervent apologies if this came off as "attitudinal", everyone who read my message. It was never my intent to offend anyone. I am not a C programmer, but I've programmed in just about every other language over the last 30 years, from toggling machine code instructions into a front panel, to so-called 4GLs. I may use this to learn C, who knows. But my observation is based on my years of experience not only as a developer, but also as a system administrator. Every program "worth its salt" that manipulates files allows some form of logging, without regard to the specific setting of stdout and/or stderr. There is always a way to redirect the output or pipe it to another command. That is sort of an unwritten law in the Unix world, as far as I know, for command line utilities. I realize that OpenSSH was and is written primarily for OpenBSD, and the herculean efforts of the portability team make it available to the rest of the world for free, as in beer. I am most and humbly grateful for all this. Nevertheless, I see requests going back to 2000 for this feature, but apparently there simply has not been the demand that I would have anticipated. Yes, I can use rsync, but it means installing rsync on all of my servers, and we have a relatively large AIX and Linux server farm, and I was hoping for a way to simply log the activity of this command. My suggestion (since nothing else has been suggested) is that the progress meter be (optionally) not quite so flashy and smart and cool and all that, and simply have a mode where the file name and bytes transferred come out after the copy completes, rather than writing a line with the file name at the left margin, and a constantly-updated progress meter at the right margin. It's very cool and all, but perhaps simply checking the TERM variable and if it's set to something like tty, or the logic that detects that stdout is not going to a CRT could just not do that fancy stuff. You could still supress it with the -q option, but that simple change would nicely handle the simplest of logging at the client side. Logging at the server side should also be configurable, so that such things go to the syslog file. This is also in keeping with the spirit of most utilities that provide a remote service. As OpenSSH is used more and more in this age of SOX compliance, it would be nice if these kinds of logging and auditing were available. I may try and pitch in, who knows. But it's clear that I'm not the only that needs this, so I'm tossing my $0,000,000.02 into the game, and dropping this into the "Suggestion" box. Jerel Crosland Technical Specialist 21st Century Insurance Knott's Berry Farm & National Organization of Women: Knott NOW! -----Original Message----- From: Roy L Butler [mailto:roy.butler at jpl.nasa.gov] Sent: Tuesday, May 09, 2006 3:49 PM To: Crosland, Jerel Cc: openssh-unix-dev at mindrot.org Subject: Re: scp logging Jerel, Crosland, Jerel wrote: > The ability to log even just the names of the files being transferred, and possibly their sizes, has been a requested feature since early 2000 (over six years!!) and I've yet to see any of the developers on this list respond directly. I've found a patch from V?clav Tomec here: http://sweb.cz/v_t_m/ but it includes lots of other stuff (SecureID implementation and a tweak for being able to select allow/deny users for each kind of authentication) which I don't need and don't want to "support". > > Every file manipulation utility available for the Unix/Linux world provides the ability to log what it is doing, except for scp and sftp. This is crazy!! It displays the "progress meter" as long as the output is directed to a screen, but if you redirect stdout to a file, it disables all output, except errors! Is there really only about 10 of us in the entire world that want to use scp in a script, and want a log of what it did? I find that hard to believe!!! Is this planned as a feature in some future release, or is it just being ignored? It's insane that there's no way to log the output! You can't use -o LOGLEVEL=something and if you use -v or the debug logging level, tons of stuff spews out, but not one single line that contains the file name, it's size, and an indication of the status of the transfer. > > Am I just nuts for expecting this? At first, I thought you meant logging on the server, and thought "Yeah, that would be cool". It follows along the lines of web and FTP servers usually logging uploads, but I can see how it doesn't necessarily fall within sshd's needed facilities (who knows, maybe it is there and I just don't know it). But from reading further, it sounds like what you're complaining about, is the lack of logging on the client side. If that's the case, I have two comments for you, one about open source, and one that is a technical solution to your wish, if you'll allow it to be so: - If you want something from an open source project, you usually need to step up to the plate with code. If it's accepted, great. If not, fork. People who aren't getting paid to do something for you aren't going to deal with a bad attitude. - Use rsync over ssh. It will provide you all of the logging you like, as well as the ability to perform incremental pushes depending on source/destination contents. Hope this helps. If not, you could also probably pay a commercial vendor to implement your requests... Roy *********************************************************************** This e-mail and any files transmitted with it are intended solely for the use of the addressee. This e-mail may contain confidential and/or legally privileged information. Any review, transmission, disclosure, copying, or any action taken or not taken, by other than the intended recipient, in reliance on the information, is prohibited. If you received this e-mail in error, notify the sender and delete this e-mail (and any accompanying material) from your computer and network. In addition, please be advised that 21st Century Insurance Group reserves the right to monitor, access and review all messages, data and images transmitted through our electronic mail system. By using our e-mail system, you consent to this monitoring. *********************************************************************** From girish1729 at gmail.com Wed May 10 19:34:30 2006 From: girish1729 at gmail.com (Girish Venkatachalam) Date: Wed, 10 May 2006 15:04:30 +0530 Subject: Patch to add resume feature to scp In-Reply-To: References: Message-ID: Sorry folks, there was a nasty merge issue and hence my previous patch was broken. Please bear with me for the oversight. Here is the correct patch. regards, Girish On 5/10/06, Girish Venkatachalam wrote: > Dear all, > > I have enhanced scp to do the following. > > 1) Check the SHA1 checksums of the file fragments at the source and > destination and resume file transfer from where it left off last time > > 2) If the file checksums match and size also matches, then the file is > assumed to be identical and skipped, the user is also informed of the > same > > 3) If the destination file size is larger than the source, it is > overwritten(conforms to prev behavior, the enhancement here being that > checksum computation is short circuited) > > 4) If the checksums do not match for the fragment, then the file is overwritten > > 5) All the above works well in recursive mode also, the identical > files are skipped, broken transfers resumed and all other times files > are transferred like before > > 6) One important feature of this enhancement is that if the same file > is not found at the destination , then the previous wire protocol is > preserved, thus there would be no version mismatch problem for fresh > transfers. > > > However these changes do necessitate a bump in the version number > IMHO. I could not think of any other way to solve this problem. > > I will only be too glad to make whatever changes are necessary to > apply this patch to HEAD. > > Hope you like this work. :-) > > regards, > Girish > > > -- Whenever people agree with me I feel I am wrong. -- Oscar Wilde From jmknoble at pobox.com Thu May 11 15:40:06 2006 From: jmknoble at pobox.com (Jim Knoble) Date: Thu, 11 May 2006 01:40:06 -0400 Subject: Patch to add resume feature to scp In-Reply-To: References: Message-ID: <20060511054006.GE1397@crawfish.ais.com> Circa 2006-05-10 03:10 dixit Girish Venkatachalam: : Dear all, : : I have enhanced scp to do the following. [do pretty much the same thing as rsync] What's wrong with using rsync? It already does pretty much the same thing, with no bump in version number necessary. http://rsync.samba.org/ -- jim knoble | jmknoble at pobox.com | http://www.pobox.com/~jmknoble/ (GnuPG key ID: 6F39C2CC >>>>>> http://www.pobox.com/~jmknoble/keys/ ) (GnuPG fingerprint: 5024:D578:7CF4:5660:7269::F6F3:B919:9307:6F39:C2CC) ________________________________________________________________________ |"[L]iberty, as we all know, cannot flourish in a country that is perma- | nently on a war footing, or even a near-war footing." --Aldous Huxley |_______________________________________________________________________ From djm at mindrot.org Thu May 11 15:55:46 2006 From: djm at mindrot.org (Damien Miller) Date: Thu, 11 May 2006 15:55:46 +1000 (EST) Subject: Patch to add resume feature to scp In-Reply-To: <20060511054006.GE1397@crawfish.ais.com> References: <20060511054006.GE1397@crawfish.ais.com> Message-ID: On Thu, 11 May 2006, Jim Knoble wrote: > Circa 2006-05-10 03:10 dixit Girish Venkatachalam: > > : Dear all, > : > : I have enhanced scp to do the following. > > [do pretty much the same thing as rsync] > > What's wrong with using rsync? It already does pretty much the same > thing, with no bump in version number necessary. Sorry, but I agree: scp is pretty much unmaintainable as it is - without throwing the complexity of multiple incompatible implementations into the mix. If you want to implement new feature, please base them on sftp. It is a far saner protocol and many improvements only need changes on the client. It also offers a clean protocol extension mechanism, so changes that do require server support can be made without breaking older clients. -d From senthilkumar_sen at hotpop.com Thu May 11 21:55:43 2006 From: senthilkumar_sen at hotpop.com (Senthil Kumar) Date: Thu, 11 May 2006 17:25:43 +0530 Subject: OpenSSH fips compliance References: <78CD474EB76D9C4C9E8F03720184A36B0BD2913C@ALVMBXW02.prod.quest.corp> Message-ID: <279701c674f1$dce7b1b0$220110ac@sekco> "Damien Miller" wrote: > On Mon, 8 May 2006, Einar Mykletun wrote: > >> Senthil, >> >> I just came across your thread about OpenSSH and FIPS 140 OpenSSL. I >> have played around with compiling my OpenSSL applications to become FIPS >> 140 compliant, and after finding out about fipsld (used to link your app >> to the library), I got this working. >> >> I'm also now looking for a version of OpenSSH, as well as Apache Web >> Server, that has been compiled with the OpenSSL FIPS 140 Cryptographic >> Module. I will post another email if I find these versions. > > there was a patch posted to this mailing list a while ago, but it will > probably need some further work. > Here is the link for the old post http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=108635432706845 --Senthil Kumar. From rapier at psc.edu Fri May 12 01:17:33 2006 From: rapier at psc.edu (Chris Rapier) Date: Thu, 11 May 2006 11:17:33 -0400 Subject: Patch to add resume feature to scp In-Reply-To: References: <20060511054006.GE1397@crawfish.ais.com> Message-ID: <4463558D.4020006@psc.edu> > Sorry, but I agree: scp is pretty much unmaintainable as it is - > without throwing the complexity of multiple incompatible > implementations into the mix. > If you want to implement new feature, please base them on sftp. It > is a far saner protocol and many improvements only need changes on > the client. It also offers a clean protocol extension mechanism, so > changes that do require server support can be made without breaking > older clients. Based on the interactions I have with the people that make use of our facilities most people still prefer SCP especially when it comes to automated file transfer processes. Since SCP, as such, is unmaintainable maybe it makes sense to actually write a new SCP that incorporates the best points of the old version (ease of use, ease of scripting, etc) with more advanced features. That way backward compatibility is maintained without abandoning a useful and widely used file transfer tool. Something that makes use of the multiplex channels to handle file control information would allow concatenation of multiple files (the drop back into slow start with each file is a killer). Something that could do an auto resume would be great. Even better would be parallel file transfer, multiple streams for large (GB+) files, etc etc etc. Many of these features are available in things like GridFTP and bbFTP for example. Unfortunately, they are more difficult to use and users want the simplicity of SCP. Obviously you can make use of other tools in association with ssh (the concatenation can be done with tar for example) but I've always felt that isn't the right answer. Requiring a user to have X and Y in order to do Z when it makes sense for Z to be part of the application just seems counter intuitive. This is especially true when you are dealing with minimal installs (embedded systems, XP, etc). Without a doubt, this is just my opinion on things but it is based on dealing with a lot of users who ask for things like this. Chris From weigelt at metux.de Fri May 12 04:58:05 2006 From: weigelt at metux.de (Enrico Weigelt) Date: Thu, 11 May 2006 20:58:05 +0200 Subject: ctrl+s locks up ssh Message-ID: <20060511185805.GA25525@nibiru.local> Hi folks, I've noticed an problem with openssh on GNU/Linux: pressing ctrl+s locks up the ssh client. Only killing it helps. Is this problem already known ? cu -- --------------------------------------------------------------------- Enrico Weigelt == metux IT service phone: +49 36207 519931 www: http://www.metux.de/ fax: +49 36207 519932 email: contact at metux.de cellphone: +49 174 7066481 --------------------------------------------------------------------- -- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops -- --------------------------------------------------------------------- From corsmith at gmail.com Fri May 12 05:05:48 2006 From: corsmith at gmail.com (Corey Smith) Date: Thu, 11 May 2006 15:05:48 -0400 Subject: ctrl+s locks up ssh In-Reply-To: <20060511185805.GA25525@nibiru.local> References: <20060511185805.GA25525@nibiru.local> Message-ID: <8061fbee0605111205o12e4e3dav9b26f85c3d999e87@mail.gmail.com> On 5/11/06, Enrico Weigelt wrote: > I've noticed an problem with openssh on GNU/Linux: > pressing ctrl+s locks up the ssh client. Only killing it helps. > > Is this problem already known ? That is called software flow-control AKA Xon/Xoff. Ctrl-s = Xoff (stops the flow) Ctrl-q = Xon (resumes the flow) This is a feature of your terminal and not a bug in ssh. -Corey Smith From girish1729 at yahoo.com Fri May 12 10:56:11 2006 From: girish1729 at yahoo.com (Girish Venkatachalam) Date: Thu, 11 May 2006 17:56:11 -0700 (PDT) Subject: The conclusion regarding resume patch Message-ID: <20060512005611.2503.qmail@web35605.mail.mud.yahoo.com> Dear folks, To me suspend and resume is not a fancy feature. It is a must have like all the other conveniences and simplicity that scp provides. I agree with Damien that this will cause multiple protocol versions to float around, but we can't make omelettes without breaking eggs. The question is how important is this feature? I would say it is very basic compared to other fancy features like multiple simultaneous file transfers and all that. To argue Damien's point again, we can have a protocol check in the beginning the way we have to check protocol 1 and 2, in the connect string, and interoperate. Please let me know your thoughts. regards, Girish __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From rapier at psc.edu Fri May 12 11:57:38 2006 From: rapier at psc.edu (Chris Rapier) Date: Thu, 11 May 2006 21:57:38 -0400 Subject: The conclusion regarding resume patch In-Reply-To: <20060512005611.2503.qmail@web35605.mail.mud.yahoo.com> References: <20060512005611.2503.qmail@web35605.mail.mud.yahoo.com> Message-ID: <4463EB92.8000509@psc.edu> Girish Venkatachalam wrote: > I would say it is very basic compared to other fancy > features like multiple simultaneous file transfers and > all that. Whether or not a feature is fancy really depends on your needs. I support a community that regularly using OC12s as their lower end long haul paths and 30Gb+ paths at the higher end (I2 and ETF research networks). Once the speed issues with SSH were resolved the two main features they want are a more intelligent approach to multiple file transfers in scp and a resume function (even at 800Mb/s when a 2TB transfer dies 1GB from the end its really annoying). Also just so you know, I was supporting your position regarding the resume feature. > To argue Damien's point again, we can have a protocol > check in the beginning the way we have to check > protocol 1 and 2, in the connect string, and > interoperate. Having had to play with that quite a bit for the HPN patch (www.psc.edu/networking/projects/hpn-ssh) dealing with versioning issues is pretty annoying and it rarely seems to be as straightforward as one would hope. While I'm not saying you shouldn't consider this it can really open up a can of worms. The main reason why I suggested a new incarnation of SCP as opposed to patching the old one was really to get around some of these issues. Chris From djm at mindrot.org Fri May 12 14:54:37 2006 From: djm at mindrot.org (Damien Miller) Date: Fri, 12 May 2006 14:54:37 +1000 (EST) Subject: The conclusion regarding resume patch In-Reply-To: <20060512005611.2503.qmail@web35605.mail.mud.yahoo.com> References: <20060512005611.2503.qmail@web35605.mail.mud.yahoo.com> Message-ID: On Thu, 11 May 2006, Girish Venkatachalam wrote: > To argue Damien's point again, we can have a protocol > check in the beginning the way we have to check > protocol 1 and 2, in the connect string, and > interoperate. You are referring to the SSH protcol negotiation. There is no "scp protocol negotiation" which is why we cannot change the scp protocol. It doesn't matter how simple, meritorius or cool your feature is - if it changes the protocol then it will not be added to OpenSSH's scp implementation. If you want to work on something that has a change of being committed, then please help improve the sftp client. This means: - Adding recursive transfers (there is already a patch in bugzilla for one side of this) - Supporting a scp-like commandline syntax "sftp -r aaa foo:/bbb" - Improving the performance of multiple file transfers and remote glob operations (pipelining between files, caching attributes, etc.) Implementing the scp features that are currently missing in our sftp client is probably only a few days' work and would provide a much more sane base to implement new features like the one you propose. -d From tryponraj at gmail.com Fri May 12 16:25:26 2006 From: tryponraj at gmail.com (ponraj) Date: Fri, 12 May 2006 11:55:26 +0530 Subject: "ls -l" command and performance of sftp Message-ID: <007e01c6758c$eaf8c140$180110ac@pomco> Hi all, Patch to cache group and userids is attched along with this mail. The patch looks up the cache first before proceeding with getgrgid,getpwuid calls and thus reduces the amount of lookups and increases preformance in environments such as LDAP database. -- M.P ----- Original Message ----- From: ponraj To: openssh-unix-dev at mindrot.org Sent: Saturday, May 06, 2006 10:01 AM Subject: "ls -l" command and performance of sftp Hi all, I am using OpenSSH4.3p2. User database is stored in LDAP server.When I tried to list about 400 files using "ls -l" command in ftp and sftp, I observed that sftp took considerable amount of time greater than ftp. I suspect sftp does not cache the username and groupname lookups and makes fresh calls to getpwuid(), getgrgid() functions for each file that makes its performance worse. Any comments ? -- M.P -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: sftp_ls.txt Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20060512/98b5051b/attachment.txt From gert at greenie.muc.de Fri May 12 17:28:30 2006 From: gert at greenie.muc.de (Gert Doering) Date: Fri, 12 May 2006 09:28:30 +0200 Subject: The conclusion regarding resume patch In-Reply-To: <20060512005611.2503.qmail@web35605.mail.mud.yahoo.com> References: <20060512005611.2503.qmail@web35605.mail.mud.yahoo.com> Message-ID: <20060512072830.GL229@greenie.muc.de> Hi, On Thu, May 11, 2006 at 05:56:11PM -0700, Girish Venkatachalam wrote: > I agree with Damien that this will cause multiple > protocol versions to float around, but we can't make > omelettes without breaking eggs. So are you going to maintain the necessary code parts for the next 20 years? >From a developer's view, "user must have!" features quite often turn out to be a serious maintenance nightmare, especially if interoperability with old and new versions must be maintained. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany gert at greenie.muc.de fax: +49-89-35655025 gert at net.informatik.tu-muenchen.de From djm at mindrot.org Fri May 12 21:46:35 2006 From: djm at mindrot.org (Damien Miller) Date: Fri, 12 May 2006 21:46:35 +1000 (EST) Subject: "ls -l" command and performance of sftp In-Reply-To: <007e01c6758c$eaf8c140$180110ac@pomco> References: <007e01c6758c$eaf8c140$180110ac@pomco> Message-ID: On Fri, 12 May 2006, ponraj wrote: > Hi all, > > Patch to cache group and userids is attched along with this > mail. The patch looks up the cache first before proceeding with > getgrgid,getpwuid calls and thus reduces the amount of lookups and > increases preformance in environments such as LDAP database. Isn't that what nscd is for? -d From djm at mindrot.org Fri May 12 21:58:11 2006 From: djm at mindrot.org (Damien Miller) Date: Fri, 12 May 2006 21:58:11 +1000 (EST) Subject: "ls -l" command and performance of sftp In-Reply-To: <007e01c6758c$eaf8c140$180110ac@pomco> References: <007e01c6758c$eaf8c140$180110ac@pomco> Message-ID: On Fri, 12 May 2006, ponraj wrote: > Hi all, > > Patch to cache group and userids is attched along with this > mail. The patch looks up the cache first before proceeding with > getgrgid,getpwuid calls and thus reduces the amount of lookups and > increases preformance in environments such as LDAP database. BTW a related problem in sftp is that it effectively does the remote stat() operations twice during a remote glob(). The SSH2_FXP_READDIR operation returns an Attrib (the protocol's equivalent of "struct stat"), but we throw it away when we do a remote_glob() because the libc glob() API has no way to report this information back. For things like "ls -l" we end up doing a remote stat() because we need this information anyway... A relatively easy performance win would be to take the glob() implementation from OpenBSD's libc (also in openbsd-compat/ in portable OpenSSH) and modify its API so that it does native remote sftp operations and retains the Attrib information that they provide. Any takers? This is pretty small project... -d From dtucker at zip.com.au Fri May 12 22:06:57 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 12 May 2006 22:06:57 +1000 Subject: "ls -l" command and performance of sftp In-Reply-To: References: <007e01c6758c$eaf8c140$180110ac@pomco> Message-ID: <44647A61.2000809@zip.com.au> Damien Miller wrote: > On Fri, 12 May 2006, ponraj wrote: > >> Patch to cache group and userids is attched along with this >> mail. The patch looks up the cache first before proceeding with >> getgrgid,getpwuid calls and thus reduces the amount of lookups and >> increases preformance in environments such as LDAP database. > > Isn't that what nscd is for? Not all platforms have nscd, though. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From djm at mindrot.org Fri May 12 22:12:03 2006 From: djm at mindrot.org (Damien Miller) Date: Fri, 12 May 2006 22:12:03 +1000 (EST) Subject: "ls -l" command and performance of sftp In-Reply-To: <44647A61.2000809@zip.com.au> References: <007e01c6758c$eaf8c140$180110ac@pomco> <44647A61.2000809@zip.com.au> Message-ID: On Fri, 12 May 2006, Darren Tucker wrote: > Damien Miller wrote: > > On Fri, 12 May 2006, ponraj wrote: > > > > > Patch to cache group and userids is attched along with this > > > mail. The patch looks up the cache first before proceeding with > > > getgrgid,getpwuid calls and thus reduces the amount of lookups and > > > increases preformance in environments such as LDAP database. > > > > Isn't that what nscd is for? > > Not all platforms have nscd, though. What platforms have nsswitch but not nscd? -d From dtucker at zip.com.au Fri May 12 22:24:39 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 12 May 2006 22:24:39 +1000 Subject: "ls -l" command and performance of sftp In-Reply-To: References: <007e01c6758c$eaf8c140$180110ac@pomco> <44647A61.2000809@zip.com.au> Message-ID: <44647E87.1050101@zip.com.au> Damien Miller wrote: > On Fri, 12 May 2006, Darren Tucker wrote: >> Not all platforms have nscd, though. > > What platforms have nsswitch but not nscd? AIX (it's actually /etc/netsvc.conf, but it serves the same purpose). HP-UX (at least 11.00). I think also Tru64 but I'm not sure about that. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From cmadams at hiwaay.net Fri May 12 23:21:12 2006 From: cmadams at hiwaay.net (Chris Adams) Date: Fri, 12 May 2006 08:21:12 -0500 Subject: "ls -l" command and performance of sftp In-Reply-To: <44647E87.1050101@zip.com.au> References: <007e01c6758c$eaf8c140$180110ac@pomco> <44647A61.2000809@zip.com.au> <44647E87.1050101@zip.com.au> Message-ID: <20060512132112.GA1257070@hiwaay.net> Once upon a time, Darren Tucker said: > Damien Miller wrote: > > On Fri, 12 May 2006, Darren Tucker wrote: > >> Not all platforms have nscd, though. > > > > What platforms have nsswitch but not nscd? > > AIX (it's actually /etc/netsvc.conf, but it serves the same purpose). > HP-UX (at least 11.00). I think also Tru64 but I'm not sure about that. Tru64 has /etc/nsswitch.conf (previously /etc/svc.conf) but has no nscd or like service. However, the possibility is there I think via the Security Integration Architecture, so I'd say it isn't the business of OpenSSH to try to cache results. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From wdoud at us.ibm.com Sat May 13 00:42:17 2006 From: wdoud at us.ibm.com (Walter Doud) Date: Fri, 12 May 2006 10:42:17 -0400 Subject: How to log pubkey used in a keyring Message-ID: Hi, I'm trying to create a log of which key is being used to access a given account. I can turn auth.debug on, but that generates *copious* output to the log file which isn't terribly desirable. Furthermore, the log's format from one ssh implementation to the next varies, causes parsing complexities. Tried a kludge using the "command=/some/path/to/script " prefix on each key, where the script took the ID and logged it along with some of the other ssh variables. However that meant either exec'ing the command being sent from the remote system, or forcing the session into a specific shell. Is there any other way to determine what key is used? Thanks in advance, Walt Walter Doud UNIX System Administrator Information Technology Services Americas, Global Services, IBM From rapier at psc.edu Sat May 13 01:13:11 2006 From: rapier at psc.edu (Chris Rapier) Date: Fri, 12 May 2006 11:13:11 -0400 Subject: The conclusion regarding resume patch In-Reply-To: References: <20060512005611.2503.qmail@web35605.mail.mud.yahoo.com> Message-ID: <4464A607.7030605@psc.edu> Damien Miller wrote: > On Thu, 11 May 2006, Girish Venkatachalam wrote: > >> To argue Damien's point again, we can have a protocol >> check in the beginning the way we have to check >> protocol 1 and 2, in the connect string, and >> interoperate. > > You are referring to the SSH protcol negotiation. There is no > "scp protocol negotiation" which is why we cannot change the scp > protocol. I believe his idea was that by using the versioning information that is passed along at the initial negotiation you can tune feature sets to suit the server. Being that OpenSSH is already doing this it doesn't seem to be a excessive leap to apply it to this. That being said, the more that can be done to avoid the necessity of doing this the better. > It doesn't matter how simple, meritorius or cool your feature is - > if it changes the protocol then it will not be added to OpenSSH's > scp implementation. I understand why OpenSSH doesn't want to bother with scp anymore. Its really not the best solution to the problem. However, my feeling is that the developers will not be able to lead the users to water in this regard. The users *want* the functionality of scp and so they'll continue to use it even though sftp is a better solution. I think the only way to get rid of scp and lose the need to maintain the code ad infinitum is to make some mode of sftp act like scp and then use a symbolic link to maintain the scp name. If this isn't going to happen then the fact is that people will continue to use scp and will ask for improvements to, and submit patches for, scp. > - Supporting a scp-like commandline syntax "sftp -r aaa foo:/bbb" Of course to replace scp you'll need to copy most if not all of the command line structure syntax or its going to break thousands of scripts. I've actually talked to a couple of hundred users (people I met at various academic and industry high performance computing conferences) about this issue. A good percentage don't even know about sftp (no, they aren't idiots) and those that do want the simplicity of the scp interface. I've asked them about replacements to scp and they've also said they're only really interested in drop in replacements because they don't want the hassle of fixing a multitude of scripts, cronjobs, and so forth. > - Improving the performance of multiple file transfers and remote > glob operations (pipelining between files, caching attributes, etc.) So this interests me - what is the problem with multiple file transfers? > Implementing the scp features that are currently missing in our sftp > client is probably only a few days' work and would provide a much more > sane base to implement new features like the one you propose. My feeling is that the scp like functionality would probably be the most fruitful avenue at this time. It means on the next release you could just get rid of all the scp code. Then if anyone asks to patch scp you can say "what scp? its just a link to sftp" :) Has anyone looked at the performance differentials between scp and sftp for common tasks? From f_mohr at yahoo.de Sat May 13 01:55:55 2006 From: f_mohr at yahoo.de (frank mohr) Date: Fri, 12 May 2006 08:55:55 -0700 (PDT) Subject: How to log pubkey used in a keyring In-Reply-To: Message-ID: <20060512155555.8616.qmail@web25701.mail.ukl.yahoo.com> Hi without patching the sshd, the easiest way is to run it with LogLevel VERBOSE and parse the log for Found matching key: messages. if you search the list archive, you find several patches that add a log message for the key comment frank --- Walter Doud wrote: > > Hi, > > I'm trying to create a log of which key is being used to access a > given > account. > > I can turn auth.debug on, but that generates *copious* output to the > log > file which isn't terribly desirable. Furthermore, the log's format > from > one ssh implementation to the next varies, causes parsing > complexities. > > Tried a kludge using the "command=/some/path/to/script " prefix > on > each key, where the script took the ID and logged it along with some > of the > other ssh variables. However that meant either exec'ing the command > being > sent from the remote system, or forcing the session into a specific > shell. > > Is there any other way to determine what key is used? > > Thanks in advance, > Walt > > Walter Doud > UNIX System Administrator > Information Technology Services Americas, Global Services, IBM > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From william at 25thandClement.com Sat May 13 03:00:46 2006 From: william at 25thandClement.com (William Ahern) Date: Fri, 12 May 2006 10:00:46 -0700 Subject: The conclusion regarding resume patch In-Reply-To: <4464A607.7030605@psc.edu> References: <20060512005611.2503.qmail@web35605.mail.mud.yahoo.com> <4464A607.7030605@psc.edu> Message-ID: <20060512170046.GA7753@orville.25thandClement.com> On Fri, May 12, 2006 at 11:13:11AM -0400, Chris Rapier wrote: > Of course to replace scp you'll need to copy most if not all of the > command line structure syntax or its going to break thousands of > scripts. I've actually talked to a couple of hundred users (people I met > at various academic and industry high performance computing conferences) > about this issue. A good percentage don't even know about sftp (no, they > aren't idiots) and those that do want the simplicity of the scp For some definitions of "idiot". ;) I think at this point it sounds like there's been a meeting of minds. An sftp which has been taught to emulate scp, or which has been gifted with sufficient capabilites where emulation can be accomplished easily threw a script, for instance. I can't wait to see the code. - Bill From rapier at psc.edu Sat May 13 03:47:24 2006 From: rapier at psc.edu (Chris Rapier) Date: Fri, 12 May 2006 13:47:24 -0400 Subject: The conclusion regarding resume patch In-Reply-To: <20060512170046.GA7753@orville.25thandClement.com> References: <20060512005611.2503.qmail@web35605.mail.mud.yahoo.com> <4464A607.7030605@psc.edu> <20060512170046.GA7753@orville.25thandClement.com> Message-ID: <4464CA2C.1020606@psc.edu> William Ahern wrote: > On Fri, May 12, 2006 at 11:13:11AM -0400, Chris Rapier wrote: >> Of course to replace scp you'll need to copy most if not all of the >> command line structure syntax or its going to break thousands of >> scripts. I've actually talked to a couple of hundred users (people I met >> at various academic and industry high performance computing conferences) >> about this issue. A good percentage don't even know about sftp (no, they >> aren't idiots) and those that do want the simplicity of the scp > > For some definitions of "idiot". ;) Well, most of them hold at least one PhD in things like physics, chemistry, molecular biology, and the like. They are comfortable with computers but they are tool users and not computer people if you know what I mean. > I think at this point it sounds like there's been a meeting of minds. An > sftp which has been taught to emulate scp, or which has been gifted with > sufficient capabilites where emulation can be accomplished easily threw a > script, for instance. Ya know, an advanced enough script could actually do all of that. Take the command line parameters and build a script to be fed into sftp. Of course, that would just be a whole different world of problems. I'm also loathe to make assumptions about what users may or may not have installed now or in the future (it would also be a limiting feature if it depended on perl or even sh in as far as portability to non unix system goes). > I can't wait to see the code. Me too ;) Maybe I should go hire another student... Chris From mstone at mathom.us Sat May 13 10:47:38 2006 From: mstone at mathom.us (Michael Stone) Date: Fri, 12 May 2006 20:47:38 -0400 Subject: Patch to add resume feature to scp In-Reply-To: <4463558D.4020006@psc.edu> References: <20060511054006.GE1397@crawfish.ais.com> <4463558D.4020006@psc.edu> Message-ID: <20060513004737.GB16533@mathom.us> On Thu, May 11, 2006 at 11:17:33AM -0400, you wrote: >Based on the interactions I have with the people that make use of our >facilities most people still prefer SCP especially when it comes to >automated file transfer processes. Since SCP, as such, is unmaintainable >maybe it makes sense to actually write a new SCP that incorporates the >best points of the old version (ease of use, ease of scripting, etc) >with more advanced features. That way backward compatibility is >maintained without abandoning a useful and widely used file transfer tool. Or, just change/add an interface to sftp. I can't think of any generally useful feature of scp that can't be implemented fairly cleanly over the sftp protocol. Mike Stone From adam at skullslayer.rod.org Sun May 14 19:02:04 2006 From: adam at skullslayer.rod.org (adam at skullslayer.rod.org) Date: Sun, 14 May 2006 19:02:04 +1000 Subject: scp patch to delete source files after copy Message-ID: <20060514090204.GA32007@port.my.lan> At work we have a large collection of scripts to move log and config files around. These depend on commercial (F-Secure) ssh/scp, as it supports the -u option to delete the source file after (successful) copying. That is the sole reason we can't run openssh on our 150+ unix boxes. I have attached a patch below, which adds the -u option to delete the source file after copying, provided there were no errors. I would appreciate any feedback on this patch, with an aim to seeing it included in future releases. Adam *** scp.c 2006-01-31 22:11:38.000000000 +1100 --- scp.c.new 2006-05-14 18:11:14.000000000 +1000 *************** *** 99,104 **** --- 99,107 ---- /* This is set to zero if the progressmeter is not desired. */ int showprogress = 1; + /* Delete the source after copying. */ + int delete_source = 0; + /* This is the program to execute for the secured connection. ("ssh" or -S) */ char *ssh_program = _PATH_SSH_PROGRAM; *************** *** 278,284 **** addargs(&args, "-oClearAllForwardings yes"); fflag = tflag = 0; ! while ((ch = getopt(argc, argv, "dfl:prtvBCc:i:P:q1246S:o:F:")) != -1) switch (ch) { /* User-visible flags. */ case '1': --- 281,287 ---- addargs(&args, "-oClearAllForwardings yes"); fflag = tflag = 0; ! while ((ch = getopt(argc, argv, "dfl:prtuvBCc:i:P:q1246S:o:F:")) != -1) switch (ch) { /* User-visible flags. */ case '1': *************** *** 315,320 **** --- 318,326 ---- case 'S': ssh_program = xstrdup(optarg); break; + case 'u': + delete_source = 1; + break; case 'v': addargs(&args, "-v"); verbose_mode = 1; *************** *** 373,381 **** remin = remout = -1; do_cmd_pid = -1; /* Command to be executed on remote system using "ssh". */ ! (void) snprintf(cmd, sizeof cmd, "scp%s%s%s%s", verbose_mode ? " -v" : "", iamrecursive ? " -r" : "", pflag ? " -p" : "", targetshouldbedirectory ? " -d" : ""); (void) signal(SIGPIPE, lostconn); --- 379,388 ---- remin = remout = -1; do_cmd_pid = -1; /* Command to be executed on remote system using "ssh". */ ! (void) snprintf(cmd, sizeof cmd, "scp%s%s%s%s%s", verbose_mode ? " -v" : "", iamrecursive ? " -r" : "", pflag ? " -p" : "", + delete_source ? " -u" : "", targetshouldbedirectory ? " -d" : ""); (void) signal(SIGPIPE, lostconn); *************** *** 651,659 **** haderr = errno; fd = -1; } ! if (!haderr) (void) atomicio(vwrite, remout, "", 1); ! else run_err("%s: %s", name, strerror(haderr)); (void) response(); } --- 658,672 ---- haderr = errno; fd = -1; } ! if (!haderr) { ! if (delete_source) { ! if (verbose_mode) { ! fprintf(stderr, "Deleting source: %s\n", name); ! } ! unlink(name); ! } (void) atomicio(vwrite, remout, "", 1); ! } else run_err("%s: %s", name, strerror(haderr)); (void) response(); } *************** *** 1084,1090 **** usage(void) { (void) fprintf(stderr, ! "usage: scp [-1246BCpqrv] [-c cipher] [-F ssh_config] [-i identity_file]\n" " [-l limit] [-o ssh_option] [-P port] [-S program]\n" " [[user@]host1:]file1 [...] [[user@]host2:]file2\n"); exit(1); --- 1097,1103 ---- usage(void) { (void) fprintf(stderr, ! "usage: scp [-1246BCpqruv] [-c cipher] [-F ssh_config] [-i identity_file]\n" " [-l limit] [-o ssh_option] [-P port] [-S program]\n" " [[user@]host1:]file1 [...] [[user@]host2:]file2\n"); exit(1); *** scp.1 2006-01-20 11:31:47.000000000 +1100 --- scp.1.new 2006-05-14 18:59:35.000000000 +1000 *************** *** 20,26 **** .Sh SYNOPSIS .Nm scp .Bk -words ! .Op Fl 1246BCpqrv .Op Fl c Ar cipher .Op Fl F Ar ssh_config .Op Fl i Ar identity_file --- 20,26 ---- .Sh SYNOPSIS .Nm scp .Bk -words ! .Op Fl 1246BCpqruv .Op Fl c Ar cipher .Op Fl F Ar ssh_config .Op Fl i Ar identity_file *************** *** 188,193 **** --- 188,195 ---- The program must understand .Xr ssh 1 options. + .It Fl u + Deletes the source file after copying. .It Fl v Verbose mode. Causes From rapier at psc.edu Tue May 16 05:48:02 2006 From: rapier at psc.edu (Chris Rapier) Date: Mon, 15 May 2006 15:48:02 -0400 Subject: Problems with proxy connections Message-ID: <4468DAF2.4040303@psc.edu> Could someone explain to me how the proxy command regression test works? I'm having a problem as it relates to the HPN patch and could use a little insight into what is happening in the proxy connections. The back story is that the HPN patch was failing the regression tests when it his the proxy connections. It would just hang because the tcp window size that we get when a channel is created was returning 0. That set the internal receive buffer to 0 which just hung up everything. I was able to get around the problem by explicitly testing to see if the connection was on a socket with packet_connection_is_on_socket. If its false then I return an arbitrary value (in this case 128k). Otherwise I return the window size. I don't like this solution though because, even though I know it works, I don't know enough to know if its working in the right way. So the question is, what is this connection type and are there any thoughts on what the correct value would be to return? From kjhall at us.ibm.com Tue May 16 06:18:54 2006 From: kjhall at us.ibm.com (Kylene Jo Hall) Date: Mon, 15 May 2006 15:18:54 -0500 Subject: [PATCH 1/12] bug fix: openssh-4.3p2 memory leak Message-ID: <1147724335.29414.269.camel@localhost.localdomain> The variable cmd is xmalloc'd by buffer_get_string. It is then used in some places but never freed. This patch places the xfree after the last usage and within the confines of all paths. This entire set of patches passed the regression tests on my system. Memory leak bug found by Coverity. Signed-off-by: Kylene Hall --- clientloop.c | 2 ++ 1 files changed, 2 insertions(+) diff -uprN openssh-4.3p2/clientloop.c openssh-4.3p2-kylie/clientloop.c --- openssh-4.3p2/clientloop.c 2005-12-30 23:22:32.000000000 -0600 +++ openssh-4.3p2-kylie/clientloop.c 2006-05-04 10:36:49.000000000 -0500 @@ -833,6 +833,8 @@ client_process_control(fd_set * readset) debug2("%s: accepted tty %d, subsys %d, cmd %s", __func__, cctx->want_tty, cctx->want_subsys, cmd); + xfree(cmd); + /* Gather fds from client */ new_fd[0] = mm_receive_fd(client_fd); new_fd[1] = mm_receive_fd(client_fd); From adam at skullslayer.rod.org Tue May 16 18:22:49 2006 From: adam at skullslayer.rod.org (adam at skullslayer.rod.org) Date: Tue, 16 May 2006 18:22:49 +1000 Subject: scp patch to delete source files after copy In-Reply-To: <20060514090204.GA32007@port.my.lan> References: <20060514090204.GA32007@port.my.lan> Message-ID: <20060516082249.GB2724@port.my.lan> On Sun, May 14, 2006 at 07:02:04PM +1000, adam at skullslayer.rod.org wrote: > > I have attached a patch below, which adds the -u option to > delete the source file after copying, provided there were no > errors. I would appreciate any feedback on this patch, with > an aim to seeing it included in future releases. After thinking more about my patch, I have decided that this is not the best way to go about it. The commercial scp client is able to delete files on an openssh server, so obviously relying on the -u support on the server end is not correct. I will think about how to do it, then submit a new patch. Adam From kjhall at us.ibm.com Tue May 16 06:19:01 2006 From: kjhall at us.ibm.com (Kylene Jo Hall) Date: Mon, 15 May 2006 15:19:01 -0500 Subject: [PATCH 3/12] bug fix: openssh-4.3p2 resource leak Message-ID: <1147724342.29414.271.camel@localhost.localdomain> The file descriptor f is not closed in this error path. This patch adds the fclose as is customary in the rest of the function. This entire set of patches passed the regression tests on my system. Resource leak bug found by Coverity. Signed-off-by: Kylene Hall --- hostfile.c | 4 +++- 1 files changed, 3 insertions(+), 1 deletion(-) diff -uprN openssh-4.3p2/hostfile.c openssh-4.3p2-kylie/hostfile.c --- openssh-4.3p2/hostfile.c 2005-11-22 02:43:27.000000000 -0600 +++ openssh-4.3p2-kylie/hostfile.c 2006-05-04 13:51:10.000000000 -0500 @@ -254,8 +254,10 @@ check_host_in_hostfile_by_key_or_type(co if (key == NULL) { /* we found a key of the requested type */ - if (found->type == keytype) + if (found->type == keytype) { + fclose(f); return HOST_FOUND; + } continue; } From kjhall at us.ibm.com Tue May 16 06:18:58 2006 From: kjhall at us.ibm.com (Kylene Jo Hall) Date: Mon, 15 May 2006 15:18:58 -0500 Subject: [PATCH 2/12] bug fix: openssh-4.3p2 NULL dereference Message-ID: <1147724338.29414.270.camel@localhost.localdomain> The variable IV does can be NULL when passed into the function. However, IV is dereferenced in CMP, therefore, IV should be checked before sending it to this macro. This patch adds what is common in other parts of the code but is missing on this particular check. This entire set of patches passed the regression tests on my system. Null dereference bug found by Coverity. Signed-off-by: Kylene Hall --- deattack.c | 2 +- 1 files changed, 1 insertion(+), 1 deletion(-) diff -uprN openssh-4.3p2/deattack.c openssh-4.3p2-kylie/deattack.c --- openssh-4.3p2/deattack.c 2003-09-22 06:04:23.000000000 -0500 +++ openssh-4.3p2-kylie/deattack.c 2006-05-04 15:10:19.000000000 -0500 @@ -137,7 +137,7 @@ detect_attack(u_char *buf, u_int32_t len for (i = HASH(c) & (n - 1); h[i] != HASH_UNUSED; i = (i + 1) & (n - 1)) { if (h[i] == HASH_IV) { - if (!CMP(c, IV)) { + if (IV && !CMP(c, IV)) { if (check_crc(c, buf, len, IV)) return (DEATTACK_DETECTED); else From kjhall at us.ibm.com Tue May 16 06:19:04 2006 From: kjhall at us.ibm.com (Kylene Jo Hall) Date: Mon, 15 May 2006 15:19:04 -0500 Subject: [PATCH 4/12] bug fix: openssh-4.3p2 memory leak Message-ID: <1147724345.29414.272.camel@localhost.localdomain> If the operation in the function is not allowed memory is leaked in three variables which were xmalloc'ed with buffer_get_string. In the allowed case these variables are pointed to by variables with a greater scope thus the reason this is a condtional leak. This entire set of patches passed the regression tests on my system. Resource leak bugs found by Coverity. Signed-off-by: Kylene Hall --- monitor.c | 4 ++++ 1 files changed, 4 insertions(+) diff -uprN openssh-4.3p2/monitor.c openssh-4.3p2-kylie/monitor.c --- openssh-4.3p2/monitor.c 2005-11-04 22:07:05.000000000 -0600 +++ openssh-4.3p2-kylie/monitor.c 2006-05-08 17:18:15.697809744 -0500 @@ -1010,6 +1010,10 @@ mm_answer_keyallowed(int sock, Buffer *m key_blobtype = type; hostbased_cuser = cuser; hostbased_chost = chost; + } else { + xfree(blob); + xfree(chost); + xfree(cuser); } debug3("%s: key %p is %s", From kjhall at us.ibm.com Tue May 16 06:19:07 2006 From: kjhall at us.ibm.com (Kylene Jo Hall) Date: Mon, 15 May 2006 15:19:07 -0500 Subject: [PATCH 5/12] bug fix: openssh-4.3p2 scp bugs Message-ID: <1147724348.29414.273.camel@localhost.localdomain> There are 2 bugs here. The first is pipe's return code is not checked in this instance and it can return a negative value. The purpose of the call is to make sure 0 and 1 are not assigned to the pin and pout descriptors because those values won't work for later calls. If the pipe call fails the correct behavior cannot be ensured. This patch adds an error case consistent with the rest of the function. The second bug is a memory leak. arg is allocated with xstrdup. It is the assigned in some paths to another local variable but neither are ever freed. This patch adds the xfree. This entire set of patches passed the regression tests on my system. Bugs found by Coverity. Signed-off-by: Kylene Hall --- scp.c | 4 +++- 1 files changed, 3 insertions(+), 1 deletion(-) diff -uprN openssh-4.3p2/scp.c openssh-4.3p2-kylie/scp.c --- openssh-4.3p2/scp.c 2006-01-31 05:11:38.000000000 -0600 +++ openssh-4.3p2-kylie/scp.c 2006-05-08 15:15:04.016516104 -0500 @@ -181,7 +181,8 @@ do_cmd(char *host, char *remuser, char * * Reserve two descriptors so that the real pipes won't get * descriptors 0 and 1 because that will screw up dup2 below. */ - pipe(reserved); + if (pipe(reserved) < 0) + fatal("pipe: %s", strerror(errno)); /* Create a socket pair for communicating with ssh. */ if (pipe(pin) < 0) @@ -490,6 +491,7 @@ toremote(char *targ, int argc, char **ar source(1, argv + i); } } + xfree(arg); } void From kjhall at us.ibm.com Tue May 16 06:19:11 2006 From: kjhall at us.ibm.com (Kylene Jo Hall) Date: Mon, 15 May 2006 15:19:11 -0500 Subject: [PATCH 6/12] bug fix: openssh-4.3p2 memory leak Message-ID: <1147724351.29414.274.camel@localhost.localdomain> cancel_address is allocated in packet_get_string and used in the call to channel_cancel_rport_listener and then it goes out of scope. This patch adds the xfree. This entire set of patches passed the regression tests on my system. Resource leak bug found by Coverity. Signed-off-by: Kylene Hall --- serverloop.c | 1 + 1 files changed, 1 insertion(+) diff -uprN openssh-4.3p2/serverloop.c openssh-4.3p2-kylie/serverloop.c --- openssh-4.3p2/serverloop.c 2005-12-30 23:33:37.000000000 -0600 +++ openssh-4.3p2-kylie/serverloop.c 2006-05-03 16:52:06.000000000 -0500 @@ -1085,6 +1085,7 @@ server_input_global_request(int type, u_ success = channel_cancel_rport_listener(cancel_address, cancel_port); + xfree(cancel_address); } if (want_reply) { packet_start(success ? From kjhall at us.ibm.com Tue May 16 06:19:23 2006 From: kjhall at us.ibm.com (Kylene Jo Hall) Date: Mon, 15 May 2006 15:19:23 -0500 Subject: [PATCH 10/12 bugfix: openssh-4.3p2: memory leak Message-ID: <1147724363.29414.278.camel@localhost.localdomain> The variable local_user was allocated by xstrdup and is not freed or pointed to in this branch. This patch adds the xfree. This entire set of patches passed the regression tests on my system. Bug found by Coverity. Signed-off-by: Kylene Hall --- sshconnect.c | 1 + 1 files changed, 1 insertion(+) diff -uprN openssh-4.3p2/sshconnect.c openssh-4.3p2-kylie/sshconnect.c --- openssh-4.3p2/sshconnect.c 2005-12-13 02:29:03.000000000 -0600 +++ openssh-4.3p2-kylie/sshconnect.c 2006-05-04 10:07:57.000000000 -0500 @@ -937,6 +937,7 @@ ssh_login(Sensitive *sensitive, const ch } else { ssh_kex(host, hostaddr); ssh_userauth1(local_user, server_user, host, sensitive); + xfree(local_user); } } From kjhall at us.ibm.com Tue May 16 06:19:17 2006 From: kjhall at us.ibm.com (Kylene Jo Hall) Date: Mon, 15 May 2006 15:19:17 -0500 Subject: [PATCH 8/12] openssh-4.3p2 return code check bugs Message-ID: <1147724357.29414.276.camel@localhost.localdomain> The get_handle function can return a negative value. The variable that value is assigned to is eventually passed to handle_close which uses the value as an array index thus not being able to handle negative values. This patch adds the return code check and provides an appropriate error exit in the event of a negative return code. This entire set of patches passed the regression tests on my system. Bugs found by Coverity. Signed-off-by: Kylene Hall --- sftp-server.c | 27 +++++++++++++++++++++++++-- 1 files changed, 25 insertions(+), 2 deletions(-) diff -uprN openssh-4.3p2/sftp-server.c openssh-4.3p2-kylie/sftp-server.c --- openssh-4.3p2/sftp-server.c 2006-01-02 06:40:51.000000000 -0600 +++ openssh-4.3p2-kylie/sftp-server.c 2006-05-08 15:42:04.795120304 -0500 @@ -408,9 +408,12 @@ process_close(void) id = get_int(); handle = get_handle(); + if (handle < 0) + goto out; TRACE("close id %u handle %d", id, handle); ret = handle_close(handle); status = (ret == -1) ? errno_to_portable(errno) : SSH2_FX_OK; +out: send_status(id, status); } @@ -424,6 +427,8 @@ process_read(void) id = get_int(); handle = get_handle(); + if (handle < 0) + goto out; off = get_int64(); len = get_int(); @@ -450,6 +455,7 @@ process_read(void) } } } +out: if (status != SSH2_FX_OK) send_status(id, status); } @@ -461,10 +467,12 @@ process_write(void) u_int64_t off; u_int len; int handle, fd, ret, status = SSH2_FX_FAILURE; - char *data; + char *data = NULL; id = get_int(); handle = get_handle(); + if (handle < 0) + goto out; off = get_int64(); data = get_string(&len); @@ -488,8 +496,10 @@ process_write(void) } } } +out: send_status(id, status); - xfree(data); + if (data) + xfree(data); } static void @@ -539,6 +549,8 @@ process_fstat(void) id = get_int(); handle = get_handle(); + if (handle < 0) + goto out; TRACE("fstat id %u handle %d", id, handle); fd = handle_to_fd(handle); if (fd >= 0) { @@ -551,6 +563,7 @@ process_fstat(void) status = SSH2_FX_OK; } } +out: if (status != SSH2_FX_OK) send_status(id, status); } @@ -614,6 +627,10 @@ process_fsetstat(void) id = get_int(); handle = get_handle(); + if (handle < 0) { + status = SSH2_FX_FAILURE; + goto out; + } a = get_attrib(); TRACE("fsetstat id %u handle %d", id, handle); fd = handle_to_fd(handle); @@ -654,6 +671,7 @@ process_fsetstat(void) status = errno_to_portable(errno); } } +out: send_status(id, status); } @@ -697,6 +715,11 @@ process_readdir(void) id = get_int(); handle = get_handle(); + if (handle < 0) { + send_status(id, SSH2_FX_FAILURE); + return; + } + TRACE("readdir id %u handle %d", id, handle); dirp = handle_to_dir(handle); path = handle_to_name(handle); From kjhall at us.ibm.com Tue May 16 06:19:26 2006 From: kjhall at us.ibm.com (Kylene Jo Hall) Date: Mon, 15 May 2006 15:19:26 -0500 Subject: [PATCH 11/12] bugfix: openssh-4.3p2 variable reuse bug Message-ID: <1147724366.29414.279.camel@localhost.localdomain> Since the comment variable is used later in the function for other purposes. It is necessary to NULL the variable so it can be differentiated as a new allocation from the previous use remenants (which have already been freed) to avoid using an already freed pointer in the assignment comment = cp ? *cp : comment. When the code path is such that comment has not been reset. This entire set of patches passed the regression tests on my system. Bug found by Coverity. Signed-off-by: Kylene Hall --- ssh-keygen.c | 4 +++- 1 files changed, 3 insertions(+), 1 deletion(-) diff -uprN openssh-4.3p2/ssh-keygen.c openssh-4.3p2-kylie/ssh-keygen.c --- openssh-4.3p2/ssh-keygen.c 2005-11-28 20:10:25.000000000 -0600 +++ openssh-4.3p2-kylie/ssh-keygen.c 2006-05-03 16:23:38.000000000 -0500 @@ -485,8 +485,10 @@ do_fingerprint(struct passwd *pw) xfree(fp); exit(0); } - if (comment) + if (comment) { xfree(comment); + comment = NULL; + } f = fopen(identity_file, "r"); if (f != NULL) { From kjhall at us.ibm.com Tue May 16 06:19:30 2006 From: kjhall at us.ibm.com (Kylene Jo Hall) Date: Mon, 15 May 2006 15:19:30 -0500 Subject: [PATCH 12/12] bug fix: openssh 4.3p2 ssh-rand-helper bugs Message-ID: <1147724371.29414.280.camel@localhost.localdomain> There are 2 bugs here. Since mkdir can return an error. The rest of the function's operations depend on this directory being created thus an error should be handled at this point. The second is f is never closed. This patch adds the needed fclose. This entire set of patches passed the regression tests on my system. Bugs found by Coverity. Signed-off-by: Kylene Hall --- ssh-rand-helper.c | 4 +++- 1 files changed, 3 insertions(+), 1 deletion(-) diff -uprN openssh-4.3p2/ssh-rand-helper.c openssh-4.3p2-kylie/ssh-rand-helper.c --- openssh-4.3p2/ssh-rand-helper.c 2005-07-17 02:26:44.000000000 -0500 +++ openssh-4.3p2-kylie/ssh-rand-helper.c 2006-05-08 15:22:13.967153672 -0500 @@ -564,7 +564,8 @@ prng_write_seedfile(void) /* Try to ensure that the parent directory is there */ snprintf(filename, sizeof(filename), "%.512s/%s", pw->pw_dir, _PATH_SSH_USER_DIR); - mkdir(filename, 0700); + if (mkdir(filename, 0700) < 0) + fatal("mkdir: %s", strerror(errno)); snprintf(filename, sizeof(filename), "%.512s/%s", pw->pw_dir, SSH_PRNG_SEED_FILE); @@ -774,6 +775,7 @@ prng_read_commands(char *cmdfilename) debug("Loaded %d entropy commands from %.100s", cur_cmd, cmdfilename); + fclose(f); return cur_cmd < MIN_ENTROPY_SOURCES ? -1 : 0; } From kjhall at us.ibm.com Tue May 16 06:19:14 2006 From: kjhall at us.ibm.com (Kylene Jo Hall) Date: Mon, 15 May 2006 15:19:14 -0500 Subject: [PATCH 7/12] bugfix: openssh-4.3p2 Message-ID: <1147724354.29414.275.camel@localhost.localdomain> There are several memory management bugs here. First, the variable tmp is allocated by infer_path. In one path this allocating function is called again on the same variable without freeing the first instance. In another path the variable is just not freed. The fix is to add the xfree before the second call to infer_path and to move the existing xfree to cover both paths (in one case this is on the result of the first infer_path in the second it is on the second call. The second bug is deadcode. The abs_dst variable has always been freed by the time the value is checked to call xfree before return. This patch fixes both bugs. This entire set of patches passed the regression tests on my system. Bug found by Coverity. Signed-off-by: Kylene Hall --- sftp.c | 5 ++--- 1 files changed, 2 insertions(+), 3 deletions(-) diff -uprN openssh-4.3p2/sftp.c openssh-4.3p2-kylie/sftp.c --- openssh-4.3p2/sftp.c 2006-01-31 04:49:28.000000000 -0600 +++ openssh-4.3p2-kylie/sftp.c 2006-05-08 15:01:49.907239064 -0500 @@ -539,14 +539,15 @@ process_get(struct sftp_conn *conn, char if (g.gl_matchc == 1 && dst) { /* If directory specified, append filename */ if (is_dir(dst)) { + xfree(tmp); if (infer_path(g.gl_pathv[0], &tmp)) { err = 1; goto out; } abs_dst = path_append(dst, tmp); - xfree(tmp); } else abs_dst = xstrdup(dst); + xfree(tmp); } else if (dst) { abs_dst = path_append(dst, tmp); xfree(tmp); @@ -562,8 +563,6 @@ process_get(struct sftp_conn *conn, char out: xfree(abs_src); - if (abs_dst) - xfree(abs_dst); globfree(&g); return(err); } From kjhall at us.ibm.com Tue May 16 06:19:20 2006 From: kjhall at us.ibm.com (Kylene Jo Hall) Date: Mon, 15 May 2006 15:19:20 -0500 Subject: [PATCH 9/12] bug fix: openssh 4.3p2 possible NULL dereference Message-ID: <1147724360.29414.277.camel@localhost.localdomain> key is freed outside of the if that checks if key is NULL therefore, NULL could be sent to the key_free function which will not handle it correctly. The fix is to move key_free to a place where you know key is not NULL. This patch moves the key_free call. This entire set of patches passed the regression tests on my system. Bug found by Coverity. Signed-off-by: Kylene Hall --- ssh-agent.c | 2 +- 1 files changed, 1 insertion(+), 1 deletion(-) diff -uprN openssh-4.3p2/ssh-agent.c openssh-4.3p2-kylie/ssh-agent.c --- openssh-4.3p2/ssh-agent.c 2005-11-04 22:15:00.000000000 -0600 +++ openssh-4.3p2-kylie/ssh-agent.c 2006-05-04 15:05:48.000000000 -0500 @@ -305,8 +305,8 @@ process_sign_request2(SocketEntry *e) Identity *id = lookup_identity(key, 2); if (id != NULL && (!id->confirm || confirm_key(id) == 0)) ok = key_sign(id->key, &signature, &slen, data, dlen); + key_free(key); } - key_free(key); buffer_init(&msg); if (ok == 0) { buffer_put_char(&msg, SSH2_AGENT_SIGN_RESPONSE); From srinath_balaraman at mentor.com Wed May 17 00:13:02 2006 From: srinath_balaraman at mentor.com (Balaraman, Srinath) Date: Tue, 16 May 2006 09:13:02 -0500 Subject: [PATCH 10/12 bugfix: openssh-4.3p2: memory leak Message-ID: Kylene, Why is it that the "local_user" is being freed only in case of SSH1 and not in case of SSH2? Thanks, Srinath. -----Original Message----- From: openssh-unix-dev-bounces+srinath_balaraman=mentor.com at mindrot.org [mailto:openssh-unix-dev-bounces+srinath_balaraman=mentor.com at mindrot.or g] On Behalf Of Kylene Jo Hall Sent: Monday, May 15, 2006 3:19 PM To: openssh-devel Subject: [PATCH 10/12 bugfix: openssh-4.3p2: memory leak The variable local_user was allocated by xstrdup and is not freed or pointed to in this branch. This patch adds the xfree. This entire set of patches passed the regression tests on my system. Bug found by Coverity. Signed-off-by: Kylene Hall --- sshconnect.c | 1 + 1 files changed, 1 insertion(+) diff -uprN openssh-4.3p2/sshconnect.c openssh-4.3p2-kylie/sshconnect.c --- openssh-4.3p2/sshconnect.c 2005-12-13 02:29:03.000000000 -0600 +++ openssh-4.3p2-kylie/sshconnect.c 2006-05-04 10:07:57.000000000 -0500 @@ -937,6 +937,7 @@ ssh_login(Sensitive *sensitive, const ch } else { ssh_kex(host, hostaddr); ssh_userauth1(local_user, server_user, host, sensitive); + xfree(local_user); } } _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org http://www.mindrot.org/mailman/listinfo/openssh-unix-dev From markus.r.friedl at arcor.de Wed May 17 00:15:01 2006 From: markus.r.friedl at arcor.de (Markus Friedl) Date: Tue, 16 May 2006 16:15:01 +0200 Subject: [PATCH 2/12] bug fix: openssh-4.3p2 NULL dereference In-Reply-To: <1147724338.29414.270.camel@localhost.localdomain> References: <1147724338.29414.270.camel@localhost.localdomain> Message-ID: <20060516141501.GA3504@folly> IV is always valid in this case. however, we removed this code for the next release, since it's not used. On Mon, May 15, 2006 at 03:18:58PM -0500, Kylene Jo Hall wrote: > The variable IV does can be NULL when passed into the function. However, > IV is dereferenced in CMP, therefore, IV should be checked before > sending it to this macro. This patch adds what is common in other parts > of the code but is missing on this particular check. This entire set of > patches passed the regression tests on my system. Null dereference bug > found by Coverity. > > Signed-off-by: Kylene Hall > --- > deattack.c | 2 +- > 1 files changed, 1 insertion(+), 1 deletion(-) > > diff -uprN openssh-4.3p2/deattack.c openssh-4.3p2-kylie/deattack.c > --- openssh-4.3p2/deattack.c 2003-09-22 06:04:23.000000000 -0500 > +++ openssh-4.3p2-kylie/deattack.c 2006-05-04 15:10:19.000000000 -0500 > @@ -137,7 +137,7 @@ detect_attack(u_char *buf, u_int32_t len > for (i = HASH(c) & (n - 1); h[i] != HASH_UNUSED; > i = (i + 1) & (n - 1)) { > if (h[i] == HASH_IV) { > - if (!CMP(c, IV)) { > + if (IV && !CMP(c, IV)) { > if (check_crc(c, buf, len, IV)) > return (DEATTACK_DETECTED); > else > > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev From kjhall at us.ibm.com Wed May 17 00:37:40 2006 From: kjhall at us.ibm.com (Kylene Jo Hall) Date: Tue, 16 May 2006 09:37:40 -0500 Subject: [PATCH 10/12 bugfix: openssh-4.3p2: memory leak In-Reply-To: References: Message-ID: <1147790260.4836.24.camel@localhost.localdomain> It was because in the function ssh_userauth2 local_user is pointed to by a variable (authctx.local_user). However, upon closer examination that variable is local to the ssh_userauth2 function and I think local_user should be freed in both cases. Here is an updated patch. Signed-off-by: Kylene Hall --- sshconnect.c | 1 + 1 files changed, 1 insertion(+) --- openssh-4.3p2/sshconnect.c 2005-12-13 02:29:03.000000000 -0600 +++ openssh-4.3p2-kylie/sshconnect.c 2006-05-16 09:39:58.495647952 -0500 @@ -938,6 +938,7 @@ ssh_login(Sensitive *sensitive, const ch ssh_kex(host, hostaddr); ssh_userauth1(local_user, server_user, host, sensitive); } + xfree(local_user); } void On Tue, 2006-05-16 at 09:13 -0500, Balaraman, Srinath wrote: > Kylene, > > Why is it that the "local_user" is being freed only in case of SSH1 and > not in case of SSH2? > > Thanks, > Srinath. > > -----Original Message----- > From: openssh-unix-dev-bounces+srinath_balaraman=mentor.com at mindrot.org > [mailto:openssh-unix-dev-bounces+srinath_balaraman=mentor.com at mindrot.or > g] On Behalf Of Kylene Jo Hall > Sent: Monday, May 15, 2006 3:19 PM > To: openssh-devel > Subject: [PATCH 10/12 bugfix: openssh-4.3p2: memory leak > > The variable local_user was allocated by xstrdup and is not freed or > pointed to in this branch. This patch adds the xfree. This entire set > of patches passed the regression tests on my system. Bug found by > Coverity. > Signed-off-by: Kylene Hall > --- > sshconnect.c | 1 + > 1 files changed, 1 insertion(+) > > diff -uprN openssh-4.3p2/sshconnect.c openssh-4.3p2-kylie/sshconnect.c > --- openssh-4.3p2/sshconnect.c 2005-12-13 02:29:03.000000000 -0600 > +++ openssh-4.3p2-kylie/sshconnect.c 2006-05-04 10:07:57.000000000 > -0500 > @@ -937,6 +937,7 @@ ssh_login(Sensitive *sensitive, const ch > } else { > ssh_kex(host, hostaddr); > ssh_userauth1(local_user, server_user, host, sensitive); > + xfree(local_user); > } > } > > > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev From markus.r.friedl at arcor.de Wed May 17 00:46:47 2006 From: markus.r.friedl at arcor.de (Markus Friedl) Date: Tue, 16 May 2006 16:46:47 +0200 Subject: [PATCH 8/12] openssh-4.3p2 return code check bugs In-Reply-To: <1147724357.29414.276.camel@localhost.localdomain> References: <1147724357.29414.276.camel@localhost.localdomain> Message-ID: <20060516144647.GA22350@folly> On Mon, May 15, 2006 at 03:19:17PM -0500, Kylene Jo Hall wrote: > The get_handle function can return a negative value. The variable that > value is assigned to is eventually passed to handle_close which uses the > value as an array index thus not being able to handle negative values. > This patch adds the return code check and provides an appropriate error > exit in the event of a negative return code. This entire set of patches > passed the regression tests on my system. Bugs found by Coverity. i'm not sure about this one. we always call handle_is_ok() after get_handle(), so an error is sent back in any case. From kjhall at us.ibm.com Wed May 17 00:49:46 2006 From: kjhall at us.ibm.com (Kylene Jo Hall) Date: Tue, 16 May 2006 09:49:46 -0500 Subject: [PATCH 8/12] openssh-4.3p2 return code check bugs In-Reply-To: <20060516144647.GA22350@folly> References: <1147724357.29414.276.camel@localhost.localdomain> <20060516144647.GA22350@folly> Message-ID: <1147790986.4836.27.camel@localhost.localdomain> On Tue, 2006-05-16 at 16:46 +0200, Markus Friedl wrote: > On Mon, May 15, 2006 at 03:19:17PM -0500, Kylene Jo Hall wrote: > > The get_handle function can return a negative value. The variable that > > value is assigned to is eventually passed to handle_close which uses the > > value as an array index thus not being able to handle negative values. > > This patch adds the return code check and provides an appropriate error > > exit in the event of a negative return code. This entire set of patches > > passed the regression tests on my system. Bugs found by Coverity. > > i'm not sure about this one. we always call handle_is_ok() > after get_handle(), so an error is sent back in any case. In the instances in this patch I don't see handle_is_ok being called. Is it called by some intermediate function that I didn't think to look in. Maybe adding handle_is_ok is the appropriate fix here instead of the way I dealt with it. From stuge-openssh-unix-dev at cdy.org Wed May 17 03:31:58 2006 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Tue, 16 May 2006 19:31:58 +0200 Subject: scp patch to delete source files after copy In-Reply-To: <20060516082249.GB2724@port.my.lan> References: <20060514090204.GA32007@port.my.lan> <20060516082249.GB2724@port.my.lan> Message-ID: <20060516173158.9950.qmail@cdy.org> On Tue, May 16, 2006 at 06:22:49PM +1000, adam at skullslayer.rod.org wrote: > I will think about how to do it, then submit a new patch. Running sshd under strace, ktrace, truss or similar could prove informative if standard logging doesn't provide enough detail. //Peter From rob at inversepath.com Wed May 17 17:14:51 2006 From: rob at inversepath.com (Rob Holland) Date: Wed, 17 May 2006 00:14:51 -0700 Subject: Patch to abstract key sources Message-ID: <446ACD6B.1070406@inversepath.com> Hi, Attached is a patch to allow multiple files and/or pipes to be read when searching for keys. The patch centralises the file reading code into one place, rather than repeating it amongst several files as it was previously. It also allows reading keys from a pipe as well as files. This functionality is not used in the current patch. The eventual goal is to make custom key sources, such as searching LDAP or a database, easier to write and maintain. Currently things such as the openssh-lpk patch are quite invasive and must track upstream openssh carefully with each release. If we allow reading of keys from a pipe, the abstraction allows the two things to remain seperate. Please let me know your thoughts on the patch and/or the idea in general. Thanks, Rob -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: openssh-keysource.patch Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20060517/805c1e6f/attachment.ksh From weigelt at metux.de Sat May 20 01:02:06 2006 From: weigelt at metux.de (Enrico Weigelt) Date: Fri, 19 May 2006 17:02:06 +0200 Subject: detachable ssh sessions / ssh terminal server Message-ID: <20060519150206.GA10499@nibiru.local> Hi folks, is there an solution for an detachable ssh (like an terminal server, but for text console) ? I imagine something like what screen(1) does, but integrated into ssh: + if an connection breaks down, the session (an all processes) remain running an can be re-attached. + all active sessions can be queried + the output of sessions can be logged and retrieved later + xterm window title settings are recorded and shown on query + additional monitors (ie. via external programs) can be set up to do something on certain events, ie. notify the user if an detached session gets back to the shell If such an solution doesn't exist already, could anyone please give me some hints, how to implement this ? (probably could be done as an subsystem ?) thx -- --------------------------------------------------------------------- Enrico Weigelt == metux IT service phone: +49 36207 519931 www: http://www.metux.de/ fax: +49 36207 519932 email: contact at metux.de cellphone: +49 174 7066481 --------------------------------------------------------------------- -- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops -- --------------------------------------------------------------------- From stuge-openssh-unix-dev at cdy.org Sat May 20 04:04:40 2006 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Fri, 19 May 2006 20:04:40 +0200 Subject: detachable ssh sessions / ssh terminal server In-Reply-To: <20060519150206.GA10499@nibiru.local> References: <20060519150206.GA10499@nibiru.local> Message-ID: <20060519180441.15001.qmail@cdy.org> On Fri, May 19, 2006 at 05:02:06PM +0200, Enrico Weigelt wrote: > I imagine something like what screen(1) does, but integrated > into ssh: Why would screen be included into ssh? :) Just use screen on it's own. > + xterm window title settings are recorded and shown on query Check out x11vnc. > + additional monitors (ie. via external programs) can be > set up to do something on certain events, ie. notify the > user if an detached session gets back to the shell bash can do this. > If such an solution doesn't exist already, could anyone please > give me some hints, how to implement this ? > (probably could be done as an subsystem ?) IMHO the best way to accomplish what you want is to combine some of the tools already available that solve the exact same problems. //Peter From rapier at psc.edu Sat May 20 07:33:52 2006 From: rapier at psc.edu (Chris Rapier) Date: Fri, 19 May 2006 17:33:52 -0400 Subject: New HPN Patch Released Message-ID: <446E39C0.1070901@psc.edu> The HPN12 patch available from http://www.psc.edu/networking/projects/hpn-ssh addresses performance issues with bulk data transfer over high bandwidth delay paths. By adjusting internal flow control buffers to better fit the outstanding data capacity of the path significant improvements in bulk data throughput performance are achieved. In other words, transfers over the internet are a lot faster with this patch. Increase in performance of more than an order of magnitude are pretty common. If you make use of the now included NONE cipher I've hit data rates of more than 800Mbps between Pittsburgh and Chicago and 650Mbps between Pittsburgh and San Diego. The NONE cipher is only used during the bulk data transfer and *not* during authentication. This version of the patch makes the NONE cipher a server side configuration option so you don't have to enable it if you don't want to. Command line switches have been abandoned in favor of configuration options which are outlined below and in the HPN12-README included in the patch. Other versions of the patch showed some performance decrease in local area network transfers. I've addressed this by changing the size of one of the buffers (thanks Darren) and giving people the option of turning off HPN functionality. I've done my best to verify this by running several thousand tests and analyzing the results. These results are available from http://www.psc.edu/networking/projects/hpn-ssh/results.html However, there is always the chance that new problems have been introduced that didn't show up in my environment. So while I am reasonably confident there are no problems with this patch use al appropriate caution especially in production environments. Configuration options for HPN: TcpRcvBuf=[int] (KB) client set the TCP socket receive buffer to n Kilobytes. It can be set up to the maximum socket size allowed by the system. This is useful in situations where the tcp receive window is set low but the maximum buffer size is set higher (as is typical). This works on a per TCP connection basis. You can also use this to artificially limit the transfer rate of the connection. In these cases the throughput will be no more than n/RTT. The minimum buffer size is 1KB. Default is the current system wide tcp receive buffer size. TcpRcvBufPoll=[yes/no] client/server enable of disable the polling of the tcp receive buffer through the life of the connection. You would want to make sure that this option is enabled for systems making use of autotuning kernels (linux 2.4.24+, 2.6, MS Vista) default is no. NoneEnabled=[yes/no] client/server enable or disable the use of the None cipher. Care must always be used when enabling this as it will allow users to send data in the clear. However, it is important to note that authentication information remains encrypted even if this option is enabled. Set to no by default. NoneSwitch=[yes/no] client Switch the encryption cipher being used to the None cipher after authentication takes place. NoneEnabled must be enabled on both the client and server side of the connection. The connection attempt will fail with an error if a client requests a NoneSwitch from the server that does not explicitly have NoneEnabled set to yes. Set to no by default. HPNDisabled=[yes/no] client/server In some situations, such as transfers on a local area network, the impact of the HPN code produces a net decrease in performance. In these cases it is helpful to disable the HPN functionality. By default HPNDisabled is set to no. HPNBufferSize=[int] (KB) client/server This is the default buffer size the HPN functionality uses when interacting with nonHPN SSH installations. Conceptually this is similar to the TcpRcvBuf option as applied to the internal SSH flow control. This value can range from 1KB to 14MB (1-14336). Use of oversized or undersized buffers can cause performance problems depending on the length of the network path. The default size of this buffer is 2MB. TcpRcvBufPoll, if set to yes, will override this value. This behaviour may change in future versions. Comments, questions, and especially critiques are always welcome. Note: I did not attach the patch, as is customary, because its around 1900 lines. Chris Rapier Network Research & Application Engineer Pittsburgh Supercomputing Center From dtucker at zip.com.au Tue May 23 22:05:28 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 23 May 2006 22:05:28 +1000 Subject: Problems with proxy connections In-Reply-To: <4468DAF2.4040303@psc.edu> References: <4468DAF2.4040303@psc.edu> Message-ID: <4472FA88.2020707@zip.com.au> Chris Rapier wrote: > Could someone explain to me how the proxy command regression test works? > I'm having a problem as it relates to the HPN patch and could use a > little insight into what is happening in the proxy connections. Typically, the proxycommand is an external command that connects to the server somehow (eg directly, via a SOCKS server). Usually (but not necessarily) this will be over a TCP connection. In the case of the regress test, the proxycommand is actually a shell script that invokes sshd directly (in inetd mode, so it speaks the SSH protocol on its stdin/stdout) rather than making some kind of network connection. In fact the shell script wrapper isn't necessary, but it's there to redirect sshd's stderr for debugging purposes. > So the question is, what is this connection type and are there any > thoughts on what the correct value would be to return? Good question, but I don't have any answer other than "it depends". Your arbitrary value of 128k or similar sounds as good as any. A similar issue would also occur if a platform did not support the SO_RCVBUF socket option (dunno if such a platform exists, now or ever). -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From ron.flory at adtran.com Wed May 24 05:50:30 2006 From: ron.flory at adtran.com (ron flory) Date: Tue, 23 May 2006 14:50:30 -0500 Subject: Are there OpenSSH library coding examples Message-ID: <44736786.8020607@adtran.com> Hi- Apologies in advance if this is off-topic, but I've been unable to find any coding or usage examples on how to open a SSH client to a remote server. I'll happily RTFM if I can just find the FM (!). The client environment is x86 Linux 2.6.x, the remote SSH servers will be on proprietary embedded devices. My current application uses a socket interface and select() to communicate with local serial ports and/or remote TCP/telnet ports. I need to extend this C++ program to also support communication to remote servers over SSH. I would prefer to not 'hook into' other commandline applications. Is this a practical exercise? Thank-you for any suggestions. ron From dkg-openssh.com at fifthhorseman.net Wed May 24 07:06:23 2006 From: dkg-openssh.com at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 23 May 2006 17:06:23 -0400 Subject: Are there OpenSSH library coding examples In-Reply-To: <44736786.8020607@adtran.com> References: <44736786.8020607@adtran.com> Message-ID: <17523.31055.683308.947647@localhost.localdomain> Hi Ron-- On May 23, ron.flory at adtran.com said: > I need to extend this C++ program to also support communication to > remote servers over SSH. I would prefer to not 'hook into' other > commandline applications. Is this a practical exercise? I believe the current feeling is that you should, in fact, hook into the other commandline applications. Interacting with the openssh tools as separate processes (using fork/exec, sockets, stdio, etc) is preferred to trying to link libssh.a (or other chunks of openssh) into your application directly. For example: http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=114721160324354&w=2 The folks on this list will probably be better able to give you advice if you follow that general strategy. It will also helps you with future maintenance: you can keep your openssh installation up to date without worrying about tweaking your own code to match a potentially-shifting API. The command-line interface tends to be stabler than the library calls. --dkg From djm at mindrot.org Wed May 24 12:35:16 2006 From: djm at mindrot.org (Damien Miller) Date: Wed, 24 May 2006 12:35:16 +1000 (EST) Subject: Are there OpenSSH library coding examples In-Reply-To: <44736786.8020607@adtran.com> References: <44736786.8020607@adtran.com> Message-ID: On Tue, 23 May 2006, ron flory wrote: > Hi- > > Apologies in advance if this is off-topic, but I've been > unable to find any coding or usage examples on how to open a > SSH client to a remote server. I'll happily RTFM if I can just > find the FM (!). The client environment is x86 Linux 2.6.x, > the remote SSH servers will be on proprietary embedded devices. It would be nice to offer a SSH client API, but we don't have one yet. libssh.a certainly isn't a client API, just an internal thing for functions shared between the various tools. The only way at present is to open the ssh client as a subprocess. This is what scp and sftp do, and it works very well. I suggest that you have a look at the sftp.c:connect_to_server() function to see how it is done there - it is very straightforward. -d From andrew.chace at gmail.com Wed May 24 13:10:58 2006 From: andrew.chace at gmail.com (Andrew) Date: Tue, 23 May 2006 22:10:58 -0500 Subject: Are there OpenSSH library coding examples In-Reply-To: References: <44736786.8020607@adtran.com> Message-ID: <1148440259.2572.48.camel@LatitudeFC5.network> On Wed, 2006-05-24 at 12:35 +1000, Damien Miller wrote: > On Tue, 23 May 2006, ron flory wrote: > > > Hi- > > > > Apologies in advance if this is off-topic, but I've been > > unable to find any coding or usage examples on how to open a > > SSH client to a remote server. I'll happily RTFM if I can just > > find the FM (!). The client environment is x86 Linux 2.6.x, > > the remote SSH servers will be on proprietary embedded devices. > > It would be nice to offer a SSH client API, but we don't have one > yet. libssh.a certainly isn't a client API, just an internal thing > for functions shared between the various tools. > > The only way at present is to open the ssh client as a subprocess. > This is what scp and sftp do, and it works very well. I suggest that > you have a look at the sftp.c:connect_to_server() function to see how > it is done there - it is very straightforward. > > -d Hello, New to the list, but I had the exact same question. Ron, I might suggest libssh2 [ http://libssh2.sourceforge.net ]. I haven't used any of their code yet, as I am considering trying to hack together a library from the OpenSSH code base. I haven't checked with anyone on this yet regarding licenses, developers' projects, etc. It's on my todo list :-). Also, there is another called libssh [ http://www.0xbadc0de.be/?part=libssh ]. I think it's considered 'alpha' though. Hope that is of some help... -Andrew From Justin.Clift at aig.com Wed May 24 18:05:12 2006 From: Justin.Clift at aig.com (Clift, Justin) Date: Wed, 24 May 2006 04:05:12 -0400 Subject: Patches to enable logging of sftp and scp Message-ID: Hi all, Looking around for a way to turn on server side logging of files transferred via sftp/scp, these kept-up-to-date patches cropped up: For SFTP http://sftplogging.sourceforge.net For SCP http://sweb.cz/v_t_m/ (near the bottom) Would someone from the OpenSSH team have time/inclination enough to look at adding these to OpenSSH itself? Regards and best wishes, Justin Clift Unix Administrator AIG - ICT Operations Group 553 St. Kilda Road Melbourne, Vic 3004 Email: justin.clift at aig.com Mobile: 0423 968 373 From stuge-openssh-unix-dev at cdy.org Thu May 25 05:02:39 2006 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Wed, 24 May 2006 21:02:39 +0200 Subject: Are there OpenSSH library coding examples In-Reply-To: <1148440259.2572.48.camel@LatitudeFC5.network> References: <44736786.8020607@adtran.com> <1148440259.2572.48.camel@LatitudeFC5.network> Message-ID: <20060524190240.2705.qmail@cdy.org> On Tue, May 23, 2006 at 10:10:58PM -0500, Andrew wrote: > Also, there is another called libssh Getting off-topic now, but yet another SSH client implementation is PuTTY, which is portable, self-contained and public domain. //Peter From dinoklein at hotmail.com Thu May 25 05:38:49 2006 From: dinoklein at hotmail.com (Dino Klein) Date: Wed, 24 May 2006 15:38:49 -0400 Subject: SSH Doesn't Close stdio/err When Backgrounded Message-ID: Hi, I've recently started employing the opportunistic multiplexing feature, and I've come across what seems like a bug. Here's how it goes: in Fedora Core 5 I run the Gnome terminal application, and open two terminals (two tabs). In the first terminal I initiate an ssh connetion that becomes the master for multiplexing; in the second terminal I open a second terminal session to the same host. After this, I background the master on the first terminal via "~&"; even though the process forked, it still had the I/O/Err descriptors open according to /proc/$PID/fd. Now, the funny part - if I run ssh in first terminal with the same target host, it opens the connection through the master, but I cannot do anything since the input seems to be hijacked by the backgrounded master. This does not manifest itself if I do anything else locally, eg running ls or vi. Furthermore, after goning through the input-hijacking mention above, the backgrounded master won't terminate even after all connection through it finish (even after killing the defunt session which has no input). Also, this is reproducible. From fcusack at fcusack.com Thu May 25 07:07:34 2006 From: fcusack at fcusack.com (Frank Cusack) Date: Wed, 24 May 2006 14:07:34 -0700 Subject: Are there OpenSSH library coding examples In-Reply-To: <20060524190240.2705.qmail@cdy.org> References: <44736786.8020607@adtran.com> <1148440259.2572.48.camel@LatitudeFC5.network> <20060524190240.2705.qmail@cdy.org> Message-ID: <5555F3AD0D41D6752542AE46@maguro.local> On May 24, 2006 9:02:39 PM +0200 Peter Stuge wrote: > Getting off-topic now, but yet another SSH client implementation is > PuTTY, which is portable, self-contained and public domain. PuTTY is most certainly not public domain. -frank From stuge-openssh-unix-dev at cdy.org Thu May 25 10:09:50 2006 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Thu, 25 May 2006 02:09:50 +0200 Subject: Are there OpenSSH library coding examples In-Reply-To: <5555F3AD0D41D6752542AE46@maguro.local> References: <44736786.8020607@adtran.com> <1148440259.2572.48.camel@LatitudeFC5.network> <20060524190240.2705.qmail@cdy.org> <5555F3AD0D41D6752542AE46@maguro.local> Message-ID: <20060525000951.6552.qmail@cdy.org> On Wed, May 24, 2006 at 02:07:34PM -0700, Frank Cusack wrote: > > Getting off-topic now, but yet another SSH client implementation > > is PuTTY, which is portable, self-contained and public domain. > > PuTTY is most certainly not public domain. Certainly not! Thank you for correcting me! For the record: "The PuTTY executables and source code are distributed under the MIT licence, which is similar in effect to the BSD licence." Thanks again, sorry about the noise, I think I need vacation to stop making mistakes like this. //Peter From ron.flory at adtran.com Fri May 26 06:28:32 2006 From: ron.flory at adtran.com (ron flory) Date: Thu, 25 May 2006 15:28:32 -0500 Subject: Are there OpenSSH library coding examples In-Reply-To: <1148440259.2572.48.camel@LatitudeFC5.network> References: <44736786.8020607@adtran.com> <1148440259.2572.48.camel@LatitudeFC5.network> Message-ID: <44761370.4080408@adtran.com> >> On Tue, 23 May 2006, ron flory wrote: >> >>> Hi- >>> >>> Apologies in advance if this is off-topic, but I've been >>> unable to find any coding or usage examples on how to open a >>> SSH client to a remote server. I'll happily RTFM if I can just >>> find the FM (!). The client environment is x86 Linux 2.6.x, >>> the remote SSH servers will be on proprietary embedded devices. >> It would be nice to offer a SSH client API, but we don't have one >> yet. libssh.a certainly isn't a client API, just an internal thing >> for functions shared between the various tools. Andrew wrote: > Ron, I might suggest libssh2 [ http://libssh2.sourceforge.net ]. > I haven't used any of their code yet, as I am considering trying to > hack together a library from the OpenSSH code base. Thanks for the tip, libssh2 is just what I was looking for... The API docs are better than most but a simple coding example would be nice. They have a functional rather than socket interface so one must make explicit calls to send/rcv data, but if you can work around that it seems to be quite usable and straight-forward. Another thing would be nice- merge this lib/API into OpenSSH (hint, hint) ;) ron From alon.barlev at gmail.com Sun May 28 00:26:43 2006 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Sat, 27 May 2006 17:26:43 +0300 Subject: [ANNOUNCE] PKCS#11 support in OpenSSH 4.3p2 (version 0.11) Message-ID: <447861A3.1080105@gmail.com> Hello, The version 0.11 of "PKCS#11 support in OpenSSH" is published. Changes: 1. Updated against OpenSSH 4.3p2. 2. Modified against Roumen Petrov's X.509 patch (version 5.4), so self-signed certificates are treated by the X.509 patch now. 3. Added --pkcs11-x509-force-ssh if X.509 patch applied, until some issues with the X.509 patch are resolved. 4. Fixed issues with gcc-2. You can grab the new version from http://alon.barlev.googlepages.com/openssh-pkcs11. I will be glad to receive any feedback regarding this patch, so I will be able to adjust it closer to requirements, and extend the support for none-agent usage. The PKCS#11 support is provided by a pkcs11-helper implementation which is common for OpenVPN, QCA (Qt Cryptographic Architecture for KDE 4.0) and may be used by many other projects, one example is this patch for OpenSSH, there is also an initial support for xsupplicant and wpa_supplicant. Best Regards, Alon Bar-Lev. --- Instructions: The PKCS#11 patch modify ssh-add and ssh-agent to support PKCS#11 private keys and certificates. It allows using multiple PKCS#11 providers at the same time, selecting keys by id, label or certificate subject, handling card removal and card insert events, handling card re-insert to a different slot, supporting session expiration. A valid X.509 certificate should exist on the token, without X.509 support it is exported as regular RSA key. There is a simple utility Timo Felbinger wrote (http://www.timof.qipc.org/x509toOpenSSH.c) that extracts ssh public key from X.509 certificate. If you like X.509 support apply the X.509 (>=5.4) patch *AFTER* the PKCS#11 patch. One significant change is that the ssh-agent prompts for passwords now... So you need to configure it with a program that asks for card insert or PIN, a program such as x11-ssh-askpass. Current implementation (ssh-add asks for passwords) is not valid for dynamic smartcard environment. Current implementation uses the askpin program also for prompting card insert... Don't be confused, it only expects ok or cancel, attached is a simple scripts that uses KDE and .NET in order to display these dialogs. You can view full usage by: $ ssh-agent /bin/sh $ ssh-add -h A common scenario is the following: $ ssh-agent /bin/sh $ ssh-add --pkcs11-ask-pin `which openssh-kde-dialogs.sh` $ ssh-add --pkcs11-add-provider --pkcs11-provider /usr/lib/pkcs11/MyProvider.so $ ssh-add --pkcs11-add-id --pkcs11-slot-type label --pkcs11-slot "MyToken" --pkcs11-id-type subject --pkcs11-id "/C=XX/CN=YY" $ ssh myhost In order to see available objects, you can use: $ ssh-add --pkcs11-show-slots --pkcs11-provider /usr/lib/pkcs11/MyProvider.so $ ssh-add --pkcs11-show-objects --pkcs11-provider /usr/lib/pkcs11/MyProvider.so --pkcs11-slot 0 From vinschen at redhat.com Wed May 31 18:11:52 2006 From: vinschen at redhat.com (Corinna Vinschen) Date: Wed, 31 May 2006 10:11:52 +0200 Subject: Patch to add resume feature to scp In-Reply-To: <20060513004737.GB16533@mathom.us> References: <20060511054006.GE1397@crawfish.ais.com> <4463558D.4020006@psc.edu> <20060513004737.GB16533@mathom.us> Message-ID: <20060531081152.GA805@calimero.vinschen.de> On May 12 20:47, Michael Stone wrote: > On Thu, May 11, 2006 at 11:17:33AM -0400, you wrote: > >Based on the interactions I have with the people that make use of our > >facilities most people still prefer SCP especially when it comes to > >automated file transfer processes. Since SCP, as such, is unmaintainable > >maybe it makes sense to actually write a new SCP that incorporates the > >best points of the old version (ease of use, ease of scripting, etc) > >with more advanced features. That way backward compatibility is > >maintained without abandoning a useful and widely used file transfer tool. > > Or, just change/add an interface to sftp. I can't think of any generally > useful feature of scp that can't be implemented fairly cleanly over the > sftp protocol. I'm almost 100% sure that users could be trained using sftp if two scp command line options are added to sftp, -r and -p. Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat