From dgbaley27 at verizon.net Mon May 3 08:31:04 2010 From: dgbaley27 at verizon.net (Matthew Monaco) Date: Sun, 02 May 2010 18:31:04 -0400 Subject: ssh-agent man page misformatted with ./configure --with-mantype=man Message-ID: <4BDDFD28.2000705@verizon.net> I've noticed in 5.4p1 and 5.5p1 that the man page for ssh-agent is misformatted when using --with-mantype=man. In DESCRIPTION, all text after -t life is indented. The line that begins "If a commandline is given..." looks as if it's part of the -t option. From info at nomachine.com Wed May 5 19:56:18 2010 From: info at nomachine.com (NX Info) Date: Wed, 05 May 2010 11:56:18 +0200 Subject: NoMachine Makes OpenSSH Win32 Port Available Message-ID: <4BE140C2.4090006@nomachine.com> Hi all, We are happy to inform you that we have made available a Win32 port of OpenSSH. We have also created a dedicated area on our website along with the relevant build and installation instructions: http://www.nomachine.com/contributions.php. While still in the early stages and requiring a little more evolvement, the port includes both the client and the server and implements a majority of the functionalities found in the original code. As per the OpenSSH development standards, we have added the portability code to the pure version of OpenSSH. For a complete list of features and open issues, please consult our website: http://www.nomachine.com/news-read.php?idnews=312. /The NoMachine Team From postbus111 at gmail.com Fri May 7 02:49:53 2010 From: postbus111 at gmail.com (Hans Harder) Date: Thu, 6 May 2010 18:49:53 +0200 Subject: NoMachine Makes OpenSSH Win32 Port Available In-Reply-To: <4BE140C2.4090006@nomachine.com> References: <4BE140C2.4090006@nomachine.com> Message-ID: Nice.. I already use my own ssh server service for Win32, but that is currently based on another ssh library (see http://www.atbas.org/wssh/index.php , including sourcecode) I think i am going to look at your port of OpenSSH and see if I can use that as a base for it. Hans On Wed, May 5, 2010 at 11:56 AM, NX Info wrote: > Hi all, > > We are happy to inform you that we have made available a Win32 port of > OpenSSH. We have also created a dedicated area on our website along with > the relevant build and installation instructions: > > http://www.nomachine.com/contributions.php. > > While still in the early stages and requiring a little more evolvement, > the port includes both the client and the server and implements a majority > of the functionalities found in the original code. As per the OpenSSH > development standards, we have added the portability code to the pure > version of OpenSSH. > > For a complete list of features and open issues, please consult our website: > > http://www.nomachine.com/news-read.php?idnews=312. > > > /The NoMachine Team > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From postbus111 at gmail.com Fri May 7 21:18:35 2010 From: postbus111 at gmail.com (Hans Harder) Date: Fri, 7 May 2010 13:18:35 +0200 Subject: NoMachine Makes OpenSSH Win32 Port Available In-Reply-To: <4BE140C2.4090006@nomachine.com> References: <4BE140C2.4090006@nomachine.com> Message-ID: Is there a specific mailinglist or forum available for discussing this win32 port ? Hans On Wed, May 5, 2010 at 11:56 AM, NX Info wrote: > Hi all, > > We are happy to inform you that we have made available a Win32 port of > OpenSSH. We have also created a dedicated area on our website along with > the relevant build and installation instructions: > > http://www.nomachine.com/contributions.php. > > While still in the early stages and requiring a little more evolvement, > the port includes both the client and the server and implements a majority > of the functionalities found in the original code. As per the OpenSSH > development standards, we have added the portability code to the pure > version of OpenSSH. > > For a complete list of features and open issues, please consult our website: > > http://www.nomachine.com/news-read.php?idnews=312. > > > /The NoMachine Team > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From djm at mindrot.org Mon May 10 12:41:57 2010 From: djm at mindrot.org (Damien Miller) Date: Mon, 10 May 2010 12:41:57 +1000 (EST) Subject: Certificates and authorized principals Message-ID: Hi, Users who are interested in certificate authentication might be interested in this change: > - djm at cvs.openbsd.org 2010/05/07 11:30:30 > [auth-options.c auth-options.h auth.c auth.h auth2-pubkey.c key.c] > [servconf.c servconf.h sshd.8 sshd_config.5] > add some optional indirection to matching of principal names listed > in certificates. Currently, a certificate must include the a user's name > to be accepted for authentication. This change adds the ability to > specify a list of certificate principal names that are acceptable. > > When authenticating using a CA trusted through ~/.ssh/authorized_keys, > this adds a new principals="name1[,name2,...]" key option. > > For CAs listed through sshd_config's TrustedCAKeys option, a new config > option "AuthorizedPrincipalsFile" specifies a per-user file containing > the list of acceptable names. > > If either option is absent, the current behaviour of requiring the > username to appear in principals continues to apply. > > These options are useful for role accounts, disjoint account namespaces > and "user at realm"-style naming policies in certificates. > > feedback and ok markus@ -d From njleanne at hotmail.com Thu May 13 14:22:38 2010 From: njleanne at hotmail.com (lvleanne) Date: Thu, 13 May 2010 04:22:38 +0000 Subject: sshd dies if passed host key with relative path on command line Message-ID: Hi all, I noticed that openssh5.5 finally revised this bug, pls check the bugzilla https://bugzilla.mindrot.org/show_bug.cgi?id=1290 but when i test it both on linux and hp-ux, it will still fails: In hp-ux, server side: root at sshia2# /opt/ssh/sbin/sshd -p 1234 -D -h ssh_host_dsa_key -ddd .......... debug3: send_rexec_state: entering fd = 9 config len 322 debug3: ssh_msg_send: type 0 debug3: send_rexec_state: done debug1: rexec start in 6 out 6 newsock 6 pipe -1 sock 9 client side: $ ssh sshia2 -p 1234 -vvv OpenSSH_5.5p1+sftpfilecontrol-v1.3-hpn13v7, OpenSSL 0.9.8n 24 Mar 2010 HP-UX Secure Shell-A.05.50.002.LdapTest, HP-UX Secure Shell version debug1: Reading configuration data /opt/ssh/etc/ssh_config debug3: RNG is ready, skipping seeding debug2: ssh_connect: needpriv 0 debug1: Connecting to sshia2 [fe80::217:8ff:fe7c:d91c] port 1234. debug1: Connection established. debug1: identity file /home/user1/.ssh/id_rsa type -1 debug1: identity file /home/user1/.ssh/id_rsa-cert type -1 debug1: identity file /home/user1/.ssh/id_dsa type -1 debug1: identity file /home/user1/.ssh/id_dsa-cert type -1 ssh_exchange_identification: Connection closed by remote host Do somebody know this reason? Best Regards Leanne _________________________________________________________________ ?????????????????msn????? http://ditu.live.com/?form=TL&swm=1 From joachim at joachimschipper.nl Sat May 22 05:22:04 2010 From: joachim at joachimschipper.nl (Joachim Schipper) Date: Fri, 21 May 2010 21:22:04 +0200 Subject: [patch] Automatically add keys to agent In-Reply-To: <20100112002433.GC27817@polymnia.jschipper.dynalias.net> References: <20100112002433.GC27817@polymnia.jschipper.dynalias.net> Message-ID: <20100521192204.GA21446@polymnia.joachimschipper.nl> On Tue, Jan 12, 2010 at 01:24:34AM +0100, Joachim Schipper wrote: > My keys are secured with a passphrase. That's good for security, but > having to type the passphrase either at every login or at every > invocation of ssh(1) is annoying. > > I know I could invoke ssh-add(1) just before invoking ssh(1), if I keep > track of whether I invoked it already, or write some hacky scripts; but > the rest of OpenSSH is wonderfully usable without any hacks. > > Hence, this patch. I'll just quote ssh_config(5): > > AddKeyToAgent > If this option is set to ``yes'' and ssh-agent(1) is running, any > keys unlocked with a password will be added to the agent (with > the default lifetime). Setting this to ``ask'' will cause ssh to > require confirmation using the SSH_ASKPASS program before the key > is added (see ssh-add(1) for details). The argument must be > ``yes'', ``ask'', or ``no''. The default is ``no''. > > Having more knobs isn't really useful, IMHO. Default lifetime is > configurable via ssh-agent(1)'s -t flag, and if you want to confirm each > key use you should be willing to live without this convenience feature. > > By the way, are there plans to replace ask_permission() (also used for > other "ask" type options, e.g. ControlMaster) by something a little > more user-friendly? Having to type "yes" works, but isn't exactly > elegant. (Not volunteering here, I know nothing about X.) > > Please be gentle, but inspect thoroughly, as this is my first patch. I sent the above message to the list quite a while ago, and was told to put my (revised) patch in the bug tracker. It's at https://bugzilla.mindrot.org/show_bug.cgi?id=1699; is there anything I can do to help the process along? I am open to suggestions/criticisms/being told to drop this - but I think it'd be a shame if this falls through the cracks. Joachim From Seth.Ellsworth at quest.com Tue May 25 06:46:12 2010 From: Seth.Ellsworth at quest.com (Seth Ellsworth) Date: Mon, 24 May 2010 13:46:12 -0700 Subject: 5.2: Solaris 10 x86 x-11 forwarding fails, assign requested address Message-ID: <6592BDAF72405343BA096C66B735B38E02556E8270@alvxmbw04.prod.quest.corp> This is on Solaris 10 x86, do not see this behavior on Solaris 10 sparc. Seen on multiple machines. Sshd debug: debug1: server_input_channel_open: ctype session rchan 256 win 16384 max 16384 debug1: input_session_request debug1: channel 0: new [server-session] debug2: session_new: allocate (allocated 0 max 10) debug3: session_unused: session id 0 unused 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 x11-req reply 1 debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 req x11-req debug2: bind port 6010: Cannot assign requested address debug2: bind port 6011: Cannot assign requested address debug2: bind port 6012: Cannot assign requested address ... debug2: bind port 6997: Cannot assign requested address debug2: bind port 6998: Cannot assign requested address debug2: bind port 6999: Cannot assign requested address Failed to allocate internet-domain X11 display socket. debug1: x11_create_display_inet failed. In a previous version, 4.7, this worked, and looked like: debug1: server_input_channel_req: channel 0 request x11-req reply 1 debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 req x11-req debug2: bind port 6010: Cannot assign requested address debug2: fd 7 setting O_NONBLOCK debug3: fd 7 is O_NONBLOCK debug1: channel 1: new [X11 inet listener] debug1: server_input_channel_req: channel 0 request exec reply 1 Looking at differences between the 4.7 and 5.2 ( 5.5 is the same in this regards ), the difference seems to be in: channels.c Function: x11_create_display_inet Line:2908: ( 4.7p1 code ) if (ai->ai_next) continue; That's right after the bind fails. If I follow the behavior, the first ai from getaddrinfo is an IPV6 address that's not valid. Errno is EADDRNOTAVAIL. Now in 4.7 the continue would make it just try the next ai. In 5.2 that continue isn't there, so instead it breaks and tries the next port number, on the same ai, which fails all the way until MAX_DISPLAYS is reached. For this situation I want to put back the if/continue, but I assume it was removed for a reason, and wanted to find out if anyone here knew. Ok, found the cvsweb, and located this: Revision 1.272.2.1: download - view: text, markup, annotated - select for diffs Thu Apr 3 03:42:02 2008 UTC (2 years, 1 month ago) by brad Branches: OPENBSD_4_3 Diff to: previous 1.272: preferred, coloured; next MAIN 1.273: preferred, coloured Changes since revision 1.272: +1 -4 lines avoid possible hijacking of x11-forwarded connections (back out 1.183) CVE-2008-1483; ok djm@ Ok, this was removed to address an attack type. So, how do I fix this so I keep the needed behavior but don't introduce the vulnerability? The root of the problem seems to be getting an invalid IPV6 addrinfo, and that failure means it doesn't try any other addrofinfo's, instead looping on port's, which all fail, because the addrinfo always fails. How about adding it back under certain circumstances: sellswor at sethe:~/tmp/2/openssh-5.5p1> diff -u channels.c channels.c.orig --- channels.c 2010-05-24 14:44:15.000000000 -0600 +++ channels.c.orig 2010-05-24 14:43:32.000000000 -0600 @@ -3271,13 +3271,9 @@ if (x11_use_localhost) channel_set_reuseaddr(sock); if (bind(sock, ai->ai_addr, ai->ai_addrlen) < 0) { - int loc_errno = errno; debug2("bind port %d: %.100s", port, strerror(errno)); close(sock); - if( loc_errno == EADDRNOTAVAIL && ai->ai_next ) - continue; - for (n = 0; n < num_socks; n++) { close(socks[n]); } You have new mail in /var/spool/mail/sellswor sellswor at sethe:~/tmp/2/openssh-5.5p1> Thoughts? Am I approaching this wrong, and this shows a mis-configured machine? ( happens on multiple machines, all default setups connected to IPV4 networks ). --- Seth Ellsworth Vintela Development The people and products of Vintela are now a part of Quest Software. Read the press release to learn more. From peter at stuge.se Tue May 25 08:55:04 2010 From: peter at stuge.se (Peter Stuge) Date: Tue, 25 May 2010 00:55:04 +0200 Subject: 5.2: Solaris 10 x86 x-11 forwarding fails, assign requested address In-Reply-To: <6592BDAF72405343BA096C66B735B38E02556E8270@alvxmbw04.prod.quest.corp> References: <6592BDAF72405343BA096C66B735B38E02556E8270@alvxmbw04.prod.quest.corp> Message-ID: <20100524225504.23721.qmail@stuge.se> Seth Ellsworth wrote: > So, how do I fix this so I keep the needed behavior but don't > introduce the vulnerability? .. > Am I approaching this wrong, and this shows a mis-configured > machine? ( happens on multiple machines, all default setups > connected to IPV4 networks ). If they are only connected with v4 but your kernel has v6 support enabled then try running sshd -4 to make sshd only use v4. //Peter From Seth.Ellsworth at quest.com Tue May 25 09:41:07 2010 From: Seth.Ellsworth at quest.com (Seth Ellsworth) Date: Mon, 24 May 2010 16:41:07 -0700 Subject: 5.2: Solaris 10 x86 x-11 forwarding fails, assign requested address In-Reply-To: <4BFAF28A.1030602@anl.gov> References: <6592BDAF72405343BA096C66B735B38E02556E8270@alvxmbw04.prod.quest.corp> <4BFAF28A.1030602@anl.gov> Message-ID: <6592BDAF72405343BA096C66B735B38E02556E86C3@alvxmbw04.prod.quest.corp> Thanks, I'll see if those lead to anything on this. --- Seth Ellsworth Vintela Development The people and products of Vintela are now a part of Quest Software. Read the press release to learn more. -----Original Message----- From: Douglas E. Engert [mailto:deengert at anl.gov] Sent: Monday, May 24, 2010 3:42 PM To: Seth Ellsworth Cc: openssh-unix-dev at mindrot.org Subject: Re: 5.2: Solaris 10 x86 x-11 forwarding fails, assign requested address Seth Ellsworth wrote: > This is on Solaris 10 x86, do not see this behavior on Solaris 10 sparc. Seen on multiple machines. > > Sshd debug: > debug1: server_input_channel_open: ctype session rchan 256 win 16384 max 16384 > debug1: input_session_request > debug1: channel 0: new [server-session] > debug2: session_new: allocate (allocated 0 max 10) > debug3: session_unused: session id 0 unused > 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 x11-req reply 1 > debug1: session_by_channel: session 0 channel 0 > debug1: session_input_channel_req: session 0 req x11-req > debug2: bind port 6010: Cannot assign requested address > debug2: bind port 6011: Cannot assign requested address > debug2: bind port 6012: Cannot assign requested address > ... > debug2: bind port 6997: Cannot assign requested address > debug2: bind port 6998: Cannot assign requested address > debug2: bind port 6999: Cannot assign requested address > Failed to allocate internet-domain X11 display socket. > debug1: x11_create_display_inet failed. > > > In a previous version, 4.7, this worked, and looked like: > debug1: server_input_channel_req: channel 0 request x11-req reply 1 > debug1: session_by_channel: session 0 channel 0 > debug1: session_input_channel_req: session 0 req x11-req > debug2: bind port 6010: Cannot assign requested address > debug2: fd 7 setting O_NONBLOCK > debug3: fd 7 is O_NONBLOCK > debug1: channel 1: new [X11 inet listener] > debug1: server_input_channel_req: channel 0 request exec reply 1 > > > Looking at differences between the 4.7 and 5.2 ( 5.5 is the same in this regards ), the difference seems to be in: > channels.c > Function: x11_create_display_inet > Line:2908: ( 4.7p1 code ) > if (ai->ai_next) > continue; > That's right after the bind fails. > > If I follow the behavior, the first ai from getaddrinfo is an IPV6 address that's not valid. Errno is EADDRNOTAVAIL. > > Now in 4.7 the continue would make it just try the next ai. > In 5.2 that continue isn't there, so instead it breaks and tries the next port number, on the same ai, which fails all the way until MAX_DISPLAYS is reached. > > For this situation I want to put back the if/continue, but I assume it was removed for a reason, and wanted to find out if anyone here knew. > > > > Ok, found the cvsweb, and located this: > Revision 1.272.2.1: download - view: text, markup, annotated - select for diffs > Thu Apr 3 03:42:02 2008 UTC (2 years, 1 month ago) by brad > Branches: OPENBSD_4_3 > Diff to: previous 1.272: preferred, coloured; next MAIN 1.273: preferred, coloured > Changes since revision 1.272: +1 -4 lines > > avoid possible hijacking of x11-forwarded connections (back out 1.183) > > CVE-2008-1483; ok djm@ > > > Ok, this was removed to address an attack type. So, how do I fix this so I keep the needed behavior but don't introduce the vulnerability? > > The root of the problem seems to be getting an invalid IPV6 addrinfo, and that failure means it doesn't try any other addrofinfo's, instead looping on port's, which all fail, because the addrinfo always fails. > > How about adding it back under certain circumstances: > sellswor at sethe:~/tmp/2/openssh-5.5p1> diff -u channels.c channels.c.orig > --- channels.c 2010-05-24 14:44:15.000000000 -0600 > +++ channels.c.orig 2010-05-24 14:43:32.000000000 -0600 > @@ -3271,13 +3271,9 @@ > if (x11_use_localhost) > channel_set_reuseaddr(sock); > if (bind(sock, ai->ai_addr, ai->ai_addrlen) < 0) { > - int loc_errno = errno; > debug2("bind port %d: %.100s", port, strerror(errno)); > close(sock); > > - if( loc_errno == EADDRNOTAVAIL && ai->ai_next ) > - continue; > - > for (n = 0; n < num_socks; n++) { > close(socks[n]); > } > You have new mail in /var/spool/mail/sellswor > sellswor at sethe:~/tmp/2/openssh-5.5p1> > > Thoughts? Sounds like it is related to IPv6 Google for: ssh bind X11 ipv6 and also see: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=327443 > > Am I approaching this wrong, and this shows a mis-configured machine? ( happens on multiple machines, all default setups connected to IPV4 networks ). > --- > Seth Ellsworth > Vintela Development > The people and products of Vintela are now a part of Quest Software. > Read the press release to learn more. > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > > -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From Seth.Ellsworth at quest.com Tue May 25 09:43:32 2010 From: Seth.Ellsworth at quest.com (Seth Ellsworth) Date: Mon, 24 May 2010 16:43:32 -0700 Subject: 5.2: Solaris 10 x86 x-11 forwarding fails, assign requested address In-Reply-To: <20100524225504.23721.qmail@stuge.se> References: <6592BDAF72405343BA096C66B735B38E02556E8270@alvxmbw04.prod.quest.corp> <20100524225504.23721.qmail@stuge.se> Message-ID: <6592BDAF72405343BA096C66B735B38E02556E86D2@alvxmbw04.prod.quest.corp> That works, and setting listen-addrs to only IPV4 address works as well. This is in a package I provide to multiple distinct customers, and would prefer to fix it in a way that 'just works' across the board. Meaning no config needed, and still allows IPV6 if desired. --- Seth Ellsworth Vintela Development The people and products of Vintela are now a part of Quest Software. Read the press release to learn more. -----Original Message----- From: openssh-unix-dev-bounces+seth.ellsworth=quest.com at mindrot.org [mailto:openssh-unix-dev-bounces+seth.ellsworth=quest.com at mindrot.org] On Behalf Of Peter Stuge Sent: Monday, May 24, 2010 4:55 PM To: openssh-unix-dev at mindrot.org Subject: Re: 5.2: Solaris 10 x86 x-11 forwarding fails, assign requested address Seth Ellsworth wrote: > So, how do I fix this so I keep the needed behavior but don't > introduce the vulnerability? .. > Am I approaching this wrong, and this shows a mis-configured > machine? ( happens on multiple machines, all default setups > connected to IPV4 networks ). If they are only connected with v4 but your kernel has v6 support enabled then try running sshd -4 to make sshd only use v4. //Peter _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From deengert at anl.gov Tue May 25 07:41:30 2010 From: deengert at anl.gov (Douglas E. Engert) Date: Mon, 24 May 2010 16:41:30 -0500 Subject: 5.2: Solaris 10 x86 x-11 forwarding fails, assign requested address In-Reply-To: <6592BDAF72405343BA096C66B735B38E02556E8270@alvxmbw04.prod.quest.corp> References: <6592BDAF72405343BA096C66B735B38E02556E8270@alvxmbw04.prod.quest.corp> Message-ID: <4BFAF28A.1030602@anl.gov> Seth Ellsworth wrote: > This is on Solaris 10 x86, do not see this behavior on Solaris 10 sparc. Seen on multiple machines. > > Sshd debug: > debug1: server_input_channel_open: ctype session rchan 256 win 16384 max 16384 > debug1: input_session_request > debug1: channel 0: new [server-session] > debug2: session_new: allocate (allocated 0 max 10) > debug3: session_unused: session id 0 unused > 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 x11-req reply 1 > debug1: session_by_channel: session 0 channel 0 > debug1: session_input_channel_req: session 0 req x11-req > debug2: bind port 6010: Cannot assign requested address > debug2: bind port 6011: Cannot assign requested address > debug2: bind port 6012: Cannot assign requested address > ... > debug2: bind port 6997: Cannot assign requested address > debug2: bind port 6998: Cannot assign requested address > debug2: bind port 6999: Cannot assign requested address > Failed to allocate internet-domain X11 display socket. > debug1: x11_create_display_inet failed. > > > In a previous version, 4.7, this worked, and looked like: > debug1: server_input_channel_req: channel 0 request x11-req reply 1 > debug1: session_by_channel: session 0 channel 0 > debug1: session_input_channel_req: session 0 req x11-req > debug2: bind port 6010: Cannot assign requested address > debug2: fd 7 setting O_NONBLOCK > debug3: fd 7 is O_NONBLOCK > debug1: channel 1: new [X11 inet listener] > debug1: server_input_channel_req: channel 0 request exec reply 1 > > > Looking at differences between the 4.7 and 5.2 ( 5.5 is the same in this regards ), the difference seems to be in: > channels.c > Function: x11_create_display_inet > Line:2908: ( 4.7p1 code ) > if (ai->ai_next) > continue; > That's right after the bind fails. > > If I follow the behavior, the first ai from getaddrinfo is an IPV6 address that's not valid. Errno is EADDRNOTAVAIL. > > Now in 4.7 the continue would make it just try the next ai. > In 5.2 that continue isn't there, so instead it breaks and tries the next port number, on the same ai, which fails all the way until MAX_DISPLAYS is reached. > > For this situation I want to put back the if/continue, but I assume it was removed for a reason, and wanted to find out if anyone here knew. > > > > Ok, found the cvsweb, and located this: > Revision 1.272.2.1: download - view: text, markup, annotated - select for diffs > Thu Apr 3 03:42:02 2008 UTC (2 years, 1 month ago) by brad > Branches: OPENBSD_4_3 > Diff to: previous 1.272: preferred, coloured; next MAIN 1.273: preferred, coloured > Changes since revision 1.272: +1 -4 lines > > avoid possible hijacking of x11-forwarded connections (back out 1.183) > > CVE-2008-1483; ok djm@ > > > Ok, this was removed to address an attack type. So, how do I fix this so I keep the needed behavior but don't introduce the vulnerability? > > The root of the problem seems to be getting an invalid IPV6 addrinfo, and that failure means it doesn't try any other addrofinfo's, instead looping on port's, which all fail, because the addrinfo always fails. > > How about adding it back under certain circumstances: > sellswor at sethe:~/tmp/2/openssh-5.5p1> diff -u channels.c channels.c.orig > --- channels.c 2010-05-24 14:44:15.000000000 -0600 > +++ channels.c.orig 2010-05-24 14:43:32.000000000 -0600 > @@ -3271,13 +3271,9 @@ > if (x11_use_localhost) > channel_set_reuseaddr(sock); > if (bind(sock, ai->ai_addr, ai->ai_addrlen) < 0) { > - int loc_errno = errno; > debug2("bind port %d: %.100s", port, strerror(errno)); > close(sock); > > - if( loc_errno == EADDRNOTAVAIL && ai->ai_next ) > - continue; > - > for (n = 0; n < num_socks; n++) { > close(socks[n]); > } > You have new mail in /var/spool/mail/sellswor > sellswor at sethe:~/tmp/2/openssh-5.5p1> > > Thoughts? Sounds like it is related to IPv6 Google for: ssh bind X11 ipv6 and also see: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=327443 > > Am I approaching this wrong, and this shows a mis-configured machine? ( happens on multiple machines, all default setups connected to IPV4 networks ). > --- > Seth Ellsworth > Vintela Development > The people and products of Vintela are now a part of Quest Software. > Read the press release to learn more. > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > > -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From njleanne at hotmail.com Wed May 26 12:27:19 2010 From: njleanne at hotmail.com (lvleanne) Date: Wed, 26 May 2010 02:27:19 +0000 Subject: sshd dies if passed host key with relative path on command line Message-ID: Hi, Any comments on this problem? From: njleanne at hotmail.com To: openssh-unix-dev at mindrot.org Subject: sshd dies if passed host key with relative path on command line Date: Thu, 13 May 2010 04:22:39 +0000 Hi all, I noticed that openssh5.5 finally revised this bug, pls check the bugzilla https://bugzilla.mindrot.org/show_bug.cgi?id=1290 but when i test it both on linux and hp-ux, it will still fails: In hp-ux, server side: root at sshia2# /opt/ssh/sbin/sshd -p 1234 -D -h ssh_host_dsa_key -ddd .......... debug3: send_rexec_state: entering fd = 9 config len 322 debug3: ssh_msg_send: type 0 debug3: send_rexec_state: done debug1: rexec start in 6 out 6 newsock 6 pipe -1 sock 9 client side: $ ssh sshia2 -p 1234 -vvv OpenSSH_5.5p1+sftpfilecontrol-v1.3-hpn13v7, OpenSSL 0.9.8n 24 Mar 2010 HP-UX Secure Shell-A.05.50.002.LdapTest, HP-UX Secure Shell version debug1: Reading configuration data /opt/ssh/etc/ssh_config debug3: RNG is ready, skipping seeding debug2: ssh_connect: needpriv 0 debug1: Connecting to sshia2 [fe80::217:8ff:fe7c:d91c] port 1234. debug1: Connection established. debug1: identity file /home/user1/.ssh/id_rsa type -1 debug1: identity file /home/user1/.ssh/id_rsa-cert type -1 debug1: identity file /home/user1/.ssh/id_dsa type -1 debug1: identity file /home/user1/.ssh/id_dsa-cert type -1 ssh_exchange_identification: Connection closed by remote host Do somebody know this reason? Best Regards Leanne ??????????MSN??? ????? _________________________________________________________________ ?????????Windows Live????????? http://windowslivesky.spaces.live.com/blog/cns!5892B6048E2498BD!889.entry From kai_yang2008 at 163.com Wed May 26 19:42:04 2010 From: kai_yang2008 at 163.com (kai_yang2008) Date: Wed, 26 May 2010 17:42:04 +0800 (CST) Subject: hostbase authentication of hostcertificate Message-ID: <147fcd9.1260c.128d3fd7d29.Coremail.kai_yang2008@163.com> Dear All, I am trying to use the hostcertificate to do the hostbaed authentication with the steps in the regress/cert-hostkey.sh But it seems that it can not login with the hostcertificate.: Here is debug message from the ssh client : ssh -2 -oUserKnownHostsFile=/opt/ssh/etc/known_hosts-cert \ > -oGlobalKnownHostsFile=/opt/ssh/etc/known_hosts-cert sshia3 -p 1111 -vvv debug1: checking without port identifier debug3: check_host_in_hostfile: host sshia3 filename /opt/ssh/etc/known_hosts-cert debug3: check_host_in_hostfile: host sshia3 filename /opt/ssh/etc/known_hosts-cert debug3: check_host_in_hostfile: CA match line 1 debug1: Host 'sshia3' is known and matches the RSA-CERT host certificate. debug1: Found certificate in /opt/ssh/etc/known_hosts-cert:1 debug1: found matching key w/out port debug2: bits set: 503/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: Roaming not allowed by server debug1: SSH2_MSG_SERVICE_REQUEST sent debug2: service_accept: ssh-userauth debug1: SSH2_MSG_SERVICE_ACCEPT received debug2: key: /.ssh/id_rsa (40057810) debug2: key: /.ssh/id_dsa (0) debug3: input_userauth_banner debug1: Authentications that can continue: password,keyboard-interactive,hostbased debug3: start over, passed a different list password,keyboard-interactive,hostbased debug3: preferred hostbased,publickey,keyboard-interactive,password debug3: authmethod_lookup hostbased debug3: remaining preferred: publickey,keyboard-interactive,password debug3: authmethod_is_enabled hostbased debug1: Next authentication method: hostbased debug2: userauth_hostbased: chost sshia3 debug2: we sent a hostbased packet, wait for reply debug1: Authentications that can continue: password,keyboard-interactive,hostbased debug2: userauth_hostbased: chost sshia3 debug2: we sent a hostbased packet, wait for reply debug1: Authentications that can continue: password,keyboard-interactive,hostbased debug1: No more client hostkeys for hostbased authentication. 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 debug2: input_userauth_info_req debug2: input_userauth_info_req: num_prompts 1 Password: And here is the debug message of ssh server: ................... ebug2: check_key_in_hostfiles: key not found for sshia3 Failed hostbased for root from fe80::217:8ff:fe7c:d9f4 port 57500 ssh2 debug1: Entering record_failed_login uid 0 debug1: audit event euid 0 user root event 7 (AUTH_FAIL_HOSTBASED) ........................... So could anyone has some idea about this?Please cc me. Thanks! Best regards, Kevin From imorgan at nas.nasa.gov Thu May 27 02:20:44 2010 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Wed, 26 May 2010 09:20:44 -0700 Subject: hostbase authentication of hostcertificate In-Reply-To: <147fcd9.1260c.128d3fd7d29.Coremail.kai_yang2008@163.com> References: <147fcd9.1260c.128d3fd7d29.Coremail.kai_yang2008@163.com> Message-ID: <20100526162044.GA19561@linux55.nas.nasa.gov> On Wed, May 26, 2010 at 04:42:04 -0500, kai_yang2008 wrote: > Dear All, > > I am trying to use the hostcertificate to do the hostbaed authentication with the steps in the regress/cert-hostkey.sh > But it seems that it can not login with the hostcertificate.: Right. As has been previously noted on this list, hostbased authentication does not currently take advantage of host certificates. The are only used by the client to validate the server. I've been working on a patch that would add certificate support for hostbased authentication and hope to submit it fairly soon. Thus far, it looks like fairly minimal changes would be needed to support it. In fact, it looks like no changes need to be made to the server. But I may have overlooked something and haven't tested the code yet. The one awkward thing that I have been wrestling with is the number of hostbased authentication attempts that a client might try. Currently, if a server offers hostbased authentication but does not trust the client system, the client will try hostbased authentication twice. If certificate support is added and the client has both an RSA and DSA cert, it could try as many as four times. It seems that some strategy is needed to either limit the number of hostbased authentication attempts or to customize the order in which keys and certs will be tried. -- Iain Morgan From drallen at cs.uwaterloo.ca Thu May 27 04:14:31 2010 From: drallen at cs.uwaterloo.ca (Daniel Allen) Date: Wed, 26 May 2010 14:14:31 -0400 Subject: PermitUserEnvironment In-Reply-To: References: <270edf4c0908251928y2beea913hdaed0ce225871525@mail.gmail.com> Message-ID: Daniel Allen wrote on Fri Sep 4 23:46:12 EST 2009: > > Damien Miller wrote: > > > We could make PermitUserEnvironment accept a pattern-list to match > > environment variables, while retaining "yes", "no", "true" and "false" > > as their current meanings of allow/deny-all. > > [...] The pattern-list would seem the more elegant approach for our > use. I am sorry that I don't have the wherewithal to submit a patch > now, though if it helps things along I'd be happy to submit a bugzilla > request. Or not, if you prefer. I'd like to let you know that we're reviewing a patch which does just as described, to accept a pattern for PermitUserEnvironment. It affects vars defined in $HOME/.ssh/environment and authorized_keys. It only accepts a single pattern, which is used as a case-insensitive stem for allowed variables. I will send along the patch as soon as I've had a few colleagues review it. While I'm digging: there is a secondary area of interest I'd appreciate comment on. If PermitUserEnvironment is turned off, but an "environment=" option is specified in authorized_keys, the key is rejected and the user sees a "Bad options in file" error, which cannot be muted. Versus "permitopen=" option, which sshd silently ignores if AllowTcpForwarding is turned off. What do people think about a (short) patch to silently ignore "environment=" specifications on disabled PermitUserEnvironment? It seems like a not-too-controvertial thing, especially since sshd silently ignores the same variables if they are in $HOME/.ssh/environment if PermitUserEnvironment is off. And it would prevent a FAQish question which I'm sure we'll see if we start using environment parameters as we expect to... Thanks, Daniel Allen Computing Technology Specialist Computer Science Computing Facility (CSCF) David R. Cheriton School of Computer Science University of Waterloo (519) 888-4567 ext. 35448 drallen at uwaterloo dot ca From philipp_subx at redfish-solutions.com Thu May 27 07:08:04 2010 From: philipp_subx at redfish-solutions.com (Philip A. Prindeville) Date: Wed, 26 May 2010 15:08:04 -0600 Subject: QoS marking for Openssh (review wanted) In-Reply-To: References: <4B931780.9010200@employees.org> <4B96EB48.3030204@employees.org> <4B96F506.7060106@employees.org> <4BAA5DD3.6020004@redfish-solutions.com> <4BDA3708.1040307@redfish-solutions.com> Message-ID: <4BFD8DB4.1090000@redfish-solutions.com> Still being patient... do we have an estimate on when you might get to it? Thanks. On 04/29/2010 08:03 PM, Damien Miller wrote: > we'll get to it - please be patient. > > On Thu, 29 Apr 2010, Philip Prindeville wrote: > >> On 3/24/10 12:45 PM, Philip A. Prindeville wrote: >>> Anyone want to code review: >>> >>> https://bugzilla.mindrot.org/show_bug.cgi?id=1733 >>> >>> There's a patch attached. We're currently using it on astlinux. >>> >>> Thanks. >>> >> >> Still looking to get a code-review and approval. >> >> Thanks. From peter at stuge.se Thu May 27 09:08:35 2010 From: peter at stuge.se (Peter Stuge) Date: Thu, 27 May 2010 01:08:35 +0200 Subject: PermitUserEnvironment In-Reply-To: References: <270edf4c0908251928y2beea913hdaed0ce225871525@mail.gmail.com> Message-ID: <20100526230835.3074.qmail@stuge.se> Daniel Allen wrote: > What do people think about a (short) patch to silently ignore > "environment=" specifications on disabled PermitUserEnvironment? I like that. //Peter From kai_yang2008 at 163.com Thu May 27 12:16:57 2010 From: kai_yang2008 at 163.com (kai_yang2008) Date: Thu, 27 May 2010 10:16:57 +0800 (CST) Subject: hostbase authentication of hostcertificate In-Reply-To: <20100526162044.GA19561@linux55.nas.nasa.gov> References: <20100526162044.GA19561@linux55.nas.nasa.gov> <147fcd9.1260c.128d3fd7d29.Coremail.kai_yang2008@163.com> Message-ID: <1a885fa.22b5.128d78c557d.Coremail.kai_yang2008@163.com> Hi Morgan, Oh, thank you for you explanation. Due to the times of the client try to do the host-basedauthentication with the certificate support, then you may follow the principle of the certificate for the user. Best regards, Kevin ?2010-05-27 00:20:44?"Iain Morgan" ??? >On Wed, May 26, 2010 at 04:42:04 -0500, kai_yang2008 wrote: >> Dear All, >> >> I am trying to use the hostcertificate to do the hostbaed authentication with the steps in the regress/cert-hostkey.sh >> But it seems that it can not login with the hostcertificate.: > >Right. As has been previously noted on this list, hostbased >authentication does not currently take advantage of host certificates. >The are only used by the client to validate the server. > >I've been working on a patch that would add certificate support for >hostbased authentication and hope to submit it fairly soon. Thus far, it >looks like fairly minimal changes would be needed to support it. In >fact, it looks like no changes need to be made to the server. But I may >have overlooked something and haven't tested the code yet. > >The one awkward thing that I have been wrestling with is the number of >hostbased authentication attempts that a client might try. Currently, if >a server offers hostbased authentication but does not trust the client >system, the client will try hostbased authentication twice. If >certificate support is added and the client has both an RSA and DSA >cert, it could try as many as four times. > >It seems that some strategy is needed to either limit the number of >hostbased authentication attempts or to customize the order in which >keys and certs will be tried. > >-- >Iain Morgan From miguel.sanders at arcelormittal.com Thu May 27 20:52:35 2010 From: miguel.sanders at arcelormittal.com (miguel.sanders at arcelormittal.com) Date: Thu, 27 May 2010 12:52:35 +0200 Subject: Idle Time-out Message-ID: <7DF29B50FFF41848BB2281EC2E71A206013988C4@GEN-MXB-V04.msad.arcelor.net> Hi Does OpenSSH have a feature in which a client gets kicked out after X minutes of inactivity (no keystrokes)? I have seen this on other SSH implementations but I don't see it in OpenSSH. Thnx! Met vriendelijke groet Best regards Bien ? vous Miguel SANDERS ArcelorMittal Gent UNIX Systems & Storage IT Supply Western Europe | John Kennedylaan 51 B-9042 Gent T +32 9 347 3538 | F +32 9 347 4901 | M +32478 805 023 E miguel.sanders at arcelormittal.com www.arcelormittal.com/gent > P Please consider the environment before printing this e-mail > **** This message and any attachment are confidential, intended solely for the use of the individual or entity to whom it is addressed and may be protected by professional secrecy or intellectual property rights. If you have received it by mistake, or are not the named recipient(s), please immediately notify the sender and delete the message. You are hereby notified that any unauthorized use, copying or dissemination of any or all information contained in this message is prohibited. Arcelormittal shall not be liable for the message if altered, falsified, or in case of error in the recipient. This message does not constitute any right or commitment for ArcelorMittal except when expressly agreed otherwise in writing in a separate agreement. **** From imorgan at nas.nasa.gov Fri May 28 01:18:13 2010 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Thu, 27 May 2010 08:18:13 -0700 Subject: Idle Time-out In-Reply-To: <7DF29B50FFF41848BB2281EC2E71A206013988C4@GEN-MXB-V04.msad.arcelor.net> References: <7DF29B50FFF41848BB2281EC2E71A206013988C4@GEN-MXB-V04.msad.arcelor.net> Message-ID: <20100527151813.GB19561@linux55.nas.nasa.gov> On Thu, May 27, 2010 at 05:52:35 -0500, miguel.sanders at arcelormittal.com wrote: > Hi > > Does OpenSSH have a feature in which a client gets kicked out after X minutes of inactivity (no keystrokes)? > I have seen this on other SSH implementations but I don't see it in OpenSSH. > > Thnx! > No. There are the {Client,Server}Alive{CountMax,Interval} options which are intended to detect dead connections, but nothing that strictly corresponds to an idle timeout. -- Iain Morgan From Seth.Ellsworth at quest.com Fri May 28 01:24:28 2010 From: Seth.Ellsworth at quest.com (Seth Ellsworth) Date: Thu, 27 May 2010 08:24:28 -0700 Subject: Idle Time-out In-Reply-To: <20100527151813.GB19561@linux55.nas.nasa.gov> References: <7DF29B50FFF41848BB2281EC2E71A206013988C4@GEN-MXB-V04.msad.arcelor.net> <20100527151813.GB19561@linux55.nas.nasa.gov> Message-ID: <6592BDAF72405343BA096C66B735B38E0257C48CF2@alvxmbw04.prod.quest.corp> That could be handled by a shell setting ( this is bash ): TMOUT If set to a value greater than zero, TMOUT is treated as the default timeout for the read builtin. The select command terminates if input does not arrive after TMOUT seconds when input is coming from a terminal. In an interactive shell, the value is interpreted as the number of seconds to wait for input after issuing the primary prompt. Bash terminates after waiting for that number of seconds if input does not arrive. Do not get the nice "This session will log out in 60 seconds due to inactivity" message I've seen, but same end effect ( logged out on timeout ). --- Seth Ellsworth Vintela Development The people and products of Vintela are now a part of Quest Software. Read the press release to learn more. -----Original Message----- From: openssh-unix-dev-bounces+seth.ellsworth=quest.com at mindrot.org [mailto:openssh-unix-dev-bounces+seth.ellsworth=quest.com at mindrot.org] On Behalf Of Iain Morgan Sent: Thursday, May 27, 2010 9:18 AM To: miguel.sanders at arcelormittal.com Cc: openssh-unix-dev at mindrot.org Subject: Re: Idle Time-out On Thu, May 27, 2010 at 05:52:35 -0500, miguel.sanders at arcelormittal.com wrote: > Hi > > Does OpenSSH have a feature in which a client gets kicked out after X minutes of inactivity (no keystrokes)? > I have seen this on other SSH implementations but I don't see it in OpenSSH. > > Thnx! > No. There are the {Client,Server}Alive{CountMax,Interval} options which are intended to detect dead connections, but nothing that strictly corresponds to an idle timeout. -- Iain Morgan _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From jose.valles at serviciosbancarios.com Fri May 28 01:46:17 2010 From: jose.valles at serviciosbancarios.com (Jose C. Valles Martinez) Date: Thu, 27 May 2010 17:46:17 +0200 Subject: A question regarding file transfer loggin in OpenSSH Message-ID: <201005271553.o4RFrBLp031343@mailserver02.serviciosbancarios.com> Hi all, We are using ssh for file transfer through SCP and SFTP in a FreeBSD box, and it works fine as expected. But from some days ago the customers are requesting the logs of the transmissions, and we?ve just realized that the sshd daemon doesn?t log the files copied to our server nor the downloaded files. I?ve tried with all the debug levels of the sshd daemon, but nothing. It logs a lot of messages in /var/log/ssh.log, but it doesn?t log the file transfers. Could you please help us for logging these file transfers? Thanks a lot and best regards, Jose Vall?s Dept. Sistemas INTOS, S.A. 93 247 71 17 (directo) 606 987 657 (m?vil) ================================================== Advertencia legal: Esta comunicaci?n puede contener informaci?n confidencial y/o material de propiedad y por tanto es para el uso exclusivo de su destinatario. Si recibe este correo por error, por favor comun?queselo al remitente y elimine este correo y sus anexos de todos los ordenadores. En el caso de que el destinatario no consintiera la utilizaci?n del correo electr?nico, deber? ponerlo en nuestro conocimiento inmediatamente. Disclaimer: This communication may contain confidential and/or otherwise proprietary material and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. If the address of this message does not consent to the use of internet e-mail, please inform us inmmediately. From lars.reimann at googlemail.com Fri May 28 02:34:41 2010 From: lars.reimann at googlemail.com (Lars Reimann) Date: Thu, 27 May 2010 18:34:41 +0200 Subject: Limit number of simultaneous sftp-server connections from same ip Message-ID: <4BFE9F21.4040705@googlemail.com> Hello all, I would like to ask a short question about the configuration capabilities of sshd / sftp-server. I want to limit the number of connections (or instances) to an sftp-server a user can spawn from the same ip address. The reason is that multiple connections overload by box (connection). My first idea was to move control of sftp-server to xinetd. There I could maintain control of such things. However, since sftp-server depends on a parent sshd, I was not successful. Maybe there is a way? While limiting the use of sftp-server I want to retain _full_ access to normal (shell-like) connections over sshd without limits. Are such things even possible or should I switch to FTP w/ SSL? By the way, how can I disable sftp-server completely (e.g. if I want to work fast on the net and not allow any file transfers over sftp-server)? Thanks for any replies, LR ps. openssh version is: latest. From imorgan at nas.nasa.gov Fri May 28 02:50:27 2010 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Thu, 27 May 2010 09:50:27 -0700 Subject: A question regarding file transfer loggin in OpenSSH In-Reply-To: <201005271553.o4RFrBLp031343@mailserver02.serviciosbancarios.com> References: <201005271553.o4RFrBLp031343@mailserver02.serviciosbancarios.com> Message-ID: <20100527165027.GC19561@linux55.nas.nasa.gov> On Thu, May 27, 2010 at 10:46:17 -0500, Jose C. Valles Martinez wrote: > Hi all, > > > > We are using ssh for file transfer through SCP and SFTP in a FreeBSD box, > and it works fine as expected. But from some days ago the customers are > requesting the logs of the transmissions, and we?ve just realized that the > sshd daemon doesn?t log the files copied to our server nor the downloaded > files. > > > > I?ve tried with all the debug levels of the sshd daemon, but nothing. It > logs a lot of messages in /var/log/ssh.log, but it doesn?t log the file > transfers. > > > > Could you please help us for logging these file transfers? > > Both the SCP and SFTP protocols are layered on top of the SSH protocol and are normally handled by external programs. Thus adjusting the log level for the server does not have any bearing on logging file transfers. If you search through the list archive you will probably find several third-party patches that add logging to either scp or sftp-server. I should note that recent versions of OpenSSH support a -l option for sftp-server which might meet your needs. I haven't played around with it myself, but it might meet your needs. -- Iain Morgan From peter at stuge.se Fri May 28 05:20:57 2010 From: peter at stuge.se (Peter Stuge) Date: Thu, 27 May 2010 21:20:57 +0200 Subject: Limit number of simultaneous sftp-server connections from same ip In-Reply-To: <4BFE9F21.4040705@googlemail.com> References: <4BFE9F21.4040705@googlemail.com> Message-ID: <20100527192057.4781.qmail@stuge.se> Lars Reimann wrote: > I want to limit the number of connections (or instances) to an > sftp-server a user can spawn from the same ip address. Wouldn't a simple wrapper (as opposed to xinetd) work? > sftp-server depends on a parent sshd How is that, exactly? > While limiting the use of sftp-server I want to retain _full_ > access to normal (shell-like) connections over sshd without limits. Add the wrapper to the subsystem directive in sshd_config. > By the way, how can I disable sftp-server completely Remove the subsystem directive from sshd_config. //Peter From lars.reimann at googlemail.com Fri May 28 05:33:45 2010 From: lars.reimann at googlemail.com (Lars Reimann) Date: Thu, 27 May 2010 21:33:45 +0200 Subject: Limit number of simultaneous sftp-server connections from same ip In-Reply-To: <20100527192057.4781.qmail@stuge.se> References: <4BFE9F21.4040705@googlemail.com> <20100527192057.4781.qmail@stuge.se> Message-ID: <4BFEC919.2020801@googlemail.com> Hello, thanks for the reply. On 5/27/2010 9:20 PM, Peter Stuge wrote: > Lars Reimann wrote: > >> I want to limit the number of connections (or instances) to an >> sftp-server a user can spawn from the same ip address. >> > Wouldn't a simple wrapper (as opposed to xinetd) work? > I suppose so. I have a shell script in mind that checks the process list for already open sftp-server connections under a specific user. If a process already exists, the script would not exec another sub-process. Please tell me if that is feasable or if there's a better method. > > >> sftp-server depends on a parent sshd >> > How is that, exactly? > Maybe it does not depend on sshd, but I cannot imagine any secure method how to operate sftp-server w/o sshd using a connection limit nor did I find any documented. A method where xinetd uses seperate rules for sshd and sftp-server while normal logins remain unaffected by the connection limit sadly was beyond my skills. > > >> While limiting the use of sftp-server I want to retain _full_ >> access to normal (shell-like) connections over sshd without limits. >> > Add the wrapper to the subsystem directive in sshd_config. > > > >> By the way, how can I disable sftp-server completely >> > Remove the subsystem directive from sshd_config. > > > //Peter > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > greetings, lr. From mouring at eviladmin.org Fri May 28 07:54:53 2010 From: mouring at eviladmin.org (Ben Lindstrom) Date: Thu, 27 May 2010 16:54:53 -0500 Subject: Limit number of simultaneous sftp-server connections from same ip In-Reply-To: <4BFEC919.2020801@googlemail.com> References: <4BFE9F21.4040705@googlemail.com> <20100527192057.4781.qmail@stuge.se> <4BFEC919.2020801@googlemail.com> Message-ID: <85CA3851-4C76-423C-8490-D801D6EAE028@eviladmin.org> >>> While limiting the use of sftp-server I want to retain _full_ >>> access to normal (shell-like) connections over sshd without limits. >>> >> Add the wrapper to the subsystem directive in sshd_config. Not really. If they have full ssh shell access they can by-pass this wrapper without much of an issue. This only keeps the honest people honest. - Ben From peter at stuge.se Fri May 28 09:15:49 2010 From: peter at stuge.se (Peter Stuge) Date: Fri, 28 May 2010 01:15:49 +0200 Subject: Limit number of simultaneous sftp-server connections from same ip In-Reply-To: <85CA3851-4C76-423C-8490-D801D6EAE028@eviladmin.org> References: <4BFE9F21.4040705@googlemail.com> <20100527192057.4781.qmail@stuge.se> <4BFEC919.2020801@googlemail.com> <85CA3851-4C76-423C-8490-D801D6EAE028@eviladmin.org> Message-ID: <20100527231549.4075.qmail@stuge.se> Ben Lindstrom wrote: > >>> While limiting the use of sftp-server I want to retain _full_ > >>> access to normal (shell-like) connections over sshd without limits. > >>> > >> Add the wrapper to the subsystem directive in sshd_config. > > Not really. If they have full ssh shell access they can by-pass > this wrapper without much of an issue. Are you sure they can bypass it when using SFTP without changing the SFTP client? > This only keeps the honest people honest. Maybe it's a workaround for a bad network situation rather than a security measure against dishonest users. Since there is a requirement that the user has normal login access there are many non-SFTP ways to transfer files which will go completely unnoticed. I assumed the original requirements had taken that into consideration already, maybe my mistake. //Peter From mouring at eviladmin.org Fri May 28 11:34:39 2010 From: mouring at eviladmin.org (Ben Lindstrom) Date: Thu, 27 May 2010 20:34:39 -0500 Subject: Limit number of simultaneous sftp-server connections from same ip In-Reply-To: <20100527231549.4075.qmail@stuge.se> References: <4BFE9F21.4040705@googlemail.com> <20100527192057.4781.qmail@stuge.se> <4BFEC919.2020801@googlemail.com> <85CA3851-4C76-423C-8490-D801D6EAE028@eviladmin.org> <20100527231549.4075.qmail@stuge.se> Message-ID: <584ACADD-3889-4D6C-93BF-7A3A266F1CFB@eviladmin.org> On May 27, 2010, at 6:15 PM, Peter Stuge wrote: > Ben Lindstrom wrote: >>>>> While limiting the use of sftp-server I want to retain _full_ >>>>> access to normal (shell-like) connections over sshd without limits. >>>>> >>>> Add the wrapper to the subsystem directive in sshd_config. >> >> Not really. If they have full ssh shell access they can by-pass >> this wrapper without much of an issue. > > Are you sure they can bypass it when using SFTP without changing the > SFTP client? sftp -s /path/to/my/sftp-server site.com No hacking or code change required. Works on v2 protocol only sshd setups. $ man sftp [..] -s subsystem | sftp_server Specifies the SSH2 subsystem or the path for an sftp server on the remote host. A path is useful for using sftp over protocol version 1, or when the remote sshd(8) does not have an sftp sub- system configured. [..] - Ben From simon.matter at invoca.ch Mon May 31 17:06:41 2010 From: simon.matter at invoca.ch (Simon Matter) Date: Mon, 31 May 2010 09:06:41 +0200 Subject: Do not echo chars when asked for (yes/no) Message-ID: Hi, In the last decade using openssh I remember only one thing that I hope it could be changed: Logging in to a host which is not yet known in my .ssh/known_hosts it asks me something like The authenticity of host 'xhost (192.168.100.1)' can't be established. RSA key fingerprint is c2:6b:6c:55:8a:1b:6b:13:8c:f1:b3:ef:65:67:a3:a7. Are you sure you want to continue connecting (yes/no)? That's all fine but if I'm doing it from a foreign client connecting to my own server, and a number of peoples looking over my shoulders, and me not realizing the question, I may blindly start typing the password instead of 'yes', and everybody can read it on the screen. I know that's me being stupid, and maybe no one else has done such mistakes, but it has happened to me in the passed years and I wondered if it would make sense to not echo the yes/no but instead print * or something to prevent such stupid things to happen. Have others been in the same situation and what do you think? Regards, Simon