From gert at greenie.muc.de Sun Feb 1 00:48:04 2009 From: gert at greenie.muc.de (Gert Doering) Date: Sat, 31 Jan 2009 14:48:04 +0100 Subject: sshd exponential backoff patch In-Reply-To: <20090126163243.GA19304@dementia.proulx.com> References: <1232701533.29828.1296322611@webmail.messagingengine.com> <20090126163243.GA19304@dementia.proulx.com> Message-ID: <20090131134804.GH288@greenie.muc.de> Hi, On Mon, Jan 26, 2009 at 09:32:43AM -0700, Bob Proulx wrote: > Sam Watkins wrote: > > I wrote a patch to openssh sshd.c which enables "exponential backoff", > > so that an attacker cannot brute force your password by making hundreds > > of login attempts. > > I read "hundreds of login attempts" in order to brute force a > password. But it actually takes orders of magnitudes more to brute > force attack a password. This is okay. You really do want the best > attack available to be a brute force attack. The present safeguards > will prevent the attack from succeeding before the end of time. The problem is that people still pick poor passwords. So the attacker might not have to test (70^8) combinations (lower+uppercase+digits+ few special caracters, 8 of them long) but might succeed after a few hundred probes. ... and slowing down attackers might actually help things here. (I use fail2ban for that, which works quite well) 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 phpete48 at gmail.com Sun Feb 1 06:04:08 2009 From: phpete48 at gmail.com (Peter Hovey) Date: Sat, 31 Jan 2009 14:04:08 -0500 Subject: ssh w/ keys: tectia ->> openssh Message-ID: <35bb67930901311104t5060bcaajf53621e27b6e3a17@mail.gmail.com> I've checked out the ssh.com knowledgebase for instructions about how to "ssh w/ keys from tectia to openssh" but they did not specifically go from tectia to openssh. Could someone pls post a complete set of instructions about how to do this. thx., pete From thesource at ldb-jab.org Sun Feb 1 07:51:42 2009 From: thesource at ldb-jab.org (LDB) Date: Sat, 31 Jan 2009 15:51:42 -0500 Subject: ssh w/ keys: tectia ->> openssh In-Reply-To: <35bb67930901311104t5060bcaajf53621e27b6e3a17@mail.gmail.com> References: <35bb67930901311104t5060bcaajf53621e27b6e3a17@mail.gmail.com> Message-ID: <4984B9DE.2080904@master.ldb-jab.org> Peter Hovey wrote: > I've checked out the ssh.com knowledgebase for instructions about > how to "ssh w/ keys from tectia to openssh" but they did not specifically > go from tectia to openssh. Could someone pls post a complete set of > instructions about how to do this. > > thx., > pete > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > > >From ssh-keygen man page ... ssh-keygen -i [-f input_keyfile] -i This option will read an unencrypted private (or public) key file in SSH2-compatible format and print an OpenSSH compatible private (or public) key to stdout. ssh-keygen also reads the RFC 4716 SSH Public Key File Format. This option allows importing keys from several commercial SSH implementations. From elvstone at gmail.com Tue Feb 3 01:25:23 2009 From: elvstone at gmail.com (Elvis Stansvik) Date: Mon, 2 Feb 2009 15:25:23 +0100 Subject: Question about key file formats used by OpenSSH In-Reply-To: <751a4f870902020604x3e125b1dk1240b08584f75414@mail.gmail.com> References: <751a4f870902020604x3e125b1dk1240b08584f75414@mail.gmail.com> Message-ID: <751a4f870902020625m85a066ek623e93a69b1de9ea@mail.gmail.com> 2009/2/2, Elvis Stansvik : > Hello OpenSSH developers, first post. > > I'm implementing SSH agent functionality in a program of mine, with > the ability to add/remove keys files as saved by OpenSSH. So I'm > trying to figure out which formats OpenSSH uses natively for the > different types of keys. The only specification related to SSH key > file formats I've found is RFC4716 (SSH Public Key File Format). > > Analysis of ssh-keygen output with varying key types shows the > following four formats for which I haven't found any specification: > > * Something similar to RFC4716 and RFC1421, but not quite the same. > Used by OpenSSH for version 2 DSA and RSA private keys. > > * "ssh-dss|rsa-dss [base64?] comment". > Used by OpenSSH for version 2 DSA and RSA public keys. > > * "[keysize?] [decimal number] [more decimal numbers]". > Used by OpenSSH for version 1 RSA public keys. Sorry. Should be "[keysize?] [decimal number] [more decimal numbers] [comment]". Elvis > > * ASCII header line followed by binary data. > Used by OpenSSH for version 1 RSA private keys. > > Are these formats specified somewhere, short of reading OpenSSH source > code? Why not use RFC4716 natively? > > Best regards, > Elvis Stansvik > From elvstone at gmail.com Tue Feb 3 01:04:54 2009 From: elvstone at gmail.com (Elvis Stansvik) Date: Mon, 2 Feb 2009 15:04:54 +0100 Subject: Question about key file formats used by OpenSSH Message-ID: <751a4f870902020604x3e125b1dk1240b08584f75414@mail.gmail.com> Hello OpenSSH developers, first post. I'm implementing SSH agent functionality in a program of mine, with the ability to add/remove keys files as saved by OpenSSH. So I'm trying to figure out which formats OpenSSH uses natively for the different types of keys. The only specification related to SSH key file formats I've found is RFC4716 (SSH Public Key File Format). Analysis of ssh-keygen output with varying key types shows the following four formats for which I haven't found any specification: * Something similar to RFC4716 and RFC1421, but not quite the same. Used by OpenSSH for version 2 DSA and RSA private keys. * "ssh-dss|rsa-dss [base64?] comment". Used by OpenSSH for version 2 DSA and RSA public keys. * "[keysize?] [decimal number] [more decimal numbers]". Used by OpenSSH for version 1 RSA public keys. * ASCII header line followed by binary data. Used by OpenSSH for version 1 RSA private keys. Are these formats specified somewhere, short of reading OpenSSH source code? Why not use RFC4716 natively? Best regards, Elvis Stansvik From djm at mindrot.org Tue Feb 3 06:17:13 2009 From: djm at mindrot.org (Damien Miller) Date: Tue, 3 Feb 2009 06:17:13 +1100 (EST) Subject: Question about key file formats used by OpenSSH In-Reply-To: <751a4f870902020604x3e125b1dk1240b08584f75414@mail.gmail.com> References: <751a4f870902020604x3e125b1dk1240b08584f75414@mail.gmail.com> Message-ID: On Mon, 2 Feb 2009, Elvis Stansvik wrote: > Hello OpenSSH developers, first post. > > I'm implementing SSH agent functionality in a program of mine, with > the ability to add/remove keys files as saved by OpenSSH. So I'm > trying to figure out which formats OpenSSH uses natively for the > different types of keys. The only specification related to SSH key > file formats I've found is RFC4716 (SSH Public Key File Format). > > Analysis of ssh-keygen output with varying key types shows the > following four formats for which I haven't found any specification: > > * Something similar to RFC4716 and RFC1421, but not quite the same. > Used by OpenSSH for version 2 DSA and RSA private keys. These are PEM encoded private keys as per rfc1421 - they certainly can be read and generated by OpenSSL's PEM API/tools ("openssl rsa" and so forth). > * "ssh-dss|rsa-dss [base64?] comment". > Used by OpenSSH for version 2 DSA and RSA public keys. The base64 data is a public key blob encoded as per rfc4253 section 6.6. Technically the string identifier is redundant since it is encoded in the blob too, but it is there for humans to read. > * "[keysize?] [decimal number] [more decimal numbers]". > Used by OpenSSH for version 1 RSA public keys. The format here is: bits rsa_e rsa_n optional_comment > * ASCII header line followed by binary data. > Used by OpenSSH for version 1 RSA private keys. AFAIK there is no documention for this other than the code, it is inherited from the old ssh-1.x code. > Are these formats specified somewhere, short of reading OpenSSH source > code? Why not use RFC4716 natively? The RFC4716 public key format does not work with OpenSSH's one-key-per-line authorized_keys format and so would have broken backwards compatibility. -d From markus.r.friedl at arcor.de Tue Feb 3 19:55:05 2009 From: markus.r.friedl at arcor.de (Markus Friedl) Date: Tue, 3 Feb 2009 09:55:05 +0100 Subject: Question about key file formats used by OpenSSH In-Reply-To: <751a4f870902020604x3e125b1dk1240b08584f75414@mail.gmail.com> References: <751a4f870902020604x3e125b1dk1240b08584f75414@mail.gmail.com> Message-ID: <20090203085505.GB22544@folly> On Mon, Feb 02, 2009 at 03:04:54PM +0100, Elvis Stansvik wrote: > Are these formats specified somewhere, short of reading OpenSSH source > code? Why not use RFC4716 natively? 1) OpenSSH predates RFC4716 2) OpenSSH traditionally uses one-line per key in authorized keys files so I decided to use the current format. -m From hosungs at gmail.com Wed Feb 4 11:58:48 2009 From: hosungs at gmail.com (Hosung Song) Date: Tue, 03 Feb 2009 18:58:48 -0600 Subject: SSH PAM authentication/login with a new user DB (through NSS) Message-ID: <4988E848.2010006@gmail.com> Hello, I'm a novice system programmer and I need some knowledge about how sshd/PAM/NSS work together. The email may be long and unclear, but I would greatly appreciate if any one could give me some info. TIA. I'm developing a new authentication module for Linux login service. I'm like a novice developer in this area, so I had to study this and that. I started with PAM naively, and the example PAM application seemed authenticating the user all right. When I tried my PAM module on ssh server, it always returned " INCORRECT" as the entered password, even though a correct password was entered. I admit that that led me to look into sshd's source code, and realized that sshd require that every user attempting to login should be valid in the sense that getpwnam() returns a correct passwd struct. So, I realized again that I needed to implement a new NSS (Name Service Switch) module myself for this additional authentication method. I tested my NSS module with example queries of getpwnam() and getpwuid(), so I tried to integrate and test everything with sshd. Now, sshd recognizes the users and entered passwords are accepted, so the PAM module successfully authenticate. It can be confirmed through the following /var/log/auth.log line: Feb 3 14:54:11 dharma sshd[7843]: Accepted keyboard-interactive/pam for hosungs at gmail.com from 127.0.0.1 port 48748 ssh2 However, before the login prompt is granted, the connection is closed. The corresponding debug log is as follows: ... Feb 3 14:54:11 dharma sshd[7863]: debug1: Allocating pty. Feb 3 14:54:11 dharma sshd[7863]: debug3: mm_request_send entering: type 26 Feb 3 14:54:11 dharma sshd[7863]: debug3: mm_pty_allocate: waiting for MONITOR_ANS_PTY Feb 3 14:54:11 dharma sshd[7863]: debug3: mm_request_receive_expect entering: type 27 Feb 3 14:54:11 dharma sshd[7863]: debug3: mm_request_receive entering Feb 3 14:54:11 dharma sshd[7843]: debug2: User child is on pid 7863 Feb 3 14:54:11 dharma sshd[7843]: debug3: mm_request_receive entering Feb 3 14:54:11 dharma sshd[7843]: debug3: monitor_read: checking request 26 Feb 3 14:54:11 dharma sshd[7843]: debug3: mm_answer_pty entering Feb 3 14:54:11 dharma sshd[7843]: debug1: session_new: init Feb 3 14:54:11 dharma sshd[7843]: debug1: session_new: session 0 Feb 3 14:54:11 dharma sshd[7843]: debug1: SELinux support disabled Feb 3 14:54:11 dharma sshd[7843]: fatal: login_init_entry: Cannot find user "" Feb 3 14:54:11 dharma sshd[7843]: debug1: do_cleanup Feb 3 14:54:11 dharma sshd[7843]: debug1: PAM: cleanup Feb 3 14:54:11 dharma sshd[7843]: debug3: PAM: sshpam_thread_cleanup entering Feb 3 14:54:11 dharma sshd[7843]: debug1: session_pty_cleanup: session 0 release /dev/pts/4 Feb 3 14:54:11 dharma sshd[7843]: fatal: login_init_entry: Cannot find user "" Feb 3 14:54:11 dharma sshd[7843]: debug1: do_cleanup Feb 3 14:54:11 dharma sshd[7863]: debug1: do_cleanup Feb 3 14:54:11 dharma sshd[7863]: debug1: PAM: cleanup Feb 3 14:54:11 dharma sshd[7863]: debug3: PAM: sshpam_thread_cleanup entering ... It looks like login_init_entry()'s username parameter (which is passed through login_alloc_entry(), record_login(), and do_login(), where the passwd struct is assigned s->pw of the Session parameter s), and this passwd struct is somehow different (blank?) from the one filled earlier by my NSS module at the time of authentication. I tried to analyze the sshd source code as much as possible to figure out how the passwd structs are related (noticed that PAM authentication is done by a separate thread, and I'm not sure how the getpwnam() result obtained in the sshpam thread is passed back to the parent thread), but my lack of patience or expertise keeps me from making any further progress. I think I may be missing something in my PAM module, but that isn't very clear either. Any of your expert comments would be greatly appreciated. I'm not yet a subscriber of this mailing list, so I may need to be CC'ed in your response. Thanks, Hosung Song From christian.pfaffel-janser at siemens.com Thu Feb 5 02:33:14 2009 From: christian.pfaffel-janser at siemens.com (Christian Pfaffel-Janser) Date: Wed, 04 Feb 2009 16:33:14 +0100 Subject: SSH PAM authentication/login with a new user DB (through NSS) In-Reply-To: <4988E848.2010006@gmail.com> References: <4988E848.2010006@gmail.com> Message-ID: <4989B53A.2030400@siemens.com> Hosung Song wrote: > Hello, > > > I tried to analyze the sshd source code as much as possible to figure > out how the passwd structs are related (noticed that PAM authentication > is done by a separate thread, and I'm not sure how the getpwnam() result > obtained in the sshpam thread is passed back to the parent thread), but > my lack of patience or expertise keeps me from making any further > progress. I think I may be missing something in my PAM module, but that > isn't very clear either. > > Any of your expert comments would be greatly appreciated. I'm not yet a > subscriber of this mailing list, so I may need to be CC'ed in your response. > > Thanks, > > Hosung Song > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > Hi, just a wild guess, does it work if You turn PriviledgeSeparation off. Best regards, Christian -- Firma: Siemens Aktiengesellschaft ?sterreich Rechtsform: Aktiengesellschaft Firmensitz: Wien, Firmenbuchnummer: FN 60562 m Firmenbuchgericht: Handelsgericht Wien, DVR: 0001708 From jblaine at kickflop.net Thu Feb 5 02:26:58 2009 From: jblaine at kickflop.net (Jeff Blaine) Date: Wed, 04 Feb 2009 10:26:58 -0500 Subject: 4.4p1 to 5.1p1 = $HOME/bin no longer in PATH? In-Reply-To: References: <4989A664.60906@mitre.org> Message-ID: <4989B3C2.6010702@kickflop.net> What's going on here? I see nothing about this in the ChangeLog, so I am confused. ================================================================== ~:cairo> pwd /afs/rcf/user/jblaine ~:cairo> cat bin/tester #!/bin/sh echo "TESTER program in $HOME/bin!" ~:cairo> ================================================================== OpenSSH 4.4p1 (previous version we were running, temporarily stood up in debug mode on port 3333): ~:cairo> ssh -p 3333 rcf-ssh tester Password: TESTER program in /afs/rcf/user/jblaine/bin! ~:cairo> ================================================================== OpenSSH 5.1p1 (current): ~:cairo> ssh rcf-ssh tester Password: bash: tester: command not found ~:cairo> From kaizaad at sharcnet.ca Thu Feb 5 03:50:21 2009 From: kaizaad at sharcnet.ca (Kaizaad Bilimorya) Date: Wed, 4 Feb 2009 11:50:21 -0500 (EST) Subject: 4.4p1 to 5.1p1 = $HOME/bin no longer in PATH? In-Reply-To: <4989B3C2.6010702@kickflop.net> References: <4989A664.60906@mitre.org> <4989B3C2.6010702@kickflop.net> Message-ID: I think this is the same issue I ran into here: http://marc.info/?l=openssh-unix-dev&m=123272045416931&w=2 -k On Wed, 4 Feb 2009, Jeff Blaine wrote: > What's going on here? I see nothing about this in the > ChangeLog, so I am confused. > > ================================================================== > > ~:cairo> pwd > /afs/rcf/user/jblaine > ~:cairo> cat bin/tester > #!/bin/sh > > echo "TESTER program in $HOME/bin!" > ~:cairo> > > ================================================================== > > OpenSSH 4.4p1 (previous version we were running, temporarily > stood up in debug mode on port 3333): > > ~:cairo> ssh -p 3333 rcf-ssh tester > Password: > TESTER program in /afs/rcf/user/jblaine/bin! > ~:cairo> > > ================================================================== > > OpenSSH 5.1p1 (current): > > ~:cairo> ssh rcf-ssh tester > Password: > bash: tester: command not found > ~:cairo> > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From jblaine at kickflop.net Thu Feb 5 03:56:39 2009 From: jblaine at kickflop.net (Jeff Blaine) Date: Wed, 04 Feb 2009 11:56:39 -0500 Subject: 5.1p1 and X11 forwarding failing Message-ID: <4989C8C7.5090607@kickflop.net> I'm really scratching my head on this one. The server is running OpenSSH 5.1p1 on Solaris 9. The authentication is via PAM if that matters. # grep X11 sshd_config | sed '/^#/D' X11Forwarding yes X11DisplayOffset 10 X11UseLocalhost yes # Now I attach to my 'master' sshd and follow all children to look for any evidence of "DISPLAY": # truss -f -a -e -p 14923 2>&1 | grep DISPLAY I then fire up ssh -X from a client machine, login, and truss reports nothing. If I perform the EXACT same test against stock Solaris 9 sshd (also authenticating against PAM), DISPLAY shows up (in truss and in the shell) and X11 forwarding works fine. Any ideas? From djm at mindrot.org Thu Feb 5 08:29:24 2009 From: djm at mindrot.org (Damien Miller) Date: Thu, 5 Feb 2009 08:29:24 +1100 (EST) Subject: 5.1p1 and X11 forwarding failing In-Reply-To: <4989C8C7.5090607@kickflop.net> References: <4989C8C7.5090607@kickflop.net> Message-ID: On Wed, 4 Feb 2009, Jeff Blaine wrote: > I'm really scratching my head on this one. The server > is running OpenSSH 5.1p1 on Solaris 9. The authentication > is via PAM if that matters. > > # grep X11 sshd_config | sed '/^#/D' > X11Forwarding yes > X11DisplayOffset 10 > X11UseLocalhost yes > # > > Now I attach to my 'master' sshd and follow all children > to look for any evidence of "DISPLAY": > > # truss -f -a -e -p 14923 2>&1 | grep DISPLAY > > I then fire up ssh -X from a client machine, login, and > truss reports nothing. truss is a really poor tool to diagnose ssh problems. Please post ssh and sshd debug traces. -d From jblaine at kickflop.net Thu Feb 5 08:46:41 2009 From: jblaine at kickflop.net (Jeff Blaine) Date: Wed, 04 Feb 2009 16:46:41 -0500 Subject: 5.1p1 and X11 forwarding failing In-Reply-To: References: <4989C8C7.5090607@kickflop.net> Message-ID: <498A0CC1.2040202@kickflop.net> =================================================================== OpenSSH_5.1p1, OpenSSL 0.9.8i 15 Sep 2008 debug1: Connecting to sshserver.our.com [XX.YY.10.1] port 3333. debug1: Connection established. debug1: identity file /cygdrive/c/Documents and Settings/jblaine/.ssh/identity type -1 debug1: identity file /cygdrive/c/Documents and Settings/jblaine/.ssh/id_rsa type -1 debug1: identity file /cygdrive/c/Documents and Settings/jblaine/.ssh/id_dsa type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1 debug1: match: OpenSSH_5.1 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_5.1 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-cbc hmac-md5 none 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 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: checking without port identifier debug1: Host 'sshserver.our.com' is known and matches the RSA host key. debug1: Found key in /cygdrive/c/Documents and Settings/jblaine/.ssh/known_hosts:2 debug1: found matching key w/out port debug1: ssh_rsa_verify: signature correct debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: keyboard-interactive debug1: Next authentication method: keyboard-interactive debug1: Authentication succeeded (keyboard-interactive). debug1: channel 0: new [client-session] debug1: Requesting no-more-sessions at openssh.com debug1: Entering interactive session. Warning: untrusted X11 forwarding setup failed: xauth key data not generated Warning: No xauth data; using fake authentication data for X11 forwarding. debug1: Requesting X11 forwarding with authentication spoofing. debug1: client_input_channel_req: channel 0 rtype exit-status reply 0 debug1: client_input_channel_req: channel 0 rtype eow at openssh.com reply 0 debug1: channel 0: free: client-session, nchannels 1 Connection to sshserver.our.com closed. Transferred: sent 1904, received 5912 bytes, in 24.6 seconds Bytes per second: sent 77.5, received 240.7 debug1: Exit status 0 =================================================================== debug1: sshd version OpenSSH_5.1p1 debug1: read PEM private key done: type RSA debug1: private host key: #0 type 1 RSA debug1: read PEM private key done: type DSA debug1: private host key: #1 type 2 DSA debug1: rexec_argv[0]='/testing/openssh-5.1p1/sbin/sshd' debug1: rexec_argv[1]='-p' debug1: rexec_argv[2]='3333' debug1: rexec_argv[3]='-d' debug1: Bind to port 3333 on ::. Server listening on :: port 3333. debug1: Bind to port 3333 on 0.0.0.0. Server listening on 0.0.0.0 port 3333. debug1: fd 6 clearing O_NONBLOCK debug1: Server will not fork when running in debugging mode. debug1: rexec start in 6 out 6 newsock 6 pipe -1 sock 11 debug1: inetd sockets after dupping: 4, 4 Connection from AA.BB.6.43 port 4872 debug1: Client protocol version 2.0; client software version OpenSSH_5.1 debug1: match: OpenSSH_5.1 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_5.1 debug1: permanently_set_uid: 27/65000 debug1: list_hostkey_types: ssh-rsa,ssh-dss debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: client->server aes128-cbc hmac-md5 none debug1: kex: server->client aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: KEX done debug1: userauth-request for user jblaine service ssh-connection method none debug1: attempt 0 failures 0 debug1: PAM: initializing for "jblaine" debug1: PAM: setting PAM_RHOST to "AA.BB.6.43" debug1: PAM: setting PAM_TTY to "ssh" debug1: userauth-request for user jblaine service ssh-connection method keyboard-interactive debug1: attempt 1 failures 0 debug1: keyboard-interactive devs debug1: auth2_challenge: user=jblaine devs= debug1: kbdint_alloc: devices 'pam' debug1: auth2_challenge_start: trying authentication method 'pam' Postponed keyboard-interactive for jblaine from AA.BB.6.43 port 4872 ssh2 Postponed keyboard-interactive/pam for jblaine from AA.BB.6.43 port 4872 ssh2 debug1: do_pam_account: called debug1: PAM: num PAM env strings 1 Postponed keyboard-interactive/pam for jblaine from AA.BB.6.43 port 4872 ssh2 debug1: do_pam_account: called Accepted keyboard-interactive/pam for jblaine from AA.BB.6.43 port 4872 ssh2 debug1: monitor_child_preauth: jblaine has been authenticated by privileged process debug1: PAM: establishing credentials User child is on pid 27888 debug1: PAM: establishing credentials debug1: permanently_set_uid: 26560/10 debug1: Entering interactive session for SSH2. debug1: server_init_dispatch_20 debug1: server_input_channel_open: ctype session rchan 0 win 1048576 max 16384 debug1: input_session_request debug1: channel 0: new [server-session] 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_global_request: rtype no-more-sessions at openssh.com want_reply 0 debug1: server_input_channel_req: channel 0 request x11-req reply 0 debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 req x11-req Failed to allocate internet-domain X11 display socket. debug1: x11_create_display_inet failed. debug1: server_input_channel_req: channel 0 request pty-req reply 1 debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 req pty-req debug1: Allocating pty. debug1: session_new: session 0 debug1: session_pty_req: session 0 alloc /dev/pts/26 debug1: server_input_channel_req: channel 0 request shell reply 1 debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 req shell debug1: Received SIGCHLD. debug1: session_by_pid: pid 29309 debug1: session_exit_message: session 0 channel 0 pid 29309 debug1: session_exit_message: release channel 0 debug1: session_by_tty: session 0 tty /dev/pts/26 debug1: session_pty_cleanup: session 0 release /dev/pts/26 debug1: session_by_channel: session 0 channel 0 debug1: session_close_by_channel: channel 0 child 0 debug1: session_close: session 0 pid 0 debug1: channel 0: free: server-session, nchannels 1 Connection closed by AA.BB.6.43 debug1: do_cleanup Transferred: sent 5912, received 1904 bytes Closing connection to AA.BB.6.43 port 4872 debug1: PAM: cleanup debug1: PAM: deleting credentials debug1: PAM: closing session Damien Miller wrote: > On Wed, 4 Feb 2009, Jeff Blaine wrote: > >> I'm really scratching my head on this one. The server >> is running OpenSSH 5.1p1 on Solaris 9. The authentication >> is via PAM if that matters. >> >> # grep X11 sshd_config | sed '/^#/D' >> X11Forwarding yes >> X11DisplayOffset 10 >> X11UseLocalhost yes >> # >> >> Now I attach to my 'master' sshd and follow all children >> to look for any evidence of "DISPLAY": >> >> # truss -f -a -e -p 14923 2>&1 | grep DISPLAY >> >> I then fire up ssh -X from a client machine, login, and >> truss reports nothing. > > truss is a really poor tool to diagnose ssh problems. Please post > ssh and sshd debug traces. > > -d > _______________________________________________ > 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 Thu Feb 5 08:51:16 2009 From: djm at mindrot.org (Damien Miller) Date: Thu, 5 Feb 2009 08:51:16 +1100 (EST) Subject: 5.1p1 and X11 forwarding failing In-Reply-To: <498A0CC1.2040202@kickflop.net> References: <4989C8C7.5090607@kickflop.net> <498A0CC1.2040202@kickflop.net> Message-ID: On Wed, 4 Feb 2009, Jeff Blaine wrote: > debug1: server_input_channel_req: channel 0 request x11-req reply 0 > debug1: session_by_channel: session 0 channel 0 > debug1: session_input_channel_req: session 0 req x11-req > Failed to allocate internet-domain X11 display socket. > debug1: x11_create_display_inet failed. Here is the problem, but I can't tell what caused it. You should send a full debug trace "sshd -ddd" -d From jblaine at kickflop.net Thu Feb 5 09:01:56 2009 From: jblaine at kickflop.net (Jeff Blaine) Date: Wed, 04 Feb 2009 17:01:56 -0500 Subject: 5.1p1 and X11 forwarding failing In-Reply-To: References: <4989C8C7.5090607@kickflop.net> <498A0CC1.2040202@kickflop.net> Message-ID: <498A1054.4090700@kickflop.net> debug2: load_server_config: filename /testing/openssh-5.1p1/etc/sshd_config debug2: load_server_config: done config len = 430 debug2: parse_server_config: config /testing/openssh-5.1p1/etc/sshd_config len 430 debug3: /testing/openssh-5.1p1/etc/sshd_config:21 setting Protocol 2 debug3: /testing/openssh-5.1p1/etc/sshd_config:30 setting KeyRegenerationInterval 30m debug3: /testing/openssh-5.1p1/etc/sshd_config:31 setting ServerKeyBits 768 debug3: /testing/openssh-5.1p1/etc/sshd_config:36 setting LogLevel VERBOSE debug3: /testing/openssh-5.1p1/etc/sshd_config:40 setting LoginGraceTime 1m debug3: /testing/openssh-5.1p1/etc/sshd_config:41 setting PermitRootLogin no debug3: /testing/openssh-5.1p1/etc/sshd_config:43 setting MaxAuthTries 8 debug3: /testing/openssh-5.1p1/etc/sshd_config:46 setting RSAAuthentication no debug3: /testing/openssh-5.1p1/etc/sshd_config:47 setting PubkeyAuthentication no debug3: /testing/openssh-5.1p1/etc/sshd_config:61 setting PasswordAuthentication no debug3: /testing/openssh-5.1p1/etc/sshd_config:86 setting UsePAM yes debug3: /testing/openssh-5.1p1/etc/sshd_config:91 setting X11Forwarding yes debug3: /testing/openssh-5.1p1/etc/sshd_config:92 setting X11DisplayOffset 10 debug3: /testing/openssh-5.1p1/etc/sshd_config:93 setting X11UseLocalhost yes debug3: /testing/openssh-5.1p1/etc/sshd_config:103 setting UseDNS no debug3: /testing/openssh-5.1p1/etc/sshd_config:113 setting Subsystem sftp /testing/openssh/libexec/sftp-server debug1: sshd version OpenSSH_5.1p1 debug3: Not a RSA1 key file /testing/openssh-5.1p1/etc/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 /testing/openssh-5.1p1/etc/ssh_host_dsa_key. debug1: read PEM private key done: type DSA debug1: private host key: #1 type 2 DSA debug1: rexec_argv[0]='/testing/openssh-5.1p1/sbin/sshd' debug1: rexec_argv[1]='-p' debug1: rexec_argv[2]='3333' debug1: rexec_argv[3]='-ddd' debug2: fd 4 setting O_NONBLOCK debug1: Bind to port 3333 on ::. Server listening on :: port 3333. debug2: fd 5 setting O_NONBLOCK debug1: Bind to port 3333 on 0.0.0.0. Server listening on 0.0.0.0 port 3333. 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 430 debug3: ssh_msg_send: type 0 debug3: send_rexec_state: done debug1: rexec start in 6 out 6 newsock 6 pipe -1 sock 11 debug1: inetd sockets after dupping: 4, 4 Connection from AA.BB.6.43 port 1040 debug1: Client protocol version 2.0; client software version OpenSSH_5.1 debug1: match: OpenSSH_5.1 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_5.1 debug2: fd 4 setting O_NONBLOCK debug2: Network child is on pid 29868 debug3: preauth child monitor started debug3: mm_request_receive entering debug3: privsep user:group 27:65000 debug1: permanently_set_uid: 27/65000 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-sha256,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,aes128-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,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64 at openssh.com,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64 at openssh.com,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-sha256,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,aes128-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,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64 at openssh.com,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64 at openssh.com,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_setup: found hmac-md5 debug1: kex: client->server aes128-cbc hmac-md5 none debug2: mac_setup: 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: monitor_read: checking request 0 debug3: mm_request_receive_expect entering: type 1 debug3: mm_answer_moduli: got parameters: 1024 1024 8192 debug3: mm_request_receive entering debug3: mm_request_send entering: type 1 debug2: monitor_read: 0 used once, disabling now debug3: mm_request_receive entering debug3: mm_choose_dh: remaining 0 debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent debug2: dh_gen_key: priv key bits set: 126/256 debug2: bits set: 500/1024 debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT debug2: bits set: 499/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 15dcf8(143) debug3: mm_request_send entering: type 5 debug2: monitor_read: 4 used once, disabling now debug3: mm_request_receive entering 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: set_newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: KEX done debug1: userauth-request for user jblaine 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 debug2: parse_server_config: config reprocess config len 430 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 jblaine debug3: mm_start_pam entering debug3: mm_request_send entering: type 45 debug3: mm_inform_authserv entering debug3: mm_request_send entering: type 3 debug2: input_userauth_request: try method none debug3: monitor_read: checking request 45 debug1: PAM: initializing for "jblaine" debug1: PAM: setting PAM_RHOST to "AA.BB.6.43" debug1: PAM: setting PAM_TTY to "ssh" debug2: monitor_read: 45 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 debug1: userauth-request for user jblaine service ssh-connection method keyboard-interactive debug1: attempt 1 failures 0 debug2: input_userauth_request: try method keyboard-interactive debug1: keyboard-interactive devs debug1: auth2_challenge: user=jblaine devs= debug1: kbdint_alloc: devices 'pam' debug2: auth2_challenge_start: devices pam debug2: kbdint_next_device: devices debug1: auth2_challenge_start: trying authentication method 'pam' debug3: mm_sshpam_init_ctx debug3: mm_request_send entering: type 48 debug3: mm_sshpam_init_ctx: waiting for MONITOR_ANS_PAM_INIT_CTX debug3: mm_request_receive_expect entering: type 49 debug3: mm_request_receive entering debug3: monitor_read: checking request 48 debug3: mm_answer_pam_init_ctx debug3: PAM: sshpam_init_ctx entering debug3: mm_request_send entering: type 49 debug3: mm_request_receive entering debug3: mm_sshpam_query debug3: mm_request_send entering: type 50 debug3: mm_sshpam_query: waiting for MONITOR_ANS_PAM_QUERY debug3: mm_request_receive_expect entering: type 51 debug3: mm_request_receive entering debug3: monitor_read: checking request 50 debug3: mm_answer_pam_query debug3: PAM: sshpam_query entering debug3: ssh_msg_recv entering debug3: PAM: sshpam_thread_conv entering, 1 messages debug3: ssh_msg_send: type 1 debug3: mm_request_send entering: type 51 debug3: mm_sshpam_query: pam_query returned 0 Postponed keyboard-interactive for jblaine from AA.BB.6.43 port 1040 ssh2 debug3: mm_request_receive entering debug3: ssh_msg_recv entering debug3: mm_sshpam_respond debug3: mm_request_send entering: type 52 debug3: mm_sshpam_respond: waiting for MONITOR_ANS_PAM_RESPOND debug3: mm_request_receive_expect entering: type 53 debug3: mm_request_receive entering debug3: monitor_read: checking request 52 debug3: mm_answer_pam_respond debug2: PAM: sshpam_respond entering, 1 responses debug3: ssh_msg_send: type 6 debug3: mm_request_send entering: type 53 debug3: mm_request_receive entering debug3: mm_sshpam_respond: pam_respond returned 1 debug3: mm_sshpam_query debug3: mm_request_send entering: type 50 debug3: mm_sshpam_query: waiting for MONITOR_ANS_PAM_QUERY debug3: mm_request_receive_expect entering: type 51 debug3: mm_request_receive entering debug3: monitor_read: checking request 50 debug3: mm_answer_pam_query debug3: PAM: sshpam_query entering debug3: ssh_msg_recv entering debug3: PAM: sshpam_thread_conv entering, 1 messages debug3: ssh_msg_send: type 1 debug3: ssh_msg_recv entering debug3: mm_request_send entering: type 51 debug3: mm_request_receive entering debug3: mm_sshpam_query: pam_query returned 0 Postponed keyboard-interactive/pam for jblaine from AA.BB.6.43 port 1040 ssh2 debug3: mm_sshpam_respond debug3: mm_request_send entering: type 52 debug3: mm_sshpam_respond: waiting for MONITOR_ANS_PAM_RESPOND debug3: mm_request_receive_expect entering: type 53 debug3: monitor_read: checking request 52 debug3: mm_request_receive entering debug3: mm_answer_pam_respond debug2: PAM: sshpam_respond entering, 1 responses debug3: ssh_msg_send: type 6 debug3: mm_request_send entering: type 53 debug3: mm_request_receive entering debug3: mm_sshpam_respond: pam_respond returned 1 debug3: mm_sshpam_query debug3: mm_request_send entering: type 50 debug3: mm_sshpam_query: waiting for MONITOR_ANS_PAM_QUERY debug3: mm_request_receive_expect entering: type 51 debug3: mm_request_receive entering debug3: monitor_read: checking request 50 debug3: mm_answer_pam_query debug3: PAM: sshpam_query entering debug3: ssh_msg_recv entering debug1: do_pam_account: called debug3: PAM: do_pam_account pam_acct_mgmt = 0 (Success) debug3: ssh_msg_send: type 0 debug3: PAM: import_environments entering debug3: sshpam_password_change_required 0 debug3: PAM: num env strings 2 debug1: PAM: num PAM env strings 1 debug3: mm_request_send entering: type 51 debug3: mm_request_receive entering debug3: mm_sshpam_query: pam_query returned 0 Postponed keyboard-interactive/pam for jblaine from AA.BB.6.43 port 1040 ssh2 debug3: mm_sshpam_respond debug3: mm_request_send entering: type 52 debug3: mm_sshpam_respond: waiting for MONITOR_ANS_PAM_RESPOND debug3: mm_request_receive_expect entering: type 53 debug3: monitor_read: checking request 52 debug3: mm_request_receive entering debug3: mm_answer_pam_respond debug2: PAM: sshpam_respond entering, 0 responses debug3: mm_request_send entering: type 53 debug3: mm_request_receive entering debug3: mm_sshpam_respond: pam_respond returned 0 debug3: mm_sshpam_free_ctx debug3: mm_request_send entering: type 54 debug3: monitor_read: checking request 54 debug3: mm_sshpam_free_ctx: waiting for MONITOR_ANS_PAM_FREE_CTX debug3: mm_request_receive_expect entering: type 55 debug3: mm_request_receive entering debug3: mm_answer_pam_free_ctx debug3: PAM: sshpam_free_ctx entering debug3: PAM: sshpam_thread_cleanup entering debug3: mm_request_send entering: type 55 debug2: monitor_read: 54 used once, disabling now debug3: mm_request_receive_expect entering: type 46 debug3: mm_do_pam_account entering debug3: mm_request_receive entering debug3: mm_request_send entering: type 46 debug3: mm_request_receive_expect entering: type 47 debug1: do_pam_account: called debug3: mm_request_receive entering debug3: mm_request_send entering: type 47 Accepted keyboard-interactive/pam for jblaine from AA.BB.6.43 port 1040 ssh2 debug3: mm_do_pam_account returning 1 debug1: monitor_child_preauth: jblaine 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_send_keystate: Sending new keys: 15db98 15da90 debug3: mm_newkeys_to_blob: converting 15db98 debug3: mm_newkeys_to_blob: converting 15da90 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 debug3: mm_newkeys_from_blob: 15cec8(118) debug2: mac_setup: found hmac-md5 debug3: mm_get_keystate: Waiting for second key debug3: mm_newkeys_from_blob: 15cec8(118) debug2: mac_setup: 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 debug1: PAM: establishing credentials debug3: PAM: opening session User child is on pid 29873 debug3: mm_request_receive entering debug1: PAM: establishing credentials debug1: permanently_set_uid: 26560/10 debug2: set_newkeys: mode 0 debug2: set_newkeys: mode 1 debug1: Entering interactive session for SSH2. debug2: fd 6 setting O_NONBLOCK debug2: fd 7 setting O_NONBLOCK debug1: server_init_dispatch_20 debug1: server_input_channel_open: ctype session rchan 0 win 1048576 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_global_request: rtype no-more-sessions at openssh.com want_reply 0 debug1: server_input_channel_req: channel 0 request x11-req reply 0 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 6013: Cannot assign requested address debug2: bind port 6014: Cannot assign requested address debug2: bind port 6015: Cannot assign requested address debug2: bind port 6016: Cannot assign requested address debug2: bind port 6017: Cannot assign requested address debug2: bind port 6018: Cannot assign requested address debug2: bind port 6019: Cannot assign requested address debug2: bind port 6020: Cannot assign requested address debug2: bind port 6021: Cannot assign requested address debug2: bind port 6022: Cannot assign requested address debug2: bind port 6023: Cannot assign requested address debug2: bind port 6024: Cannot assign requested address debug2: bind port 6025: Cannot assign requested address debug2: bind port 6026: Cannot assign requested address debug2: bind port 6027: Cannot assign requested address debug2: bind port 6028: Cannot assign requested address debug2: bind port 6029: Cannot assign requested address debug2: bind port 6030: Cannot assign requested address debug2: bind port 6031: Cannot assign requested address debug2: bind port 6032: Cannot assign requested address debug2: bind port 6033: Cannot assign requested address debug2: bind port 6034: Cannot assign requested address debug2: bind port 6035: Cannot assign requested address debug2: bind port 6036: Cannot assign requested address debug2: bind port 6037: Cannot assign requested address debug2: bind port 6038: Cannot assign requested address debug2: bind port 6039: Cannot assign requested address debug2: bind port 6040: Cannot assign requested address debug2: bind port 6041: Cannot assign requested address debug2: bind port 6042: Cannot assign requested address debug2: bind port 6043: Cannot assign requested address debug2: bind port 6044: Cannot assign requested address debug2: bind port 6045: Cannot assign requested address debug2: bind port 6046: Cannot assign requested address debug2: bind port 6047: Cannot assign requested address debug2: bind port 6048: Cannot assign requested address debug2: bind port 6049: Cannot assign requested address debug2: bind port 6050: Cannot assign requested address debug2: bind port 6051: Cannot assign requested address debug2: bind port 6052: Cannot assign requested address debug2: bind port 6053: Cannot assign requested address debug2: bind port 6054: Cannot assign requested address debug2: bind port 6055: Cannot assign requested address debug2: bind port 6056: Cannot assign requested address debug2: bind port 6057: Cannot assign requested address debug2: bind port 6058: Cannot assign requested address debug2: bind port 6059: Cannot assign requested address debug2: bind port 6060: Cannot assign requested address debug2: bind port 6061: Cannot assign requested address debug2: bind port 6062: Cannot assign requested address debug2: bind port 6063: Cannot assign requested address debug2: bind port 6064: Cannot assign requested address debug2: bind port 6065: Cannot assign requested address debug2: bind port 6066: Cannot assign requested address debug2: bind port 6067: Cannot assign requested address debug2: bind port 6068: Cannot assign requested address debug2: bind port 6069: Cannot assign requested address debug2: bind port 6070: Cannot assign requested address debug2: bind port 6071: Cannot assign requested address debug2: bind port 6072: Cannot assign requested address debug2: bind port 6073: Cannot assign requested address debug2: bind port 6074: Cannot assign requested address debug2: bind port 6075: Cannot assign requested address debug2: bind port 6076: Cannot assign requested address debug2: bind port 6077: Cannot assign requested address debug2: bind port 6078: Cannot assign requested address debug2: bind port 6079: Cannot assign requested address debug2: bind port 6080: Cannot assign requested address debug2: bind port 6081: Cannot assign requested address debug2: bind port 6082: Cannot assign requested address debug2: bind port 6083: Cannot assign requested address debug2: bind port 6084: Cannot assign requested address debug2: bind port 6085: Cannot assign requested address debug2: bind port 6086: Cannot assign requested address debug2: bind port 6087: Cannot assign requested address debug2: bind port 6088: Cannot assign requested address debug2: bind port 6089: Cannot assign requested address debug2: bind port 6090: Cannot assign requested address debug2: bind port 6091: Cannot assign requested address debug2: bind port 6092: Cannot assign requested address debug2: bind port 6093: Cannot assign requested address debug2: bind port 6094: Cannot assign requested address debug2: bind port 6095: Cannot assign requested address debug2: bind port 6096: Cannot assign requested address debug2: bind port 6097: Cannot assign requested address debug2: bind port 6098: Cannot assign requested address debug2: bind port 6099: Cannot assign requested address debug2: bind port 6100: Cannot assign requested address debug2: bind port 6101: Cannot assign requested address debug2: bind port 6102: Cannot assign requested address debug2: bind port 6103: Cannot assign requested address debug2: bind port 6104: Cannot assign requested address debug2: bind port 6105: Cannot assign requested address debug2: bind port 6106: Cannot assign requested address debug2: bind port 6107: Cannot assign requested address debug2: bind port 6108: Cannot assign requested address debug2: bind port 6109: Cannot assign requested address debug2: bind port 6110: Cannot assign requested address debug2: bind port 6111: Cannot assign requested address debug2: bind port 6112: Cannot assign requested address debug2: bind port 6113: Cannot assign requested address debug2: bind port 6114: Cannot assign requested address debug2: bind port 6115: Cannot assign requested address debug2: bind port 6116: Cannot assign requested address debug2: bind port 6117: Cannot assign requested address debug2: bind port 6118: Cannot assign requested address debug2: bind port 6119: Cannot assign requested address debug2: bind port 6120: Cannot assign requested address debug2: bind port 6121: Cannot assign requested address debug2: bind port 6122: Cannot assign requested address debug2: bind port 6123: Cannot assign requested address debug2: bind port 6124: Cannot assign requested address debug2: bind port 6125: Cannot assign requested address debug2: bind port 6126: Cannot assign requested address debug2: bind port 6127: Cannot assign requested address debug2: bind port 6128: Cannot assign requested address debug2: bind port 6129: Cannot assign requested address debug2: bind port 6130: Cannot assign requested address debug2: bind port 6131: Cannot assign requested address debug2: bind port 6132: Cannot assign requested address debug2: bind port 6133: Cannot assign requested address debug2: bind port 6134: Cannot assign requested address debug2: bind port 6135: Cannot assign requested address debug2: bind port 6136: Cannot assign requested address debug2: bind port 6137: Cannot assign requested address debug2: bind port 6138: Cannot assign requested address debug2: bind port 6139: Cannot assign requested address debug2: bind port 6140: Cannot assign requested address debug2: bind port 6141: Cannot assign requested address debug2: bind port 6142: Cannot assign requested address debug2: bind port 6143: Cannot assign requested address debug2: bind port 6144: Cannot assign requested address debug2: bind port 6145: Cannot assign requested address debug2: bind port 6146: Cannot assign requested address debug2: bind port 6147: Cannot assign requested address debug2: bind port 6148: Cannot assign requested address debug2: bind port 6149: Cannot assign requested address debug2: bind port 6150: Cannot assign requested address debug2: bind port 6151: Cannot assign requested address debug2: bind port 6152: Cannot assign requested address debug2: bind port 6153: Cannot assign requested address debug2: bind port 6154: Cannot assign requested address debug2: bind port 6155: Cannot assign requested address debug2: bind port 6156: Cannot assign requested address debug2: bind port 6157: Cannot assign requested address debug2: bind port 6158: Cannot assign requested address debug2: bind port 6159: Cannot assign requested address debug2: bind port 6160: Cannot assign requested address debug2: bind port 6161: Cannot assign requested address debug2: bind port 6162: Cannot assign requested address debug2: bind port 6163: Cannot assign requested address debug2: bind port 6164: Cannot assign requested address debug2: bind port 6165: Cannot assign requested address debug2: bind port 6166: Cannot assign requested address debug2: bind port 6167: Cannot assign requested address debug2: bind port 6168: Cannot assign requested address debug2: bind port 6169: Cannot assign requested address debug2: bind port 6170: Cannot assign requested address debug2: bind port 6171: Cannot assign requested address debug2: bind port 6172: Cannot assign requested address debug2: bind port 6173: Cannot assign requested address debug2: bind port 6174: Cannot assign requested address debug2: bind port 6175: Cannot assign requested address debug2: bind port 6176: Cannot assign requested address debug2: bind port 6177: Cannot assign requested address debug2: bind port 6178: Cannot assign requested address debug2: bind port 6179: Cannot assign requested address debug2: bind port 6180: Cannot assign requested address debug2: bind port 6181: Cannot assign requested address debug2: bind port 6182: Cannot assign requested address debug2: bind port 6183: Cannot assign requested address debug2: bind port 6184: Cannot assign requested address debug2: bind port 6185: Cannot assign requested address debug2: bind port 6186: Cannot assign requested address debug2: bind port 6187: Cannot assign requested address debug2: bind port 6188: Cannot assign requested address debug2: bind port 6189: Cannot assign requested address debug2: bind port 6190: Cannot assign requested address debug2: bind port 6191: Cannot assign requested address debug2: bind port 6192: Cannot assign requested address debug2: bind port 6193: Cannot assign requested address debug2: bind port 6194: Cannot assign requested address debug2: bind port 6195: Cannot assign requested address debug2: bind port 6196: Cannot assign requested address debug2: bind port 6197: Cannot assign requested address debug2: bind port 6198: Cannot assign requested address debug2: bind port 6199: Cannot assign requested address debug2: bind port 6200: Cannot assign requested address debug2: bind port 6201: Cannot assign requested address debug2: bind port 6202: Cannot assign requested address debug2: bind port 6203: Cannot assign requested address debug2: bind port 6204: Cannot assign requested address debug2: bind port 6205: Cannot assign requested address debug2: bind port 6206: Cannot assign requested address debug2: bind port 6207: Cannot assign requested address debug2: bind port 6208: Cannot assign requested address debug2: bind port 6209: Cannot assign requested address debug2: bind port 6210: Cannot assign requested address debug2: bind port 6211: Cannot assign requested address debug2: bind port 6212: Cannot assign requested address debug2: bind port 6213: Cannot assign requested address debug2: bind port 6214: Cannot assign requested address debug2: bind port 6215: Cannot assign requested address debug2: bind port 6216: Cannot assign requested address debug2: bind port 6217: Cannot assign requested address debug2: bind port 6218: Cannot assign requested address debug2: bind port 6219: Cannot assign requested address debug2: bind port 6220: Cannot assign requested address debug2: bind port 6221: Cannot assign requested address debug2: bind port 6222: Cannot assign requested address debug2: bind port 6223: Cannot assign requested address debug2: bind port 6224: Cannot assign requested address debug2: bind port 6225: Cannot assign requested address debug2: bind port 6226: Cannot assign requested address debug2: bind port 6227: Cannot assign requested address debug2: bind port 6228: Cannot assign requested address debug2: bind port 6229: Cannot assign requested address debug2: bind port 6230: Cannot assign requested address debug2: bind port 6231: Cannot assign requested address debug2: bind port 6232: Cannot assign requested address debug2: bind port 6233: Cannot assign requested address debug2: bind port 6234: Cannot assign requested address debug2: bind port 6235: Cannot assign requested address debug2: bind port 6236: Cannot assign requested address debug2: bind port 6237: Cannot assign requested address debug2: bind port 6238: Cannot assign requested address debug2: bind port 6239: Cannot assign requested address debug2: bind port 6240: Cannot assign requested address debug2: bind port 6241: Cannot assign requested address debug2: bind port 6242: Cannot assign requested address debug2: bind port 6243: Cannot assign requested address debug2: bind port 6244: Cannot assign requested address debug2: bind port 6245: Cannot assign requested address debug2: bind port 6246: Cannot assign requested address debug2: bind port 6247: Cannot assign requested address debug2: bind port 6248: Cannot assign requested address debug2: bind port 6249: Cannot assign requested address debug2: bind port 6250: Cannot assign requested address debug2: bind port 6251: Cannot assign requested address debug2: bind port 6252: Cannot assign requested address debug2: bind port 6253: Cannot assign requested address debug2: bind port 6254: Cannot assign requested address debug2: bind port 6255: Cannot assign requested address debug2: bind port 6256: Cannot assign requested address debug2: bind port 6257: Cannot assign requested address debug2: bind port 6258: Cannot assign requested address debug2: bind port 6259: Cannot assign requested address debug2: bind port 6260: Cannot assign requested address debug2: bind port 6261: Cannot assign requested address debug2: bind port 6262: Cannot assign requested address debug2: bind port 6263: Cannot assign requested address debug2: bind port 6264: Cannot assign requested address debug2: bind port 6265: Cannot assign requested address debug2: bind port 6266: Cannot assign requested address debug2: bind port 6267: Cannot assign requested address debug2: bind port 6268: Cannot assign requested address debug2: bind port 6269: Cannot assign requested address debug2: bind port 6270: Cannot assign requested address debug2: bind port 6271: Cannot assign requested address debug2: bind port 6272: Cannot assign requested address debug2: bind port 6273: Cannot assign requested address debug2: bind port 6274: Cannot assign requested address debug2: bind port 6275: Cannot assign requested address debug2: bind port 6276: Cannot assign requested address debug2: bind port 6277: Cannot assign requested address debug2: bind port 6278: Cannot assign requested address debug2: bind port 6279: Cannot assign requested address debug2: bind port 6280: Cannot assign requested address debug2: bind port 6281: Cannot assign requested address debug2: bind port 6282: Cannot assign requested address debug2: bind port 6283: Cannot assign requested address debug2: bind port 6284: Cannot assign requested address debug2: bind port 6285: Cannot assign requested address debug2: bind port 6286: Cannot assign requested address debug2: bind port 6287: Cannot assign requested address debug2: bind port 6288: Cannot assign requested address debug2: bind port 6289: Cannot assign requested address debug2: bind port 6290: Cannot assign requested address debug2: bind port 6291: Cannot assign requested address debug2: bind port 6292: Cannot assign requested address debug2: bind port 6293: Cannot assign requested address debug2: bind port 6294: Cannot assign requested address debug2: bind port 6295: Cannot assign requested address debug2: bind port 6296: Cannot assign requested address debug2: bind port 6297: Cannot assign requested address debug2: bind port 6298: Cannot assign requested address debug2: bind port 6299: Cannot assign requested address debug2: bind port 6300: Cannot assign requested address debug2: bind port 6301: Cannot assign requested address debug2: bind port 6302: Cannot assign requested address debug2: bind port 6303: Cannot assign requested address debug2: bind port 6304: Cannot assign requested address debug2: bind port 6305: Cannot assign requested address debug2: bind port 6306: Cannot assign requested address debug2: bind port 6307: Cannot assign requested address debug2: bind port 6308: Cannot assign requested address debug2: bind port 6309: Cannot assign requested address debug2: bind port 6310: Cannot assign requested address debug2: bind port 6311: Cannot assign requested address debug2: bind port 6312: Cannot assign requested address debug2: bind port 6313: Cannot assign requested address debug2: bind port 6314: Cannot assign requested address debug2: bind port 6315: Cannot assign requested address debug2: bind port 6316: Cannot assign requested address debug2: bind port 6317: Cannot assign requested address debug2: bind port 6318: Cannot assign requested address debug2: bind port 6319: Cannot assign requested address debug2: bind port 6320: Cannot assign requested address debug2: bind port 6321: Cannot assign requested address debug2: bind port 6322: Cannot assign requested address debug2: bind port 6323: Cannot assign requested address debug2: bind port 6324: Cannot assign requested address debug2: bind port 6325: Cannot assign requested address debug2: bind port 6326: Cannot assign requested address debug2: bind port 6327: Cannot assign requested address debug2: bind port 6328: Cannot assign requested address debug2: bind port 6329: Cannot assign requested address debug2: bind port 6330: Cannot assign requested address debug2: bind port 6331: Cannot assign requested address debug2: bind port 6332: Cannot assign requested address debug2: bind port 6333: Cannot assign requested address debug2: bind port 6334: Cannot assign requested address debug2: bind port 6335: Cannot assign requested address debug2: bind port 6336: Cannot assign requested address debug2: bind port 6337: Cannot assign requested address debug2: bind port 6338: Cannot assign requested address debug2: bind port 6339: Cannot assign requested address debug2: bind port 6340: Cannot assign requested address debug2: bind port 6341: Cannot assign requested address debug2: bind port 6342: Cannot assign requested address debug2: bind port 6343: Cannot assign requested address debug2: bind port 6344: Cannot assign requested address debug2: bind port 6345: Cannot assign requested address debug2: bind port 6346: Cannot assign requested address debug2: bind port 6347: Cannot assign requested address debug2: bind port 6348: Cannot assign requested address debug2: bind port 6349: Cannot assign requested address debug2: bind port 6350: Cannot assign requested address debug2: bind port 6351: Cannot assign requested address debug2: bind port 6352: Cannot assign requested address debug2: bind port 6353: Cannot assign requested address debug2: bind port 6354: Cannot assign requested address debug2: bind port 6355: Cannot assign requested address debug2: bind port 6356: Cannot assign requested address debug2: bind port 6357: Cannot assign requested address debug2: bind port 6358: Cannot assign requested address debug2: bind port 6359: Cannot assign requested address debug2: bind port 6360: Cannot assign requested address debug2: bind port 6361: Cannot assign requested address debug2: bind port 6362: Cannot assign requested address debug2: bind port 6363: Cannot assign requested address debug2: bind port 6364: Cannot assign requested address debug2: bind port 6365: Cannot assign requested address debug2: bind port 6366: Cannot assign requested address debug2: bind port 6367: Cannot assign requested address debug2: bind port 6368: Cannot assign requested address debug2: bind port 6369: Cannot assign requested address debug2: bind port 6370: Cannot assign requested address debug2: bind port 6371: Cannot assign requested address debug2: bind port 6372: Cannot assign requested address debug2: bind port 6373: Cannot assign requested address debug2: bind port 6374: Cannot assign requested address debug2: bind port 6375: Cannot assign requested address debug2: bind port 6376: Cannot assign requested address debug2: bind port 6377: Cannot assign requested address debug2: bind port 6378: Cannot assign requested address debug2: bind port 6379: Cannot assign requested address debug2: bind port 6380: Cannot assign requested address debug2: bind port 6381: Cannot assign requested address debug2: bind port 6382: Cannot assign requested address debug2: bind port 6383: Cannot assign requested address debug2: bind port 6384: Cannot assign requested address debug2: bind port 6385: Cannot assign requested address debug2: bind port 6386: Cannot assign requested address debug2: bind port 6387: Cannot assign requested address debug2: bind port 6388: Cannot assign requested address debug2: bind port 6389: Cannot assign requested address debug2: bind port 6390: Cannot assign requested address debug2: bind port 6391: Cannot assign requested address debug2: bind port 6392: Cannot assign requested address debug2: bind port 6393: Cannot assign requested address debug2: bind port 6394: Cannot assign requested address debug2: bind port 6395: Cannot assign requested address debug2: bind port 6396: Cannot assign requested address debug2: bind port 6397: Cannot assign requested address debug2: bind port 6398: Cannot assign requested address debug2: bind port 6399: Cannot assign requested address debug2: bind port 6400: Cannot assign requested address debug2: bind port 6401: Cannot assign requested address debug2: bind port 6402: Cannot assign requested address debug2: bind port 6403: Cannot assign requested address debug2: bind port 6404: Cannot assign requested address debug2: bind port 6405: Cannot assign requested address debug2: bind port 6406: Cannot assign requested address debug2: bind port 6407: Cannot assign requested address debug2: bind port 6408: Cannot assign requested address debug2: bind port 6409: Cannot assign requested address debug2: bind port 6410: Cannot assign requested address debug2: bind port 6411: Cannot assign requested address debug2: bind port 6412: Cannot assign requested address debug2: bind port 6413: Cannot assign requested address debug2: bind port 6414: Cannot assign requested address debug2: bind port 6415: Cannot assign requested address debug2: bind port 6416: Cannot assign requested address debug2: bind port 6417: Cannot assign requested address debug2: bind port 6418: Cannot assign requested address debug2: bind port 6419: Cannot assign requested address debug2: bind port 6420: Cannot assign requested address debug2: bind port 6421: Cannot assign requested address debug2: bind port 6422: Cannot assign requested address debug2: bind port 6423: Cannot assign requested address debug2: bind port 6424: Cannot assign requested address debug2: bind port 6425: Cannot assign requested address debug2: bind port 6426: Cannot assign requested address debug2: bind port 6427: Cannot assign requested address debug2: bind port 6428: Cannot assign requested address debug2: bind port 6429: Cannot assign requested address debug2: bind port 6430: Cannot assign requested address debug2: bind port 6431: Cannot assign requested address debug2: bind port 6432: Cannot assign requested address debug2: bind port 6433: Cannot assign requested address debug2: bind port 6434: Cannot assign requested address debug2: bind port 6435: Cannot assign requested address debug2: bind port 6436: Cannot assign requested address debug2: bind port 6437: Cannot assign requested address debug2: bind port 6438: Cannot assign requested address debug2: bind port 6439: Cannot assign requested address debug2: bind port 6440: Cannot assign requested address debug2: bind port 6441: Cannot assign requested address debug2: bind port 6442: Cannot assign requested address debug2: bind port 6443: Cannot assign requested address debug2: bind port 6444: Cannot assign requested address debug2: bind port 6445: Cannot assign requested address debug2: bind port 6446: Cannot assign requested address debug2: bind port 6447: Cannot assign requested address debug2: bind port 6448: Cannot assign requested address debug2: bind port 6449: Cannot assign requested address debug2: bind port 6450: Cannot assign requested address debug2: bind port 6451: Cannot assign requested address debug2: bind port 6452: Cannot assign requested address debug2: bind port 6453: Cannot assign requested address debug2: bind port 6454: Cannot assign requested address debug2: bind port 6455: Cannot assign requested address debug2: bind port 6456: Cannot assign requested address debug2: bind port 6457: Cannot assign requested address debug2: bind port 6458: Cannot assign requested address debug2: bind port 6459: Cannot assign requested address debug2: bind port 6460: Cannot assign requested address debug2: bind port 6461: Cannot assign requested address debug2: bind port 6462: Cannot assign requested address debug2: bind port 6463: Cannot assign requested address debug2: bind port 6464: Cannot assign requested address debug2: bind port 6465: Cannot assign requested address debug2: bind port 6466: Cannot assign requested address debug2: bind port 6467: Cannot assign requested address debug2: bind port 6468: Cannot assign requested address debug2: bind port 6469: Cannot assign requested address debug2: bind port 6470: Cannot assign requested address debug2: bind port 6471: Cannot assign requested address debug2: bind port 6472: Cannot assign requested address debug2: bind port 6473: Cannot assign requested address debug2: bind port 6474: Cannot assign requested address debug2: bind port 6475: Cannot assign requested address debug2: bind port 6476: Cannot assign requested address debug2: bind port 6477: Cannot assign requested address debug2: bind port 6478: Cannot assign requested address debug2: bind port 6479: Cannot assign requested address debug2: bind port 6480: Cannot assign requested address debug2: bind port 6481: Cannot assign requested address debug2: bind port 6482: Cannot assign requested address debug2: bind port 6483: Cannot assign requested address debug2: bind port 6484: Cannot assign requested address debug2: bind port 6485: Cannot assign requested address debug2: bind port 6486: Cannot assign requested address debug2: bind port 6487: Cannot assign requested address debug2: bind port 6488: Cannot assign requested address debug2: bind port 6489: Cannot assign requested address debug2: bind port 6490: Cannot assign requested address debug2: bind port 6491: Cannot assign requested address debug2: bind port 6492: Cannot assign requested address debug2: bind port 6493: Cannot assign requested address debug2: bind port 6494: Cannot assign requested address debug2: bind port 6495: Cannot assign requested address debug2: bind port 6496: Cannot assign requested address debug2: bind port 6497: Cannot assign requested address debug2: bind port 6498: Cannot assign requested address debug2: bind port 6499: Cannot assign requested address debug2: bind port 6500: Cannot assign requested address debug2: bind port 6501: Cannot assign requested address debug2: bind port 6502: Cannot assign requested address debug2: bind port 6503: Cannot assign requested address debug2: bind port 6504: Cannot assign requested address debug2: bind port 6505: Cannot assign requested address debug2: bind port 6506: Cannot assign requested address debug2: bind port 6507: Cannot assign requested address debug2: bind port 6508: Cannot assign requested address debug2: bind port 6509: Cannot assign requested address debug2: bind port 6510: Cannot assign requested address debug2: bind port 6511: Cannot assign requested address debug2: bind port 6512: Cannot assign requested address debug2: bind port 6513: Cannot assign requested address debug2: bind port 6514: Cannot assign requested address debug2: bind port 6515: Cannot assign requested address debug2: bind port 6516: Cannot assign requested address debug2: bind port 6517: Cannot assign requested address debug2: bind port 6518: Cannot assign requested address debug2: bind port 6519: Cannot assign requested address debug2: bind port 6520: Cannot assign requested address debug2: bind port 6521: Cannot assign requested address debug2: bind port 6522: Cannot assign requested address debug2: bind port 6523: Cannot assign requested address debug2: bind port 6524: Cannot assign requested address debug2: bind port 6525: Cannot assign requested address debug2: bind port 6526: Cannot assign requested address debug2: bind port 6527: Cannot assign requested address debug2: bind port 6528: Cannot assign requested address debug2: bind port 6529: Cannot assign requested address debug2: bind port 6530: Cannot assign requested address debug2: bind port 6531: Cannot assign requested address debug2: bind port 6532: Cannot assign requested address debug2: bind port 6533: Cannot assign requested address debug2: bind port 6534: Cannot assign requested address debug2: bind port 6535: Cannot assign requested address debug2: bind port 6536: Cannot assign requested address debug2: bind port 6537: Cannot assign requested address debug2: bind port 6538: Cannot assign requested address debug2: bind port 6539: Cannot assign requested address debug2: bind port 6540: Cannot assign requested address debug2: bind port 6541: Cannot assign requested address debug2: bind port 6542: Cannot assign requested address debug2: bind port 6543: Cannot assign requested address debug2: bind port 6544: Cannot assign requested address debug2: bind port 6545: Cannot assign requested address debug2: bind port 6546: Cannot assign requested address debug2: bind port 6547: Cannot assign requested address debug2: bind port 6548: Cannot assign requested address debug2: bind port 6549: Cannot assign requested address debug2: bind port 6550: Cannot assign requested address debug2: bind port 6551: Cannot assign requested address debug2: bind port 6552: Cannot assign requested address debug2: bind port 6553: Cannot assign requested address debug2: bind port 6554: Cannot assign requested address debug2: bind port 6555: Cannot assign requested address debug2: bind port 6556: Cannot assign requested address debug2: bind port 6557: Cannot assign requested address debug2: bind port 6558: Cannot assign requested address debug2: bind port 6559: Cannot assign requested address debug2: bind port 6560: Cannot assign requested address debug2: bind port 6561: Cannot assign requested address debug2: bind port 6562: Cannot assign requested address debug2: bind port 6563: Cannot assign requested address debug2: bind port 6564: Cannot assign requested address debug2: bind port 6565: Cannot assign requested address debug2: bind port 6566: Cannot assign requested address debug2: bind port 6567: Cannot assign requested address debug2: bind port 6568: Cannot assign requested address debug2: bind port 6569: Cannot assign requested address debug2: bind port 6570: Cannot assign requested address debug2: bind port 6571: Cannot assign requested address debug2: bind port 6572: Cannot assign requested address debug2: bind port 6573: Cannot assign requested address debug2: bind port 6574: Cannot assign requested address debug2: bind port 6575: Cannot assign requested address debug2: bind port 6576: Cannot assign requested address debug2: bind port 6577: Cannot assign requested address debug2: bind port 6578: Cannot assign requested address debug2: bind port 6579: Cannot assign requested address debug2: bind port 6580: Cannot assign requested address debug2: bind port 6581: Cannot assign requested address debug2: bind port 6582: Cannot assign requested address debug2: bind port 6583: Cannot assign requested address debug2: bind port 6584: Cannot assign requested address debug2: bind port 6585: Cannot assign requested address debug2: bind port 6586: Cannot assign requested address debug2: bind port 6587: Cannot assign requested address debug2: bind port 6588: Cannot assign requested address debug2: bind port 6589: Cannot assign requested address debug2: bind port 6590: Cannot assign requested address debug2: bind port 6591: Cannot assign requested address debug2: bind port 6592: Cannot assign requested address debug2: bind port 6593: Cannot assign requested address debug2: bind port 6594: Cannot assign requested address debug2: bind port 6595: Cannot assign requested address debug2: bind port 6596: Cannot assign requested address debug2: bind port 6597: Cannot assign requested address debug2: bind port 6598: Cannot assign requested address debug2: bind port 6599: Cannot assign requested address debug2: bind port 6600: Cannot assign requested address debug2: bind port 6601: Cannot assign requested address debug2: bind port 6602: Cannot assign requested address debug2: bind port 6603: Cannot assign requested address debug2: bind port 6604: Cannot assign requested address debug2: bind port 6605: Cannot assign requested address debug2: bind port 6606: Cannot assign requested address debug2: bind port 6607: Cannot assign requested address debug2: bind port 6608: Cannot assign requested address debug2: bind port 6609: Cannot assign requested address debug2: bind port 6610: Cannot assign requested address debug2: bind port 6611: Cannot assign requested address debug2: bind port 6612: Cannot assign requested address debug2: bind port 6613: Cannot assign requested address debug2: bind port 6614: Cannot assign requested address debug2: bind port 6615: Cannot assign requested address debug2: bind port 6616: Cannot assign requested address debug2: bind port 6617: Cannot assign requested address debug2: bind port 6618: Cannot assign requested address debug2: bind port 6619: Cannot assign requested address debug2: bind port 6620: Cannot assign requested address debug2: bind port 6621: Cannot assign requested address debug2: bind port 6622: Cannot assign requested address debug2: bind port 6623: Cannot assign requested address debug2: bind port 6624: Cannot assign requested address debug2: bind port 6625: Cannot assign requested address debug2: bind port 6626: Cannot assign requested address debug2: bind port 6627: Cannot assign requested address debug2: bind port 6628: Cannot assign requested address debug2: bind port 6629: Cannot assign requested address debug2: bind port 6630: Cannot assign requested address debug2: bind port 6631: Cannot assign requested address debug2: bind port 6632: Cannot assign requested address debug2: bind port 6633: Cannot assign requested address debug2: bind port 6634: Cannot assign requested address debug2: bind port 6635: Cannot assign requested address debug2: bind port 6636: Cannot assign requested address debug2: bind port 6637: Cannot assign requested address debug2: bind port 6638: Cannot assign requested address debug2: bind port 6639: Cannot assign requested address debug2: bind port 6640: Cannot assign requested address debug2: bind port 6641: Cannot assign requested address debug2: bind port 6642: Cannot assign requested address debug2: bind port 6643: Cannot assign requested address debug2: bind port 6644: Cannot assign requested address debug2: bind port 6645: Cannot assign requested address debug2: bind port 6646: Cannot assign requested address debug2: bind port 6647: Cannot assign requested address debug2: bind port 6648: Cannot assign requested address debug2: bind port 6649: Cannot assign requested address debug2: bind port 6650: Cannot assign requested address debug2: bind port 6651: Cannot assign requested address debug2: bind port 6652: Cannot assign requested address debug2: bind port 6653: Cannot assign requested address debug2: bind port 6654: Cannot assign requested address debug2: bind port 6655: Cannot assign requested address debug2: bind port 6656: Cannot assign requested address debug2: bind port 6657: Cannot assign requested address debug2: bind port 6658: Cannot assign requested address debug2: bind port 6659: Cannot assign requested address debug2: bind port 6660: Cannot assign requested address debug2: bind port 6661: Cannot assign requested address debug2: bind port 6662: Cannot assign requested address debug2: bind port 6663: Cannot assign requested address debug2: bind port 6664: Cannot assign requested address debug2: bind port 6665: Cannot assign requested address debug2: bind port 6666: Cannot assign requested address debug2: bind port 6667: Cannot assign requested address debug2: bind port 6668: Cannot assign requested address debug2: bind port 6669: Cannot assign requested address debug2: bind port 6670: Cannot assign requested address debug2: bind port 6671: Cannot assign requested address debug2: bind port 6672: Cannot assign requested address debug2: bind port 6673: Cannot assign requested address debug2: bind port 6674: Cannot assign requested address debug2: bind port 6675: Cannot assign requested address debug2: bind port 6676: Cannot assign requested address debug2: bind port 6677: Cannot assign requested address debug2: bind port 6678: Cannot assign requested address debug2: bind port 6679: Cannot assign requested address debug2: bind port 6680: Cannot assign requested address debug2: bind port 6681: Cannot assign requested address debug2: bind port 6682: Cannot assign requested address debug2: bind port 6683: Cannot assign requested address debug2: bind port 6684: Cannot assign requested address debug2: bind port 6685: Cannot assign requested address debug2: bind port 6686: Cannot assign requested address debug2: bind port 6687: Cannot assign requested address debug2: bind port 6688: Cannot assign requested address debug2: bind port 6689: Cannot assign requested address debug2: bind port 6690: Cannot assign requested address debug2: bind port 6691: Cannot assign requested address debug2: bind port 6692: Cannot assign requested address debug2: bind port 6693: Cannot assign requested address debug2: bind port 6694: Cannot assign requested address debug2: bind port 6695: Cannot assign requested address debug2: bind port 6696: Cannot assign requested address debug2: bind port 6697: Cannot assign requested address debug2: bind port 6698: Cannot assign requested address debug2: bind port 6699: Cannot assign requested address debug2: bind port 6700: Cannot assign requested address debug2: bind port 6701: Cannot assign requested address debug2: bind port 6702: Cannot assign requested address debug2: bind port 6703: Cannot assign requested address debug2: bind port 6704: Cannot assign requested address debug2: bind port 6705: Cannot assign requested address debug2: bind port 6706: Cannot assign requested address debug2: bind port 6707: Cannot assign requested address debug2: bind port 6708: Cannot assign requested address debug2: bind port 6709: Cannot assign requested address debug2: bind port 6710: Cannot assign requested address debug2: bind port 6711: Cannot assign requested address debug2: bind port 6712: Cannot assign requested address debug2: bind port 6713: Cannot assign requested address debug2: bind port 6714: Cannot assign requested address debug2: bind port 6715: Cannot assign requested address debug2: bind port 6716: Cannot assign requested address debug2: bind port 6717: Cannot assign requested address debug2: bind port 6718: Cannot assign requested address debug2: bind port 6719: Cannot assign requested address debug2: bind port 6720: Cannot assign requested address debug2: bind port 6721: Cannot assign requested address debug2: bind port 6722: Cannot assign requested address debug2: bind port 6723: Cannot assign requested address debug2: bind port 6724: Cannot assign requested address debug2: bind port 6725: Cannot assign requested address debug2: bind port 6726: Cannot assign requested address debug2: bind port 6727: Cannot assign requested address debug2: bind port 6728: Cannot assign requested address debug2: bind port 6729: Cannot assign requested address debug2: bind port 6730: Cannot assign requested address debug2: bind port 6731: Cannot assign requested address debug2: bind port 6732: Cannot assign requested address debug2: bind port 6733: Cannot assign requested address debug2: bind port 6734: Cannot assign requested address debug2: bind port 6735: Cannot assign requested address debug2: bind port 6736: Cannot assign requested address debug2: bind port 6737: Cannot assign requested address debug2: bind port 6738: Cannot assign requested address debug2: bind port 6739: Cannot assign requested address debug2: bind port 6740: Cannot assign requested address debug2: bind port 6741: Cannot assign requested address debug2: bind port 6742: Cannot assign requested address debug2: bind port 6743: Cannot assign requested address debug2: bind port 6744: Cannot assign requested address debug2: bind port 6745: Cannot assign requested address debug2: bind port 6746: Cannot assign requested address debug2: bind port 6747: Cannot assign requested address debug2: bind port 6748: Cannot assign requested address debug2: bind port 6749: Cannot assign requested address debug2: bind port 6750: Cannot assign requested address debug2: bind port 6751: Cannot assign requested address debug2: bind port 6752: Cannot assign requested address debug2: bind port 6753: Cannot assign requested address debug2: bind port 6754: Cannot assign requested address debug2: bind port 6755: Cannot assign requested address debug2: bind port 6756: Cannot assign requested address debug2: bind port 6757: Cannot assign requested address debug2: bind port 6758: Cannot assign requested address debug2: bind port 6759: Cannot assign requested address debug2: bind port 6760: Cannot assign requested address debug2: bind port 6761: Cannot assign requested address debug2: bind port 6762: Cannot assign requested address debug2: bind port 6763: Cannot assign requested address debug2: bind port 6764: Cannot assign requested address debug2: bind port 6765: Cannot assign requested address debug2: bind port 6766: Cannot assign requested address debug2: bind port 6767: Cannot assign requested address debug2: bind port 6768: Cannot assign requested address debug2: bind port 6769: Cannot assign requested address debug2: bind port 6770: Cannot assign requested address debug2: bind port 6771: Cannot assign requested address debug2: bind port 6772: Cannot assign requested address debug2: bind port 6773: Cannot assign requested address debug2: bind port 6774: Cannot assign requested address debug2: bind port 6775: Cannot assign requested address debug2: bind port 6776: Cannot assign requested address debug2: bind port 6777: Cannot assign requested address debug2: bind port 6778: Cannot assign requested address debug2: bind port 6779: Cannot assign requested address debug2: bind port 6780: Cannot assign requested address debug2: bind port 6781: Cannot assign requested address debug2: bind port 6782: Cannot assign requested address debug2: bind port 6783: Cannot assign requested address debug2: bind port 6784: Cannot assign requested address debug2: bind port 6785: Cannot assign requested address debug2: bind port 6786: Cannot assign requested address debug2: bind port 6787: Cannot assign requested address debug2: bind port 6788: Cannot assign requested address debug2: bind port 6789: Cannot assign requested address debug2: bind port 6790: Cannot assign requested address debug2: bind port 6791: Cannot assign requested address debug2: bind port 6792: Cannot assign requested address debug2: bind port 6793: Cannot assign requested address debug2: bind port 6794: Cannot assign requested address debug2: bind port 6795: Cannot assign requested address debug2: bind port 6796: Cannot assign requested address debug2: bind port 6797: Cannot assign requested address debug2: bind port 6798: Cannot assign requested address debug2: bind port 6799: Cannot assign requested address debug2: bind port 6800: Cannot assign requested address debug2: bind port 6801: Cannot assign requested address debug2: bind port 6802: Cannot assign requested address debug2: bind port 6803: Cannot assign requested address debug2: bind port 6804: Cannot assign requested address debug2: bind port 6805: Cannot assign requested address debug2: bind port 6806: Cannot assign requested address debug2: bind port 6807: Cannot assign requested address debug2: bind port 6808: Cannot assign requested address debug2: bind port 6809: Cannot assign requested address debug2: bind port 6810: Cannot assign requested address debug2: bind port 6811: Cannot assign requested address debug2: bind port 6812: Cannot assign requested address debug2: bind port 6813: Cannot assign requested address debug2: bind port 6814: Cannot assign requested address debug2: bind port 6815: Cannot assign requested address debug2: bind port 6816: Cannot assign requested address debug2: bind port 6817: Cannot assign requested address debug2: bind port 6818: Cannot assign requested address debug2: bind port 6819: Cannot assign requested address debug2: bind port 6820: Cannot assign requested address debug2: bind port 6821: Cannot assign requested address debug2: bind port 6822: Cannot assign requested address debug2: bind port 6823: Cannot assign requested address debug2: bind port 6824: Cannot assign requested address debug2: bind port 6825: Cannot assign requested address debug2: bind port 6826: Cannot assign requested address debug2: bind port 6827: Cannot assign requested address debug2: bind port 6828: Cannot assign requested address debug2: bind port 6829: Cannot assign requested address debug2: bind port 6830: Cannot assign requested address debug2: bind port 6831: Cannot assign requested address debug2: bind port 6832: Cannot assign requested address debug2: bind port 6833: Cannot assign requested address debug2: bind port 6834: Cannot assign requested address debug2: bind port 6835: Cannot assign requested address debug2: bind port 6836: Cannot assign requested address debug2: bind port 6837: Cannot assign requested address debug2: bind port 6838: Cannot assign requested address debug2: bind port 6839: Cannot assign requested address debug2: bind port 6840: Cannot assign requested address debug2: bind port 6841: Cannot assign requested address debug2: bind port 6842: Cannot assign requested address debug2: bind port 6843: Cannot assign requested address debug2: bind port 6844: Cannot assign requested address debug2: bind port 6845: Cannot assign requested address debug2: bind port 6846: Cannot assign requested address debug2: bind port 6847: Cannot assign requested address debug2: bind port 6848: Cannot assign requested address debug2: bind port 6849: Cannot assign requested address debug2: bind port 6850: Cannot assign requested address debug2: bind port 6851: Cannot assign requested address debug2: bind port 6852: Cannot assign requested address debug2: bind port 6853: Cannot assign requested address debug2: bind port 6854: Cannot assign requested address debug2: bind port 6855: Cannot assign requested address debug2: bind port 6856: Cannot assign requested address debug2: bind port 6857: Cannot assign requested address debug2: bind port 6858: Cannot assign requested address debug2: bind port 6859: Cannot assign requested address debug2: bind port 6860: Cannot assign requested address debug2: bind port 6861: Cannot assign requested address debug2: bind port 6862: Cannot assign requested address debug2: bind port 6863: Cannot assign requested address debug2: bind port 6864: Cannot assign requested address debug2: bind port 6865: Cannot assign requested address debug2: bind port 6866: Cannot assign requested address debug2: bind port 6867: Cannot assign requested address debug2: bind port 6868: Cannot assign requested address debug2: bind port 6869: Cannot assign requested address debug2: bind port 6870: Cannot assign requested address debug2: bind port 6871: Cannot assign requested address debug2: bind port 6872: Cannot assign requested address debug2: bind port 6873: Cannot assign requested address debug2: bind port 6874: Cannot assign requested address debug2: bind port 6875: Cannot assign requested address debug2: bind port 6876: Cannot assign requested address debug2: bind port 6877: Cannot assign requested address debug2: bind port 6878: Cannot assign requested address debug2: bind port 6879: Cannot assign requested address debug2: bind port 6880: Cannot assign requested address debug2: bind port 6881: Cannot assign requested address debug2: bind port 6882: Cannot assign requested address debug2: bind port 6883: Cannot assign requested address debug2: bind port 6884: Cannot assign requested address debug2: bind port 6885: Cannot assign requested address debug2: bind port 6886: Cannot assign requested address debug2: bind port 6887: Cannot assign requested address debug2: bind port 6888: Cannot assign requested address debug2: bind port 6889: Cannot assign requested address debug2: bind port 6890: Cannot assign requested address debug2: bind port 6891: Cannot assign requested address debug2: bind port 6892: Cannot assign requested address debug2: bind port 6893: Cannot assign requested address debug2: bind port 6894: Cannot assign requested address debug2: bind port 6895: Cannot assign requested address debug2: bind port 6896: Cannot assign requested address debug2: bind port 6897: Cannot assign requested address debug2: bind port 6898: Cannot assign requested address debug2: bind port 6899: Cannot assign requested address debug2: bind port 6900: Cannot assign requested address debug2: bind port 6901: Cannot assign requested address debug2: bind port 6902: Cannot assign requested address debug2: bind port 6903: Cannot assign requested address debug2: bind port 6904: Cannot assign requested address debug2: bind port 6905: Cannot assign requested address debug2: bind port 6906: Cannot assign requested address debug2: bind port 6907: Cannot assign requested address debug2: bind port 6908: Cannot assign requested address debug2: bind port 6909: Cannot assign requested address debug2: bind port 6910: Cannot assign requested address debug2: bind port 6911: Cannot assign requested address debug2: bind port 6912: Cannot assign requested address debug2: bind port 6913: Cannot assign requested address debug2: bind port 6914: Cannot assign requested address debug2: bind port 6915: Cannot assign requested address debug2: bind port 6916: Cannot assign requested address debug2: bind port 6917: Cannot assign requested address debug2: bind port 6918: Cannot assign requested address debug2: bind port 6919: Cannot assign requested address debug2: bind port 6920: Cannot assign requested address debug2: bind port 6921: Cannot assign requested address debug2: bind port 6922: Cannot assign requested address debug2: bind port 6923: Cannot assign requested address debug2: bind port 6924: Cannot assign requested address debug2: bind port 6925: Cannot assign requested address debug2: bind port 6926: Cannot assign requested address debug2: bind port 6927: Cannot assign requested address debug2: bind port 6928: Cannot assign requested address debug2: bind port 6929: Cannot assign requested address debug2: bind port 6930: Cannot assign requested address debug2: bind port 6931: Cannot assign requested address debug2: bind port 6932: Cannot assign requested address debug2: bind port 6933: Cannot assign requested address debug2: bind port 6934: Cannot assign requested address debug2: bind port 6935: Cannot assign requested address debug2: bind port 6936: Cannot assign requested address debug2: bind port 6937: Cannot assign requested address debug2: bind port 6938: Cannot assign requested address debug2: bind port 6939: Cannot assign requested address debug2: bind port 6940: Cannot assign requested address debug2: bind port 6941: Cannot assign requested address debug2: bind port 6942: Cannot assign requested address debug2: bind port 6943: Cannot assign requested address debug2: bind port 6944: Cannot assign requested address debug2: bind port 6945: Cannot assign requested address debug2: bind port 6946: Cannot assign requested address debug2: bind port 6947: Cannot assign requested address debug2: bind port 6948: Cannot assign requested address debug2: bind port 6949: Cannot assign requested address debug2: bind port 6950: Cannot assign requested address debug2: bind port 6951: Cannot assign requested address debug2: bind port 6952: Cannot assign requested address debug2: bind port 6953: Cannot assign requested address debug2: bind port 6954: Cannot assign requested address debug2: bind port 6955: Cannot assign requested address debug2: bind port 6956: Cannot assign requested address debug2: bind port 6957: Cannot assign requested address debug2: bind port 6958: Cannot assign requested address debug2: bind port 6959: Cannot assign requested address debug2: bind port 6960: Cannot assign requested address debug2: bind port 6961: Cannot assign requested address debug2: bind port 6962: Cannot assign requested address debug2: bind port 6963: Cannot assign requested address debug2: bind port 6964: Cannot assign requested address debug2: bind port 6965: Cannot assign requested address debug2: bind port 6966: Cannot assign requested address debug2: bind port 6967: Cannot assign requested address debug2: bind port 6968: Cannot assign requested address debug2: bind port 6969: Cannot assign requested address debug2: bind port 6970: Cannot assign requested address debug2: bind port 6971: Cannot assign requested address debug2: bind port 6972: Cannot assign requested address debug2: bind port 6973: Cannot assign requested address debug2: bind port 6974: Cannot assign requested address debug2: bind port 6975: Cannot assign requested address debug2: bind port 6976: Cannot assign requested address debug2: bind port 6977: Cannot assign requested address debug2: bind port 6978: Cannot assign requested address debug2: bind port 6979: Cannot assign requested address debug2: bind port 6980: Cannot assign requested address debug2: bind port 6981: Cannot assign requested address debug2: bind port 6982: Cannot assign requested address debug2: bind port 6983: Cannot assign requested address debug2: bind port 6984: Cannot assign requested address debug2: bind port 6985: Cannot assign requested address debug2: bind port 6986: Cannot assign requested address debug2: bind port 6987: Cannot assign requested address debug2: bind port 6988: Cannot assign requested address debug2: bind port 6989: Cannot assign requested address debug2: bind port 6990: Cannot assign requested address debug2: bind port 6991: Cannot assign requested address debug2: bind port 6992: Cannot assign requested address debug2: bind port 6993: Cannot assign requested address debug2: bind port 6994: Cannot assign requested address debug2: bind port 6995: Cannot assign requested address debug2: bind port 6996: 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. debug1: server_input_channel_req: channel 0 request pty-req reply 1 debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 req pty-req debug1: Allocating pty. debug3: mm_request_send entering: type 25 debug3: mm_pty_allocate: waiting for MONITOR_ANS_PTY debug3: mm_request_receive_expect entering: type 26 debug3: mm_request_receive entering debug3: monitor_read: checking request 25 debug3: mm_answer_pty entering debug2: session_new: allocate (allocated 0 max 10) debug3: session_unused: session id 0 unused debug1: session_new: session 0 debug3: mm_request_send entering: type 26 debug3: mm_answer_pty: tty /dev/pts/20 ptyfd 6 debug1: session_pty_req: session 0 alloc /dev/pts/20 debug3: mm_request_receive entering debug3: tty_parse_modes: SSH2 n_bytes 246 debug3: tty_parse_modes: ospeed 38400 debug3: tty_parse_modes: ispeed 38400 debug1: server_input_channel_req: channel 0 request shell reply 1 debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 req shell debug2: fd 4 setting TCP_NODELAY debug2: channel 0: rfd 11 isatty debug2: fd 11 setting O_NONBLOCK debug3: fd 9 is O_NONBLOCK debug2: channel 0: read<=0 rfd 11 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 debug1: Received SIGCHLD. debug1: session_by_pid: pid 29877 debug1: session_exit_message: session 0 channel 0 pid 29877 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: send eow debug2: channel 0: output open -> closed debug3: mm_request_send entering: type 27 debug2: channel 0: send close debug3: monitor_read: checking request 27 debug3: channel 0: will not send data after close debug3: mm_answer_pty_cleanup entering debug2: notify_done: reading debug1: session_by_tty: session 0 tty /dev/pts/20 debug3: mm_session_close: session 0 pid 29873 debug3: mm_session_close: tty /dev/pts/20 ptyfd 6 debug3: channel 0: will not send data after close debug1: session_pty_cleanup: session 0 release /dev/pts/20 debug3: session_unused: session id 0 unused debug3: mm_request_receive entering 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 debug3: session_unused: session id 0 unused 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 AA.BB.6.43 debug1: do_cleanup debug3: PAM: sshpam_thread_cleanup entering Transferred: sent 6120, received 1904 bytes Closing connection to AA.BB.6.43 port 1040 debug3: mm_request_send entering: type 58 debug3: monitor_read: checking request 58 debug3: mm_answer_term: tearing down sessions debug1: PAM: cleanup debug1: PAM: deleting credentials debug1: PAM: closing session Damien Miller wrote: > On Wed, 4 Feb 2009, Jeff Blaine wrote: > >> debug1: server_input_channel_req: channel 0 request x11-req reply 0 >> debug1: session_by_channel: session 0 channel 0 >> debug1: session_input_channel_req: session 0 req x11-req >> Failed to allocate internet-domain X11 display socket. >> debug1: x11_create_display_inet failed. > > Here is the problem, but I can't tell what caused it. You should > send a full debug trace "sshd -ddd" > > -d > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From jblaine at kickflop.net Thu Feb 5 09:05:26 2009 From: jblaine at kickflop.net (Jeff Blaine) Date: Wed, 04 Feb 2009 17:05:26 -0500 Subject: 5.1p1 and X11 forwarding failing In-Reply-To: <498A1054.4090700@kickflop.net> References: <4989C8C7.5090607@kickflop.net> <498A0CC1.2040202@kickflop.net> <498A1054.4090700@kickflop.net> Message-ID: <498A1126.9000401@kickflop.net> I should also point out that this worked fine with 4.4p1 which we upgraded from (to 5.1p1) From mouring at eviladmin.org Thu Feb 5 09:15:52 2009 From: mouring at eviladmin.org (Ben Lindstrom) Date: Wed, 4 Feb 2009 16:15:52 -0600 Subject: 5.1p1 and X11 forwarding failing In-Reply-To: <498A1054.4090700@kickflop.net> References: <4989C8C7.5090607@kickflop.net> <498A0CC1.2040202@kickflop.net> <498A1054.4090700@kickflop.net> Message-ID: <1FBC3F63-B60D-4B13-88C7-E043368829CF@eviladmin.org> On Feb 4, 2009, at 4:01 PM, Jeff Blaine wrote: [..] > debug1: server_input_channel_req: channel 0 request x11-req reply 0 > 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 6013: 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. This would imply to me an application firewall is running on your windows box denying the port binding. - Ben From jblaine at kickflop.net Thu Feb 5 09:28:49 2009 From: jblaine at kickflop.net (Jeff Blaine) Date: Wed, 04 Feb 2009 17:28:49 -0500 Subject: 5.1p1 and X11 forwarding failing In-Reply-To: <1FBC3F63-B60D-4B13-88C7-E043368829CF@eviladmin.org> References: <4989C8C7.5090607@kickflop.net> <498A0CC1.2040202@kickflop.net> <498A1054.4090700@kickflop.net> <1FBC3F63-B60D-4B13-88C7-E043368829CF@eviladmin.org> Message-ID: <498A16A1.4090903@kickflop.net> "X11UseLocalhost no" just solved the problem. I noticed our 4.4p1 install used that (just now). Now to go off and figure out why. Xwin.exe (Cygwin) has full permission to accept connections from trusted and untrusted sources. Ben Lindstrom wrote: > On Feb 4, 2009, at 4:01 PM, Jeff Blaine wrote: > [..] > >> debug1: server_input_channel_req: channel 0 request x11-req reply 0 >> 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 6013: 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. > > This would imply to me an application firewall is running on your > windows box denying the port binding. > > - Ben > _______________________________________________ > 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 Thu Feb 5 09:49:55 2009 From: djm at mindrot.org (Damien Miller) Date: Thu, 5 Feb 2009 09:49:55 +1100 (EST) Subject: 5.1p1 and X11 forwarding failing In-Reply-To: <498A1054.4090700@kickflop.net> References: <4989C8C7.5090607@kickflop.net> <498A0CC1.2040202@kickflop.net> <498A1054.4090700@kickflop.net> Message-ID: On Wed, 4 Feb 2009, Jeff Blaine wrote: > 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 6013: Cannot assign requested address > debug2: bind port 6014: Cannot assign requested address > debug2: bind port 6015: Cannot assign requested address > [ and so forth... ] You must be on one of those broken platforms whose getaddrinfo() returns instructions to listen on both IPv4 and IPv6 addresses but refuses to allow us to actually bind() to one of these addresses, usually IPv6. We don't have any good solution for this at the moment that doesn't reintroduce CVE-2008-1483*, but if you are not using IPv6 then you can workaround the problem by telling OpenSSH not to try to use it by adding "AddressFamily INET" to your sshd_config. I'd also suggest bugging your system vendor - getaddrinfo() with hints->ai_flags containing AI_PASSIVE should return a *usable* list of addresses to bind. OpenSSH's breakage here is caused by the system returning addresses that cannot be bound. -d * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1483 From peter at stuge.se Thu Feb 5 10:33:09 2009 From: peter at stuge.se (Peter Stuge) Date: Thu, 5 Feb 2009 00:33:09 +0100 Subject: SSH PAM authentication/login with a new user DB (through NSS) In-Reply-To: <4989B53A.2030400@siemens.com> References: <4988E848.2010006@gmail.com> <4989B53A.2030400@siemens.com> Message-ID: <20090204233309.16474.qmail@stuge.se> Christian Pfaffel-Janser wrote: > > Any of your expert comments would be greatly appreciated. > > just a wild guess, does it work if You turn PriviledgeSeparation off. Yes, disabling PrivilegeSeparation (speling) might help for debugging but it's not a recommended general solution. Darren Tucker has written a PAM test harness that you could try with your PAM module to maybe get more information on what is going wrong. I found http://dtucker.freeshell.org/patches/pam-test-harness.c but am unsure if it is the very latest version. Darren? //Peter From deengert at anl.gov Thu Feb 5 09:35:55 2009 From: deengert at anl.gov (Douglas E. Engert) Date: Wed, 04 Feb 2009 16:35:55 -0600 Subject: 5.1p1 and X11 forwarding failing In-Reply-To: <498A1126.9000401@kickflop.net> References: <4989C8C7.5090607@kickflop.net> <498A0CC1.2040202@kickflop.net> <498A1054.4090700@kickflop.net> <498A1126.9000401@kickflop.net> Message-ID: <498A184B.8090904@anl.gov> Jeff Blaine wrote: > I should also point out that this worked fine > with 4.4p1 which we upgraded from (to 5.1p1) This sounds similar to a problem with IPv6 and X11 ports that we have seen on Solaris 10 when IPv6 was not fully configured for the local machine, i.e. at least a loopback. Try ListenAddress 0.0.0.0 to force IPv4 only or try adding to /etc/hosts: ::1 localhost > _______________________________________________ > 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 jblaine at kickflop.net Thu Feb 5 22:14:38 2009 From: jblaine at kickflop.net (Jeff Blaine) Date: Thu, 05 Feb 2009 06:14:38 -0500 Subject: 5.1p1 and X11 forwarding failing In-Reply-To: <498A184B.8090904@anl.gov> References: <4989C8C7.5090607@kickflop.net> <498A0CC1.2040202@kickflop.net> <498A1054.4090700@kickflop.net> <498A1126.9000401@kickflop.net> <498A184B.8090904@anl.gov> Message-ID: <498ACA1E.2030608@kickflop.net> Thanks for the feedback everyone -- more below. Douglas E. Engert wrote: > > Jeff Blaine wrote: >> I should also point out that this worked fine >> with 4.4p1 which we upgraded from (to 5.1p1) > > This sounds similar to a problem with IPv6 > and X11 ports that we have seen on Solaris 10 > when IPv6 was not fully configured for the local > machine, i.e. at least a loopback. > > Try ListenAddress 0.0.0.0 to force IPv4 only or > try adding to /etc/hosts: > ::1 localhost The following works: > X11UseLocalhost no OR the following: > AddressFamily inet # force IPv4 > X11UseLocalhost yes So I think your assessment is correct. ( ListenAddress 0.0.0.0 is the default and was already in the sshd_config ) From jblaine at kickflop.net Fri Feb 6 08:29:24 2009 From: jblaine at kickflop.net (Jeff Blaine) Date: Thu, 05 Feb 2009 16:29:24 -0500 Subject: Coding help : Where to log X11 forwards? Message-ID: <498B5A34.9050403@kickflop.net> OpenSSH 5.1p1 I can't grasp why, when connecting with 'ssh -Y' to this test host, I am not tickling the verbose() call below that I have added. I am logging as auth + verbose in sshd_config The X11 forward for the session works fine as tested with xterm. At any rate, I am looking for some guidance on where to log X11 forwards that are established, ideally with a username and remote display information, but whatever I can get, I'll take. Any help would be great. session.c: packet_check_eom(); success = session_setup_x11fwd(s); if (!success) { xfree(s->auth_proto); xfree(s->auth_data); s->auth_proto = NULL; s->auth_data = NULL; } else { verbose("jblaine testing : w00t? : %s", s->auth_display); } From dopheide at ncsa.uiuc.edu Fri Feb 6 08:36:39 2009 From: dopheide at ncsa.uiuc.edu (Dop) Date: Thu, 5 Feb 2009 15:36:39 -0600 (CST) Subject: Problem with Kerberos auth on AIX 5.3 In-Reply-To: <1152366779.45441233869771842.JavaMail.root@zimbra-1.ncsa.uiuc.edu> Message-ID: <995017124.45461233869799156.JavaMail.root@zimbra-1.ncsa.uiuc.edu> I've been banging my head against this for a few days so I thought I'd see if anyone has an idea of what's going on. AIX 5.3 OpenSSH 5.1p1 MIT Kerberos 1.6.3 zlib 1.2.3 Built with CC=cc and LDFLAGS=-brtl When the client attempts to enter their kerberos password the daemon rejects it with the following message: debug1: Kerberos password authentication failed: Not enough space. If you try again the message changes to: debug1: Kerberos password authentication failed: There is not enough memory available now. I tracked that down to auth-krb5.c and a call to krb5_sname_to_principal(). If you comment out that call kerberos password authentication works just fine. Unfortunately, that's not a good long term solution. It smells like some crazy AIX memory allocation problem to me. The ulimit settings appear fine and that's about the limit of my AIX knowledge. Any thoughts? Thanks, Mike From dopheide at ncsa.uiuc.edu Fri Feb 6 08:57:15 2009 From: dopheide at ncsa.uiuc.edu (Dop) Date: Thu, 5 Feb 2009 15:57:15 -0600 (CST) Subject: Problem with Kerberos auth on AIX 5.3 In-Reply-To: <1529418725.48111233870839433.JavaMail.root@zimbra-1.ncsa.uiuc.edu> Message-ID: <922225714.48151233871035619.JavaMail.root@zimbra-1.ncsa.uiuc.edu> Kyle, Thanks for the reply. I'll try building against the IBM supplied MIT stuff, I didn't know that was available. OpenSSH binaries won't work for us, once I get the base code working as expected we'll be adding in some patches. -Mike ----- "Kyle Chapman" wrote: > Have you tried the binary stuff off: > http://sourceforge.net/project/showfiles.php?group_id=127997 > > Its not the latest, however it works (krb5 support as well). Have > you > also tried to build while using the ibm supplied MIT distro (its on > the > aix expansion kit cd)? > > -----Original Message----- > From: openssh-unix-dev-bounces+kyle_chapman=g1.com at mindrot.org > [mailto:openssh-unix-dev-bounces+kyle_chapman=g1.com at mindrot.org] On > Behalf Of Dop > Sent: Thursday, February 05, 2009 4:37 PM > To: openssh-unix-dev at mindrot.org > Subject: Problem with Kerberos auth on AIX 5.3 > > > I've been banging my head against this for a few days so I thought > I'd > see if anyone has an idea of what's going on. > > AIX 5.3 > OpenSSH 5.1p1 > MIT Kerberos 1.6.3 > zlib 1.2.3 > > Built with CC=cc and LDFLAGS=-brtl > > When the client attempts to enter their kerberos password the daemon > rejects it with the following message: > debug1: Kerberos password authentication failed: Not enough space. > > If you try again the message changes to: > debug1: Kerberos password authentication failed: There is not enough > memory available now. > > I tracked that down to auth-krb5.c and a call to > krb5_sname_to_principal(). If you comment out that call kerberos > password authentication works just fine. Unfortunately, that's not a > good long term solution. It smells like some crazy AIX memory > allocation problem to me. The ulimit settings appear fine and that's > about the limit of my AIX knowledge. > > Any thoughts? > > Thanks, > Mike > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > > NOTICE: This E-mail may contain confidential information. If you are > not > the addressee or the intended recipient please do not read this > E-mail > and please immediately delete this e-mail message and any attachments > from your workstation or network mail system. If you are the > addressee > or the intended recipient and you save or print a copy of this > E-mail, > please place it in an appropriate file, depending on whether > confidential information is contained in the message. From Kyle_Chapman at G1.com Fri Feb 6 08:49:53 2009 From: Kyle_Chapman at G1.com (Chapman, Kyle) Date: Thu, 5 Feb 2009 16:49:53 -0500 Subject: Problem with Kerberos auth on AIX 5.3 In-Reply-To: <995017124.45461233869799156.JavaMail.root@zimbra-1.ncsa.uiuc.edu> References: <1152366779.45441233869771842.JavaMail.root@zimbra-1.ncsa.uiuc.edu> <995017124.45461233869799156.JavaMail.root@zimbra-1.ncsa.uiuc.edu> Message-ID: Have you tried the binary stuff off: http://sourceforge.net/project/showfiles.php?group_id=127997 Its not the latest, however it works (krb5 support as well). Have you also tried to build while using the ibm supplied MIT distro (its on the aix expansion kit cd)? -----Original Message----- From: openssh-unix-dev-bounces+kyle_chapman=g1.com at mindrot.org [mailto:openssh-unix-dev-bounces+kyle_chapman=g1.com at mindrot.org] On Behalf Of Dop Sent: Thursday, February 05, 2009 4:37 PM To: openssh-unix-dev at mindrot.org Subject: Problem with Kerberos auth on AIX 5.3 I've been banging my head against this for a few days so I thought I'd see if anyone has an idea of what's going on. AIX 5.3 OpenSSH 5.1p1 MIT Kerberos 1.6.3 zlib 1.2.3 Built with CC=cc and LDFLAGS=-brtl When the client attempts to enter their kerberos password the daemon rejects it with the following message: debug1: Kerberos password authentication failed: Not enough space. If you try again the message changes to: debug1: Kerberos password authentication failed: There is not enough memory available now. I tracked that down to auth-krb5.c and a call to krb5_sname_to_principal(). If you comment out that call kerberos password authentication works just fine. Unfortunately, that's not a good long term solution. It smells like some crazy AIX memory allocation problem to me. The ulimit settings appear fine and that's about the limit of my AIX knowledge. Any thoughts? Thanks, Mike _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev NOTICE: This E-mail may contain confidential information. If you are not the addressee or the intended recipient please do not read this E-mail and please immediately delete this e-mail message and any attachments from your workstation or network mail system. If you are the addressee or the intended recipient and you save or print a copy of this E-mail, please place it in an appropriate file, depending on whether confidential information is contained in the message. From djm at mindrot.org Fri Feb 6 10:26:59 2009 From: djm at mindrot.org (Damien Miller) Date: Fri, 6 Feb 2009 10:26:59 +1100 (EST) Subject: Coding help : Where to log X11 forwards? In-Reply-To: <498B5A34.9050403@kickflop.net> References: <498B5A34.9050403@kickflop.net> Message-ID: On Thu, 5 Feb 2009, Jeff Blaine wrote: > OpenSSH 5.1p1 > > I can't grasp why, when connecting with 'ssh -Y' to this > test host, I am not tickling the verbose() call below that > I have added. I'm not sure why the verbose isn't triggering here, but: > At any rate, I am looking for some guidance on where > to log X11 forwards that are established, ideally with > a username and remote display information, but whatever > I can get, I'll take. You can achieve most of this by specifying a custom xauth program using sshd_config:XAuthLocation. It could be just a shell script that logs the parameters and the current user - no modifications to ssh necessary. -d From djm at mindrot.org Fri Feb 6 11:45:59 2009 From: djm at mindrot.org (Damien Miller) Date: Fri, 6 Feb 2009 11:45:59 +1100 (EST) Subject: Coding help : Where to log X11 forwards? In-Reply-To: References: <498B5A34.9050403@kickflop.net> Message-ID: On Fri, 6 Feb 2009, Damien Miller wrote: > > At any rate, I am looking for some guidance on where > > to log X11 forwards that are established, ideally with > > a username and remote display information, but whatever > > I can get, I'll take. > > You can achieve most of this by specifying a custom xauth program > using sshd_config:XAuthLocation. It could be just a shell script > that logs the parameters and the current user ^^^^^ ... and then calls the real system xauth binary. -d From hosungs at gmail.com Fri Feb 6 11:55:53 2009 From: hosungs at gmail.com (Hosung Song) Date: Thu, 05 Feb 2009 18:55:53 -0600 Subject: SSH PAM authentication/login with a new user DB (through NSS) In-Reply-To: <20090204233309.16474.qmail@stuge.se> References: <4988E848.2010006@gmail.com> <4989B53A.2030400@siemens.com> <20090204233309.16474.qmail@stuge.se> Message-ID: <498B8A99.5070609@gmail.com> Thanks much for both of your suggestions. Tried PrivilegeSeparation off, but it didn't work. I see there are now less child processes (just [pam], without [net] and [priv]). I also noticed that it's the same process which did "Accepted keyboard-interactive/pam for hosungs at gmail.com" and "fatal: login_init_entry: Cannot find user "" ". If it's the same process, I'm not sure why the username info is lost somewhere... Also tried pam-test-harness.c and it returned all Success when I tried the ssh service with my PAM module and my email username. Any more suggestions? Thanks, Hosung Peter Stuge wrote: > Christian Pfaffel-Janser wrote: >>> Any of your expert comments would be greatly appreciated. >> just a wild guess, does it work if You turn PriviledgeSeparation off. > > Yes, disabling PrivilegeSeparation (speling) might help for debugging > but it's not a recommended general solution. > > Darren Tucker has written a PAM test harness that you could try with > your PAM module to maybe get more information on what is going wrong. > > I found http://dtucker.freeshell.org/patches/pam-test-harness.c but > am unsure if it is the very latest version. Darren? > > > //Peter > From jason at bakafish.com Fri Feb 6 13:43:13 2009 From: jason at bakafish.com (Jason Benguerel) Date: Fri, 6 Feb 2009 11:43:13 +0900 Subject: Hung connection over Juniper Tunnel Message-ID: <77642DFF-3463-48A9-B0D1-58B6E020B989@bakafish.com> Hello list! So I recently reconfigured our office network to allow a permanent VPN connection to our data center. This consists of a Juniper SSG-520 connected via a tunnel to a Juniper Netscreen-25 over a 100M leased NTT VPN (yes I'm tunneling over the VPN as it's the only way to make it routable.) Here is where OpenSSH come in. When I try and ssh to a machine on the other end of the tunnel, I can get past the authentication stage and then it just hangs and times out. Everything else works, ping, http, and dns (ICMP, TCP and UDP in other words.) More cryptically, I can effortlessly ssh with PuTTY from a windows box. It seems that OpenSSH (or the Unix TCP/IP stack) is the only thing affected. Now I'm the first to admit that this is most likely some sort of subtle MTU or low level TCP issue, and I'm guessing the OpenSSH is the canary in the coal mine, it would be great if I can get someone to tell me why it's freezing so that I can fix the actual cause. There were several people complaining of similar issues, typically it turned out to be bad wireless drivers or broken routers, no direct cause was ever indicated. Here is the (OpenSSH_5.1p1, OpenSSL 0.9.7l) client side debug output: debug1: Reading configuration data /Users/jason/.ssh/config debug1: Reading configuration data /etc/ssh_config debug2: ssh_connect: needpriv 0 debug1: Connecting to dc-iscsi [172.30.253.10] port 22. debug1: Connection established. debug1: identity file /Users/jason/.ssh/identity type -1 debug3: Not a RSA1 key file /Users/jason/.ssh/id_rsa. debug2: key_type_from_name: unknown key type '-----BEGIN' debug3: key_read: missing keytype debug3: key_read: missing whitespace debug2: key_type_from_name: unknown key type '-----END' debug3: key_read: missing keytype debug1: identity file /Users/jason/.ssh/id_rsa type 1 debug3: Not a RSA1 key file /Users/jason/.ssh/id_dsa. debug2: key_type_from_name: unknown key type '-----BEGIN' debug3: key_read: missing keytype debug3: key_read: missing whitespace debug2: key_type_from_name: unknown key type '-----END' debug3: key_read: missing keytype debug1: identity file /Users/jason/.ssh/id_dsa 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_5.1 debug2: fd 3 setting O_NONBLOCK debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,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 ,aes128-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 ,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64 at openssh.com,hmac- ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64 at openssh.com,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 ,aes128-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 ,aes128-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_setup: found hmac-md5 debug1: kex: server->client aes128-cbc hmac-md5 none debug2: mac_setup: 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: 136/256 debug2: bits set: 528/1024 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug3: check_host_in_hostfile: filename /Users/jason/.ssh/known_hosts debug3: check_host_in_hostfile: match line 154 debug3: check_host_in_hostfile: filename /Users/jason/.ssh/known_hosts debug3: check_host_in_hostfile: match line 138 debug1: Host 'dc-iscsi' is known and matches the RSA host key. debug1: Found key in /Users/jason/.ssh/known_hosts:154 debug2: bits set: 531/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: /Users/jason/.ssh/id_rsa (0x107ed0) debug2: key: /Users/jason/.ssh/id_dsa (0x108470) debug2: key: /Users/jason/.ssh/identity (0x0) debug1: Authentications that can continue: publickey,gssapi-with- mic,password debug3: start over, passed a different list publickey,gssapi-with- mic,password debug3: preferred publickey,keyboard-interactive,password debug3: authmethod_lookup publickey debug3: remaining preferred: keyboard-interactive,password debug3: authmethod_is_enabled publickey debug1: Next authentication method: publickey debug1: Offering public key: /Users/jason/.ssh/id_rsa debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Authentications that can continue: publickey,gssapi-with- mic,password debug1: Offering public key: /Users/jason/.ssh/id_dsa debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Server accepts key: pkalg ssh-dss blen 434 debug2: input_userauth_pk_ok: fp a2:9e:5d:b0:18:22:ce: 43:9e:ea:f7:47:36:39:c4:ff debug3: sign_and_send_pubkey debug1: Authentication succeeded (publickey). debug1: channel 0: new [client-session] debug3: ssh_session2_open: channel_new: 0 debug2: channel 0: send open debug1: Requesting no-more-sessions at openssh.com debug1: Entering interactive session. debug2: callback start debug2: client_session2_setup: id 0 debug2: channel 0: request pty-req confirm 1 debug3: tty_make_modes: ospeed 38400 debug3: tty_make_modes: ispeed 38400 debug2: channel 0: request shell confirm 1 debug2: fd 3 setting TCP_NODELAY debug2: callback done debug2: channel 0: open confirm rwindow 0 rmax 32768 Timeout, server not responding. ******** sshd debug ******(OpenSSH_4.3p2, OpenSSL 0.9.8b)********************** debug2: load_server_config: filename /etc/ssh/sshd_config debug2: load_server_config: done config len = 540 debug2: parse_server_config: config /etc/ssh/sshd_config len 540 debug1: sshd version OpenSSH_4.3p2 debug3: Not a RSA1 key file /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 /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/sbin/sshd' debug1: rexec_argv[1]='-ddd' debug1: rexec_argv[2]='-p' debug1: rexec_argv[3]='1000' debug2: fd 3 setting O_NONBLOCK debug1: Bind to port 1000 on ::. Server listening on :: port 1000. debug2: fd 4 setting O_NONBLOCK debug1: Bind to port 1000 on 0.0.0.0. Bind to port 1000 on 0.0.0.0 failed: Address already in use. debug3: fd 4 is not O_NONBLOCK debug1: Server will not fork when running in debugging mode. debug3: send_rexec_state: entering fd = 7 config len 540 debug3: ssh_msg_send: type 0 debug3: send_rexec_state: done debug1: rexec start in 4 out 4 newsock 4 pipe -1 sock 7 debug1: inetd sockets after dupping: 3, 3 debug3: Normalising mapped IPv4 in IPv6 address Connection from 192.168.253.69 port 49165 debug1: Client protocol version 2.0; client software version OpenSSH_5.1 debug1: match: OpenSSH_5.1 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 debug2: Network child is on pid 6543 debug3: preauth child monitor started debug3: mm_request_receive entering debug3: privsep user:group 74:74 debug1: permanently_set_uid: 74/74 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 ,aes128-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 ,aes128-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-sha256,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 ,aes128-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 ,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64 at openssh.com,hmac- ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64 at openssh.com,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: monitor_read: checking request 0 debug3: mm_answer_moduli: got parameters: 1024 1024 8192 debug3: mm_request_send entering: type 1 debug3: mm_request_receive_expect entering: type 1 debug3: mm_request_receive entering debug2: monitor_read: 0 used once, disabling now debug3: mm_choose_dh: remaining 0 debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent debug2: dh_gen_key: priv key bits set: 120/256 debug2: bits set: 536/1024 debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT debug3: mm_request_receive entering debug2: bits set: 513/1024 debug3: mm_key_sign entering debug3: mm_request_send entering: type 5 debug3: mm_key_sign: waiting for MONITOR_ANS_SIGN debug3: monitor_read: checking request 5 debug3: mm_answer_sign debug3: mm_answer_sign: signature 0x7f8a5c7b28b0(271) debug3: mm_request_receive_expect entering: type 6 debug3: mm_request_receive entering debug3: mm_request_send entering: type 6 debug2: monitor_read: 5 used once, disabling now 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 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 7 debug3: mm_getpwnamallow: waiting for MONITOR_ANS_PWNAM debug3: mm_request_receive_expect entering: type 8 debug3: mm_request_receive entering debug3: monitor_read: checking request 7 debug3: mm_answer_pwnamallow debug3: mm_answer_pwnamallow: sending MONITOR_ANS_PWNAM: 1 debug3: mm_request_send entering: type 8 debug2: monitor_read: 7 used once, disabling now debug2: input_userauth_request: setting up authctxt for root debug3: mm_start_pam entering debug3: mm_request_send entering: type 46 debug3: mm_inform_authserv entering debug3: mm_request_send entering: type 3 debug3: mm_inform_authrole entering debug3: mm_request_send entering: type 4 debug2: input_userauth_request: try method none debug3: mm_request_receive entering debug3: monitor_read: checking request 46 debug1: PAM: initializing for "root" debug1: PAM: setting PAM_RHOST to "192.168.253.69" debug1: PAM: setting PAM_TTY to "ssh" debug2: monitor_read: 46 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 4 debug3: mm_answer_authrole: role= debug2: monitor_read: 4 used once, disabling now 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 debug1: test whether pkalg/pkblob are acceptable debug3: mm_key_allowed entering debug3: mm_request_send entering: type 21 debug3: mm_key_allowed: waiting for MONITOR_ANS_KEYALLOWED debug3: mm_request_receive_expect entering: type 22 debug3: mm_request_receive entering debug3: monitor_read: checking request 21 debug3: mm_answer_keyallowed entering debug3: mm_answer_keyallowed: key_from_blob: 0x7f8a5c7aaf20 debug1: temporarily_use_uid: 0/0 (e=0/0) debug1: trying public key file /root/.ssh/authorized_keys debug3: secure_filename: checking '/root/.ssh' debug3: secure_filename: checking '/root' debug3: secure_filename: terminating check at '/root' debug3: key_read: type mismatch debug2: user_key_allowed: check options: 'ssh-dss **deleted**' debug2: key_type_from_name: unknown key type '**deleted**' debug3: key_read: missing keytype debug2: user_key_allowed: advance: '**deleted**' debug1: restore_uid: 0/0 debug2: key not found debug1: temporarily_use_uid: 0/0 (e=0/0) debug1: trying public key file /root/.ssh/authorized_keys2 debug1: restore_uid: 0/0 debug3: Normalising mapped IPv4 in IPv6 address Failed publickey for root from 192.168.253.69 port 49165 ssh2 debug3: mm_answer_keyallowed: key 0x7f8a5c7aaf20 is disallowed debug3: mm_request_send entering: type 22 debug3: mm_request_receive entering debug2: userauth_pubkey: authenticated 0 pkalg ssh-rsa debug1: userauth-request for user root service ssh-connection method publickey debug1: attempt 2 failures 2 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 21 debug3: mm_key_allowed: waiting for MONITOR_ANS_KEYALLOWED debug3: mm_request_receive_expect entering: type 22 debug3: mm_request_receive entering debug3: monitor_read: checking request 21 debug3: mm_answer_keyallowed entering debug3: mm_answer_keyallowed: key_from_blob: 0x7f8a5c7aaf60 debug1: temporarily_use_uid: 0/0 (e=0/0) debug1: trying public key file /root/.ssh/authorized_keys debug3: secure_filename: checking '/root/.ssh' debug3: secure_filename: checking '/root' debug3: secure_filename: terminating check at '/root' debug1: matching key found: file /root/.ssh/authorized_keys, line 1 Found matching DSA key: a2:9e:5d:b0:18:22:ce:43:9e:ea:f7:47:36:39:c4:ff debug1: restore_uid: 0/0 debug3: mm_answer_keyallowed: key 0x7f8a5c7aaf60 is allowed debug3: mm_request_send entering: type 22 debug3: mm_request_receive entering debug2: userauth_pubkey: authenticated 0 pkalg ssh-dss debug3: Normalising mapped IPv4 in IPv6 address Postponed publickey for root from 192.168.253.69 port 49165 ssh2 debug1: userauth-request for user root service ssh-connection method publickey debug1: attempt 3 failures 2 debug2: input_userauth_request: try method publickey debug3: mm_key_allowed entering debug3: mm_request_send entering: type 21 debug3: mm_key_allowed: waiting for MONITOR_ANS_KEYALLOWED debug3: mm_request_receive_expect entering: type 22 debug3: mm_request_receive entering debug3: monitor_read: checking request 21 debug3: mm_answer_keyallowed entering debug3: mm_answer_keyallowed: key_from_blob: 0x7f8a5c7b9e40 debug1: temporarily_use_uid: 0/0 (e=0/0) debug1: trying public key file /root/.ssh/authorized_keys debug3: secure_filename: checking '/root/.ssh' debug3: secure_filename: checking '/root' debug3: secure_filename: terminating check at '/root' debug1: matching key found: file /root/.ssh/authorized_keys, line 1 Found matching DSA key: a2:9e:5d:b0:18:22:ce:43:9e:ea:f7:47:36:39:c4:ff debug1: restore_uid: 0/0 debug3: mm_answer_keyallowed: key 0x7f8a5c7b9e40 is allowed debug3: mm_request_send entering: type 22 debug3: mm_request_receive entering debug3: mm_key_verify entering debug3: mm_request_send entering: type 23 debug3: mm_key_verify: waiting for MONITOR_ANS_KEYVERIFY debug3: mm_request_receive_expect entering: type 24 debug3: mm_request_receive entering debug3: monitor_read: checking request 23 debug1: ssh_dss_verify: signature correct debug3: mm_answer_keyverify: key 0x7f8a5c7b9e40 signature verified debug3: mm_request_send entering: type 24 debug3: mm_request_receive_expect entering: type 47 debug2: userauth_pubkey: authenticated 1 pkalg ssh-dss debug3: mm_do_pam_account entering debug3: mm_request_send entering: type 47 debug3: mm_request_receive_expect entering: type 48 debug3: mm_request_receive entering debug3: mm_request_receive entering debug1: do_pam_account: called debug3: PAM: do_pam_account pam_acct_mgmt = 0 (Success) debug3: mm_request_send entering: type 48 Accepted publickey for root from 192.168.253.69 port 49165 ssh2 debug3: mm_do_pam_account returning 1 debug3: mm_send_keystate: Sending new keys: 0x7f8a5c7aa400 0x7f8a5c7aa200 debug3: mm_newkeys_to_blob: converting 0x7f8a5c7aa400 debug3: mm_newkeys_to_blob: converting 0x7f8a5c7aa200 debug3: mm_send_keystate: New keys have been sent debug3: mm_send_keystate: Sending compression state debug3: mm_request_send entering: type 25 debug3: mm_send_keystate: Finished sending state 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 25 debug3: mm_request_receive entering debug3: mm_newkeys_from_blob: 0x7f8a5c7ba4e0(122) debug2: mac_init: found hmac-md5 debug3: mm_get_keystate: Waiting for second key debug3: mm_newkeys_from_blob: 0x7f8a5c7ba4e0(122) 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 debug1: temporarily_use_uid: 0/0 (e=0/0) debug1: ssh_gssapi_storecreds: Not a GSSAPI mechanism debug1: restore_uid: 0/0 debug1: PAM: establishing credentials debug3: PAM: opening session debug2: set_newkeys: mode 0 debug2: set_newkeys: mode 1 debug1: Entering interactive session for SSH2. debug2: fd 5 setting O_NONBLOCK debug2: fd 6 setting O_NONBLOCK debug1: server_init_dispatch_20 debug1: server_input_channel_open: ctype session rchan 0 win 1048576 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_global_request: rtype no-more- sessions at openssh.com want_reply 0 ------------ Timeout ----------- ^CExiting on signal 2 debug1: do_cleanup debug1: PAM: cleanup debug1: PAM: deleting credentials debug1: PAM: closing session debug3: PAM: sshpam_thread_cleanup entering From djm at mindrot.org Fri Feb 6 16:56:24 2009 From: djm at mindrot.org (Damien Miller) Date: Fri, 6 Feb 2009 16:56:24 +1100 (EST) Subject: Hung connection over Juniper Tunnel In-Reply-To: <77642DFF-3463-48A9-B0D1-58B6E020B989@bakafish.com> References: <77642DFF-3463-48A9-B0D1-58B6E020B989@bakafish.com> Message-ID: On Fri, 6 Feb 2009, Jason Benguerel wrote: > Hello list! > > So I recently reconfigured our office network to allow a permanent VPN > connection to our data center. This consists of a Juniper SSG-520 > connected via a tunnel to a Juniper Netscreen-25 over a 100M leased > NTT VPN (yes I'm tunneling over the VPN as it's the only way to make > it routable.) Here is where OpenSSH come in. When I try and ssh to a > machine on the other end of the tunnel, I can get past the > authentication stage and then it just hangs and times out. Everything > else works, ping, http, and dns (ICMP, TCP and UDP in other words.) > More cryptically, I can effortlessly ssh with PuTTY from a windows > box. It seems that OpenSSH (or the Unix TCP/IP stack) is the only > thing affected. Now I'm the first to admit that this is most likely > some sort of subtle MTU or low level TCP issue, and I'm guessing the > OpenSSH is the canary in the coal mine, it would be great if I can get > someone to tell me why it's freezing so that I can fix the actual cause. > > There were several people complaining of similar issues, typically it > turned out to be bad wireless drivers or broken routers, no direct > cause was ever indicated. There are two types of common hang: 1) Long-lived but SSH connections being timed out of NAT/firewall state after some period of quiescence. This can be worked around with the ClientAliveInterval and ServerAliveInterval controls in ssh_config and sshd_config respectively. 2) Path MTU blackholes. The hang here usually occurs when either end first sends a packet containing a MTU of data or more. The is no SSH-level workaround for this, but the tool of choice to diagnose it is "ping -D -s xxxx yourhost" where xxxx is the packet size that your want to test (start at 1492 and work down). Windows might work where other fail because IIRC it implements PMTU blackhole detection. -d From maf at appgate.com Fri Feb 6 17:52:26 2009 From: maf at appgate.com (maf at appgate.com) Date: Fri, 6 Feb 2009 07:52:26 +0100 (CET) Subject: Hung connection over Juniper Tunnel In-Reply-To: References: <77642DFF-3463-48A9-B0D1-58B6E020B989@bakafish.com> Message-ID: TCP window scaling is also a possibility. At least that is an issue we have encountered a number of times. /MaF -- Martin Forssen Development Manager Phone: +46 31 7744361 AppGate Network Security AB From jason at bakafish.com Fri Feb 6 19:51:07 2009 From: jason at bakafish.com (Jason Benguerel) Date: Fri, 6 Feb 2009 17:51:07 +0900 Subject: Hung connection over Juniper Tunnel In-Reply-To: References: <77642DFF-3463-48A9-B0D1-58B6E020B989@bakafish.com> Message-ID: <3801C583-1BB4-4C2A-B85E-784A1D18F828@bakafish.com> I have disabled TCP Window scaling on both the client and server. I also confirmed that there are no MTU issues using ping (with the no fragment flag and full payload.) There are reports of Juniper firewalls causing similar issues, but I have applied the supposed workaround of disabling TCP sequence checking (which they claim stops the window scaling issue) and still have no results. The sshd server is still replying with: debug1: server_input_channel_open: ctype session rchan 0 win 1048576 max 16384 Which looks to me as if it is still trying to set a variable TCP window despite turning the feature off via: echo 0 > /proc/sys/net/ipv4/tcp_window_scaling Is there some other way to disable this in ssh/sshd? Jason On Feb 6, 2009, at 3:52 PM, maf at appgate.com wrote: > TCP window scaling is also a possibility. At least that is an issue we > have encountered a number of times. > > /MaF > -- > Martin Forssen Development Manager > Phone: +46 31 7744361 AppGate Network > Security AB > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From rmh at aybabtu.com Sat Feb 7 00:48:26 2009 From: rmh at aybabtu.com (Robert Millan) Date: Fri, 6 Feb 2009 14:48:26 +0100 Subject: [PATCH] GNU/kFreeBSD & GNU/kOpenSolaris support Message-ID: <20090206134826.GA28945@thorin> Hi, This patch, initially made by Aurelien Jarno for GNU/kFreeBSD, and adjusted by me to also support GNU/kOpensolaris, adds support for these two operating systems. -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." -------------- next part -------------- A non-text attachment was scrubbed... Name: openssh.diff Type: text/x-diff Size: 779 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20090206/db3ca9e8/attachment.bin From cmadams at hiwaay.net Sat Feb 7 02:48:24 2009 From: cmadams at hiwaay.net (Chris Adams) Date: Fri, 6 Feb 2009 09:48:24 -0600 Subject: Hung connection over Juniper Tunnel In-Reply-To: References: <77642DFF-3463-48A9-B0D1-58B6E020B989@bakafish.com> Message-ID: <20090206154824.GF854391@hiwaay.net> Once upon a time, Damien Miller said: > 1) Long-lived but SSH connections being timed out of NAT/firewall state > after some period of quiescence. This can be worked around with the > ClientAliveInterval and ServerAliveInterval controls in ssh_config and > sshd_config respectively. IIRC the default ScreenOS TCP session idle timeout is way too short (something like 30 minutes). Rather than use the OpenSSH keep alives (which only fixes SSH), you should adjust the firewalls to have a sane value (IIRC Linux firewall code defaults to 5 days for established TCP sessions). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From dirkjan at ochtman.nl Sat Feb 7 03:44:05 2009 From: dirkjan at ochtman.nl (Dirkjan Ochtman) Date: Fri, 6 Feb 2009 17:44:05 +0100 Subject: ssh -vvv doesn't show the username anywhere Message-ID: ... and that's kind of annoying when I'm trying to debug something. Also, it doesn't seem like openssh.org lists the IRC channel (even though it's referenced) anywhere. Cheers, Dirkjan From djm at mindrot.org Sat Feb 7 04:46:01 2009 From: djm at mindrot.org (Damien Miller) Date: Sat, 7 Feb 2009 04:46:01 +1100 (EST) Subject: Hung connection over Juniper Tunnel In-Reply-To: <3801C583-1BB4-4C2A-B85E-784A1D18F828@bakafish.com> References: <77642DFF-3463-48A9-B0D1-58B6E020B989@bakafish.com> <3801C583-1BB4-4C2A-B85E-784A1D18F828@bakafish.com> Message-ID: On Fri, 6 Feb 2009, Jason Benguerel wrote: > I have disabled TCP Window scaling on both the client and server. I > also confirmed that there are no MTU issues using ping (with the no > fragment flag and full payload.) There are reports of Juniper > firewalls causing similar issues, but I have applied the supposed > workaround of disabling TCP sequence checking (which they claim stops > the window scaling issue) and still have no results. > > The sshd server is still replying with: > > debug1: server_input_channel_open: ctype session rchan 0 win 1048576 > max 16384 > > Which looks to me as if it is still trying to set a variable TCP > window despite turning the feature off via: > > echo 0 > /proc/sys/net/ipv4/tcp_window_scaling > > Is there some other way to disable this in ssh/sshd? No, the "win" here is the SSH session level windows which has little to do with the TCP window. Stock OpenSSH doesn't touch the TCP window in any way. -d From vadud3 at gmail.com Sat Feb 7 04:10:11 2009 From: vadud3 at gmail.com (Asif Iqbal) Date: Fri, 6 Feb 2009 12:10:11 -0500 Subject: ssh -vvv doesn't show the username anywhere In-Reply-To: References: Message-ID: On Fri, Feb 6, 2009 at 11:44 AM, Dirkjan Ochtman wrote: > ... and that's kind of annoying when I'm trying to debug something. what are you trying to debug? annoyed by user error ? :-) sshd -d -p 8000 (server) ssh -vv -p 8000 server-ip (client) now look for the username on the server side. > > Also, it doesn't seem like openssh.org lists the IRC channel (even > though it's referenced) anywhere. > > Cheers, > > Dirkjan > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > -- Asif Iqbal PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu From dirkjan at ochtman.nl Sat Feb 7 05:34:54 2009 From: dirkjan at ochtman.nl (Dirkjan Ochtman) Date: Fri, 6 Feb 2009 19:34:54 +0100 Subject: ssh -vvv doesn't show the username anywhere In-Reply-To: References: Message-ID: On Fri, Feb 6, 2009 at 18:10, Asif Iqbal wrote: > what are you trying to debug? annoyed by user error ? :-) I'm trying to push to Mozilla's Mercurial repositories. > sshd -d -p 8000 (server) ... and so I don't control the server side... > ssh -vv -p 8000 server-ip (client) > > now look for the username on the server side. ... so that's no good. :) Cheers, Dirkjan From vinschen at redhat.com Sat Feb 7 06:35:15 2009 From: vinschen at redhat.com (Corinna Vinschen) Date: Fri, 6 Feb 2009 20:35:15 +0100 Subject: ssh -vvv doesn't show the username anywhere In-Reply-To: References: Message-ID: <20090206193515.GK16129@calimero.vinschen.de> On Feb 6 19:34, Dirkjan Ochtman wrote: > On Fri, Feb 6, 2009 at 18:10, Asif Iqbal wrote: > > what are you trying to debug? annoyed by user error ? :-) > > I'm trying to push to Mozilla's Mercurial repositories. > > > sshd -d -p 8000 (server) > > ... and so I don't control the server side... > > > ssh -vv -p 8000 server-ip (client) > > > > now look for the username on the server side. > > ... so that's no good. :) If you're debugging the client side, you know the username anyway. It's either the same as your local username, or you specified it on the command line, or it's mentioned in the config file. Why do you need it in the debug output again? Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From jblaine at kickflop.net Sat Feb 7 06:42:14 2009 From: jblaine at kickflop.net (Jeff Blaine) Date: Fri, 06 Feb 2009 14:42:14 -0500 Subject: Coding help : Where to log X11 forwards? In-Reply-To: <498B5A34.9050403@kickflop.net> References: <498B5A34.9050403@kickflop.net> Message-ID: <498C9296.7040604@kickflop.net> Really confused now. Neither w00t gets tickled but the X11 session is established fine. % strings /linus/tmp/jblaine/sbin/sshd | grep w00t jblaine testing : pre-w00t jblaine testing : w00t? : %s % % sudo /linus/tmp/jblaine/sbin/sshd -p 3333 -ddd 2>&1 | grep w00t % /* session.c */ ... debug2("jblaine testing : pre-w00t"); packet_check_eom(); success = session_setup_x11fwd(s); if (!success) { xfree(s->auth_proto); xfree(s->auth_data); s->auth_proto = NULL; s->auth_data = NULL; } else { debug2("jblaine testing : w00t? : %s", s->auth_display); } ... Jeff Blaine wrote: > OpenSSH 5.1p1 > > I can't grasp why, when connecting with 'ssh -Y' to this > test host, I am not tickling the verbose() call below that > I have added. > > I am logging as auth + verbose in sshd_config > > The X11 forward for the session works fine as tested with > xterm. > > At any rate, I am looking for some guidance on where > to log X11 forwards that are established, ideally with > a username and remote display information, but whatever > I can get, I'll take. > > Any help would be great. > > session.c: > > packet_check_eom(); > success = session_setup_x11fwd(s); > if (!success) { > xfree(s->auth_proto); > xfree(s->auth_data); > s->auth_proto = NULL; > s->auth_data = NULL; > } else { > verbose("jblaine testing : w00t? : %s", s->auth_display); > } > From dtucker at zip.com.au Sat Feb 7 09:11:24 2009 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 07 Feb 2009 09:11:24 +1100 Subject: Coding help : Where to log X11 forwards? In-Reply-To: <498C9296.7040604@kickflop.net> References: <498B5A34.9050403@kickflop.net> <498C9296.7040604@kickflop.net> Message-ID: <498CB58C.9000209@zip.com.au> Jeff Blaine wrote: > Really confused now. Neither w00t gets tickled but the > X11 session is established fine. > > % strings /linus/tmp/jblaine/sbin/sshd | grep w00t > jblaine testing : pre-w00t > jblaine testing : w00t? : %s > % > > % sudo /linus/tmp/jblaine/sbin/sshd -p 3333 -ddd 2>&1 | grep w00t You can add "-e" to force all debug messages to stderr although I don't think it will make a difference. > % > > /* session.c */ > ... > debug2("jblaine testing : pre-w00t"); > > packet_check_eom(); > success = session_setup_x11fwd(s); > if (!success) { > xfree(s->auth_proto); > xfree(s->auth_data); > s->auth_proto = NULL; > s->auth_data = NULL; > } else { > debug2("jblaine testing : w00t? : %s", s->auth_display); > } Sounds odd. The code is in session_x11_req() which is called when the client sends a "x11-req" channel request. Are you sure you client is sending one? Does the X11 request show up on the client-side debugging? You said that X gets set up, is it possible it's done outside of ssh? -- 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 Sat Feb 7 16:06:22 2009 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 07 Feb 2009 16:06:22 +1100 Subject: Hung connection over Juniper Tunnel In-Reply-To: References: <77642DFF-3463-48A9-B0D1-58B6E020B989@bakafish.com> Message-ID: <498D16CE.4040500@zip.com.au> Damien Miller wrote: > On Fri, 6 Feb 2009, Jason Benguerel wrote: > >> Hello list! >> >> So I recently reconfigured our office network to allow a permanent VPN >> connection to our data center. This consists of a Juniper SSG-520 >> connected via a tunnel to a Juniper Netscreen-25 over a 100M leased >> NTT VPN (yes I'm tunneling over the VPN as it's the only way to make >> it routable.) Here is where OpenSSH come in. When I try and ssh to a >> machine on the other end of the tunnel, I can get past the >> authentication stage and then it just hangs and times out. Everything >> else works, ping, http, and dns (ICMP, TCP and UDP in other words.) >> More cryptically, I can effortlessly ssh with PuTTY from a windows >> box. It seems that OpenSSH (or the Unix TCP/IP stack) is the only >> thing affected. Now I'm the first to admit that this is most likely >> some sort of subtle MTU or low level TCP issue, and I'm guessing the >> OpenSSH is the canary in the coal mine, it would be great if I can get >> someone to tell me why it's freezing so that I can fix the actual cause. >> >> There were several people complaining of similar issues, typically it >> turned out to be bad wireless drivers or broken routers, no direct >> cause was ever indicated. > > There are two types of common hang: > > 1) Long-lived but SSH connections being timed out of NAT/firewall state > after some period of quiescence. This can be worked around with the > ClientAliveInterval and ServerAliveInterval controls in ssh_config and > sshd_config respectively. > > 2) Path MTU blackholes. The hang here usually occurs when either end first > sends a packet containing a MTU of data or more. The is no SSH-level > workaround for this, but the tool of choice to diagnose it is > "ping -D -s xxxx yourhost" where xxxx is the packet size that your want > to test (start at 1492 and work down). 3) some NAT/firewalls seem to choke when Nagle gets disabled on an established connection (that's what's happening when the debug output says "setting TCP_NODELAY" immediately before your connection freezes, which is what makes me think that's the problem here). You can test this theory by editing misc.c:set_nodelay() and adding a "return;" immediately after the variable declarations (this is around line 138 in recent versions) and recompiling ssh. -- 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 jblaine at kickflop.net Sun Feb 8 00:42:32 2009 From: jblaine at kickflop.net (Jeff Blaine) Date: Sat, 07 Feb 2009 08:42:32 -0500 Subject: Coding help : Where to log X11 forwards? In-Reply-To: <498CB58C.9000209@zip.com.au> References: <498B5A34.9050403@kickflop.net> <498C9296.7040604@kickflop.net> <498CB58C.9000209@zip.com.au> Message-ID: <498D8FC8.2060205@kickflop.net> >> /* session.c */ >> ... >> debug2("jblaine testing : pre-w00t"); >> >> packet_check_eom(); >> success = session_setup_x11fwd(s); >> if (!success) { >> xfree(s->auth_proto); >> xfree(s->auth_data); >> s->auth_proto = NULL; >> s->auth_data = NULL; >> } else { >> debug2("jblaine testing : w00t? : %s", s->auth_display); >> } > > Sounds odd. > > The code is in session_x11_req() which is called when the client sends a > "x11-req" channel request. Are you sure you client is sending one? Sorry, I should have provided more info. My debug2() calls above are around line 348 in the 'case SSH_CMSG_X11_REQUEST_FORWARDING:' section. I take it that's the wrong place? From jblaine at kickflop.net Sun Feb 8 03:28:53 2009 From: jblaine at kickflop.net (Jeff Blaine) Date: Sat, 07 Feb 2009 11:28:53 -0500 Subject: Patch to 5.1p1 : Log X11 forwarding Message-ID: <498DB6C5.1080908@kickflop.net> --- /linus/src/openssh-5.1p1/session.c 2008-06-16 09:29:18.000000000 -0400 +++ session.c 2009-02-07 11:27:37.146134000 -0500 @@ -344,6 +344,7 @@ } else { s->screen = 0; } + packet_check_eom(); success = session_setup_x11fwd(s); if (!success) { @@ -2246,6 +2247,7 @@ { int success = 0; Session *s; + const char *host = NULL; if ((s = session_by_channel(c->self)) == NULL) { logit("session_input_channel_req: no session %d req %.100s", @@ -2267,6 +2269,10 @@ success = session_pty_req(s); } else if (strcmp(rtype, "x11-req") == 0) { success = session_x11_req(s); + if (success) { + host = get_canonical_hostname(options.use_dns); + verbose("X11 forwarding for %s to %s", s->pw->pw_name, host); + } } else if (strcmp(rtype, "auth-agent-req at openssh.com") == 0) { success = session_auth_agent_req(s); } else if (strcmp(rtype, "subsystem") == 0) { From dtucker at zip.com.au Sun Feb 8 12:06:07 2009 From: dtucker at zip.com.au (Darren Tucker) Date: Sun, 08 Feb 2009 12:06:07 +1100 Subject: Coding help : Where to log X11 forwards? In-Reply-To: <498D8FC8.2060205@kickflop.net> References: <498B5A34.9050403@kickflop.net> <498C9296.7040604@kickflop.net> <498CB58C.9000209@zip.com.au> <498D8FC8.2060205@kickflop.net> Message-ID: <498E2FFF.10901@zip.com.au> Jeff Blaine wrote: >[...] >> The code is in session_x11_req() which is called when the client sends a >> "x11-req" channel request. Are you sure you client is sending one? > > Sorry, I should have provided more info. My debug2() calls > above are around line 348 in the 'case SSH_CMSG_X11_REQUEST_FORWARDING:' > section. > > I take it that's the wrong place? It's the right place but only for Protocol 1 connections (SSH_CMSG_* are SSH1 protocol message types). -- 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 extrospective at gmail.com Sun Feb 8 13:38:32 2009 From: extrospective at gmail.com (Artis) Date: Sun, 8 Feb 2009 04:38:32 +0200 Subject: [OpenSSH_5.1] Untrusted X11 forwarding (ssh -X) no longer works? Message-ID: $ ssh -v OpenSSH_5.1, OpenSSL 0.9.8j 07 Jan 2009 $ ssh -vvv -X example.com [ Relevant debug info: ] debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1 [OpenSSH_5.1, OpenSSL 0.9.7j 04 May 2006] debug2: x11_get_proto: /usr/X11R6/bin/xauth -f /tmp/ssh-TLLOFKxvay/xauthfile generate :0.0 MIT-MAGIC-COOKIE-1 untrusted timeout 1200 2>/dev/null Warning: untrusted X11 forwarding setup failed: xauth key data not generated Warning: No xauth data; using fake authentication data for X11 forwarding. debug1: Requesting X11 forwarding with authentication spoofing. debug2: channel 0: request x11-req confirm 0 $ xeyes $ xeyes debug1: client_input_channel_open: ctype x11 rchan 2 win 65536 max 16384 debug1: client_request_x11: request from 127.0.0.1 39892 debug2: fd 10 setting O_NONBLOCK debug3: fd 10 is O_NONBLOCK debug1: channel 1: new [x11] debug1: confirm x11 debug2: channel 1: read<=0 rfd 10 len 0 debug2: channel 1: read failed debug2: channel 1: close_read debug2: channel 1: input open -> drain debug2: channel 1: ibuf empty debug2: channel 1: send eof debug2: channel 1: input drain -> closed debug2: channel 1: rcvd eof debug2: channel 1: output open -> drain debug2: channel 1: obuf empty debug2: channel 1: close_write debug2: channel 1: output drain -> closed debug2: channel 1: rcvd close debug3: channel 1: will not send data after close debug2: channel 1: send close debug2: channel 1: is dead debug2: channel 1: garbage collecting debug1: channel 1: free: x11, nchannels 2 debug3: channel 1: status: The following connections are open: #0 client-session (t4 r0 i0/0 o0/139 fd 6/7 cfd -1) #1 x11 (t4 r2 i3/0 o3/0 fd 10/10 cfd -1) debug3: channel 1: close_fds r 10 w 10 e -1 c -1 Xlib: connection to "localhost:10.0" refused by server Xlib: Invalid MIT-MAGIC-COOKIE-1 key Error: Can't open display: localhost:10.0 [Both ends are OpenBSDs. Client side is 4.4-RELEASE. X server is CURRENT] The above xauth command that ssh client tries, fails if executed manually: $ /usr/X11R6/bin/xauth -f /tmp/ssh-TLLOFKxvay/xauthfile generate :0.0 MIT-MAGIC-COOKIE-1 untrusted timeout 1200 /usr/X11R6/bin/xauth: error in locking authority file /tmp/ssh-TLLOFKxvay/xauthfile I have to manually exec xauth +localhost to fix forwarding. Trusted forwarding (-Y) works. Is this somehow related to http://bugs.gentoo.org/237778 and https://bugzilla.redhat.com/show_bug.cgi?id=436230 Artis P.S. I'm not subscribed to the list. From tcreedon at easystreet.net Sun Feb 8 13:58:42 2009 From: tcreedon at easystreet.net (Ted Creedon) Date: Sat, 7 Feb 2009 18:58:42 -0800 Subject: KRB5 support Message-ID: Is krb5 support native, through gssapi or pam? thanks tedc From djm at mindrot.org Sun Feb 8 14:04:27 2009 From: djm at mindrot.org (Damien Miller) Date: Sun, 8 Feb 2009 14:04:27 +1100 (EST) Subject: KRB5 support In-Reply-To: References: Message-ID: On Sat, 7 Feb 2009, Ted Creedon wrote: > Is krb5 support native, through gssapi or pam? Depending on your configuration, any of the above. -d From jason.dickerson at gmail.com Tue Feb 10 11:24:35 2009 From: jason.dickerson at gmail.com (Jason Dickerson) Date: Mon, 9 Feb 2009 18:24:35 -0600 Subject: Restrict commands available in an SFTP session Message-ID: <906820b60902091624s3d4ebb5cv45804c33b984f3d1@mail.gmail.com> I am currently running OpenSSH 4.3. I would like to restrict the commands SFTP users can run to a list. For example, "put, get, mput, mget, mkdir, rmdir, and rm". Is this possible with OpenSSH? I have seen many posts concerning chroot'ing and the Forced Command option, but none of these solution address restricting the commands actually available inside the SFTP subsystem. Any insight would be greatly appreciated. Thanks, Jason Dickerson From djm at mindrot.org Tue Feb 10 13:13:09 2009 From: djm at mindrot.org (Damien Miller) Date: Tue, 10 Feb 2009 13:13:09 +1100 (EST) Subject: Restrict commands available in an SFTP session In-Reply-To: <906820b60902091624s3d4ebb5cv45804c33b984f3d1@mail.gmail.com> References: <906820b60902091624s3d4ebb5cv45804c33b984f3d1@mail.gmail.com> Message-ID: On Mon, 9 Feb 2009, Jason Dickerson wrote: > I am currently running OpenSSH 4.3. I would like to restrict the commands > SFTP users can run to a list. For example, "put, get, mput, mget, mkdir, > rmdir, and rm". Is this possible with OpenSSH? I have seen many posts > concerning chroot'ing and the Forced Command option, but none of these > solution address restricting the commands actually available inside the SFTP > subsystem. Any insight would be greatly appreciated. This isn't supported, or planned. You can perform fairly effective restriction with file/directory permissions alone. -d From jason at bakafish.com Tue Feb 10 13:14:18 2009 From: jason at bakafish.com (Jason Benguerel) Date: Tue, 10 Feb 2009 11:14:18 +0900 Subject: Hung connection over Juniper Tunnel In-Reply-To: <498D16CE.4040500@zip.com.au> References: <77642DFF-3463-48A9-B0D1-58B6E020B989@bakafish.com> <498D16CE.4040500@zip.com.au> Message-ID: <4DC88504-78DC-41D6-B35F-B474F18BF617@bakafish.com> Sorry to not respond quickly to these suggestions. This is not a long term timeout, it locks up immediately after establishing the password is valid or that the key file is in authorized_keys. There is a very high probability that this is MTU related as it is an IPsec tunnel over a PPPoE link, so there are plenty of things that could go wrong. I set the PPoE MTU to 1492 and the tunnel endpoints to 1480 on the basis that the largest unsegmented packet I could transmit had a payload of 1472. I disabled the set_nodelay() on both client and server sides, but it didn't have any effect. I understand I have to solve the underlying MTU problem before I'm able to look at the other issues. Because this is a somewhat convoluted setup it is proving difficult to figure out. My connection looks like this: Client A (MTU1500) <---> IPsec Tunnel (MTU1480) <---> PPPoE-VPN (MTU1492) <---> IPsec Tunnel (MTU1480) <---> Client B (MTU1500) From Client A to B I can send up to a 1472 byte packet before it chokes. However on the B side it is only able to send a 1420 byte packet for reasons that are not at all clear. I therefore changed the client B side of the tunnel to MTU1448 to no visible effect. Again, sorry to sideline the OpenSSH list with a potentially off topic networking issue, but only OpenSSH so far is visibly suffering from this and understanding why that may be may allow the tool to become more robust, or at least flag the exact cause in it's dubug output. On Feb 7, 2009, at 2:06 PM, Darren Tucker wrote: > Damien Miller wrote: >> On Fri, 6 Feb 2009, Jason Benguerel wrote: >>> Hello list! >>> >>> So I recently reconfigured our office network to allow a permanent >>> VPN connection to our data center. This consists of a Juniper >>> SSG-520 connected via a tunnel to a Juniper Netscreen-25 over a >>> 100M leased NTT VPN (yes I'm tunneling over the VPN as it's the >>> only way to make it routable.) Here is where OpenSSH come in. >>> When I try and ssh to a machine on the other end of the tunnel, I >>> can get past the authentication stage and then it just hangs and >>> times out. Everything else works, ping, http, and dns (ICMP, TCP >>> and UDP in other words.) More cryptically, I can effortlessly ssh >>> with PuTTY from a windows box. It seems that OpenSSH (or the Unix >>> TCP/IP stack) is the only thing affected. Now I'm the first to >>> admit that this is most likely some sort of subtle MTU or low >>> level TCP issue, and I'm guessing the OpenSSH is the canary in >>> the coal mine, it would be great if I can get someone to tell me >>> why it's freezing so that I can fix the actual cause. >>> >>> There were several people complaining of similar issues, typically >>> it turned out to be bad wireless drivers or broken routers, no >>> direct cause was ever indicated. >> There are two types of common hang: >> 1) Long-lived but SSH connections being timed out of NAT/firewall >> state >> after some period of quiescence. This can be worked around with the >> ClientAliveInterval and ServerAliveInterval controls in >> ssh_config and >> sshd_config respectively. >> 2) Path MTU blackholes. The hang here usually occurs when either >> end first >> sends a packet containing a MTU of data or more. The is no SSH- >> level >> workaround for this, but the tool of choice to diagnose it is >> "ping -D -s xxxx yourhost" where xxxx is the packet size that your >> want >> to test (start at 1492 and work down). > > 3) some NAT/firewalls seem to choke when Nagle gets disabled on an > established connection (that's what's happening when the debug > output says "setting TCP_NODELAY" immediately before your connection > freezes, which is what makes me think that's the problem here). > > You can test this theory by editing misc.c:set_nodelay() and adding > a "return;" immediately after the variable declarations (this is > around line 138 in recent versions) and recompiling ssh. > > -- > 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 Tue Feb 10 13:17:51 2009 From: djm at mindrot.org (Damien Miller) Date: Tue, 10 Feb 2009 13:17:51 +1100 (EST) Subject: Hung connection over Juniper Tunnel In-Reply-To: <4DC88504-78DC-41D6-B35F-B474F18BF617@bakafish.com> References: <77642DFF-3463-48A9-B0D1-58B6E020B989@bakafish.com> <498D16CE.4040500@zip.com.au> <4DC88504-78DC-41D6-B35F-B474F18BF617@bakafish.com> Message-ID: On Tue, 10 Feb 2009, Jason Benguerel wrote: > Again, sorry to sideline the OpenSSH list with a potentially off topic > networking issue, but only OpenSSH so far is visibly suffering from > this and understanding why that may be may allow the tool to become > more robust, or at least flag the exact cause in it's dubug output. You should try to recreate the problem unidirectionally using netcat or similar. OpenSSH has a lot going on that distracts from debugging problems that occur at lower levels. -d From jason.dickerson at gmail.com Tue Feb 10 14:51:20 2009 From: jason.dickerson at gmail.com (Jason Dickerson) Date: Mon, 9 Feb 2009 21:51:20 -0600 Subject: Restrict commands available in an SFTP session In-Reply-To: References: <906820b60902091624s3d4ebb5cv45804c33b984f3d1@mail.gmail.com> Message-ID: <906820b60902091951qe3fbd9fs47c7bac22fe2fc32@mail.gmail.com> I see your point about file permissions being fairly effective; however, I need to be able to keep users from changing file permissions with chown, chmod, and chgrp. I do not see how file permissions can accomplish this. My goal is to allow certain SFTP users into shared folders whose access is controlled by ACL's, in such a way they cannot give unauthorized users access to the shared folder. For instance... I have a chroot jail at /mountpoint/sftp. Within this there are home directories for users at /mountpoint/sftp/home/user. Also, there are shared folders at /mountpoint/sftp/shared/folder1, /mountpoint/sftp/shared/folder2, etc... When user1 logs in, they are automatically put in /mountpoint/sftp/home/user1. By ACL, user1 has access to /mountpoint/sftp/shared/folder1, but not .../folder2. Also, user2 has ACL access to /mountpoint/sftp/shared/folder2, but not .../folder1. There is no way to keep user1 from performing "chmod 777 /shared/folder1"; thus giving user2 (or any other user) unauthorized access to /shared/folder1 within the chroot jail. I know to some this may seem paranoid or "hokey", but I really have a good reason for this. Any suggestions, would be welcome. Jason On Mon, Feb 9, 2009 at 8:13 PM, Damien Miller wrote: > On Mon, 9 Feb 2009, Jason Dickerson wrote: > > > I am currently running OpenSSH 4.3. I would like to restrict the > commands > > SFTP users can run to a list. For example, "put, get, mput, mget, mkdir, > > rmdir, and rm". Is this possible with OpenSSH? I have seen many posts > > concerning chroot'ing and the Forced Command option, but none of these > > solution address restricting the commands actually available inside the > SFTP > > subsystem. Any insight would be greatly appreciated. > > This isn't supported, or planned. You can perform fairly effective > restriction with file/directory permissions alone. > > -d > From mloftis at wgops.com Tue Feb 10 14:56:31 2009 From: mloftis at wgops.com (Michael Loftis) Date: Mon, 09 Feb 2009 20:56:31 -0700 Subject: Restrict commands available in an SFTP session In-Reply-To: <906820b60902091951qe3fbd9fs47c7bac22fe2fc32@mail.gmail.com> References: <906820b60902091624s3d4ebb5cv45804c33b984f3d1@mail.gmail.com> <906820b60902091951qe3fbd9fs47c7bac22fe2fc32@mail.gmail.com> Message-ID: <348434FC0643084976BB72CC@ZOP-MACTEL.local> make the directory owned by a different user, group read and execute, other none, and put the users you want to have access into the group. --On February 9, 2009 9:51:20 PM -0600 Jason Dickerson wrote: > I see your point about file permissions being fairly effective; however, I > need to be able to keep users from changing file permissions with chown, > chmod, and chgrp. I do not see how file permissions can accomplish this. > > My goal is to allow certain SFTP users into shared folders whose access is > controlled by ACL's, in such a way they cannot give unauthorized users > access to the shared folder. For instance... > > I have a chroot jail at /mountpoint/sftp. Within this there are home > directories for users at /mountpoint/sftp/home/user. Also, there are > shared folders at /mountpoint/sftp/shared/folder1, > /mountpoint/sftp/shared/folder2, etc... When user1 logs in, they are > automatically put in > /mountpoint/sftp/home/user1. By ACL, user1 has access to > /mountpoint/sftp/shared/folder1, but not .../folder2. Also, user2 has ACL > access to /mountpoint/sftp/shared/folder2, but not .../folder1. There is > no way to keep user1 from performing "chmod 777 /shared/folder1"; thus > giving user2 (or any other user) unauthorized access to /shared/folder1 > within the chroot jail. > > I know to some this may seem paranoid or "hokey", but I really have a good > reason for this. > > Any suggestions, would be welcome. > > Jason > > > > On Mon, Feb 9, 2009 at 8:13 PM, Damien Miller wrote: > >> On Mon, 9 Feb 2009, Jason Dickerson wrote: >> >> > I am currently running OpenSSH 4.3. I would like to restrict the >> commands >> > SFTP users can run to a list. For example, "put, get, mput, mget, >> > mkdir, rmdir, and rm". Is this possible with OpenSSH? I have seen >> > many posts concerning chroot'ing and the Forced Command option, but >> > none of these solution address restricting the commands actually >> > available inside the >> SFTP >> > subsystem. Any insight would be greatly appreciated. >> >> This isn't supported, or planned. You can perform fairly effective >> restriction with file/directory permissions alone. >> >> -d >> > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev -- "Genius might be described as a supreme capacity for getting its possessors into trouble of all kinds." -- Samuel Butler From peter at stuge.se Tue Feb 10 17:47:27 2009 From: peter at stuge.se (Peter Stuge) Date: Tue, 10 Feb 2009 07:47:27 +0100 Subject: Restrict commands available in an SFTP session In-Reply-To: <348434FC0643084976BB72CC@ZOP-MACTEL.local> References: <906820b60902091624s3d4ebb5cv45804c33b984f3d1@mail.gmail.com> <906820b60902091951qe3fbd9fs47c7bac22fe2fc32@mail.gmail.com> <348434FC0643084976BB72CC@ZOP-MACTEL.local> Message-ID: <20090210064727.8174.qmail@stuge.se> Michael Loftis wrote: > > There is no way to keep user1 from performing > > "chmod 777 /shared/folder1"; thus giving user2 (or any other > > user) unauthorized access to /shared/folder1 within the chroot > > jail. > > make the directory owned by a different user, group read and > execute, other none, and put the users you want to have access into > the group. To clarify, this applies to /mountpoint/sftp/shared in your case. If your users do not have write permission in /shared they can not change permissions for the subdirectories. That said, I sometimes also want a little more out of sftp-server than it can do at present. Has there been any discussion upstream about a configuration file for sftp-server? For starters I would like to set umask and have a way to artificially restrict and/or enforce permissions and ownership on a per-directory basis. I can hack but it will likely take forever until anything is finished. //Peter From chris at qwirx.com Tue Feb 10 19:48:05 2009 From: chris at qwirx.com (Chris Wilson) Date: Tue, 10 Feb 2009 08:48:05 +0000 (GMT) Subject: Hung connection over Juniper Tunnel In-Reply-To: <4DC88504-78DC-41D6-B35F-B474F18BF617@bakafish.com> References: <77642DFF-3463-48A9-B0D1-58B6E020B989@bakafish.com> <498D16CE.4040500@zip.com.au> <4DC88504-78DC-41D6-B35F-B474F18BF617@bakafish.com> Message-ID: Hi Jason, On Tue, 10 Feb 2009, Jason Benguerel wrote: > Client A (MTU1500) <---> IPsec Tunnel (MTU1480) <---> PPPoE-VPN > (MTU1492) <---> IPsec Tunnel (MTU1480) <---> Client B (MTU1500) > > From Client A to B I can send up to a 1472 byte packet before it > chokes. However on the B side it is only able to send a 1420 byte > packet for reasons that are not at all clear. I therefore changed the > client B side of the tunnel to MTU1448 to no visible effect. If the maximum packet you can send from a machine is 1420 bytes long, then you need to set the MTU on that machine to 1420, not 1448 or any higher number. Cheers, Chris. -- _____ __ _ \ __/ / ,__(_)_ | Chris Wilson <0000 at qwirx.com> - Cambs UK | / (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Ruby/Perl/SQL Developer | \__/_/_/_//_/___/ | We are GNU : free your mind & your software | From sfandino at yahoo.com Wed Feb 11 04:11:50 2009 From: sfandino at yahoo.com (Salvador Fandino) Date: Tue, 10 Feb 2009 18:11:50 +0100 Subject: Restrict commands available in an SFTP session In-Reply-To: <906820b60902091624s3d4ebb5cv45804c33b984f3d1@mail.gmail.com> References: <906820b60902091624s3d4ebb5cv45804c33b984f3d1@mail.gmail.com> Message-ID: Jason Dickerson wrote: > I am currently running OpenSSH 4.3. I would like to restrict the commands > SFTP users can run to a list. For example, "put, get, mput, mget, mkdir, > rmdir, and rm". Is this possible with OpenSSH? I have seen many posts > concerning chroot'ing and the Forced Command option, but none of these > solution address restricting the commands actually available inside the SFTP > subsystem. Any insight would be greatly appreciated. > > Thanks, > > Jason Dickerson The sftp-server application source code is quite simple. It will require a minimal C knowledge to replace the unwanted command handlers with versions that return SSH_FXP_STATUS messages with a SSH_FX_FAILURE code. Modify the source, compile it and install the new application on your server (as /usr/lib/my-sftp-server, for instance) and change the sshd sftp sub-system configuration to use it for all or some users. Cheers, - Salva From adam.spragg at octaltelecom.co.uk Wed Feb 11 05:15:02 2009 From: adam.spragg at octaltelecom.co.uk (Adam Spragg) Date: Tue, 10 Feb 2009 18:15:02 +0000 Subject: sshd_config allows multiple AllowUsers lines? Message-ID: <200902101815.02376.adam.spragg@octaltelecom.co.uk> Hi, I've just been adding a few extra hosts to my sshd_config's AllowUsers, and it's got a bit unwieldy. As far as I can tell from the sshd_config(5) and ssh_config(5) man pages, the *only* way to specify multiple AllowUsers patterns is on a single line, separated by spaces. With more than 6 or 7 patterns it starts wrapping on to multiple lines and gets hard to read, especially as the sshd_config file does not support backslash newline continuation. Searching the mailing list archives for AllowUsers, I came across a message which implies that multiple DenyUsers (which I assume works the same as AllowUsers) lines are permitted[0], and that they are equivalent to a single concatenated DenyUsers line. Further, using multiple AllowUsers directives appears to work. But I can find no mention of this behaviour in the man pages. So, is this guaranteed behaviour, or is it a quirk of the current implementation? Is it possible that future implementations will change this and only use the first AllowUsers directive, or possibly use only the last, or some other behaviour? If it is guaranteed behaviour, is it documented? If so, where? If not, should it be? Thanks, Adam Spragg. [0] http://marc.info/?l=openssh-unix-dev&m=112000646419696&w=2 -- Adam Spragg mailto:adam.spragg at octaltelecom.co.uk Developer Octal Telecom http://www.octaltelecom.co.uk/ It reverses the logical flow of conversation! > Why? > > No. > > > Should I top post? http://www.google.com/search?q=%22top+posting%22 From roger_no_spam at hotmail.com Wed Feb 11 20:05:32 2009 From: roger_no_spam at hotmail.com (Roger No-Spam) Date: Wed, 11 Feb 2009 10:05:32 +0100 Subject: Configure re-keying in sftp server Message-ID: Hello, I'm trying to configure the openssh sftp server to perform re-keying. On the client side I've found the RekeyLimit parameter. But I am unable to find an equivalent for the server side. Is it currently not possible to configure the sftp server to perform re-keying? Or have I overlooked something. -- R _________________________________________________________________ Snygga till dina bilder snabbt, enkelt och gratis med PhotoGallery http://download.live.com/photogallery From luciano at debian.org Thu Feb 12 10:23:12 2009 From: luciano at debian.org (Luciano Bello) Date: Wed, 11 Feb 2009 21:23:12 -0200 Subject: sshd_config allows multiple AllowUsers lines? In-Reply-To: <200902101815.02376.adam.spragg@octaltelecom.co.uk> References: <200902101815.02376.adam.spragg@octaltelecom.co.uk> Message-ID: <200902112123.13035.luciano@debian.org> El Mar 10 Feb 2009, Adam Spragg escribi?: > If it is guaranteed behaviour, is it documented? If so, where? If not, should > it be? I found it in "SSH, the Secure Shell: The Definitive Guide" by Barrett and Silverman, First Edition page 177. It's not official documentation... but there it is. luciano From djm at mindrot.org Thu Feb 12 12:43:12 2009 From: djm at mindrot.org (Damien Miller) Date: Thu, 12 Feb 2009 12:43:12 +1100 (EST) Subject: Configure re-keying in sftp server In-Reply-To: References: Message-ID: On Wed, 11 Feb 2009, Roger No-Spam wrote: > > Hello, > > I'm trying to configure the openssh sftp server to perform re-keying. > On the client side I've found the RekeyLimit parameter. But I am > unable to find an equivalent for the server side. Is it currently not > possible to configure the sftp server to perform re-keying? Or have I > overlooked something. sshd will rekey automatically at bytes limits that are appropriate for the underlying cipher. RekeyLimit on this client is really just there so we can test the rekeying mechanism. -d From miklos at szeredi.hu Fri Feb 13 08:11:41 2009 From: miklos at szeredi.hu (Miklos Szeredi) Date: Thu, 12 Feb 2009 22:11:41 +0100 Subject: [patch] hard link protocol extension for sftp Message-ID: Here's a patch that adds support for the creation of hard links over SFTP. Hard links are not used very often nowdays, but they do still have their uses and this is currently the most often requested improvement for SSHFS. To detect hard links the st_nlink, st_dev and st_ino attributes are usually used. I'll also post patches adding extensions for these and other attributes. Please consider adding these to the OpenSSH sftp-server/client implementations. Comments are welcome. Thanks, Miklos Index: ssh/sftp-client.c =================================================================== --- ssh.orig/sftp-client.c 2009-02-10 14:54:58.000000000 +0100 +++ ssh/sftp-client.c 2009-02-10 15:15:08.000000000 +0100 @@ -63,6 +63,7 @@ struct sftp_conn { #define SFTP_EXT_POSIX_RENAME 0x00000001 #define SFTP_EXT_STATVFS 0x00000002 #define SFTP_EXT_FSTATVFS 0x00000004 +#define SFTP_EXT_LINK 0x00000008 u_int exts; }; @@ -328,10 +329,14 @@ do_init(int fd_in, int fd_out, u_int tra strcmp(value, "2") == 0) { exts |= SFTP_EXT_STATVFS; known = 1; - } if (strcmp(name, "fstatvfs at openssh.com") == 0 && + } else if (strcmp(name, "fstatvfs at openssh.com") == 0 && strcmp(value, "2") == 0) { exts |= SFTP_EXT_FSTATVFS; known = 1; + } else if (strcmp(name, "link at openssh.com") == 0 && + strcmp(value, "1") == 0) { + exts |= SFTP_EXT_LINK; + known = 1; } if (known) { debug2("Server supports extension \"%s\" revision %s", @@ -731,6 +736,39 @@ do_rename(struct sftp_conn *conn, char * newpath, fx2txt(status)); return(status); +} + +int +do_link(struct sftp_conn *conn, char *oldpath, char *newpath) +{ + Buffer msg; + u_int status, id; + + buffer_init(&msg); + + /* Send link request */ + id = conn->msg_id++; + if ((conn->exts & SFTP_EXT_LINK) == 0) { + error("Server does not support link at openssh.com extension"); + return -1; + } + + buffer_put_char(&msg, SSH2_FXP_EXTENDED); + buffer_put_int(&msg, id); + buffer_put_cstring(&msg, "link at openssh.com"); + buffer_put_cstring(&msg, oldpath); + buffer_put_cstring(&msg, newpath); + send_msg(conn->fd_out, &msg); + debug3("Sent message link at openssh.com \"%s\" -> \"%s\"", + oldpath, newpath); + buffer_free(&msg); + + status = get_status(conn->fd_in, id); + if (status != SSH2_FX_OK) + error("Couldn't link file \"%s\" to \"%s\": %s", oldpath, + newpath, fx2txt(status)); + + return(status); } int Index: ssh/sftp-client.h =================================================================== --- ssh.orig/sftp-client.h 2009-02-10 14:54:58.000000000 +0100 +++ ssh/sftp-client.h 2009-02-10 15:15:08.000000000 +0100 @@ -94,6 +94,9 @@ int do_statvfs(struct sftp_conn *, const /* Rename 'oldpath' to 'newpath' */ int do_rename(struct sftp_conn *, char *, char *); +/* Link 'oldpath' to 'newpath' */ +int do_link(struct sftp_conn *, char *, char *); + /* Rename 'oldpath' to 'newpath' */ int do_symlink(struct sftp_conn *, char *, char *); Index: ssh/sftp-server.c =================================================================== --- ssh.orig/sftp-server.c 2009-02-10 14:54:58.000000000 +0100 +++ ssh/sftp-server.c 2009-02-10 15:15:08.000000000 +0100 @@ -523,6 +523,9 @@ process_init(void) /* fstatvfs extension */ buffer_put_cstring(&msg, "fstatvfs at openssh.com"); buffer_put_cstring(&msg, "2"); /* version */ + /* link extension */ + buffer_put_cstring(&msg, "link at openssh.com"); + buffer_put_cstring(&msg, "1"); /* version */ send_msg(&msg); buffer_free(&msg); } @@ -1153,6 +1156,23 @@ process_extended_fstatvfs(u_int32_t id) } static void +process_extended_link(u_int32_t id) +{ + char *oldpath, *newpath; + + oldpath = get_string(NULL); + newpath = get_string(NULL); + debug3("request %u: link", id); + logit("link old \"%s\" new \"%s\"", oldpath, newpath); + if (link(oldpath, newpath) == -1) + send_status(id, errno_to_portable(errno)); + else + send_status(id, SSH2_FX_OK); + xfree(oldpath); + xfree(newpath); +} + +static void process_extended(void) { u_int32_t id; @@ -1166,6 +1186,8 @@ process_extended(void) process_extended_statvfs(id); else if (strcmp(request, "fstatvfs at openssh.com") == 0) process_extended_fstatvfs(id); + else if (strcmp(request, "link at openssh.com") == 0) + process_extended_link(id); else send_status(id, SSH2_FX_OP_UNSUPPORTED); /* MUST */ xfree(request); Index: ssh/sftp.c =================================================================== --- ssh.orig/sftp.c 2009-02-10 14:54:58.000000000 +0100 +++ ssh/sftp.c 2009-02-10 15:15:19.000000000 +0100 @@ -98,6 +98,7 @@ int remote_glob(struct sftp_conn *, cons #define I_GET 5 #define I_HELP 6 #define I_LCHDIR 7 +#define I_LINK 25 #define I_LLS 8 #define I_LMKDIR 9 #define I_LPWD 10 @@ -135,6 +136,7 @@ static const struct CMD cmds[] = { { "help", I_HELP }, { "lcd", I_LCHDIR }, { "lchdir", I_LCHDIR }, + { "link", I_LINK }, { "lls", I_LLS }, { "lmkdir", I_LMKDIR }, { "ln", I_SYMLINK }, @@ -198,6 +200,7 @@ help(void) "get [-P] remote-path [local-path] Download file\n" "help Display this help text\n" "lcd path Change local directory to 'path'\n" + "link oldpath newpath Create hard link to remote file\n" "lls [ls-options [path]] Display local directory listing\n" "lmkdir path Create local directory\n" "ln oldpath newpath Symlink remote file\n" @@ -1111,6 +1114,7 @@ parse_args(const char **cpp, int *pflag, } break; case I_RENAME: + case I_LINK: case I_SYMLINK: if (argc - optidx < 2) { error("You must specify two paths after a %s " @@ -1250,6 +1254,11 @@ parse_dispatch_command(struct sftp_conn path2 = make_absolute(path2, *pwd); err = do_rename(conn, path1, path2); break; + case I_LINK: + path1 = make_absolute(path1, *pwd); + path2 = make_absolute(path2, *pwd); + err = do_link(conn, path1, path2); + break; case I_SYMLINK: path2 = make_absolute(path2, *pwd); err = do_symlink(conn, path1, path2); Index: ssh/PROTOCOL =================================================================== --- ssh.orig/PROTOCOL 2009-02-10 14:54:58.000000000 +0100 +++ ssh/PROTOCOL 2009-02-10 15:22:05.000000000 +0100 @@ -240,4 +240,20 @@ The values of the f_flag bitmask are as Both the "statvfs at openssh.com" and "fstatvfs at openssh.com" extensions are advertised in the SSH_FXP_VERSION hello with version "2". +10. sftp: Extension request "link at openssh.com" + +This request is for creating a hard link to a regular file. This +request is implemented as a SSH_FXP_EXTENDED request with the +following format: + + uint32 id + string "link at openssh.com" + string oldpath + string newpath + +On receiving this request the server will perform the operation +link(oldpath, newpath) and will respond with a SSH_FXP_STATUS message. +This extension is advertised in the SSH_FXP_VERSION hello with version +"1". + $OpenBSD: PROTOCOL,v 1.11 2008/07/05 05:16:01 djm Exp $ From miklos at szeredi.hu Fri Feb 13 08:25:35 2009 From: miklos at szeredi.hu (Miklos Szeredi) Date: Thu, 12 Feb 2009 22:25:35 +0100 Subject: [patch 2/3] add attribute configuration message In-Reply-To: (message from Miklos Szeredi on Thu, 12 Feb 2009 22:19:03 +0100) References: Message-ID: This patch adds a new extended request with which the client can request which attributes it wants to receive. By default only the basic attributes are transferred, but the client can request that any subset of the basic or extra attributes to be sent. Attributes can be selected separately for STAT and READDIR requests. Also there's a flag to turn off the generation of long names in READDIR requests. The server also sends the attributes it can actually support in the attribute configuration reply so the client may make decisions based on the server's capabilities. Index: ssh/sftp-server.c =================================================================== --- ssh.orig/sftp-server.c 2009-02-12 14:11:30.000000000 +0100 +++ ssh/sftp-server.c 2009-02-12 14:37:39.000000000 +0100 @@ -61,6 +61,45 @@ Buffer oqueue; /* Version of client */ int version; +/* Attributes which this implementation can send */ +#define SUPPORTED_ATTR ( \ + SSH2_FILEXFER_ATTR_SIZE | \ + SSH2_FILEXFER_ATTR_UIDGID | \ + SSH2_FILEXFER_ATTR_PERMISSIONS | \ + SSH2_FILEXFER_ATTR_ACMODTIME \ + ) + +/* Extra attributes which this implementation can send */ +#define SUPPORTED_EXT_ATTR ( \ + SSH2_FXE_EXTATTR_DEV | \ + SSH2_FXE_EXTATTR_INO | \ + SSH2_FXE_EXTATTR_NLINK | \ + SSH2_FXE_EXTATTR_RDEV | \ + SSH2_FXE_EXTATTR_BLKSIZE | \ + SSH2_FXE_EXTATTR_BLOCKS | \ + SSH2_FXE_EXTATTR_ATIME | \ + SSH2_FXE_EXTATTR_ATIMENSEC | \ + SSH2_FXE_EXTATTR_MTIME | \ + SSH2_FXE_EXTATTR_MTIMENSEC | \ + SSH2_FXE_EXTATTR_CTIME | \ + SSH2_FXE_EXTATTR_CTIMENSEC \ + ) + +/* Attributes to send in the stat reply */ +u_int stat_attr_mask = SUPPORTED_ATTR; + +/* Extra attributes to send in the stat reply */ +u_int stat_ext_attr_mask = 0; + +/* Attributes to send in the readdir reply */ +u_int dir_attr_mask = SUPPORTED_ATTR; + +/* Extra attributes to send in the readdir reply */ +u_int dir_ext_attr_mask = 0; + +/* If false, send empty long name in the readdir reply */ +int dir_send_long_name = 1; + /* portable attributes, etc. */ typedef struct Stat Stat; @@ -502,6 +541,28 @@ send_statvfs(u_int32_t id, struct statvf buffer_free(&msg); } +static void +send_attrconfig_reply(u_int32_t id) +{ + Buffer msg; + int flags = 0; + + /* Send the actual value of the masks */ + if (!dir_send_long_name) + flags |= SSH2_FXE_ATTRCONFIG_NOLONGNAME; + + buffer_init(&msg); + buffer_put_char(&msg, SSH2_FXP_EXTENDED_REPLY); + buffer_put_int(&msg, id); + buffer_put_int(&msg, flags); + buffer_put_int(&msg, stat_attr_mask); + buffer_put_int(&msg, stat_ext_attr_mask); + buffer_put_int(&msg, dir_attr_mask); + buffer_put_int(&msg, dir_ext_attr_mask); + send_msg(&msg); + buffer_free(&msg); +} + /* parse incoming */ static void @@ -526,6 +587,9 @@ process_init(void) /* link extension */ buffer_put_cstring(&msg, "link at openssh.com"); buffer_put_cstring(&msg, "1"); /* version */ + /* attrconfig extension */ + buffer_put_cstring(&msg, "attrconfig at openssh.com"); + buffer_put_cstring(&msg, "1"); /* version */ send_msg(&msg); buffer_free(&msg); } @@ -677,6 +741,8 @@ process_do_stat(int do_lstat) status = errno_to_portable(errno); } else { stat_to_attrib(&st, &a); + a.flags &= stat_attr_mask; + a.ext_flags &= stat_ext_attr_mask; send_attrib(id, &a); status = SSH2_FX_OK; } @@ -716,6 +782,8 @@ process_fstat(void) status = errno_to_portable(errno); } else { stat_to_attrib(&st, &a); + a.flags &= stat_attr_mask; + a.ext_flags &= stat_ext_attr_mask; send_attrib(id, &a); status = SSH2_FX_OK; } @@ -891,6 +959,8 @@ process_readdir(void) stats = xcalloc(nstats, sizeof(Stat)); while ((dp = readdir(dirp)) != NULL) { + char *long_name; + if (count >= nstats) { nstats *= 2; stats = xrealloc(stats, nstats, sizeof(Stat)); @@ -901,8 +971,16 @@ process_readdir(void) if (lstat(pathname, &st) < 0) continue; stat_to_attrib(&st, &(stats[count].attrib)); + + if (dir_send_long_name) + long_name = ls_file(dp->d_name, &st, 0); + else + long_name = xstrdup(""); + + stats[count].attrib.flags &= dir_attr_mask; + stats[count].attrib.ext_flags &= dir_ext_attr_mask; stats[count].name = xstrdup(dp->d_name); - stats[count].long_name = ls_file(dp->d_name, &st, 0); + stats[count].long_name = long_name; count++; /* send up to 100 entries in one message */ /* XXX check packet size instead */ @@ -1173,6 +1251,33 @@ process_extended_link(u_int32_t id) } static void +process_extended_attrconfig(u_int32_t id) +{ + u_int flags; + u_int mask; + + flags = get_int(); + if (flags & SSH2_FXE_ATTRCONFIG_NOLONGNAME) + dir_send_long_name = 0; + else + dir_send_long_name = 1; + + mask = get_int(); + stat_attr_mask = mask & SUPPORTED_ATTR; + mask = get_int(); + stat_ext_attr_mask = mask & SUPPORTED_EXT_ATTR; + mask = get_int(); + dir_attr_mask = mask & SUPPORTED_ATTR; + mask = get_int(); + dir_ext_attr_mask = mask & SUPPORTED_EXT_ATTR; + + debug3("request %u: attrconfig", id); + + send_attrconfig_reply(id); +} + + +static void process_extended(void) { u_int32_t id; @@ -1188,6 +1293,8 @@ process_extended(void) process_extended_fstatvfs(id); else if (strcmp(request, "link at openssh.com") == 0) process_extended_link(id); + else if (strcmp(request, "attrconfig at openssh.com") == 0) + process_extended_attrconfig(id); else send_status(id, SSH2_FX_OP_UNSUPPORTED); /* MUST */ xfree(request); Index: ssh/sftp.h =================================================================== --- ssh.orig/sftp.h 2009-02-12 14:11:31.000000000 +0100 +++ ssh/sftp.h 2009-02-12 14:15:44.000000000 +0100 @@ -97,6 +97,9 @@ #define SSH2_FXE_EXTATTR_CTIME 0x00000400 #define SSH2_FXE_EXTATTR_CTIMENSEC 0x00000800 +/* attrconfig at openssh.com flags */ +#define SSH2_FXE_ATTRCONFIG_NOLONGNAME 0x00000001 + /* status messages */ #define SSH2_FX_OK 0 #define SSH2_FX_EOF 1 From miklos at szeredi.hu Fri Feb 13 08:28:14 2009 From: miklos at szeredi.hu (Miklos Szeredi) Date: Thu, 12 Feb 2009 22:28:14 +0100 Subject: [patch 3/3] optimize attribute sending In-Reply-To: (message from Miklos Szeredi on Thu, 12 Feb 2009 22:19:03 +0100) References: Message-ID: This patch turns off sending unnecessary attributes: - the nanosecond part of timestamps if they are zero - the 32bit atime and mtime if the 64bit atime/mtime are sent Index: ssh/sftp-common.c =================================================================== --- ssh.orig/sftp-common.c 2009-02-12 14:11:31.000000000 +0100 +++ ssh/sftp-common.c 2009-02-12 15:54:13.000000000 +0100 @@ -87,12 +87,18 @@ stat_to_attrib(const struct stat *st, At a->mtime = st->st_mtime; a->ext_flags |= SSH2_FXE_EXTATTR_CTIME; a->ctime = st->st_ctime; - a->ext_flags |= SSH2_FXE_EXTATTR_ATIMENSEC; - a->atimensec = st->st_atimensec; - a->ext_flags |= SSH2_FXE_EXTATTR_MTIMENSEC; - a->mtimensec = st->st_mtimensec; - a->ext_flags |= SSH2_FXE_EXTATTR_CTIMENSEC; - a->ctimensec = st->st_ctimensec; + if (st->st_atimensec) { + a->ext_flags |= SSH2_FXE_EXTATTR_ATIMENSEC; + a->atimensec = st->st_atimensec; + } + if (st->st_mtimensec) { + a->ext_flags |= SSH2_FXE_EXTATTR_MTIMENSEC; + a->mtimensec = st->st_mtimensec; + } + if (st->st_ctimensec) { + a->ext_flags |= SSH2_FXE_EXTATTR_CTIMENSEC; + a->ctimensec = st->st_ctimensec; + } a->ext_flags |= SSH2_FXE_EXTATTR_DEV; a->dev = st->st_dev; a->ext_flags |= SSH2_FXE_EXTATTR_INO; Index: ssh/sftp-server.c =================================================================== --- ssh.orig/sftp-server.c 2009-02-12 14:37:39.000000000 +0100 +++ ssh/sftp-server.c 2009-02-12 16:00:10.000000000 +0100 @@ -1271,6 +1271,13 @@ process_extended_attrconfig(u_int32_t id mask = get_int(); dir_ext_attr_mask = mask & SUPPORTED_EXT_ATTR; + if ((stat_ext_attr_mask & SSH2_FXE_EXTATTR_ATIME) && + (stat_ext_attr_mask & SSH2_FXE_EXTATTR_MTIME)) + stat_attr_mask &= ~SSH2_FILEXFER_ATTR_ACMODTIME; + if ((dir_ext_attr_mask & SSH2_FXE_EXTATTR_ATIME) && + (dir_ext_attr_mask & SSH2_FXE_EXTATTR_MTIME)) + dir_attr_mask &= ~SSH2_FILEXFER_ATTR_ACMODTIME; + debug3("request %u: attrconfig", id); send_attrconfig_reply(id); From miklos at szeredi.hu Fri Feb 13 08:19:03 2009 From: miklos at szeredi.hu (Miklos Szeredi) Date: Thu, 12 Feb 2009 22:19:03 +0100 Subject: [patch 1/3] add protocol extension to ATTR message Message-ID: This patch adds all the missing commonly used UNIX attributes: st_dev, st_ino, st_nlink, st_rdev, st_blocks, st_blksize, st_ctime. In addition it extends st_atime and st_mtime to 64bits, and adds nanosecond resolution to all three timestamps. This is implemented as an extension to the ATTR message. This patch alone is sufficient for SSHFS to be able to use these attributes. The following two patches optimize the bandwidth use for this extension. Index: ssh/sftp-common.c =================================================================== --- ssh.orig/sftp-common.c 2009-02-12 14:11:15.000000000 +0100 +++ ssh/sftp-common.c 2009-02-12 14:11:31.000000000 +0100 @@ -47,12 +47,23 @@ void attrib_clear(Attrib *a) { a->flags = 0; + a->ext_flags = 0; + a->dev = 0; + a->ino = 0; + a->rdev = 0; a->size = 0; + a->blocks = 0; + a->blksize = 0; a->uid = 0; a->gid = 0; a->perm = 0; + a->nlink = 0; a->atime = 0; a->mtime = 0; + a->ctime = 0; + a->atimensec = 0; + a->mtimensec = 0; + a->ctimensec = 0; } /* Convert from struct stat to filexfer attribs */ @@ -61,6 +72,7 @@ stat_to_attrib(const struct stat *st, At { attrib_clear(a); a->flags = 0; + a->ext_flags = 0; a->flags |= SSH2_FILEXFER_ATTR_SIZE; a->size = st->st_size; a->flags |= SSH2_FILEXFER_ATTR_UIDGID; @@ -69,8 +81,32 @@ stat_to_attrib(const struct stat *st, At a->flags |= SSH2_FILEXFER_ATTR_PERMISSIONS; a->perm = st->st_mode; a->flags |= SSH2_FILEXFER_ATTR_ACMODTIME; + a->ext_flags |= SSH2_FXE_EXTATTR_ATIME; + a->ext_flags |= SSH2_FXE_EXTATTR_MTIME; a->atime = st->st_atime; a->mtime = st->st_mtime; + a->ext_flags |= SSH2_FXE_EXTATTR_CTIME; + a->ctime = st->st_ctime; + a->ext_flags |= SSH2_FXE_EXTATTR_ATIMENSEC; + a->atimensec = st->st_atimensec; + a->ext_flags |= SSH2_FXE_EXTATTR_MTIMENSEC; + a->mtimensec = st->st_mtimensec; + a->ext_flags |= SSH2_FXE_EXTATTR_CTIMENSEC; + a->ctimensec = st->st_ctimensec; + a->ext_flags |= SSH2_FXE_EXTATTR_DEV; + a->dev = st->st_dev; + a->ext_flags |= SSH2_FXE_EXTATTR_INO; + a->ino = st->st_ino; + a->ext_flags |= SSH2_FXE_EXTATTR_NLINK; + a->nlink = st->st_nlink; + if (S_ISCHR(st->st_mode) || S_ISBLK(st->st_mode)) { + a->ext_flags |= SSH2_FXE_EXTATTR_RDEV; + a->rdev = st->st_rdev; + } + a->ext_flags |= SSH2_FXE_EXTATTR_BLKSIZE; + a->blksize = st->st_blksize; + a->ext_flags |= SSH2_FXE_EXTATTR_BLOCKS; + a->blocks = st->st_blocks; } /* Convert from filexfer attribs to struct stat */ @@ -87,10 +123,62 @@ attrib_to_stat(const Attrib *a, struct s } if (a->flags & SSH2_FILEXFER_ATTR_PERMISSIONS) st->st_mode = a->perm; - if (a->flags & SSH2_FILEXFER_ATTR_ACMODTIME) { + if ((a->flags & SSH2_FILEXFER_ATTR_ACMODTIME) || + (a->ext_flags & SSH2_FXE_EXTATTR_ATIME)) st->st_atime = a->atime; + if ((a->flags & SSH2_FILEXFER_ATTR_ACMODTIME) || + (a->ext_flags & SSH2_FXE_EXTATTR_MTIME)) st->st_mtime = a->mtime; - } + if (a->ext_flags & SSH2_FXE_EXTATTR_CTIME) + st->st_ctime = a->ctime; + if (a->ext_flags & SSH2_FXE_EXTATTR_ATIMENSEC) + st->st_atimensec = a->atimensec; + if (a->ext_flags & SSH2_FXE_EXTATTR_MTIMENSEC) + st->st_mtimensec = a->mtimensec; + if (a->ext_flags & SSH2_FXE_EXTATTR_CTIMENSEC) + st->st_ctimensec = a->ctimensec; + if (a->ext_flags & SSH2_FXE_EXTATTR_DEV) + st->st_dev = a->dev; + if (a->ext_flags & SSH2_FXE_EXTATTR_INO) + st->st_ino = a->ino; + if (a->ext_flags & SSH2_FXE_EXTATTR_NLINK) + st->st_nlink = a->nlink; + if (a->ext_flags & SSH2_FXE_EXTATTR_RDEV) + st->st_rdev = a->rdev; + if (a->ext_flags & SSH2_FXE_EXTATTR_BLKSIZE) + st->st_blksize = a->blksize; + if (a->ext_flags & SSH2_FXE_EXTATTR_BLOCKS) + st->st_blocks = a->blocks; +} + +static void +decode_extra_attrib(Buffer *b, Attrib *a) +{ + a->ext_flags = buffer_get_int(b); + if (a->ext_flags & SSH2_FXE_EXTATTR_DEV) + a->dev = buffer_get_int64(b); + if (a->ext_flags & SSH2_FXE_EXTATTR_INO) + a->ino = buffer_get_int64(b); + if (a->ext_flags & SSH2_FXE_EXTATTR_NLINK) + a->nlink = buffer_get_int(b); + if (a->ext_flags & SSH2_FXE_EXTATTR_RDEV) + a->rdev = buffer_get_int64(b); + if (a->ext_flags & SSH2_FXE_EXTATTR_BLKSIZE) + a->blksize = buffer_get_int(b); + if (a->ext_flags & SSH2_FXE_EXTATTR_BLOCKS) + a->blocks = buffer_get_int64(b); + if (a->ext_flags & SSH2_FXE_EXTATTR_ATIME) + a->atime = buffer_get_int64(b); + if (a->ext_flags & SSH2_FXE_EXTATTR_ATIMENSEC) + a->atimensec = buffer_get_int(b); + if (a->ext_flags & SSH2_FXE_EXTATTR_MTIME) + a->mtime = buffer_get_int64(b); + if (a->ext_flags & SSH2_FXE_EXTATTR_MTIMENSEC) + a->mtimensec = buffer_get_int(b); + if (a->ext_flags & SSH2_FXE_EXTATTR_CTIME) + a->ctime = buffer_get_int64(b); + if (a->ext_flags & SSH2_FXE_EXTATTR_CTIMENSEC) + a->ctimensec = buffer_get_int(b); } /* Decode attributes in buffer */ @@ -115,26 +203,70 @@ decode_attrib(Buffer *b) } /* vendor-specific extensions */ if (a.flags & SSH2_FILEXFER_ATTR_EXTENDED) { - char *type, *data; + char *type; + void *data; int i, count; + u_int datalen; count = buffer_get_int(b); for (i = 0; i < count; i++) { type = buffer_get_string(b, NULL); - data = buffer_get_string(b, NULL); + data = buffer_get_string_ptr(b, &datalen); debug3("Got file attribute \"%s\"", type); + if (strcmp(type, "extattr at openssh.com") == 0) { + Buffer ext; + + buffer_init(&ext); + buffer_append(&ext, data, datalen); + decode_extra_attrib(&ext, &a); + buffer_free(&ext); + } xfree(type); - xfree(data); } } return &a; } +static void +encode_extra_attrib(Buffer *b, const Attrib *a) +{ + buffer_put_int(b, a->ext_flags); + if (a->ext_flags & SSH2_FXE_EXTATTR_DEV) + buffer_put_int64(b, a->dev); + if (a->ext_flags & SSH2_FXE_EXTATTR_INO) + buffer_put_int64(b, a->ino); + if (a->ext_flags & SSH2_FXE_EXTATTR_NLINK) + buffer_put_int(b, a->nlink); + if (a->ext_flags & SSH2_FXE_EXTATTR_RDEV) + buffer_put_int64(b, a->rdev); + if (a->ext_flags & SSH2_FXE_EXTATTR_BLKSIZE) + buffer_put_int(b, a->blksize); + if (a->ext_flags & SSH2_FXE_EXTATTR_BLOCKS) + buffer_put_int64(b, a->blocks); + if (a->ext_flags & SSH2_FXE_EXTATTR_ATIME) + buffer_put_int64(b, a->atime); + if (a->ext_flags & SSH2_FXE_EXTATTR_ATIMENSEC) + buffer_put_int(b, a->atimensec); + if (a->ext_flags & SSH2_FXE_EXTATTR_MTIME) + buffer_put_int64(b, a->mtime); + if (a->ext_flags & SSH2_FXE_EXTATTR_MTIMENSEC) + buffer_put_int(b, a->mtimensec); + if (a->ext_flags & SSH2_FXE_EXTATTR_CTIME) + buffer_put_int64(b, a->ctime); + if (a->ext_flags & SSH2_FXE_EXTATTR_CTIMENSEC) + buffer_put_int(b, a->ctimensec); +} + /* Encode attributes to buffer */ void encode_attrib(Buffer *b, const Attrib *a) { - buffer_put_int(b, a->flags); + int flags = a->flags; + + if (a->ext_flags != 0) + flags |= SSH2_FILEXFER_ATTR_EXTENDED; + + buffer_put_int(b, flags); if (a->flags & SSH2_FILEXFER_ATTR_SIZE) buffer_put_int64(b, a->size); if (a->flags & SSH2_FILEXFER_ATTR_UIDGID) { @@ -147,6 +279,19 @@ encode_attrib(Buffer *b, const Attrib *a buffer_put_int(b, a->atime); buffer_put_int(b, a->mtime); } + + if (flags & SSH2_FILEXFER_ATTR_EXTENDED) { + u_int ext_count = 1; + Buffer ext; + + buffer_put_int(b, ext_count); + buffer_put_cstring(b, "extattr at openssh.com"); + + buffer_init(&ext); + encode_extra_attrib(&ext, a); + buffer_put_string(b, buffer_ptr(&ext), buffer_len(&ext)); + buffer_free(&ext); + } } /* Convert from SSH2_FX_ status to text error message */ Index: ssh/sftp-common.h =================================================================== --- ssh.orig/sftp-common.h 2009-02-12 14:11:15.000000000 +0100 +++ ssh/sftp-common.h 2009-02-12 14:11:31.000000000 +0100 @@ -33,12 +33,23 @@ typedef struct Attrib Attrib; /* File attributes */ struct Attrib { u_int32_t flags; + u_int32_t ext_flags; + u_int64_t dev; + u_int64_t ino; + u_int64_t rdev; u_int64_t size; + u_int64_t blocks; + u_int32_t blksize; u_int32_t uid; u_int32_t gid; u_int32_t perm; - u_int32_t atime; - u_int32_t mtime; + u_int32_t nlink; + u_int64_t atime; + u_int64_t mtime; + u_int64_t ctime; + u_int32_t atimensec; + u_int32_t mtimensec; + u_int32_t ctimensec; }; void attrib_clear(Attrib *); Index: ssh/sftp.h =================================================================== --- ssh.orig/sftp.h 2009-02-12 14:11:15.000000000 +0100 +++ ssh/sftp.h 2009-02-12 14:11:31.000000000 +0100 @@ -83,6 +83,20 @@ #define SSH2_FXE_STATVFS_ST_RDONLY 0x00000001 #define SSH2_FXE_STATVFS_ST_NOSUID 0x00000002 +/* extattr at openssh.com extra attribute flags */ +#define SSH2_FXE_EXTATTR_DEV 0x00000001 +#define SSH2_FXE_EXTATTR_INO 0x00000002 +#define SSH2_FXE_EXTATTR_NLINK 0x00000004 +#define SSH2_FXE_EXTATTR_RDEV 0x00000008 +#define SSH2_FXE_EXTATTR_BLKSIZE 0x00000010 +#define SSH2_FXE_EXTATTR_BLOCKS 0x00000020 +#define SSH2_FXE_EXTATTR_ATIME 0x00000040 +#define SSH2_FXE_EXTATTR_ATIMENSEC 0x00000080 +#define SSH2_FXE_EXTATTR_MTIME 0x00000100 +#define SSH2_FXE_EXTATTR_MTIMENSEC 0x00000200 +#define SSH2_FXE_EXTATTR_CTIME 0x00000400 +#define SSH2_FXE_EXTATTR_CTIMENSEC 0x00000800 + /* status messages */ #define SSH2_FX_OK 0 #define SSH2_FX_EOF 1 Index: ssh/sftp-client.c =================================================================== --- ssh.orig/sftp-client.c 2009-02-12 14:11:30.000000000 +0100 +++ ssh/sftp-client.c 2009-02-12 14:11:37.000000000 +0100 @@ -1201,6 +1201,7 @@ do_upload(struct sftp_conn *conn, char * } stat_to_attrib(&sb, &a); + a.ext_flags = 0; a.flags &= ~SSH2_FILEXFER_ATTR_SIZE; a.flags &= ~SSH2_FILEXFER_ATTR_UIDGID; a.perm &= 0777; From djm at mindrot.org Fri Feb 13 09:34:35 2009 From: djm at mindrot.org (Damien Miller) Date: Fri, 13 Feb 2009 09:34:35 +1100 (EST) Subject: [patch] hard link protocol extension for sftp In-Reply-To: References: Message-ID: On Thu, 12 Feb 2009, Miklos Szeredi wrote: > Here's a patch that adds support for the creation of hard links over > SFTP. > > Hard links are not used very often nowdays, but they do still have > their uses and this is currently the most often requested improvement > for SSHFS. > > To detect hard links the st_nlink, st_dev and st_ino attributes are > usually used. I'll also post patches adding extensions for these and > other attributes. > > Please consider adding these to the OpenSSH sftp-server/client > implementations. Comments are welcome. Nice - could you please post this on https://bugzilla.mindrot.org/ -d From djm at mindrot.org Fri Feb 13 09:38:50 2009 From: djm at mindrot.org (Damien Miller) Date: Fri, 13 Feb 2009 09:38:50 +1100 (EST) Subject: [patch 2/3] add attribute configuration message In-Reply-To: References: Message-ID: On Thu, 12 Feb 2009, Miklos Szeredi wrote: > This patch adds a new extended request with which the client can > request which attributes it wants to receive. By default only the > basic attributes are transferred, but the client can request that any > subset of the basic or extra attributes to be sent. Attributes can be > selected separately for STAT and READDIR requests. > > Also there's a flag to turn off the generation of long names in > READDIR requests. > > The server also sends the attributes it can actually support in the > attribute configuration reply so the client may make decisions based > on the server's capabilities. Very nice! Could you please attach this to a bug on https://bugzilla.mindrot.org/ too? attrconfig would make it much nicer to support named users and groups semi-efficently. -d From miklos at szeredi.hu Fri Feb 13 22:15:00 2009 From: miklos at szeredi.hu (Miklos Szeredi) Date: Fri, 13 Feb 2009 12:15:00 +0100 Subject: [patch] hard link protocol extension for sftp In-Reply-To: (message from Damien Miller on Fri, 13 Feb 2009 09:34:35 +1100 (EST)) References: Message-ID: On Fri, 13 Feb 2009, Damien Miller wrote: > Nice - could you please post this on https://bugzilla.mindrot.org/ > OK, created a bug and attached all four patches: https://bugzilla.mindrot.org/show_bug.cgi?id=1555 Thanks, Miklos From jquest07 at gmail.com Sat Feb 14 04:42:28 2009 From: jquest07 at gmail.com (John C. Hardt) Date: Fri, 13 Feb 2009 10:42:28 -0700 Subject: when to display a banner Message-ID: <4995B104.5050600@gmail.com> i want to be able to suppress the banner from the client side (ssh/slogin/scp/sftp) but i don't see a way to do it cleanly. for example, if there were a -B flag that suppressed the banner that would be alright. i did try -q, but that suppresses all stderr, which is unacceptable since i do want to see the error output when ssh fails to know why it failed. another idea would be to have -q suppress the banner and -qq suppress all warning and diagnostic messages but changing the behavior or an existing flag might be a bad idea. the main reason for bringing this up is that i'd like to be able to turn on a banner in sshd_config on the server side without breaking a multitude of existing automated scripts that will barf when they start getting unexpected output in the form of a banner statement. it is true that if a flag were provided to suppress the banner i would have to touch each script to add the flag as well as ask end-users to update any scripts they might be using, but that's much cleaner than updating each script to be smart enough to try and figure out what output is part of the banner statement that needs to be ignored. an idea i had that would allow turning on the banner that would not require changing any of the automated scripts to either add a flag or ignore the banner statement was the following simple code change. this is from openssh-5.1p1: *** sshconnect2.c.orig Thu Jul 17 03:15:43 2008 --- sshconnect2.c Fri Feb 13 09:19:22 2009 *************** *** 377,386 **** --- 377,387 ---- void input_userauth_banner(int type, u_int32_t seq, void *ctxt) { char *msg, *raw, *lang; u_int len; debug3("input_userauth_banner"); + if (!isatty(1) || !isatty(2)) return; raw = packet_get_string(&len); lang = packet_get_string(NULL); if (options.log_level >= SYSLOG_LEVEL_INFO) { what i think this will accomplish is that if one of the ssh client programs is called normally by a user, the banner will be displayed. if however either stdout or stderr is redirected like you would do in an automated script, the banner will be suppressed. can anyone think of any unintended side-effects of the above change? i'm new to this list. how are requests for enhancement handled? i figured discussion would at least be the first step so that's what i'm attempting to do with this email. -john From jquest07 at gmail.com Sat Feb 14 08:08:36 2009 From: jquest07 at gmail.com (John Hardt) Date: Fri, 13 Feb 2009 14:08:36 -0700 Subject: when to display a banner In-Reply-To: <20090213203657.GA10328@linux55.nas.nasa.gov> References: <4995B104.5050600@gmail.com> <20090213203657.GA10328@linux55.nas.nasa.gov> Message-ID: <3c468df00902131308t567331c3l61b62cefe70c8876@mail.gmail.com> On Fri, Feb 13, 2009 at 1:36 PM, Iain Morgan wrote: > On Fri, Feb 13, 2009 at 10:42:28 -0700, John C. Hardt wrote: >> i want to be able to suppress the banner from the client side >> (ssh/slogin/scp/sftp) but i don't see a way to do it cleanly. for >> example, if there were a -B flag that suppressed the banner that would >> be alright. i did try -q, but that suppresses all stderr, which is >> unacceptable since i do want to see the error output when ssh fails to >> know why it failed. another idea would be to have -q suppress the >> banner and -qq suppress all warning and diagnostic messages but >> changing the behavior or an existing flag might be a bad idea. > > -oLogLevel=error i tried that, and tried -oLogLevel=fatal, and the banner still displays. -john From imorgan at nas.nasa.gov Sat Feb 14 07:36:57 2009 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Fri, 13 Feb 2009 12:36:57 -0800 Subject: when to display a banner In-Reply-To: <4995B104.5050600@gmail.com> References: <4995B104.5050600@gmail.com> Message-ID: <20090213203657.GA10328@linux55.nas.nasa.gov> On Fri, Feb 13, 2009 at 10:42:28 -0700, John C. Hardt wrote: > i want to be able to suppress the banner from the client side > (ssh/slogin/scp/sftp) but i don't see a way to do it cleanly. for > example, if there were a -B flag that suppressed the banner that would > be alright. i did try -q, but that suppresses all stderr, which is > unacceptable since i do want to see the error output when ssh fails to > know why it failed. another idea would be to have -q suppress the > banner and -qq suppress all warning and diagnostic messages but > changing the behavior or an existing flag might be a bad idea. -oLogLevel=error -- Iain Morgan From imorgan at nas.nasa.gov Sat Feb 14 09:14:09 2009 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Fri, 13 Feb 2009 14:14:09 -0800 Subject: when to display a banner In-Reply-To: <3c468df00902131308t567331c3l61b62cefe70c8876@mail.gmail.com> References: <4995B104.5050600@gmail.com> <20090213203657.GA10328@linux55.nas.nasa.gov> <3c468df00902131308t567331c3l61b62cefe70c8876@mail.gmail.com> Message-ID: <20090213221409.GA11302@linux55.nas.nasa.gov> On Fri, Feb 13, 2009 at 14:08:36 -0700, John Hardt wrote: > On Fri, Feb 13, 2009 at 1:36 PM, Iain Morgan wrote: > > On Fri, Feb 13, 2009 at 10:42:28 -0700, John C. Hardt wrote: > >> i want to be able to suppress the banner from the client side > >> (ssh/slogin/scp/sftp) but i don't see a way to do it cleanly. for > >> example, if there were a -B flag that suppressed the banner that would > >> be alright. i did try -q, but that suppresses all stderr, which is > >> unacceptable since i do want to see the error output when ssh fails to > >> know why it failed. another idea would be to have -q suppress the > >> banner and -qq suppress all warning and diagnostic messages but > >> changing the behavior or an existing flag might be a bad idea. > > > > -oLogLevel=error > > i tried that, and tried -oLogLevel=fatal, and the banner still displays. > -john What client version are you using? For some versions the banner was only suppressed for LogLevel=quiet, but LogLevel=error has done the right thing with regards to the banner for dome time now. -- Iain Morgan From jquest07 at gmail.com Sat Feb 14 09:41:55 2009 From: jquest07 at gmail.com (John Hardt) Date: Fri, 13 Feb 2009 15:41:55 -0700 Subject: when to display a banner In-Reply-To: <20090213221409.GA11302@linux55.nas.nasa.gov> References: <4995B104.5050600@gmail.com> <20090213203657.GA10328@linux55.nas.nasa.gov> <3c468df00902131308t567331c3l61b62cefe70c8876@mail.gmail.com> <20090213221409.GA11302@linux55.nas.nasa.gov> Message-ID: <3c468df00902131441v18098952obae6fb6afb406753@mail.gmail.com> On Fri, Feb 13, 2009 at 3:14 PM, Iain Morgan wrote: > On Fri, Feb 13, 2009 at 14:08:36 -0700, John Hardt wrote: >> On Fri, Feb 13, 2009 at 1:36 PM, Iain Morgan wrote: >> > On Fri, Feb 13, 2009 at 10:42:28 -0700, John C. Hardt wrote: >> >> i want to be able to suppress the banner from the client side >> >> (ssh/slogin/scp/sftp) but i don't see a way to do it cleanly. for >> >> example, if there were a -B flag that suppressed the banner that would >> >> be alright. i did try -q, but that suppresses all stderr, which is >> >> unacceptable since i do want to see the error output when ssh fails to >> >> know why it failed. another idea would be to have -q suppress the >> >> banner and -qq suppress all warning and diagnostic messages but >> >> changing the behavior or an existing flag might be a bad idea. >> > >> > -oLogLevel=error >> >> i tried that, and tried -oLogLevel=fatal, and the banner still displays. >> -john > > What client version are you using? For some versions the banner was only > suppressed for LogLevel=quiet, but LogLevel=error has done the right > thing with regards to the banner for dome time now. i didn't realize i was using the openssh-4.6p1 client when trying this since i had both versions around while we move to the new version. when i tried openssh-5.1p1, it worked as you say, and problem solved. thanks for your help! -john From brian at interlinx.bc.ca Sat Feb 14 10:38:36 2009 From: brian at interlinx.bc.ca (Brian J. Murrell) Date: Fri, 13 Feb 2009 23:38:36 +0000 (UTC) Subject: forward the dbus session? Message-ID: Am I crazy for thinking about forwarding the DBUS session over an ssh connection much like the X session is forwarded? I've proven the concept with socat (to use the unix socket that dbus normally listens on rather than reconfiguring dbus to use a tcp socket) and it works just as expected. Any reason we wouldn't want openssh doing this natively? b. From mouring at eviladmin.org Sat Feb 14 19:20:42 2009 From: mouring at eviladmin.org (Ben Lindstrom) Date: Sat, 14 Feb 2009 02:20:42 -0600 Subject: forward the dbus session? In-Reply-To: References: Message-ID: <8CFDE91A-32A0-4755-B4BB-282C3B657BA1@eviladmin.org> Any reason why this has to be an unique feature? Is there some form of authentication cookie or something that needs to be managed? That is really the only reason why X forwarding exists. Otherwise it could also be yet another port tunnel. - Ben On Feb 13, 2009, at 5:38 PM, Brian J. Murrell wrote: > Am I crazy for thinking about forwarding the DBUS session over an ssh > connection much like the X session is forwarded? > > I've proven the concept with socat (to use the unix socket that dbus > normally listens on rather than reconfiguring dbus to use a tcp > socket) > and it works just as expected. > > Any reason we wouldn't want openssh doing this natively? > > b. > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From gorhas at gmail.com Sat Feb 14 20:39:00 2009 From: gorhas at gmail.com (Goran Hasse) Date: Sat, 14 Feb 2009 10:39:00 +0100 Subject: forward the dbus session? In-Reply-To: <8CFDE91A-32A0-4755-B4BB-282C3B657BA1@eviladmin.org> References: <8CFDE91A-32A0-4755-B4BB-282C3B657BA1@eviladmin.org> Message-ID: In the past it was not a problem to log into a system many times (as the same user). Now it is a mess! If you start a lot of programs on one seat and then moves to another system and log in remotly to the first - you get all sort of problems. Application already started. Locks betwen files, mixed chaches and other stuff. example: (sleep 5 ; DISPLAY=:1 xterm ) & Xnest :1 Then in the xterm window you write "firefox". You get: "firefox is already running..." So you can't get another instans running. Effectivily you have turned your mutliuser system into a single user one... GH 2009/2/14 Ben Lindstrom : > Any reason why this has to be an unique feature? Is there some form > of authentication cookie or something that needs to be managed? That > is really the only reason why X forwarding exists. Otherwise it could > also be yet another port tunnel. > > - Ben > > On Feb 13, 2009, at 5:38 PM, Brian J. Murrell wrote: > >> Am I crazy for thinking about forwarding the DBUS session over an ssh >> connection much like the X session is forwarded? >> >> I've proven the concept with socat (to use the unix socket that dbus >> normally listens on rather than reconfiguring dbus to use a tcp >> socket) >> and it works just as expected. >> >> Any reason we wouldn't want openssh doing this natively? >> >> b. >> >> _______________________________________________ >> openssh-unix-dev mailing list >> openssh-unix-dev at mindrot.org >> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > -- gorhas at gmail.com Mob: 070-5530148 From brian at interlinx.bc.ca Sun Feb 15 00:18:48 2009 From: brian at interlinx.bc.ca (Brian J. Murrell) Date: Sat, 14 Feb 2009 13:18:48 +0000 (UTC) Subject: forward the dbus session? References: <8CFDE91A-32A0-4755-B4BB-282C3B657BA1@eviladmin.org> Message-ID: On Sat, 14 Feb 2009 02:20:42 -0600, Ben Lindstrom wrote: > > Any reason why this has to be an unique feature? Is there some form of > authentication cookie or something that needs to be managed? No but there is an environment variable that needs to be set, in the same manner as DISPLAY is set for X forwarding. And the socket being forwarded will most likely be a UNIX (socat calls them "abstract") socket. AFAIK ssh does not handle UNIX sockets currently, does it? It is possible to set the local dbus transport to use TCP (in addition to or instead of) the UNIX socket, but I think making that a pre-requisite for DBUS forwarding is just lame. By default it is a UNIX socket, so SSH should just use that. > That is > really the only reason why X forwarding exists. Otherwise it could also > be yet another port tunnel. How would the setting of the DISPLAY variable be done then? b. From dan at nf15.lightwave.net.ru Sun Feb 15 01:04:09 2009 From: dan at nf15.lightwave.net.ru (Dan Yefimov) Date: Sat, 14 Feb 2009 17:04:09 +0300 Subject: forward the dbus session? In-Reply-To: References: <8CFDE91A-32A0-4755-B4BB-282C3B657BA1@eviladmin.org> Message-ID: <4996CF59.4030808@nf15.lightwave.net.ru> On 14.02.2009 12:39, Goran Hasse wrote: > In the past it was not a problem to log into a system many times (as the > same user). Now it is a mess! If you start a lot of programs on one seat > and then moves to another system and log in remotly to the first - you get > all sort of problems. Application already started. Locks betwen files, mixed > chaches and other stuff. > > example: > > (sleep 5 ; DISPLAY=:1 xterm )& Xnest :1 > > Then in the xterm window you write "firefox". > > You get: "firefox is already running..." > So you can't get another instans running. Effectivily you have turned > your mutliuser > system into a single user one... > IMO that's not the problem to be solved with OpenSSH. AFAIK, Firefox doesn't have any profile sharing support built in, does it? What has the OpenSSH to deal with in that case? -- Sincerely Your, Dan. From peter at stuge.se Sun Feb 15 01:27:51 2009 From: peter at stuge.se (Peter Stuge) Date: Sat, 14 Feb 2009 15:27:51 +0100 Subject: forward the dbus session? In-Reply-To: References: <8CFDE91A-32A0-4755-B4BB-282C3B657BA1@eviladmin.org> Message-ID: <20090214142751.32540.qmail@stuge.se> Brian J. Murrell wrote: > And the socket being forwarded will most likely be a UNIX (socat > calls them "abstract") socket. AFAIK ssh does not handle UNIX > sockets currently, does it? I seem to recall previous posts about forwarding UNIX sockets. Maybe it was already implemented by someone? Search archive and bugzilla. > How would the setting of the DISPLAY variable be done then? SendEnv in ssh_config and AcceptEnv in sshd_config can be used to push out environment variables, but I guess you want to customize a little on the server to update the socket name. I guess the objection is simply that dbus is too fluffy for anyone to jump on it, but if you can provide a patch which turns out to be very small and if you can demonstrate/explain how the feature is a great benefit for users then it has a better chance of being included anyway. //Peter From brian at interlinx.bc.ca Sun Feb 15 01:59:10 2009 From: brian at interlinx.bc.ca (Brian J. Murrell) Date: Sat, 14 Feb 2009 14:59:10 +0000 (UTC) Subject: forward the dbus session? References: <8CFDE91A-32A0-4755-B4BB-282C3B657BA1@eviladmin.org> <20090214142751.32540.qmail@stuge.se> Message-ID: On Sat, 14 Feb 2009 15:27:51 +0100, Peter Stuge wrote: > > I seem to recall previous posts about forwarding UNIX sockets. Maybe it > was already implemented by someone? Search archive and bugzilla. That would be cool. But the implementation of having a local ssh connect to a UNIX socket and relay to/from it to/from a tunnel is trivial. > SendEnv in ssh_config and AcceptEnv in sshd_config can be used to push > out environment variables, but I guess you want to customize a little on > the server to update the socket name. Yeah. And I don't want the feature to be any more intrusive and laborious than X forwarding already is, which does not require the {Send,Accept}Env settings on either end. > I guess the objection is simply that dbus is too fluffy for anyone to > jump on it, Objection, or just that nobody has done it yet? > but if you can provide a patch which turns out to be very > small and if you can demonstrate/explain how the feature is a great > benefit for users then it has a better chance of being included anyway. Well, the benefit is clear to anyone who understands what DBUS is and what it's good for. My immediate need however is that Totem won't work properly without a DBUS connection to the display it's displaying on. Arguably this is a bug in Totem, yes, but this is just one example. But in general, DBUS is the glue that binds disparate desktop applications together, allowing them to send and receive signals. It would be nice if a desktop app started on a remote machine but displaying to my local desktop could interact with my desktop as if I ran it locally. Given that there have not been any strong rejections of the idea (yet) maybe I will spend an hour or two and hack up a patch. b. From peter at stuge.se Sun Feb 15 04:19:41 2009 From: peter at stuge.se (Peter Stuge) Date: Sat, 14 Feb 2009 18:19:41 +0100 Subject: forward the dbus session? In-Reply-To: References: <8CFDE91A-32A0-4755-B4BB-282C3B657BA1@eviladmin.org> <20090214142751.32540.qmail@stuge.se> Message-ID: <20090214171942.25502.qmail@stuge.se> Brian J. Murrell wrote: > > I guess the objection is simply that dbus is too fluffy for anyone > > to jump on it, > > Objection, or just that nobody has done it yet? Possible objection or so.. > > but if you can provide a patch which turns out to be very > > small and if you can demonstrate/explain how the feature is a great > > benefit for users then it has a better chance of being included anyway. > > Well, the benefit is clear to anyone who understands what DBUS is and > what it's good for. My point is that we probably do not. I certainly don't. I really dislike DBUS because it adds thousands (well, almost) of idiotic dependencies and I can not understand wtf it is trying to accomplish. > But in general, DBUS is the glue that binds disparate desktop > applications together, allowing them to send and receive signals. I thought the kernel did that.. ;) > It would be nice if a desktop app started on a remote machine but > displaying to my local desktop could interact with my desktop as if > I ran it locally. Sure, but for the purpose of a great many it might already do that. I wouldn't know, I don't want a desktop. But please explain with a good example and I'm sure you'll win me over. > Given that there have not been any strong rejections of the idea > (yet) maybe I will spend an hour or two and hack up a patch. Please do - and again - please explain, concretely, why it is useful, in order to improve it's standing. Is there DBUS on OpenBSD as well? In that case I guess the change should go upstream rather than here. //Peter From mouring at eviladmin.org Sun Feb 15 05:16:42 2009 From: mouring at eviladmin.org (Ben Lindstrom) Date: Sat, 14 Feb 2009 12:16:42 -0600 Subject: forward the dbus session? In-Reply-To: <20090214171942.25502.qmail@stuge.se> References: <8CFDE91A-32A0-4755-B4BB-282C3B657BA1@eviladmin.org> <20090214142751.32540.qmail@stuge.se> <20090214171942.25502.qmail@stuge.se> Message-ID: <47FA866B-7D49-4F26-8953-A94358E83B6E@eviladmin.org> On Feb 14, 2009, at 11:19 AM, Peter Stuge wrote: > Brian J. Murrell wrote: >>> I guess the objection is simply that dbus is too fluffy for anyone >>> to jump on it, >> >> Objection, or just that nobody has done it yet? > > Possible objection or so.. > To clarify what Peter is may be getting at... Next the KDE people will want their version of DBUS to have a special hook into OpenSSH. Maybe Enlightenment will invent their own protocol and want it in. The objection would be to implement something that isn't a universal standard. If all the desktops used one DBUS-like protocol it may be a different story. Also, what security risks are opened up by this? Do we have issues of trust and security like we do with X forward? >>> but if you can provide a patch which turns out to be very >>> small and if you can demonstrate/explain how the feature is a great >>> benefit for users then it has a better chance of being included >>> anyway. >> >> Well, the benefit is clear to anyone who understands what DBUS is and >> what it's good for. > > My point is that we probably do not. I certainly don't. I really > dislike DBUS because it adds thousands (well, almost) of idiotic > dependencies and I can not understand wtf it is trying to accomplish. My issue is this is being presented without a list of changes (or patch, or list of current hackery need to make DBUS work) that would need to be made. e.g. Variable FOO needs to be set to :: so that OpenSSH needs to grok so that OpenSSH needs to grok os that ..etc.. I was hoping my first question to Brian Murrel would product such a list besides. But I guess I wasn't clear enough. >> It would be nice if a desktop app started on a remote machine but >> displaying to my local desktop could interact with my desktop as if >> I ran it locally. > > Sure, but for the purpose of a great many it might already do that. > I wouldn't know, I don't want a desktop. But please explain with a > good example and I'm sure you'll win me over. > I'd argue that was the idea behind X11 myself, and DBUS decided to do an end-run around the that group and implement their own. And now we're stuck with yet another protocol to tunnel. >> Given that there have not been any strong rejections of the idea >> (yet) maybe I will spend an hour or two and hack up a patch. > > Please do - and again - please explain, concretely, why it is useful, > in order to improve it's standing. > > Is there DBUS on OpenBSD as well? In that case I guess the change > should go upstream rather than here. I agree. Until I know the full extend of the hackery needed to implement DBUS support I'd be inclined to ignore the idea. =) - Ben From Jefferson.Ogata at noaa.gov Sun Feb 15 06:04:43 2009 From: Jefferson.Ogata at noaa.gov (Jefferson Ogata) Date: Sat, 14 Feb 2009 19:04:43 +0000 Subject: forward the dbus session? In-Reply-To: References: <8CFDE91A-32A0-4755-B4BB-282C3B657BA1@eviladmin.org> <20090214142751.32540.qmail@stuge.se> Message-ID: <499715CB.8050108@noaa.gov> On 2009-02-14 14:59, Brian J. Murrell wrote: > But in general, DBUS is the glue that binds disparate desktop > applications together, allowing them to send and receive signals. It > would be nice if a desktop app started on a remote machine but displaying > to my local desktop could interact with my desktop as if I ran it locally. I generally handle this by running a remote X server under vncserver, and simply forwarding a VNC client connection over SSH. -- Jefferson Ogata NOAA Computer Incident Response Team (N-CIRT) "Never try to retrieve anything from a bear."--National Park Service From bob at proulx.com Sun Feb 15 07:18:56 2009 From: bob at proulx.com (Bob Proulx) Date: Sat, 14 Feb 2009 14:18:56 -0600 Subject: forward the dbus session? In-Reply-To: <499715CB.8050108@noaa.gov> References: <8CFDE91A-32A0-4755-B4BB-282C3B657BA1@eviladmin.org> <20090214142751.32540.qmail@stuge.se> <499715CB.8050108@noaa.gov> Message-ID: <20090214201856.GA28346@discord.proulx.com> Jefferson Ogata wrote: > Brian J. Murrell wrote: > > But in general, DBUS is the glue that binds disparate desktop > > applications together, allowing them to send and receive signals. It > > would be nice if a desktop app started on a remote machine but displaying > > to my local desktop could interact with my desktop as if I ran it locally. > > I generally handle this by running a remote X server under vncserver, > and simply forwarding a VNC client connection over SSH. When I need this then this is what I normally do as well. It is simple and uncomplicated. I worry that dbus is a large and incompletely documented system environment with many dependencies and tendrils. It isn't something that is easy to fully understand at one sitting. I do not understand it after many sittings. Coding it into ssh probably isn't a general purpose solution. It doesn't feel like the right direction to me. Bob From martin at oneiros.de Sun Feb 15 10:33:16 2009 From: martin at oneiros.de (=?ISO-8859-1?Q?Martin_Schr=F6der?=) Date: Sun, 15 Feb 2009 00:33:16 +0100 Subject: forward the dbus session? In-Reply-To: <20090214171942.25502.qmail@stuge.se> References: <8CFDE91A-32A0-4755-B4BB-282C3B657BA1@eviladmin.org> <20090214142751.32540.qmail@stuge.se> <20090214171942.25502.qmail@stuge.se> Message-ID: <68c491a60902141533o489caffx814dc4f295cc6904@mail.gmail.com> 2009/2/14 Peter Stuge : > My point is that we probably do not. I certainly don't. I really > dislike DBUS because it adds thousands (well, almost) of idiotic > dependencies and I can not understand wtf it is trying to accomplish. http://en.wikipedia.org/wiki/D-Bus Best Martin From peter at stuge.se Sun Feb 15 12:52:15 2009 From: peter at stuge.se (Peter Stuge) Date: Sun, 15 Feb 2009 02:52:15 +0100 Subject: forward the dbus session? In-Reply-To: <68c491a60902141533o489caffx814dc4f295cc6904@mail.gmail.com> References: <8CFDE91A-32A0-4755-B4BB-282C3B657BA1@eviladmin.org> <20090214142751.32540.qmail@stuge.se> <20090214171942.25502.qmail@stuge.se> <68c491a60902141533o489caffx814dc4f295cc6904@mail.gmail.com> Message-ID: <20090215015215.16302.qmail@stuge.se> Martin Schr?der wrote: > http://en.wikipedia.org/wiki/D-Bus --8<-- D-Bus is designed for two specific cases: * Communication between desktop applications in the same desktop session; to allow integration of the desktop session as a whole, and address issues of process lifecycle. * Communication between the desktop session and the operating system, where the operating system would typically include the kernel and any system daemons or processes. -->8-- This is too generic to help me. Can you describe a few problems that will be solved by forwarding D-Bus across ssh? Also, should OpenSSH bridge the two D-Busses? Why? Why not? //Peter From djm at mindrot.org Mon Feb 16 15:32:26 2009 From: djm at mindrot.org (Damien Miller) Date: Mon, 16 Feb 2009 15:32:26 +1100 (EST) Subject: Call for testing: openssh-5.2 Message-ID: Hi, OpenSSH 5.2 is almost ready for release, so we would appreciate testing on as many platforms and systems as possible. This is primarily a bug-fix release, to follow the feature-focused 5.1 release. Snapshot releases for portable OpenSSH are available from http://www.mindrot.org/openssh_snap/ The OpenBSD version is available in CVS HEAD: http://www.openbsd.org/anoncvs.html Portable OpenSSH is also available via anonymous CVS using the instructions at http://www.openssh.com/portable.html#cvs Running the regression tests supplied with Portable OpenSSH does not require installation and is a simply: $ ./configure && make tests Live testing on suitable non-production systems is also appreciated. Please send reports of success or failure to openssh-unix-dev at mindrot.org. Below is a summary of changes. More detail may be found in the ChangeLog in the portable OpenSSH tarballs. Thanks to the many people who contributed to this release. Changes since OpenSSH 5.1 ========================= Security: * This release changes the default cipher order to prefer the AES CTR modes and the revised "arcfour256" mode to CBC mode ciphers that are susceptible to CPNI-957037 "Plaintext Recovery Attack Against SSH". * This release also adds countermeasures to mitigate CPNI-957037-style attacks against the SSH protocol's use of CBC-mode ciphers. Upon detection of an invalid packet length or Message Authentication Code, ssh/sshd will continue reading up to the maximum supported packet length rather than immediately terminating the connection. This eliminates most of the known differences in behaviour that leaked information about the plaintext of injected data which formed the basis of this attack. We believe that these attacks are rendered infeasible by these changes. New features: * Added a -y option to ssh(1) to force logging to syslog rather than stderr, which is useful when running daemonised (ssh -f) * The sshd_config(5) ForceCommand directive now accepts commandline arguments for the internal-sftp server. * The ssh(1) ~C escape commandline now support runtime creation of dynamic (-D) port forwards. * Support the SOCKS4A protocol in ssh(1) dynamic (-D) forwards. (bz#1482) * Support remote port forwarding with a listen port of '0'. This informs the server that it should dynamically allocate a listen port and report it back to the client. (bz#1003) * sshd(8) now supports setting PermitEmptyPasswords and AllowAgentForwarding in Match blocks Bug and documentation fixes * Repair a ssh(1) crash introduced in openssh-5.1 when the client is sent a zero-length banner (bz#1496) * Due to interoperability problems with certain broken SSH implementations, the eow at openssh.com and no-more-sessions at openssh.com protocol extensions are now only sent to peers that identify themselves as OpenSSH. * Make ssh(1) send the correct channel number for SSH2_MSG_CHANNEL_SUCCESS and SSH2_MSG_CHANNEL_FAILURE messages to avoid triggering 'Non-public channel' error messages on sshd(8) in openssh-5.1. * Avoid printing 'Non-public channel' warnings in sshd(8), since the ssh(1) has sent incorrect channel numbers since ~2004 (this reverts a behaviour introduced in openssh-5.1). * Avoid double-free in ssh(1) ~C escape -L handler (bz#1539) * Correct fail-on-error behaviour in sftp(1) batchmode for remote stat operations. (bz#1541) * Disable nonfunctional ssh(1) ~C escape handler in multiplex slave connections. (bz#1543) * Avoid hang in ssh(1) when attempting to connect to a server that has MaxSessions=0 set. * Multiple fixes to sshd(8) configuration test (-T) mode * Several core and portable OpenSSH bugs fixed: 1380, 1412, 1418, 1419, 1421, 1490, 1491, 1492, 1514, 1515, 1518, 1520, 1538, 1540 * Many manual page improvements. -d From djm at mindrot.org Mon Feb 16 15:38:22 2009 From: djm at mindrot.org (Damien Miller) Date: Mon, 16 Feb 2009 15:38:22 +1100 (EST) Subject: [PATCH] GNU/kFreeBSD & GNU/kOpenSolaris support In-Reply-To: <20090206134826.GA28945@thorin> References: <20090206134826.GA28945@thorin> Message-ID: On Fri, 6 Feb 2009, Robert Millan wrote: > > Hi, > > This patch, initially made by Aurelien Jarno for GNU/kFreeBSD, and adjusted > by me to also support GNU/kOpensolaris, adds support for these two operating > systems. Applied. Please create bugs for future patches at http://bugzilla.mindrot.org - it is much easier to track them there and avoid them getting lost (as this one almost did). -d From vinschen at redhat.com Tue Feb 17 00:56:49 2009 From: vinschen at redhat.com (Corinna Vinschen) Date: Mon, 16 Feb 2009 14:56:49 +0100 Subject: Call for testing: openssh-5.2 In-Reply-To: References: Message-ID: <20090216135649.GH5416@calimero.vinschen.de> On Feb 16 15:32, Damien Miller wrote: > Hi, > > OpenSSH 5.2 is almost ready for release, so we would appreciate testing > on as many platforms and systems as possible. This is primarily a bug-fix > release, to follow the feature-focused 5.1 release. Builds and runs fine on Cygwin 1.7. Since I won't support any new OpenSSH package for Cygwin 1.5, and since Cygwin 1.7 will stop supporting Windows 9x, I'm wondering if it's ok to strip all Windows 9x support, as well as the *really* old Cygwin version considerations from OpenSSH at this point. It will strip some extra Cygwin-only code from portable SSH. Or, maybe we should do that right after the 5.2p1 release? Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From Zube at CS.ColoState.EDU Tue Feb 17 00:32:11 2009 From: Zube at CS.ColoState.EDU (Zube) Date: Mon, 16 Feb 2009 06:32:11 -0700 Subject: OpenSSH 5.2 testing Message-ID: <20090216133211.GA12411@mozart.cs.colostate.edu> All tests passed on: Solaris 9 sparc CentOS 4.7 x86 / x86_64 CentOS 5.2 x86_64 Cheers, Zube From gert at greenie.muc.de Tue Feb 17 01:45:15 2009 From: gert at greenie.muc.de (Gert Doering) Date: Mon, 16 Feb 2009 15:45:15 +0100 Subject: Call for testing: openssh-5.2 In-Reply-To: References: Message-ID: <20090216144515.GP290@greenie.muc.de> Hi, On Mon, Feb 16, 2009 at 03:32:26PM +1100, Damien Miller wrote: > OpenSSH 5.2 is almost ready for release, so we would appreciate testing > on as many platforms and systems as possible. This is primarily a bug-fix > release, to follow the feature-focused 5.1 release. I've checked out the CVS snapshot, autoreconf / configure / make'd things, and it all built fine. NetBSD 3.1 on Sparc64. "make tests" fails after a while, though, with these last lines: ... mm_send_fd: sendmsg(0): Invalid argument muxclient: send fds failed Falling back to non-multiplexed connection mm_receive_fd: recvmsg: expected received 1 got 0 muxserver_accept_control: failed to receive fd 0 from slave ssh: Could not resolve hostname otherhost: No address associated with hostname exit code (with sleep) mismatch for protocol : 255 != 44 Master running (pid=15159) Exit request sent. failed connection multiplexing *** Error code 1 "should it be doing this"? 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 doctor at doctor.nl2k.ab.ca Tue Feb 17 05:34:18 2009 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Mon, 16 Feb 2009 11:34:18 -0700 Subject: Call for testing: openssh-5.2 In-Reply-To: <20090216144515.GP290@greenie.muc.de> References: <20090216144515.GP290@greenie.muc.de> Message-ID: <20090216183418.GA27852@doctor.nl2k.ab.ca> On Mon, Feb 16, 2009 at 03:45:15PM +0100, Gert Doering wrote: > Hi, > > On Mon, Feb 16, 2009 at 03:32:26PM +1100, Damien Miller wrote: > > OpenSSH 5.2 is almost ready for release, so we would appreciate testing > > on as many platforms and systems as possible. This is primarily a bug-fix > > release, to follow the feature-focused 5.1 release. > > I've checked out the CVS snapshot, autoreconf / configure / make'd things, > and it all built fine. NetBSD 3.1 on Sparc64. > > "make tests" fails after a while, though, with these last lines: > > ... > mm_send_fd: sendmsg(0): Invalid argument > muxclient: send fds failed > Falling back to non-multiplexed connection > mm_receive_fd: recvmsg: expected received 1 got 0 > muxserver_accept_control: failed to receive fd 0 from slave > ssh: Could not resolve hostname otherhost: No address associated with hostname > exit code (with sleep) mismatch for protocol : 255 != 44 > Master running (pid=15159) > Exit request sent. > failed connection multiplexing > *** Error code 1 > > > "should it be doing this"? > > gert So far nothing wrong on BSD/OS 4.3.1 using openssl 0.9.9-dev . I will try on Free BSD. > -- > USENET is *not* the non-clickable part of WWW! 10/10 . > //www.muc.de/~gert/ > Gert Doering - Munich, Germany gert at greenie.muc.de > fax: +49-89-35655025 gert at net.informatik.tu-muenchen.de > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > -- Member - Liberal International This is doctor at nl2k.ab.ca Ici doctor at nl2k.ab.ca God, Queen and country! Beware Anti-Christ rising! Never Satan President Republic! Christian(n): A Jew that believe Christ is Messiah and Saviour and alive -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From rac at tenzing.org Tue Feb 17 06:07:18 2009 From: rac at tenzing.org (Roger Cornelius) Date: Mon, 16 Feb 2009 14:07:18 -0500 Subject: Call for testing: openssh-5.2 In-Reply-To: References: Message-ID: <20090216190718.GA27374@tenzing.org> On 02/16/2009 15:32, Damien Miller wrote: > Hi, > > OpenSSH 5.2 is almost ready for release, so we would appreciate testing > on as many platforms and systems as possible. This is primarily a bug-fix > release, to follow the feature-focused 5.1 release. [...] > $ ./configure && make tests > > Live testing on suitable non-production systems is also appreciated. > Please send reports of success or failure to > openssh-unix-dev at mindrot.org. On SCO OSR6 w/mp3 installed, openssh-SNAP-20090216.tar.gz, 'make tests' fails with: run test key-options.sh ... key option proto 1 command="echo bar" key option proto 1 no-pty,command="echo bar" key option proto 2 command="echo bar" key option proto 2 no-pty,command="echo bar" key option proto 1 no-pty key option proto 2 no-pty key option proto 1 environment key option proto 2 environment key option proto 1 from="127.0.0.1" key option proto 1 from="127.0.0.1" not allowed but should be key option proto 1 from="127.0.0.0/8" key option proto 1 from="127.0.0.0/8" not allowed but should be key option proto 2 from="127.0.0.1" key option proto 2 from="127.0.0.1" not allowed but should be key option proto 2 from="127.0.0.0/8" key option proto 2 from="127.0.0.0/8" not allowed but should be failed key options make[1]: *** [t-exec] Error 1 make[1]: Leaving directory `/u1/src/rac/openssh/csv/openssh/regress' make: *** [tests] Error 2 I won't have time to investigate for several days. If anyone has suggestions they would be appreciated. -- Roger Cornelius rac at tenzing.org From andyb1 at andy-t.org Tue Feb 17 07:15:30 2009 From: andyb1 at andy-t.org (Andy Tsouladze) Date: Mon, 16 Feb 2009 14:15:30 -0600 (CST) Subject: Call for testing: openssh-5.2 In-Reply-To: <20090216190718.GA27374@tenzing.org> References: <20090216190718.GA27374@tenzing.org> Message-ID: Compiled and tested openssh-SNAP-20090217.tar.gz on Slackware-12.0.0. All tests succeeded. Thanks, Andy Dr Andy Tsouladze Sr Unix/Storage SysAdmin From vadud3 at gmail.com Tue Feb 17 07:43:41 2009 From: vadud3 at gmail.com (Asif Iqbal) Date: Mon, 16 Feb 2009 15:43:41 -0500 Subject: StrictHostKeyChecking is being ignored Message-ID: ssh -oStrictHostKeyChecking=no scrub @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that the RSA host key has just been changed. The fingerprint for the RSA key sent by the remote host is 4b:c2:f2:a1:ee:f6:b2:01:e1:45:5a:6c:85:d4:ee:94. Please contact your system administrator. Add correct host key in /home/iqbala/.ssh/known_hosts to get rid of this message. Offending key in /home/iqbala/.ssh/known_hosts:93 Password authentication is disabled to avoid man-in-the-middle attacks. Keyboard-interactive authentication is disabled to avoid man-in-the-middle attacks. Permission denied (gssapi-keyex,gssapi-with-mic,publickey,password,keyboard-interactive). Why is it ignoring `StrictHostKeyChecking=no' ? The ssh version is $ ssh -v OpenSSH_4.4p1, OpenSSL 0.9.8d 28 Sep 2006 -- Asif Iqbal PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? From djm at mindrot.org Tue Feb 17 08:11:38 2009 From: djm at mindrot.org (Damien Miller) Date: Tue, 17 Feb 2009 08:11:38 +1100 (EST) Subject: Call for testing: openssh-5.2 In-Reply-To: <20090216135649.GH5416@calimero.vinschen.de> References: <20090216135649.GH5416@calimero.vinschen.de> Message-ID: On Mon, 16 Feb 2009, Corinna Vinschen wrote: > On Feb 16 15:32, Damien Miller wrote: > > Hi, > > > > OpenSSH 5.2 is almost ready for release, so we would appreciate testing > > on as many platforms and systems as possible. This is primarily a bug-fix > > release, to follow the feature-focused 5.1 release. > > Builds and runs fine on Cygwin 1.7. Since I won't support any new > OpenSSH package for Cygwin 1.5, and since Cygwin 1.7 will stop > supporting Windows 9x, I'm wondering if it's ok to strip all Windows 9x > support, as well as the *really* old Cygwin version considerations from > OpenSSH at this point. It will strip some extra Cygwin-only code from > portable SSH. Or, maybe we should do that right after the 5.2p1 release? Yes, we can do this after the release of 5.2p1. Thanks for testing :) -d From jblaine at kickflop.net Tue Feb 17 08:12:50 2009 From: jblaine at kickflop.net (Jeff Blaine) Date: Mon, 16 Feb 2009 16:12:50 -0500 Subject: -R port forwarding and remote host:port info Message-ID: <4999D6D2.3020902@kickflop.net> After the previous small patch submitted to log info about X11 forwarding, I've moved on to trying to log information about remote port forwarding. The remote hostname is showing up as 'localhost'. That's not useful. sshd -ddd shows the following in the midst of an incoming "ssh -R 22220:faron:22 linus". Obviously I want to see the word 'faron' somewhere but don't. That seems like a bug to me. ... debug1: server_input_global_request: rtype tcpip-forward want_reply 1 debug1: server_input_global_request: tcpip-forward listen localhost port 22220 debug3: channel_setup_fwd_listener: type 11 wildcard 0 addr NULL debug1: Local forwarding listening on 127.0.0.1 port 22220. ... Fantastic! But half the useful information. Okay, maybe I have to connect through the forward to get the full info for some reason. I see the following from that same sshd when I 'tickle' the forward on linus by doing 'ssh -p 22220 localhost' (which takes me to faron:22 properly) ... debug1: Connection to port 22220 forwarding to localhost port 0 requested. ... debug1: channel 2: free: forwarded-tcpip: listening port 22220 for localhost port 0, connect from 127.0.0.1 port 49644, nchannels 3 debug3: channel 2: status: The following connections are open: #1 server-session (t4 r0 i0/0 o0/0 fd 12/10 cfd -1) #2 forwarded-tcpip: listening port 22220 for localhost port 0, connect from 127.0.0.1 port 49644 (t4 r1 i3/0 o3/0 fd 11/11 cfd -1) ... Again, only half of the useful information. This time with other information: localhost port 0 That's not useful :) The problem is, I cannot figure out on my own where 'faron' is being lost in the code in order to log it. From djm at mindrot.org Tue Feb 17 08:16:06 2009 From: djm at mindrot.org (Damien Miller) Date: Tue, 17 Feb 2009 08:16:06 +1100 (EST) Subject: StrictHostKeyChecking is being ignored In-Reply-To: References: Message-ID: On Mon, 16 Feb 2009, Asif Iqbal wrote: > ssh -oStrictHostKeyChecking=no scrub > @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ > @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ > @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ > IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! > Someone could be eavesdropping on you right now (man-in-the-middle attack)! > It is also possible that the RSA host key has just been changed. > The fingerprint for the RSA key sent by the remote host is > 4b:c2:f2:a1:ee:f6:b2:01:e1:45:5a:6c:85:d4:ee:94. > Please contact your system administrator. > Add correct host key in /home/iqbala/.ssh/known_hosts to get rid of > this message. > Offending key in /home/iqbala/.ssh/known_hosts:93 > Password authentication is disabled to avoid man-in-the-middle attacks. > Keyboard-interactive authentication is disabled to avoid > man-in-the-middle attacks. > Permission denied > (gssapi-keyex,gssapi-with-mic,publickey,password,keyboard-interactive). > > Why is it ignoring `StrictHostKeyChecking=no' ? It isn't ignoring it, it just doesn't do what you think it means. StrictHostKeyChecking=no still checks existing host keys and will disable "unsafe" authentication mechanisms if the hostkey doesn't match. StrictHostKeyChecking is mainly about relaxing the *acceptance* of previously unseen host keys. If you really don't care about the host key of your target, then try: ssh -oUserKnownHostsFile=/dev/null -oStrictHostKeyChecking=no yourhost (or better yet, put an alias in .ssh/config). -d From djm at mindrot.org Tue Feb 17 08:20:44 2009 From: djm at mindrot.org (Damien Miller) Date: Tue, 17 Feb 2009 08:20:44 +1100 (EST) Subject: Call for testing: openssh-5.2 In-Reply-To: <20090216144515.GP290@greenie.muc.de> References: <20090216144515.GP290@greenie.muc.de> Message-ID: On Mon, 16 Feb 2009, Gert Doering wrote: > Hi, > > On Mon, Feb 16, 2009 at 03:32:26PM +1100, Damien Miller wrote: > > OpenSSH 5.2 is almost ready for release, so we would appreciate testing > > on as many platforms and systems as possible. This is primarily a bug-fix > > release, to follow the feature-focused 5.1 release. > > I've checked out the CVS snapshot, autoreconf / configure / make'd things, > and it all built fine. NetBSD 3.1 on Sparc64. > > "make tests" fails after a while, though, with these last lines: > ... > mm_send_fd: sendmsg(0): Invalid argument > muxclient: send fds failed > Falling back to non-multiplexed connection > mm_receive_fd: recvmsg: expected received 1 got 0 > muxserver_accept_control: failed to receive fd 0 from slave > ssh: Could not resolve hostname otherhost: No address associated with hostname > exit code (with sleep) mismatch for protocol : 255 != 44 > Master running (pid=15159) > Exit request sent. > failed connection multiplexing > *** Error code 1 I think that this is the kernel bug mentioned here: http://lists.mindrot.org/pipermail/openssh-unix-dev/2008-July/026591.html -d From vadud3 at gmail.com Tue Feb 17 09:10:30 2009 From: vadud3 at gmail.com (Asif Iqbal) Date: Mon, 16 Feb 2009 17:10:30 -0500 Subject: StrictHostKeyChecking is being ignored In-Reply-To: References: Message-ID: On Mon, Feb 16, 2009 at 4:16 PM, Damien Miller wrote: > On Mon, 16 Feb 2009, Asif Iqbal wrote: > >> ssh -oStrictHostKeyChecking=no scrub >> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ >> @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ >> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ >> IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! >> Someone could be eavesdropping on you right now (man-in-the-middle attack)! >> It is also possible that the RSA host key has just been changed. >> The fingerprint for the RSA key sent by the remote host is >> 4b:c2:f2:a1:ee:f6:b2:01:e1:45:5a:6c:85:d4:ee:94. >> Please contact your system administrator. >> Add correct host key in /home/iqbala/.ssh/known_hosts to get rid of >> this message. >> Offending key in /home/iqbala/.ssh/known_hosts:93 >> Password authentication is disabled to avoid man-in-the-middle attacks. >> Keyboard-interactive authentication is disabled to avoid >> man-in-the-middle attacks. >> Permission denied >> (gssapi-keyex,gssapi-with-mic,publickey,password,keyboard-interactive). >> >> Why is it ignoring `StrictHostKeyChecking=no' ? > > It isn't ignoring it, it just doesn't do what you think it means. > StrictHostKeyChecking=no still checks existing host keys and will disable > "unsafe" authentication mechanisms if the hostkey doesn't match. > > StrictHostKeyChecking is mainly about relaxing the *acceptance* of > previously unseen host keys. > > If you really don't care about the host key of your target, then try: > ssh -oUserKnownHostsFile=/dev/null -oStrictHostKeyChecking=no yourhost > (or better yet, put an alias in .ssh/config). That worked. Thanks a lot > > -d > -- Asif Iqbal PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? From plambrechtsen at gmail.com Tue Feb 17 11:22:00 2009 From: plambrechtsen at gmail.com (Peter Lambrechtsen) Date: Tue, 17 Feb 2009 13:22:00 +1300 Subject: Support for merging LPK and hpn-ssh into mainline openssh? Message-ID: Hello Are there plans to merge the hpn-ssh (http://www.psc.edu/networking/projects/hpn-ssh/) and the LPK (http://code.google.com/p/openssh-lpk/) into the mainline openssh. Adding lpk has been logged as a bug in bugzilla as They are two patches that I always apply as the performance boost from hpn-ssh is substantial to say the least, and centralisation of the authorized_keys into a LDAP server is a very helpful way to manage the authorized keys across a myriad of servers. Is there any chance these patches could get included into mainline openssh? Thanks Peter From doctor at doctor.nl2k.ab.ca Tue Feb 17 08:58:12 2009 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Mon, 16 Feb 2009 14:58:12 -0700 Subject: Call for testing: openssh-5.2 In-Reply-To: <20090216183418.GA27852@doctor.nl2k.ab.ca> References: <20090216144515.GP290@greenie.muc.de> <20090216183418.GA27852@doctor.nl2k.ab.ca> Message-ID: <20090216215812.GA28474@doctor.nl2k.ab.ca> On Mon, Feb 16, 2009 at 11:34:18AM -0700, The Doctor wrote: > On Mon, Feb 16, 2009 at 03:45:15PM +0100, Gert Doering wrote: > > Hi, > > > > On Mon, Feb 16, 2009 at 03:32:26PM +1100, Damien Miller wrote: > > > OpenSSH 5.2 is almost ready for release, so we would appreciate testing > > > on as many platforms and systems as possible. This is primarily a bug-fix > > > release, to follow the feature-focused 5.1 release. > > > > I've checked out the CVS snapshot, autoreconf / configure / make'd things, > > and it all built fine. NetBSD 3.1 on Sparc64. > > > > "make tests" fails after a while, though, with these last lines: > > > > ... > > mm_send_fd: sendmsg(0): Invalid argument > > muxclient: send fds failed > > Falling back to non-multiplexed connection > > mm_receive_fd: recvmsg: expected received 1 got 0 > > muxserver_accept_control: failed to receive fd 0 from slave > > ssh: Could not resolve hostname otherhost: No address associated with hostname > > exit code (with sleep) mismatch for protocol : 255 != 44 > > Master running (pid=15159) > > Exit request sent. > > failed connection multiplexing > > *** Error code 1 > > > > > > "should it be doing this"? > > > > gert > > So far nothing wrong on BSD/OS 4.3.1 using openssl 0.9.9-dev . > > I will try on Free BSD. > FreeBSD 6.4 amd 64 with openssl 0.9.8k FIPs everything passes. FreeBSD 6.4 i386 with openssl 0.9.8k no-fips tests choke. > > -- > > USENET is *not* the non-clickable part of WWW! > > 10/10 . > > > //www.muc.de/~gert/ > > Gert Doering - Munich, Germany gert at greenie.muc.de > > fax: +49-89-35655025 gert at net.informatik.tu-muenchen.de > > _______________________________________________ > > openssh-unix-dev mailing list > > openssh-unix-dev at mindrot.org > > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > > > > -- > > This message has been scanned for viruses and > > dangerous content by MailScanner, and is > > believed to be clean. > > > > -- > Member - Liberal International This is doctor at nl2k.ab.ca > Ici doctor at nl2k.ab.ca God, Queen and country! Beware Anti-Christ rising! > Never Satan President Republic! > Christian(n): A Jew that believe Christ is Messiah and Saviour and alive > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev -- Member - Liberal International This is doctor at nl2k.ab.ca Ici doctor at nl2k.ab.ca God, Queen and country! Beware Anti-Christ rising! Never Satan President Republic! Christian(n): A Jew that believe Christ is Messiah and Saviour and alive -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From vadud3 at gmail.com Tue Feb 17 12:18:20 2009 From: vadud3 at gmail.com (Asif Iqbal) Date: Mon, 16 Feb 2009 20:18:20 -0500 Subject: StrictHostKeyChecking is being ignored In-Reply-To: References: Message-ID: On Mon, Feb 16, 2009 at 4:16 PM, Damien Miller wrote: > On Mon, 16 Feb 2009, Asif Iqbal wrote: > >> ssh -oStrictHostKeyChecking=no scrub >> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ >> @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ >> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ >> IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! >> Someone could be eavesdropping on you right now (man-in-the-middle attack)! >> It is also possible that the RSA host key has just been changed. >> The fingerprint for the RSA key sent by the remote host is >> 4b:c2:f2:a1:ee:f6:b2:01:e1:45:5a:6c:85:d4:ee:94. >> Please contact your system administrator. >> Add correct host key in /home/iqbala/.ssh/known_hosts to get rid of >> this message. >> Offending key in /home/iqbala/.ssh/known_hosts:93 >> Password authentication is disabled to avoid man-in-the-middle attacks. >> Keyboard-interactive authentication is disabled to avoid >> man-in-the-middle attacks. >> Permission denied >> (gssapi-keyex,gssapi-with-mic,publickey,password,keyboard-interactive). >> >> Why is it ignoring `StrictHostKeyChecking=no' ? > > It isn't ignoring it, it just doesn't do what you think it means. > StrictHostKeyChecking=no still checks existing host keys and will disable > "unsafe" authentication mechanisms if the hostkey doesn't match. > > StrictHostKeyChecking is mainly about relaxing the *acceptance* of > previously unseen host keys. > > If you really don't care about the host key of your target, then try: > ssh -oUserKnownHostsFile=/dev/null -oStrictHostKeyChecking=no yourhost > (or better yet, put an alias in .ssh/config). > I noticed some difference in Sun's SSH. I am planning to create a ticket with SUN to fix this SUN's SSH does not fail if set the stricthostkeychecking to no (iqbala)@scrub:~$ uname -a SunOS scrub 5.11 snv_106 i86pc i386 i86pc (iqbala)@scrub:~$ /usr/bin/ssh -V Sun_SSH_1.3, SSH protocols 1.5/2.0, OpenSSL 0x0090801f (iqbala)@scrub:~$ /usr/bin/ssh -oStrictHostKeyChecking=no 0 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that the RSA host key has just been changed. The fingerprint for the RSA key sent by the remote host is bf:7a:b7:e6:35:69:02:69:32:df:38:4e:fd:50:a9:d1. Please contact your system administrator. Add correct host key in /export/home/iqbala/.ssh/known_hosts to get rid of this message. Offending key in /export/home/iqbala/.ssh/known_hosts:92 Password authentication is disabled to avoid man-in-the-middle attacks. Password: It looks like it does not disable keyboard interactive authentication like OpenSSH does > -d > -- Asif Iqbal PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? From peter at stuge.se Tue Feb 17 12:52:29 2009 From: peter at stuge.se (Peter Stuge) Date: Tue, 17 Feb 2009 02:52:29 +0100 Subject: -R port forwarding and remote host:port info In-Reply-To: <4999D6D2.3020902@kickflop.net> References: <4999D6D2.3020902@kickflop.net> Message-ID: <20090217015229.26424.qmail@stuge.se> Jeff Blaine wrote: > sshd -ddd shows the following in the midst of an > incoming "ssh -R 22220:faron:22 linus". Obviously > I want to see the word 'faron' somewhere but don't. > > That seems like a bug to me. It isn't. sshd in this case only knows to listen on port 22220 and forward connections. Only ssh knows about faron. I guess you'll see faron if you run ssh -vvv. //Peter From djm at mindrot.org Tue Feb 17 13:18:44 2009 From: djm at mindrot.org (Damien Miller) Date: Tue, 17 Feb 2009 13:18:44 +1100 (EST) Subject: Support for merging LPK and hpn-ssh into mainline openssh? In-Reply-To: References: Message-ID: On Tue, 17 Feb 2009, Peter Lambrechtsen wrote: > Hello > > Are there plans to merge the hpn-ssh > (http://www.psc.edu/networking/projects/hpn-ssh/) and the LPK > (http://code.google.com/p/openssh-lpk/) into the mainline openssh. > > Adding lpk has been logged as a bug in bugzilla as > > They are two patches that I always apply as the performance boost from > hpn-ssh is substantial to say the least, and centralisation of the > authorized_keys into a LDAP server is a very helpful way to manage the > authorized keys across a myriad of servers. > > Is there any chance these patches could get included into mainline > openssh? We are slowly working on SSH performance on high B*D networks, and OpenSSH 5.1 should be comparable in performance to the HPN patches for most users - our internal limits should fill a 100Mbps path of 165ms. For reference, the circumference of the earth is 135 ms @ c. We don't yet have the smarts that the HPN patch has to adjust the ssh windows to follow TCP autotuning that are probably required to go further/faster. I don't think there are any plans to merge the LPK patch. We really don't want a dependency on LDAP libraries in sshd. Maybe if it were abstracted into a helper app that sshd could consult to verify keys then it would be more palatable, but even this is doubtful unless it can be done in a way that avoids complexity - there is a lot that can go wrong. -d From wknox at mitre.org Tue Feb 17 07:17:37 2009 From: wknox at mitre.org (Knox, Bill) Date: Mon, 16 Feb 2009 15:17:37 -0500 Subject: Call for testing: openssh-5.2 In-Reply-To: References: Message-ID: Just to make sure that the oldies are covered... All tests completed and passed on Solaris 8 and Fedora 7. Solaris 8 required the --without-zlib-version-check flag to configure due to having merely patched the long ago vulnerable version of zlib without updating the version number. No configure flags were used otherwise. Bill Knox Lead Infosec Engineer/Scientist The MITRE Corporation -----Original Message----- From: openssh-unix-dev-bounces+wknox=mitre.org at mindrot.org [mailto:openssh-unix-dev-bounces+wknox=mitre.org at mindrot.org] On Behalf Of Damien Miller Sent: Sunday, February 15, 2009 11:32 PM To: openssh-unix-dev at mindrot.org Subject: Call for testing: openssh-5.2 Hi, OpenSSH 5.2 is almost ready for release, so we would appreciate testing on as many platforms and systems as possible. This is primarily a bug-fix release, to follow the feature-focused 5.1 release. Snapshot releases for portable OpenSSH are available from http://www.mindrot.org/openssh_snap/ The OpenBSD version is available in CVS HEAD: http://www.openbsd.org/anoncvs.html Portable OpenSSH is also available via anonymous CVS using the instructions at http://www.openssh.com/portable.html#cvs Running the regression tests supplied with Portable OpenSSH does not require installation and is a simply: $ ./configure && make tests Live testing on suitable non-production systems is also appreciated. Please send reports of success or failure to openssh-unix-dev at mindrot.org. Below is a summary of changes. More detail may be found in the ChangeLog in the portable OpenSSH tarballs. Thanks to the many people who contributed to this release. Changes since OpenSSH 5.1 ========================= Security: * This release changes the default cipher order to prefer the AES CTR modes and the revised "arcfour256" mode to CBC mode ciphers that are susceptible to CPNI-957037 "Plaintext Recovery Attack Against SSH". * This release also adds countermeasures to mitigate CPNI-957037-style attacks against the SSH protocol's use of CBC-mode ciphers. Upon detection of an invalid packet length or Message Authentication Code, ssh/sshd will continue reading up to the maximum supported packet length rather than immediately terminating the connection. This eliminates most of the known differences in behaviour that leaked information about the plaintext of injected data which formed the basis of this attack. We believe that these attacks are rendered infeasible by these changes. New features: * Added a -y option to ssh(1) to force logging to syslog rather than stderr, which is useful when running daemonised (ssh -f) * The sshd_config(5) ForceCommand directive now accepts commandline arguments for the internal-sftp server. * The ssh(1) ~C escape commandline now support runtime creation of dynamic (-D) port forwards. * Support the SOCKS4A protocol in ssh(1) dynamic (-D) forwards. (bz#1482) * Support remote port forwarding with a listen port of '0'. This informs the server that it should dynamically allocate a listen port and report it back to the client. (bz#1003) * sshd(8) now supports setting PermitEmptyPasswords and AllowAgentForwarding in Match blocks Bug and documentation fixes * Repair a ssh(1) crash introduced in openssh-5.1 when the client is sent a zero-length banner (bz#1496) * Due to interoperability problems with certain broken SSH implementations, the eow at openssh.com and no-more-sessions at openssh.com protocol extensions are now only sent to peers that identify themselves as OpenSSH. * Make ssh(1) send the correct channel number for SSH2_MSG_CHANNEL_SUCCESS and SSH2_MSG_CHANNEL_FAILURE messages to avoid triggering 'Non-public channel' error messages on sshd(8) in openssh-5.1. * Avoid printing 'Non-public channel' warnings in sshd(8), since the ssh(1) has sent incorrect channel numbers since ~2004 (this reverts a behaviour introduced in openssh-5.1). * Avoid double-free in ssh(1) ~C escape -L handler (bz#1539) * Correct fail-on-error behaviour in sftp(1) batchmode for remote stat operations. (bz#1541) * Disable nonfunctional ssh(1) ~C escape handler in multiplex slave connections. (bz#1543) * Avoid hang in ssh(1) when attempting to connect to a server that has MaxSessions=0 set. * Multiple fixes to sshd(8) configuration test (-T) mode * Several core and portable OpenSSH bugs fixed: 1380, 1412, 1418, 1419, 1421, 1490, 1491, 1492, 1514, 1515, 1518, 1520, 1538, 1540 * Many manual page improvements. -d _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From plambrechtsen at gmail.com Tue Feb 17 13:41:33 2009 From: plambrechtsen at gmail.com (Peter Lambrechtsen) Date: Tue, 17 Feb 2009 15:41:33 +1300 Subject: Support for merging LPK and hpn-ssh into mainline openssh? In-Reply-To: References: Message-ID: On Tue, Feb 17, 2009 at 3:18 PM, Damien Miller wrote: > > We are slowly working on SSH performance on high B*D networks, and > OpenSSH 5.1 should be comparable in performance to the HPN patches > for most users - our internal limits should fill a 100Mbps path of > 165ms. For reference, the circumference of the earth is 135 ms @ c. > We don't yet have the smarts that the HPN patch has to adjust the > ssh windows to follow TCP autotuning that are probably required to go > further/faster. With my tests I have found ~15%+ (depending on a lot of factors like system load, network congestion, disk subsystem etc) on a GB LAN when transferring GB files. Having no encryption for the transfer and using HPN patched OpenSSH 5.1 Client & Server, or WinSCP Client (which already includes the HPN patches) and OpenSSH 5.1+HPN server. Would be nice to include, but again understand the complexity with merging the patch into the current mainline with the myriad of platforms that are supported by OpenSSH Portable. > I don't think there are any plans to merge the LPK patch. We really > don't want a dependency on LDAP libraries in sshd. Maybe if it were > abstracted into a helper app that sshd could consult to verify keys > then it would be more palatable, but even this is doubtful unless it > can be done in a way that avoids complexity - there is a lot that can > go wrong. Yes, the OpenLDAP+OpenSSL dependencies can make it a challenge to compile. However if it was not a default module, and when compiling OpenSSH you could add --with-ldap=/ldap/shared/libs then that would give end-users the option to build OpenSSH with LDAP support or not. Thanks for the response Peter From djm at mindrot.org Tue Feb 17 15:22:05 2009 From: djm at mindrot.org (Damien Miller) Date: Tue, 17 Feb 2009 15:22:05 +1100 (EST) Subject: Support for merging LPK and hpn-ssh into mainline openssh? In-Reply-To: References: Message-ID: On Tue, 17 Feb 2009, Peter Lambrechtsen wrote: > On Tue, Feb 17, 2009 at 3:18 PM, Damien Miller wrote: > > > > We are slowly working on SSH performance on high B*D networks, and > > OpenSSH 5.1 should be comparable in performance to the HPN patches > > for most users - our internal limits should fill a 100Mbps path of > > 165ms. For reference, the circumference of the earth is 135 ms @ c. > > We don't yet have the smarts that the HPN patch has to adjust the > > ssh windows to follow TCP autotuning that are probably required to go > > further/faster. > > With my tests I have found ~15%+ (depending on a lot of factors like > system load, network congestion, disk subsystem etc) on a GB LAN when > transferring GB files. Having no encryption for the transfer and > using HPN patched OpenSSH 5.1 Client & Server, or WinSCP Client (which > already includes the HPN patches) and OpenSSH 5.1+HPN server. Would > be nice to include, but again understand the complexity with merging > the patch into the current mainline with the myriad of platforms that > are supported by OpenSSH Portable. Ok, so you are (at least in part) talking about the "none" cipher parts of the HPN patch. We have no intention of implementing those - have a look at the list archives to see this discussed ad nauseum. > > I don't think there are any plans to merge the LPK patch. We really > > don't want a dependency on LDAP libraries in sshd. Maybe if it were > > abstracted into a helper app that sshd could consult to verify keys > > then it would be more palatable, but even this is doubtful unless it > > can be done in a way that avoids complexity - there is a lot that can > > go wrong. > > Yes, the OpenLDAP+OpenSSL dependencies can make it a challenge to > compile. However if it was not a default module, and when compiling > OpenSSH you could add --with-ldap=/ldap/shared/libs then that would > give end-users the option to build OpenSSH with LDAP support or not. My concern is more with the complexity and maintenance hassle of LDAP, not the run-time linkage. -d From dylan at dylanjay.com Tue Feb 17 14:10:20 2009 From: dylan at dylanjay.com (Dylan Jay) Date: Tue, 17 Feb 2009 14:10:20 +1100 Subject: Idea: reverse socks proxy Message-ID: <5F7A35DF-7D10-4647-9037-9294CF129459@dylanjay.com> Hi, Just a usecase that I'm sure has been covered before but just in case its not an openssh solution would be very helpful. I was trying to install software on a server that was firewalled so no outbound http connections would work. I was also tunnelling via another server. Outbound ssh connections also were a convenient option. What would have been nice would be a remote version of the dynamic socks proxy ssh -D, so I could for instance > ssh me at remote --remote-socks=8123 remote> export http_proxy=localhost:8123 remote> wget --spider www.google.com Instead I had to do the following > sudo apt-get install polipo > ssh me at remote -R 8123:localhost:8123 remote> export http_proxy=localhost:8123 remote> wget --spider www.google.com From gert at greenie.muc.de Tue Feb 17 18:22:24 2009 From: gert at greenie.muc.de (Gert Doering) Date: Tue, 17 Feb 2009 08:22:24 +0100 Subject: Call for testing: openssh-5.2 In-Reply-To: References: <20090216144515.GP290@greenie.muc.de> Message-ID: <20090217072224.GU290@greenie.muc.de> Hi, On Tue, Feb 17, 2009 at 08:20:44AM +1100, Damien Miller wrote: > On Mon, 16 Feb 2009, Gert Doering wrote: [..] > > muxserver_accept_control: failed to receive fd 0 from slave > > ssh: Could not resolve hostname otherhost: No address associated with hostname > > exit code (with sleep) mismatch for protocol : 255 != 44 > > Master running (pid=15159) > > Exit request sent. > > failed connection multiplexing > > *** Error code 1 > > I think that this is the kernel bug mentioned here: > > http://lists.mindrot.org/pipermail/openssh-unix-dev/2008-July/026591.html Oh indeed, I remember now. So - besides this, it seems to work well on NetBSD/Sparc 5.0 3.1. I'll see whether I can run a quick test on NetBSD/Sparc64 5.0 later today. 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 tcreedon at easystreet.net Wed Feb 18 03:07:41 2009 From: tcreedon at easystreet.net (Ted Creedon) Date: Tue, 17 Feb 2009 08:07:41 -0800 Subject: Call for testing: openssh-5.2 In-Reply-To: <20090217072224.GU290@greenie.muc.de> References: <20090216144515.GP290@greenie.muc.de> <20090217072224.GU290@greenie.muc.de> Message-ID: Anyone checking out native KRB5 authentication (w/o PAM)? I'm interested but need some help... Tedc On Mon, Feb 16, 2009 at 11:22 PM, Gert Doering wrote: > Hi, > > On Tue, Feb 17, 2009 at 08:20:44AM +1100, Damien Miller wrote: > > On Mon, 16 Feb 2009, Gert Doering wrote: > [..] > > > muxserver_accept_control: failed to receive fd 0 from slave > > > ssh: Could not resolve hostname otherhost: No address associated with > hostname > > > exit code (with sleep) mismatch for protocol : 255 != 44 > > > Master running (pid=15159) > > > Exit request sent. > > > failed connection multiplexing > > > *** Error code 1 > > > > I think that this is the kernel bug mentioned here: > > > > > http://lists.mindrot.org/pipermail/openssh-unix-dev/2008-July/026591.html > > Oh indeed, I remember now. So - besides this, it seems to work well on > NetBSD/Sparc 5.0 3.1. > > I'll see whether I can run a quick test on NetBSD/Sparc64 5.0 later today. > > 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 > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From markus.r.friedl at arcor.de Wed Feb 18 04:10:32 2009 From: markus.r.friedl at arcor.de (Markus Friedl) Date: Tue, 17 Feb 2009 18:10:32 +0100 Subject: Idea: reverse socks proxy In-Reply-To: <5F7A35DF-7D10-4647-9037-9294CF129459@dylanjay.com> References: <5F7A35DF-7D10-4647-9037-9294CF129459@dylanjay.com> Message-ID: <20090217171032.GA32208@folly> On Tue, Feb 17, 2009 at 02:10:20PM +1100, Dylan Jay wrote: > Just a usecase that I'm sure has been covered before but just in case > its not an openssh solution would be very helpful. > > I was trying to install software on a server that was firewalled so no > outbound http connections would work. I was also tunnelling via > another server. Outbound ssh connections also were a convenient option. > > What would have been nice would be a remote version of the dynamic > socks proxy ssh -D, so I could for instance it's on my todo list. From medsalim.bouhlel at enis.rnu.tn Wed Feb 18 05:47:38 2009 From: medsalim.bouhlel at enis.rnu.tn (SETIT 2009) Date: Tue, 17 Feb 2009 19:47:38 +0100 Subject: Invitation to attend SETIT2009 Message-ID: <2009217.398610,824747268518519@enis.rnu.tn> Invitation Dear We would like to invite you to join us for the 5th International Conference named Sciences of Electronics, Technologies of Information and Telecommunications SETIT 2009 which will be held in Hammamet-Tunisia from 22 to 26 March 2009. As you know, this International Conference is under the supervision of Professor Lazhar BOUOUNI, the Tunisian Minister of Higher Education and Scientific Research and Technology. This Conference is supported by IEEE. In this fifth version, more than 600 papers have been proposed among which 300 have been retained for publication. The papers? authors are from more than 40 nationalities. The SETIT conference is an essential forum for sharing knowledge about the latest progress and advances in information and telecommunication technologies, and has an excellent track record for fostering synergism between research teams that are working in the fields related to the conference topics. The rich assortment of tutorials, presentation sessions, and receptions will allow you to gain in-depth knowledge of fundamental principles and the latest trends in the sciences of electronics, technologies of information and telecommunications. With its many sessions, the Conference is an excellent opportunity to renew old friendships and network with new contacts. You and your accompanists will also enjoy the vibrant culture and many points of interest in our beautiful and hospitable country Tunisia. So make your plans now to join us for this exciting event. The organizing committee of the SETIT conference cordially invites you to join this event. Some participants can benefit from a financial support. In fact their accommodation fees (from the 22nd to the 26th March 2009 at the conference hotel) can be assumed by the conference. This Financial support is available to help participants from developing countries and countries with poor currencies to attend the 5th International Conference Sciences of Electronics, Technologies of Information and Telecommunications (SETIT?2009) that will be held in TUNISIA from March 22-26, 2009. The criteria used for the allocation of the financial support are: Country of residence (developing country, country with poor currency?) Occupational status. The financial support form is available on the web site http://www.setit.rnu.tn/FinancialSupport.dot. It should be filled in in details and sent by e-mail to the SETIT organization committee financialsupport.setit at gmail.com who examines on a case by case basis all requests and provides a response over 1 week. Our receipt for your request will be sent within 48 hours. Please note that financial support requests must be sent before 22 February 2009. Please do not hesitate to contact us if you have any queries regarding SETIT 2009. Updated information about the conference can be found at: http://www.setit.rnu.tn Online registration can be found at: http://www.setit.rnu.tn/?main=1&pg=registration_aut .. NB: As official carrier sponsor for the 5th International Conference SETIT 2009, TUNISAIR will offer to all participants attending this Conference the following special offer: 50% discount on the excursion fares to Tunisia on Tunisair in economic class. To benefit of this very special offer contact the Tunisair Representation Offices in your country and ask for more information. See you in Hammamet. Mohamed Salim BOUHLEL General Co-Chair, SETIT 2009 Director Higher Institute of Electronics and Communication (University of Sfax) Head of Research Unit:Sciences & Technologies of Image and Telecommunications ( Sfax University ) GSM +216 20 200005 Skype Name: UR-SETIT ================================================================== If you want to be removed from our database, please send an email to unsubscribe.setit at gmail.com with subject: Unsubscribe ================================================================== SETIT 2009 Fifth International Conference Sciences of Electronic, Technologies of Information and Telecommunications Technically co-sponsored IEEE Hmmamet, Tunisia, March 22-26, 2009 http://www.setit.rnu.tn/ == SETIT 2009 PRESENTATION ============================================= SETIT 2009 has the ambition to promote a technological reference frame, to give answers and original innovating ideas and to contribute to a common language around the information processing and the telecommunications. This conference will allow, on one hand, to share experience, to make a state of the art of the theory, research, telecommunication applications and the Information processing. On the other hand, Setit will present future innovations. == TOPICS ============================================================== The topics of this conference are voluntarily opened in order to support the participation of many teams (researchers, teachers, engineers, industrialists and students). A broad place will be reserved for the new ideas, with not yet succeeded work, original work positioning clearly compared to what exists. Here a non exhaustive list of the topics: Electronic Systems on chip Electronic integration Radiofrequence circuits and systems Telecommunications? circuits and systems Image and Video Image compression and coding Image processing technology Cryptology and watermarking Image 3D Multimedia Management and diffusion of multimedia applications Multimedia data base Documents modelisation and interpretation Telecommunication?s computer science Telecommunications and Networks Telecommunications Networks Communication protocoles Transmission technics Signal Processing Statistical analysis Speech processing Speech compression and coding Information Processing Information fusion Neuronal networks and fuzzy logic Rationing methods Data mining == CONFERENCE'S PLACE ====================================================== Hammamet is a town in Tunisia. Due to its beaches it is a popular destination for swimming and water sports; it was the first tourist destination in Tunisia.It is located in the south east of the northern peninsula of Cap Bon in the Governorate of Nabeul. The reported number of inhabitants varies from 20,000 to 70,000 and the population quadruples due to tourists in the summer. From gert at greenie.muc.de Thu Feb 19 01:27:38 2009 From: gert at greenie.muc.de (Gert Doering) Date: Wed, 18 Feb 2009 15:27:38 +0100 Subject: Call for testing: openssh-5.2 In-Reply-To: <20090217072224.GU290@greenie.muc.de> References: <20090216144515.GP290@greenie.muc.de> <20090217072224.GU290@greenie.muc.de> Message-ID: <20090218142738.GW290@greenie.muc.de> Hi, On Tue, Feb 17, 2009 at 08:22:24AM +0100, Gert Doering wrote: > I'll see whether I can run a quick test on NetBSD/Sparc64 5.0 later today. Well, "today" took a while. But here's the result :-) System: NetBSD 5.0_BETA sparc64 Result: all tests passed as a bonus, you get AIX with it... System: AIX 6.1.0 Result: all tests passed good work! 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 Jan.Pechanec at Sun.COM Thu Feb 19 01:49:15 2009 From: Jan.Pechanec at Sun.COM (Jan Pechanec) Date: Wed, 18 Feb 2009 15:49:15 +0100 (CET) Subject: Call for testing: openssh-5.2 In-Reply-To: References: Message-ID: On Mon, 16 Feb 2009, Damien Miller wrote: >Running the regression tests supplied with Portable OpenSSH does not >require installation and is a simply: > >$ ./configure && make tests both tests with: http://www.mindrot.org/openssh_snap/openssh-SNAP-20090219.tar.gz gcc 3.4.3 OpenSSL 0.9.8a (with security fixes) SPARC VII, Solaris Nevada 107 (01/2009), all tests passed i386, Solaris Nevada 108 (02/2009), all test passed -- Jan Pechanec From scott_n at xypro.com Thu Feb 19 03:36:28 2009 From: scott_n at xypro.com (Scott Neugroschl) Date: Wed, 18 Feb 2009 08:36:28 -0800 Subject: FW: Call for testing: openssh-5.2 Message-ID: <78DD71C304F38B41885A242996B96F7301B91DD4@xyservd.XYPRO-23.LOCAL> Whoops -- sent to wrong address... Mandriva 2008.1 openssh-SNAP-20090218 passes all tests. > -----Original Message----- > From: Scott Neugroschl > Sent: Tuesday, February 17, 2009 10:06 AM > To: Damien Miller > Subject: RE: Call for testing: openssh-5.2 > > Mandriva 2008.1 -- openssh-SNAP-20090218 passes > > > -----Original Message----- > From: openssh-unix-dev-bounces+scott_n=xypro.com at mindrot.org on behalf > of Damien Miller > Sent: Sun 2/15/2009 8:32 PM > To: openssh-unix-dev at mindrot.org > Subject: Call for testing: openssh-5.2 > > Hi, > > OpenSSH 5.2 is almost ready for release, so we would appreciate testing > on as many platforms and systems as possible. This is primarily a bug- > fix > release, to follow the feature-focused 5.1 release. > > Snapshot releases for portable OpenSSH are available from > http://www.mindrot.org/openssh_snap/ > > The OpenBSD version is available in CVS HEAD: > http://www.openbsd.org/anoncvs.html > > Portable OpenSSH is also available via anonymous CVS using the > instructions at http://www.openssh.com/portable.html#cvs > > Running the regression tests supplied with Portable OpenSSH does not > require installation and is a simply: > > $ ./configure && make tests > > Live testing on suitable non-production systems is also appreciated. > Please send reports of success or failure to > openssh-unix-dev at mindrot.org. > > Below is a summary of changes. More detail may be found in the > ChangeLog in the portable OpenSSH tarballs. > > Thanks to the many people who contributed to this release. > > > Changes since OpenSSH 5.1 > ========================= > > Security: > > * This release changes the default cipher order to prefer the AES CTR > modes and the revised "arcfour256" mode to CBC mode ciphers that are > susceptible to CPNI-957037 "Plaintext Recovery Attack Against SSH". > > * This release also adds countermeasures to mitigate CPNI-957037-style > attacks against the SSH protocol's use of CBC-mode ciphers. Upon > detection of an invalid packet length or Message Authentication > Code, ssh/sshd will continue reading up to the maximum supported > packet length rather than immediately terminating the connection. > This eliminates most of the known differences in behaviour that > leaked information about the plaintext of injected data which formed > the basis of this attack. We believe that these attacks are rendered > infeasible by these changes. > > New features: > > * Added a -y option to ssh(1) to force logging to syslog rather than > stderr, which is useful when running daemonised (ssh -f) > > * The sshd_config(5) ForceCommand directive now accepts commandline > arguments for the internal-sftp server. > > * The ssh(1) ~C escape commandline now support runtime creation of > dynamic (-D) port forwards. > > * Support the SOCKS4A protocol in ssh(1) dynamic (-D) forwards. > (bz#1482) > > * Support remote port forwarding with a listen port of '0'. This > informs the server that it should dynamically allocate a listen > port and report it back to the client. (bz#1003) > > * sshd(8) now supports setting PermitEmptyPasswords and > AllowAgentForwarding in Match blocks > > Bug and documentation fixes > > * Repair a ssh(1) crash introduced in openssh-5.1 when the client is > sent a zero-length banner (bz#1496) > > * Due to interoperability problems with certain > broken SSH implementations, the eow at openssh.com and > no-more-sessions at openssh.com protocol extensions are now only sent > to peers that identify themselves as OpenSSH. > > * Make ssh(1) send the correct channel number for > SSH2_MSG_CHANNEL_SUCCESS and SSH2_MSG_CHANNEL_FAILURE messages to > avoid triggering 'Non-public channel' error messages on sshd(8) in > openssh-5.1. > > * Avoid printing 'Non-public channel' warnings in sshd(8), since the > ssh(1) has sent incorrect channel numbers since ~2004 (this reverts > a behaviour introduced in openssh-5.1). > > * Avoid double-free in ssh(1) ~C escape -L handler (bz#1539) > > * Correct fail-on-error behaviour in sftp(1) batchmode for remote > stat operations. (bz#1541) > > * Disable nonfunctional ssh(1) ~C escape handler in multiplex slave > connections. (bz#1543) > > * Avoid hang in ssh(1) when attempting to connect to a server that > has MaxSessions=0 set. > > * Multiple fixes to sshd(8) configuration test (-T) mode > > * Several core and portable OpenSSH bugs fixed: 1380, 1412, 1418, > 1419, 1421, 1490, 1491, 1492, 1514, 1515, 1518, 1520, 1538, 1540 > > * Many manual page improvements. > > > -d > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From f_mohr at yahoo.de Thu Feb 19 04:06:49 2009 From: f_mohr at yahoo.de (Frank Mohr) Date: Wed, 18 Feb 2009 18:06:49 +0100 Subject: Call for testing: openssh-5.2 In-Reply-To: References: Message-ID: <499C4029.2010904@yahoo.de> System: AIX 5.2 Result: all tests passed System: AIX 5.3 Result: all tests passed on both systems the test "agent-getpeereid.sh" was skipped: need SUDO to switch to uid nobody frank ___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de From folkert at vanheusden.com Thu Feb 19 08:34:33 2009 From: folkert at vanheusden.com (Folkert van Heusden) Date: Wed, 18 Feb 2009 22:34:33 +0100 Subject: ssh -f & pid Message-ID: <20090218213433.GI16949@vanheusden.com> Hi, Ssh -f forks itself in the background. Very usefull if you would like to e.g. tunnel munin over ssh. Now it's tricky to terminate one process if you have multiple running. It seems that ssh currently (looked at 5.1p1) has no write-pid-to-file functionality So I implemented a patch which do so. Tested it a little and it seems to work. Hopefully it is of any use in my form or inspires the developers to implement this kind of functionality in the ssh distribution. Url: http://www.vanheusden.com/Linux/openssh-5.1p1_writepidfile.diff.gz And the patch itself: diff -uNrBbd openssh-5.1p1.org/ssh.c openssh-5.1p1.new/ssh.c --- openssh-5.1p1.org/ssh.c 2008-07-04 04:53:50.000000000 +0200 +++ openssh-5.1p1.new/ssh.c 2009-02-18 21:15:26.000000000 +0100 @@ -140,6 +140,9 @@ /* optional user configfile */ char *config = NULL; +/* file to write the pid in after daemonizing */ +char *pid_file = NULL; + /* * Name of the host we are connecting to. This is the name given on the * command line, or the HostName specified for the user-supplied name in a @@ -185,6 +188,7 @@ " [-l login_name] [-m mac_spec] [-O ctl_cmd] [-o option] [-p port]\n" " [-R [bind_address:]port:host:hostport] [-S ctl_path]\n" " [-w local_tun[:remote_tun]] [user@]hostname [command]\n" +" [-z pid_file]\n" ); exit(255); } @@ -197,6 +201,26 @@ void muxclient(const char *); void muxserver_listen(void); +int write_pid_file(char *pid_file) +{ + char buffer[16]; + int len; + int fd = open(pid_file, O_WRONLY | O_EXCL | O_CREAT, 0644); + if (fd == -1) + return -1; + + len = snprintf(buffer, sizeof(buffer), "%d\n", getpid()); + if (write(fd, buffer, len) != len) + { + close(fd); + return -1; + } + + close(fd); + + return 0; +} + /* * Main program for the ssh client. */ @@ -271,9 +295,12 @@ host = NULL; again: - while ((opt = getopt(ac, av, "1246ab:c:e:fgi:kl:m:no:p:qstvx" + while ((opt = getopt(ac, av, "1246ab:c:e:fgi:kl:m:no:p:qstvxz:" "ACD:F:I:KL:MNO:PR:S:TVw:XY")) != -1) { switch (opt) { + case 'z': + pid_file = optarg; + break; case '1': options.protocol = SSH_PROTO_1; break; @@ -833,6 +860,9 @@ if (options.control_path != NULL && muxserver_sock != -1) unlink(options.control_path); + if (pid_file) + unlink(pid_file); + /* * Send SIGHUP to proxy command if used. We don't wait() in * case it hangs and instead rely on init to reap the child @@ -1080,6 +1110,12 @@ fatal("daemon() failed: %.200s", strerror(errno)); } + if (pid_file) + { + if (write_pid_file(pid_file) == -1) + fatal("write_pid(%s) failed: %.200s", pid_file, strerror(errno)); + } + /* * If a command was specified on the command line, execute the * command now. Otherwise request the server to start a shell. @@ -1223,6 +1259,12 @@ fatal("daemon() failed: %.200s", strerror(errno)); } + if (pid_file) + { + if (write_pid_file(pid_file) == -1) + fatal("write_pid(%s) failed: %.200s", pid_file, strerror(errno)); + } + return client_loop(tty_flag, tty_flag ? options.escape_char : SSH_ESCAPECHAR_NONE, id); } Folkert van Heusden -- MultiTail is a versatile tool for watching logfiles and output of commands. Filtering, coloring, merging, diff-view, etc. http://www.vanheusden.com/multitail/ ---------------------------------------------------------------------- Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com From djm at mindrot.org Thu Feb 19 09:11:58 2009 From: djm at mindrot.org (Damien Miller) Date: Thu, 19 Feb 2009 09:11:58 +1100 (EST) Subject: ssh -f & pid In-Reply-To: <20090218213433.GI16949@vanheusden.com> References: <20090218213433.GI16949@vanheusden.com> Message-ID: On Wed, 18 Feb 2009, Folkert van Heusden wrote: > Hi, > > Ssh -f forks itself in the background. Very usefull if you would like to > e.g. tunnel munin over ssh. Now it's tricky to terminate one process if > you have multiple running. You can use ControlMaster to set a listen socket for your backgrounded connections and then "ssh -O exit" to terminate them. -d From vadud3 at gmail.com Fri Feb 20 04:48:14 2009 From: vadud3 at gmail.com (Asif Iqbal) Date: Thu, 19 Feb 2009 12:48:14 -0500 Subject: Connection reset by peer Message-ID: I am getting the 'Connection reset by peer' only sometimes when I run this command (user)host:~$ /usr/local/bin/ssh example.net "cat /this/file > /tmp/file" Read from remote host example.net: Connection reset by peer (user)host:~$ (user)host:~$ /usr/local/bin/ssh example.net "cat /this/file > /tmp/file" (user)host:~$ Any idea where to look for troubleshooting. Since it is not consistent, it is very difficult to trouble the usual way with truss and ssh debug. -- Asif Iqbal PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? From pulkitsinghal at gmail.com Fri Feb 20 07:12:08 2009 From: pulkitsinghal at gmail.com (Pulkit Singhal) Date: Thu, 19 Feb 2009 12:12:08 -0800 Subject: How to encode Non-English directories and filenames Message-ID: <15dcf8060902191212icf28930t992472f0a3fbb81a@mail.gmail.com> Hello All, I have a custom client which successfully connects to the SSH server both on cygwin/OpenSSH-server running on windows and to standard SSH servers runnign on Linux. If I send a command like the following in bytes: ==== mkdir ==== after having encoded the whole command in bytes with Shift_JIS, to a linux SSH server ... it works. BUT if I send a similar command to a cygwin/SSH-server on windows, it fails. It seems like the OpenSSH implementation does not honor the default system encoding specified by the windows operating system for non-Unicode programs. 1) Can someone please hint at what kind of encoding the OpenSSH server would prefer to get its data or decipher user commands in? I hope you say something like UTF-8 or a similar superset. 2) Can you also maybe recommend how to escape my characters, if that's the way to go? Right now if I browse to an existing directory (from the server machine itself using cygwin and NOT my client) with I can see that it likes to escape in this manner: cd \220V\202\265\202\242\203t\203H\203\213\203_/ I just don't know what kind of escape-sequence notation this is ... it seems to resemble Unicode escapes but not exactly. Looking forward to your input .... Thanks! From basavarajdengi at gmail.com Fri Feb 20 18:39:01 2009 From: basavarajdengi at gmail.com (Basavaraj Dengi) Date: Fri, 20 Feb 2009 13:09:01 +0530 Subject: openssh-5.1p1 configure failure Message-ID: <914d879d0902192339x71f44fe2ud35613d7527df4d0@mail.gmail.com> Hi If I try to run configure for openssh-5.1p1 with --wtih-selinux option it fails giving the error "selinux support requires selinux library" all of the below also dont work a) --wtih-selinux b) --wtih-selinux=path of cross complied library c) LDFLAGS=-Lpath of cross complied library if I remove --wtih-selinux option I am able to everything is fine. How to solve this error? Thanks for your time Regards Basavaraj From djm at mindrot.org Fri Feb 20 18:43:16 2009 From: djm at mindrot.org (Damien Miller) Date: Fri, 20 Feb 2009 18:43:16 +1100 (EST) Subject: openssh-5.1p1 configure failure In-Reply-To: <914d879d0902192339x71f44fe2ud35613d7527df4d0@mail.gmail.com> References: <914d879d0902192339x71f44fe2ud35613d7527df4d0@mail.gmail.com> Message-ID: On Fri, 20 Feb 2009, Basavaraj Dengi wrote: > Hi > > If I try to run configure for openssh-5.1p1 with --wtih-selinux option > it fails giving the error "selinux support requires selinux library" > > all of the below also dont work > > a) --wtih-selinux > b) --wtih-selinux=path of cross complied library > c) LDFLAGS=-Lpath of cross complied library > > if I remove --wtih-selinux option I am able to everything is fine. > How to solve this error? You can look in config.log after a failure to see what is going wrong. -d From vinschen at redhat.com Fri Feb 20 20:31:06 2009 From: vinschen at redhat.com (Corinna Vinschen) Date: Fri, 20 Feb 2009 10:31:06 +0100 Subject: How to encode Non-English directories and filenames In-Reply-To: <15dcf8060902191212icf28930t992472f0a3fbb81a@mail.gmail.com> References: <15dcf8060902191212icf28930t992472f0a3fbb81a@mail.gmail.com> Message-ID: <20090220093106.GA906@calimero.vinschen.de> On Feb 19 12:12, Pulkit Singhal wrote: > Hello All, > > I have a custom client which successfully connects to the SSH server > both on cygwin/OpenSSH-server running on windows and to standard SSH > servers runnign on Linux. > > If I send a command like the following in bytes: > ==== > mkdir > ==== > after having encoded the whole command in bytes with Shift_JIS, to a > linux SSH server ... it works. > > BUT if I send a similar command to a cygwin/SSH-server on windows, it fails. > > It seems like the OpenSSH implementation does not honor the default > system encoding specified by the windows operating system for > non-Unicode programs. You can try running the sshd service with the environment variable CYGWIN set to "codepage:oem" plus setting LC_CTYPE to "C-JIS". Native language support in Cygwin exists only marginally, especially since the underlying newlib C library is lacking in this area quite a bit. I'm working on that, but it will take time. Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From imorgan at nas.nasa.gov Sat Feb 21 11:45:05 2009 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Fri, 20 Feb 2009 16:45:05 -0800 Subject: Call for testing: openssh-5.2 In-Reply-To: References: Message-ID: <20090221004505.GA4464@linux55.nas.nasa.gov> On Sun, Feb 15, 2009 at 22:32:26 -0600, Damien Miller wrote: > Hi, > > OpenSSH 5.2 is almost ready for release, so we would appreciate testing > on as many platforms and systems as possible. This is primarily a bug-fix > release, to follow the feature-focused 5.1 release. > The 20090220 snapshot builds and tests successfully against the following platforms: Red Hat Enterprise Linux 4u7 (x86_64), gcc 3.4.6 Red Hat Enterprise Linux 5.3 (x86_64), gcc 4.1.2 SuSE Linux Enterprise Server 10u2 (x86_64), gcc 4.1.2 SuSE Linux Enterprise Server 10u1 (IA64), gcc 4.1.2 Solaris 9 (SPARC), Forte 7 C Solaris 9 (SPARC), gcc 3.3.1 -- Iain Morgan From peter at stuge.se Sat Feb 21 12:03:53 2009 From: peter at stuge.se (Peter Stuge) Date: Sat, 21 Feb 2009 02:03:53 +0100 Subject: Call for testing: openssh-5.2 In-Reply-To: <20090221004505.GA4464@linux55.nas.nasa.gov> References: <20090221004505.GA4464@linux55.nas.nasa.gov> Message-ID: <20090221010353.7386.qmail@stuge.se> Iain Morgan wrote: > > OpenSSH 5.2 is almost ready for release, so we would appreciate > > testing on as many platforms and systems as possible. > > The 20090220 snapshot builds and tests successfully against the > following platforms: > > Red Hat Enterprise Linux 4u7 (x86_64), gcc 3.4.6 > Red Hat Enterprise Linux 5.3 (x86_64), gcc 4.1.2 > SuSE Linux Enterprise Server 10u2 (x86_64), gcc 4.1.2 > SuSE Linux Enterprise Server 10u1 (IA64), gcc 4.1.2 all tests passed also on 32-bit x86, gcc (Gentoo 4.3.2-r2 p1.5, pie-10.1.5) 4.3.2 //Peter From djm at cvs.openbsd.org Mon Feb 23 13:23:34 2009 From: djm at cvs.openbsd.org (Damien Miller) Date: Sun, 22 Feb 2009 19:23:34 -0700 (MST) Subject: Announce: OpenSSH 5.2 released Message-ID: <200902230223.n1N2NY74014893@cvs.openbsd.org> OpenSSH 5.2 has just been released. It will be available from the mirrors listed at http://www.openssh.com/ shortly. OpenSSH is a 100% complete SSH protocol version 1.3, 1.5 and 2.0 implementation and includes sftp client and server support. We have also recently completed another Internet SSH usage scan, the results of which may be found at http://www.openssh.com/usage.html Once again, we would like to thank the OpenSSH community for their continued support of the project, especially those who contributed code or patches, reported bugs, tested snapshots or donated to the project. More information on donations may be found at: http://www.openssh.com/donations.html The focus of this release has been on bugfixes as the previous openssh-5.1 release introduced many new features and made some invasive changes. Changes since OpenSSH 5.1 ========================= Security: * This release changes the default cipher order to prefer the AES CTR modes and the revised "arcfour256" mode to CBC mode ciphers that are susceptible to CPNI-957037 "Plaintext Recovery Attack Against SSH". * This release also adds countermeasures to mitigate CPNI-957037-style attacks against the SSH protocol's use of CBC-mode ciphers. Upon detection of an invalid packet length or Message Authentication Code, ssh/sshd will continue reading up to the maximum supported packet length rather than immediately terminating the connection. This eliminates most of the known differences in behaviour that leaked information about the plaintext of injected data which formed the basis of this attack. We believe that these attacks are rendered infeasible by these changes. New features: * Added a -y option to ssh(1) to force logging to syslog rather than stderr, which is useful when running daemonised (ssh -f) * The sshd_config(5) ForceCommand directive now accepts commandline arguments for the internal-sftp server. * The ssh(1) ~C escape commandline now support runtime creation of dynamic (-D) port forwards. * Support the SOCKS4A protocol in ssh(1) dynamic (-D) forwards. (bz#1482) * Support remote port forwarding with a listen port of '0'. This informs the server that it should dynamically allocate a listen port and report it back to the client. (bz#1003) * sshd(8) now supports setting PermitEmptyPasswords and AllowAgentForwarding in Match blocks Bug and documentation fixes * Repair a ssh(1) crash introduced in openssh-5.1 when the client is sent a zero-length banner (bz#1496) * Due to interoperability problems with certain broken SSH implementations, the eow at openssh.com and no-more-sessions at openssh.com protocol extensions are now only sent to peers that identify themselves as OpenSSH. * Make ssh(1) send the correct channel number for SSH2_MSG_CHANNEL_SUCCESS and SSH2_MSG_CHANNEL_FAILURE messages to avoid triggering 'Non-public channel' error messages on sshd(8) in openssh-5.1. * Avoid printing 'Non-public channel' warnings in sshd(8), since the ssh(1) has sent incorrect channel numbers since ~2004 (this reverts a behaviour introduced in openssh-5.1). * Avoid double-free in ssh(1) ~C escape -L handler (bz#1539) * Correct fail-on-error behaviour in sftp(1) batchmode for remote stat operations. (bz#1541) * Disable nonfunctional ssh(1) ~C escape handler in multiplex slave connections. (bz#1543) * Avoid hang in ssh(1) when attempting to connect to a server that has MaxSessions=0 set. * Multiple fixes to sshd(8) configuration test (-T) mode * Several core and portable OpenSSH bugs fixed: 1380, 1412, 1418, 1419, 1421, 1490, 1491, 1492, 1514, 1515, 1518, 1520, 1538, 1540 * Many manual page improvements. Checksums: ========== - SHA1 (openssh-5.2.tar.gz) = 260074ed466e95f054ac05a4406f613d08575217 - SHA1 (openssh-5.2p1.tar.gz) = 8273a0237db98179fbdc412207ff8eb14ff3d6de Reporting Bugs: =============== - Please read http://www.openssh.com/report.html Security bugs should be reported directly to openssh at openssh.com OpenSSH is brought to you by Markus Friedl, Niels Provos, Theo de Raadt, Kevin Steves, Damien Miller, Darren Tucker, Jason McIntyre, Tim Rice and Ben Lindstrom. From openssh at roumenpetrov.info Tue Feb 24 07:22:33 2009 From: openssh at roumenpetrov.info (Roumen Petrov) Date: Mon, 23 Feb 2009 22:22:33 +0200 Subject: Announce: X.509 certificates support v6.2 for OpenSSH version 5.2p1 Message-ID: <49A30589.6070903@roumenpetrov.info> Hi All, Version 6.2 of "X.509 certificates support in OpenSSH" is ready for immediate download. Visit "http://roumenpetrov.info/openssh/" for details. Regards, Roumen Petrov From wieland at purdue.edu Wed Feb 25 03:02:22 2009 From: wieland at purdue.edu (Jeff Wieland) Date: Tue, 24 Feb 2009 11:02:22 -0500 Subject: Hanging ssh sessions with openssh-5.[12]p1 and Solaris 8 & 10 In-Reply-To: <4897C65B.9030605@purdue.edu> References: <48974BAF.1020402@purdue.edu> <20080805011902.GA19142@gate.dtucker.net> <4897C65B.9030605@purdue.edu> Message-ID: <49A41A0E.8060707@purdue.edu> Jeff Wieland wrote: > Darren Tucker wrote: >> On Mon, Aug 04, 2008 at 02:34:23PM -0400, Jeff Wieland wrote: >>> Since we upgraded OpenSSH from 5.0p1 to 5.1p1 on our Solaris 8 boxes >>> (I know, I know, we should upgrade or retire them...), we've started >>> experiencing problems with slogin'ing into these boxes, running vi, >>> and pasting text into the vi session. >>> >>> As long as we are pasting in less that 1024 characters it's fine. >>> With >= 1024 characters, the session hangs. >> Do you know if the problem occurs on the client or server side? ie if >> you use an older client with a newer server (and vice versa) does the >> problem occur? > > It's the server side. It still happens if you use the 5.0p1 client, > and it also happens with the SecureCRT client. > >>> If you run "/usr/ucb/lptest 72 23 | cat -n" in one window, and >>> then cut paste up to the "V" on line 13, things work as expected. >>> If you include the "W" on the line 13, the vi session will hang >>> with none of characters that are being pasted showing up. >>> >>> We've been building OpenSSH with Sun Studio 11 -- I tried building >>> it with GNU-CC 3.4.4 with the same results. We also link against >>> a locally built zlib, since Solaris 8 doesn't have zlib 1.2.3. >>> And we've used OpenSSL 0.9.8g and 0.9.8h with the same results. >>> >>> We also tried building OpenSSH 5.1p1 on our Solaris 10 boxes using >>> Sun Studio 12, and we also get the hangs there. The client doesn't >>> seem to matter -- we've seen it OpenSSH 5.1p1 from both Solaris >>> and Slackware Linux, and also from SecureCRT. >>> >>> I have not been able to get anything useful from running sshd in >>> debug mode (at least, not that I recognize as useful :-) ). >> Well you could post it, someone else might recognise someting :-) > > I'll see if I can get this done tomorrow. It's a crazy couple of > weeks right now... > >> Some versions of AIX have bugs in the tty drivers that prevent largish >> writes from working correctly. Pehaps Solaris has something similar >> (although I can't imagine why it's only started recently). >> >> You could try the patch below to test this theory. >> >> Index: channels.c >> =================================================================== >> RCS file: /usr/local/src/security/openssh/cvs/openssh/channels.c,v >> retrieving revision 1.273 >> diff -u -p -r1.273 channels.c >> --- channels.c 16 Jul 2008 12:42:06 -0000 1.273 >> +++ channels.c 5 Aug 2008 01:08:22 -0000 >> @@ -1578,11 +1578,10 @@ channel_handle_wfd(Channel *c, fd_set *r >> } >> return 1; >> } >> -#ifdef _AIX >> + >> /* XXX: Later AIX versions can't push as much data to tty */ >> if (compat20 && c->wfd_isatty) >> - dlen = MIN(dlen, 8*1024); >> -#endif >> + dlen = MIN(dlen, 1024); >> >> len = write(c->wfd, buf, dlen); >> if (len < 0 && >> > > OK -- I can try this too. But it isn't necessary with the 5.0p1 sshd, > so I'm thinking that something changed w.r.t. OpenSSH. Sorry for the very long delay :-(. The above patch made no difference to 5.1p1. I'm still seeing this problem with OpenSSH_5.2p1 on Solaris 8 and Solaris 10. I've tried starting sshd with '-d -d -d -e', and when the hang happens sshd doesn't log anything. The 5.1p1 and 5.2p1 servers hang when used with the 5.[012]p1 clients. The 5.0p1 server works fine when used with and of the 5.X clients. -- Jeff Wieland | Purdue University Network Systems Administrator | ITN&S Data Networks Voice: (765)496-8234 | 501 Harrison Street FAX: (765)494-6620 | West Lafayette, IN 47907-2025 From basavarajdengi at gmail.com Wed Feb 25 15:52:19 2009 From: basavarajdengi at gmail.com (Basavaraj Dengi) Date: Wed, 25 Feb 2009 10:22:19 +0530 Subject: openssh-5.1p1 configure failure In-Reply-To: References: <914d879d0902192339x71f44fe2ud35613d7527df4d0@mail.gmail.com> Message-ID: <914d879d0902242052p17d594d3h534ede0899dc4af9@mail.gmail.com> Looking at the config log, the problem is that, configure is not taking the selinux library path[even though I am providing it with -L option] attached is the config.log for your reference. thanks for your time regards basavaraj On Fri, Feb 20, 2009 at 1:13 PM, Damien Miller wrote: > On Fri, 20 Feb 2009, Basavaraj Dengi wrote: > > > Hi > > > > If I try to run configure for openssh-5.1p1 with --wtih-selinux option > > it fails giving the error "selinux support requires selinux library" > > > > all of the below also dont work > > > > a) --wtih-selinux > > b) --wtih-selinux=path of cross complied library > > c) LDFLAGS=-Lpath of cross complied library > > > > if I remove --wtih-selinux option I am able to everything is fine. > > How to solve this error? > > You can look in config.log after a failure to see what is going wrong. > > -d > -------------- next part -------------- A non-text attachment was scrubbed... Name: config.tar.gz Type: application/x-gzip Size: 27918 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20090225/2d73bf88/attachment-0001.bin From sway2004009 at hotmail.com Wed Feb 25 19:04:40 2009 From: sway2004009 at hotmail.com (=?gb2312?B?yqnN/g==?=) Date: Wed, 25 Feb 2009 16:04:40 +0800 Subject: miss handling of the SIGHUP signal for sshd when sshd is started with a relative path sshd_config file Message-ID: Hi I am just porting ssh-5.2 to my HPUX system. but while I'm doing it, I accidently found a different handling of the sshd for the SIGHUP signal when it is started with a "./sshd_config" and "/sshd_config". The problem is as following: root at sshpa6# uname -a HP-UX sshpa6 B.11.31 U 9000/800 2404418693 unlimited-user license root at sshpa6# /opt/ssh/sbin/sshd -f ./sshd_config ### ./sshd_config is a relative path root at sshpa6# ps -ef|grep sshd root 12616 1 0 15:51:00 ? 0:00 /opt/ssh/sbin/sshd -f ./sshd_config root 12618 17401 0 15:51:03 pts/tb 0:00 grep sshd root at sshpa6# kill -HUP 12616 root at sshpa6# ps -ef|grep sshd root 12620 17401 0 15:51:12 pts/tb 0:00 grep sshd ### sshd is killed but not restarted as it should be. So is it a bug or a normal situation? -Best Regards -Sway Thanks. _________________________________________________________________ ?????????????????????????????? http://piao.live.com/?form=PANER01 From tiagomnm at gmail.com Thu Feb 26 00:33:04 2009 From: tiagomnm at gmail.com (Tiago Marques) Date: Wed, 25 Feb 2009 13:33:04 +0000 Subject: Disabling specific port-forwarding Message-ID: Hi all, I have a server where I allow some people to do SSH port forwarding for SVN, GIT, since I need to do that to access these services in certain locations. I can't access SVN ports in some work locations. Thing is, I also give specific access to some user accounts, mainly git and svn user, to some people I don't fully trust to have access to my VNC server, which is without password since it doesn't make any sense to have it there either way. If someone tries to do a tunnel of the VNC port with any of the other users that not the user run the VNC session, they have full access to that session and the computer. The idea is to be able to limit both svn and git users to tunnel only to the service specific port. I know I have done this once but can't seem to find the right options now. What can I do? I want to open all ports to some users but limit some for the rest(3-4 different user accounts). Best regards, Tiago Marques From peter at stuge.se Thu Feb 26 01:59:04 2009 From: peter at stuge.se (Peter Stuge) Date: Wed, 25 Feb 2009 15:59:04 +0100 Subject: Disabling specific port-forwarding In-Reply-To: References: Message-ID: <20090225145904.9844.qmail@stuge.se> Tiago Marques wrote: > What can I do? I want to open all ports to some users but limit > some for the rest(3-4 different user accounts). One way is to use permitopen= in authorized_keys. Then you even get a setting per key. //Peter From vinschen at redhat.com Thu Feb 26 03:22:18 2009 From: vinschen at redhat.com (Corinna Vinschen) Date: Wed, 25 Feb 2009 17:22:18 +0100 Subject: An old new idea, and a Cygwin patch (was Re: Call for testing: openssh-5.2) In-Reply-To: References: <20090216135649.GH5416@calimero.vinschen.de> Message-ID: <20090225162218.GM18319@calimero.vinschen.de> On Feb 17 08:11, Damien Miller wrote: > On Mon, 16 Feb 2009, Corinna Vinschen wrote: > > On Feb 16 15:32, Damien Miller wrote: > > > OpenSSH 5.2 is almost ready for release, [...] > > > > Builds and runs fine on Cygwin 1.7. Since I won't support any new > > OpenSSH package for Cygwin 1.5, and since Cygwin 1.7 will stop > > supporting Windows 9x, I'm wondering if it's ok to strip all Windows 9x > > support, as well as the *really* old Cygwin version considerations from > > OpenSSH at this point. It will strip some extra Cygwin-only code from > > portable SSH. Or, maybe we should do that right after the 5.2p1 release? > > Yes, we can do this after the release of 5.2p1. Below is the patch to remove support for Windows 95/98/Me as well as support for very old versions of Cygwin. Please apply. What's still missing in the upstream sources is code which abstracts the idea of the root user to the idea of a user with certain privileges. Cygwin/Windows is not the only platform which has the capability to give finer grained user rights to a user, so that certain types of tasks are not necessarily run by the root user. Given that, the hardcoded checks for uid == 0 don't make sense in many environments. To reiterate an idea I'm proposing for quite some time now: Instead of checks as if (getuid() == 0) do_foo_bar (); else EEEEK! openssh should have checks along the lines of if (uid_has_capability (getuid (), CAP_foo_bar)) do_foo_bar (); else EEEEK! The function uid_has_capability() would be quite simple on systems which don't have fine-grained user rights: int uid_has_capability (uid_t uid, int capability) { return uid == 0; } but could be much more elaborate on other platforms like Linux, Solaris, or Cygwin. And, again, I'm willing to help with this stuff in terms of coding. Corinna Index: auth-passwd.c =================================================================== RCS file: /cvs/openssh/auth-passwd.c,v retrieving revision 1.89 diff -u -p -r1.89 auth-passwd.c --- auth-passwd.c 26 Oct 2007 04:25:12 -0000 1.89 +++ auth-passwd.c 25 Feb 2009 16:06:53 -0000 @@ -102,7 +102,7 @@ auth_password(Authctxt *authctxt, const } #endif #ifdef HAVE_CYGWIN - if (is_winnt) { + { HANDLE hToken = cygwin_logon_user(pw, password); if (hToken == INVALID_HANDLE_VALUE) Index: auth1.c =================================================================== RCS file: /cvs/openssh/auth1.c,v retrieving revision 1.124 diff -u -p -r1.124 auth1.c --- auth1.c 9 Jul 2008 10:54:05 -0000 1.124 +++ auth1.c 25 Feb 2009 16:06:53 -0000 @@ -318,15 +318,7 @@ do_authloop(Authctxt *authctxt) } #endif /* _UNICOS */ -#ifdef HAVE_CYGWIN - if (authenticated && - !check_nt_auth(type == SSH_CMSG_AUTH_PASSWORD, - authctxt->pw)) { - packet_disconnect("Authentication rejected for uid %d.", - authctxt->pw == NULL ? -1 : authctxt->pw->pw_uid); - authenticated = 0; - } -#else +#ifndef HAVE_CYGWIN /* Special handling for root */ if (authenticated && authctxt->pw->pw_uid == 0 && !auth_root_allowed(meth->name)) { Index: auth2-kbdint.c =================================================================== RCS file: /cvs/openssh/auth2-kbdint.c,v retrieving revision 1.7 diff -u -p -r1.7 auth2-kbdint.c --- auth2-kbdint.c 1 Sep 2006 05:38:36 -0000 1.7 +++ auth2-kbdint.c 25 Feb 2009 16:06:53 -0000 @@ -58,10 +58,6 @@ userauth_kbdint(Authctxt *authctxt) xfree(devs); xfree(lang); -#ifdef HAVE_CYGWIN - if (check_nt_auth(0, authctxt->pw) == 0) - authenticated = 0; -#endif return authenticated; } Index: auth2-none.c =================================================================== RCS file: /cvs/openssh/auth2-none.c,v retrieving revision 1.19 diff -u -p -r1.19 auth2-none.c --- auth2-none.c 2 Jul 2008 12:56:09 -0000 1.19 +++ auth2-none.c 25 Feb 2009 16:06:53 -0000 @@ -61,10 +61,6 @@ userauth_none(Authctxt *authctxt) { none_enabled = 0; packet_check_eom(); -#ifdef HAVE_CYGWIN - if (check_nt_auth(1, authctxt->pw) == 0) - return (0); -#endif if (options.password_authentication) return (PRIVSEP(auth_password(authctxt, ""))); return (0); Index: auth2-passwd.c =================================================================== RCS file: /cvs/openssh/auth2-passwd.c,v retrieving revision 1.11 diff -u -p -r1.11 auth2-passwd.c --- auth2-passwd.c 5 Aug 2006 02:39:39 -0000 1.11 +++ auth2-passwd.c 25 Feb 2009 16:06:53 -0000 @@ -68,10 +68,6 @@ userauth_passwd(Authctxt *authctxt) logit("password change not supported"); else if (PRIVSEP(auth_password(authctxt, password)) == 1) authenticated = 1; -#ifdef HAVE_CYGWIN - if (check_nt_auth(1, authctxt->pw) == 0) - authenticated = 0; -#endif memset(password, 0, len); xfree(password); return authenticated; Index: auth2-pubkey.c =================================================================== RCS file: /cvs/openssh/auth2-pubkey.c,v retrieving revision 1.20 diff -u -p -r1.20 auth2-pubkey.c --- auth2-pubkey.c 4 Jul 2008 02:54:25 -0000 1.20 +++ auth2-pubkey.c 25 Feb 2009 16:06:53 -0000 @@ -170,10 +170,6 @@ done: key_free(key); xfree(pkalg); xfree(pkblob); -#ifdef HAVE_CYGWIN - if (check_nt_auth(0, authctxt->pw) == 0) - authenticated = 0; -#endif return authenticated; } Index: session.c =================================================================== RCS file: /cvs/openssh/session.c,v retrieving revision 1.380 diff -u -p -r1.380 session.c --- session.c 28 Jan 2009 05:29:49 -0000 1.380 +++ session.c 25 Feb 2009 16:06:54 -0000 @@ -571,8 +571,7 @@ do_exec_no_pty(Session *s, const char *c signal(WJSIGNAL, cray_job_termination_handler); #endif /* _UNICOS */ #ifdef HAVE_CYGWIN - if (is_winnt) - cygwin_set_impersonation_token(INVALID_HANDLE_VALUE); + cygwin_set_impersonation_token(INVALID_HANDLE_VALUE); #endif s->pid = pid; @@ -726,8 +725,7 @@ do_exec_pty(Session *s, const char *comm signal(WJSIGNAL, cray_job_termination_handler); #endif /* _UNICOS */ #ifdef HAVE_CYGWIN - if (is_winnt) - cygwin_set_impersonation_token(INVALID_HANDLE_VALUE); + cygwin_set_impersonation_token(INVALID_HANDLE_VALUE); #endif s->pid = pid; @@ -1116,7 +1114,7 @@ do_setup_env(Session *s, const char *she u_int i, envsize; char **env, *laddr; struct passwd *pw = s->pw; -#ifndef HAVE_LOGIN_CAP +#if !defined (HAVE_LOGIN_CAP) && !defined (HAVE_CYGWIN) char *path = NULL; #endif @@ -1551,9 +1549,6 @@ do_setusercontext(struct passwd *pw) #endif } -#ifdef HAVE_CYGWIN - if (is_winnt) -#endif if (getuid() != pw->pw_uid || geteuid() != pw->pw_uid) fatal("Failed to set uids to %u.", (u_int) pw->pw_uid); Index: openbsd-compat/bsd-cygwin_util.c =================================================================== RCS file: /cvs/openssh/openbsd-compat/bsd-cygwin_util.c,v retrieving revision 1.20 diff -u -p -r1.20 bsd-cygwin_util.c --- openbsd-compat/bsd-cygwin_util.c 17 Jul 2008 09:03:49 -0000 1.20 +++ openbsd-compat/bsd-cygwin_util.c 25 Feb 2009 16:06:54 -0000 @@ -39,9 +39,6 @@ #endif #include -#include -#include -#include #include #include @@ -49,11 +46,6 @@ #include #include "xmalloc.h" -#define is_winnt (GetVersion() < 0x80000000) - -#define ntsec_on(c) ((c) && strstr((c),"ntsec") && !strstr((c),"nontsec")) -#define ntsec_off(c) ((c) && strstr((c),"nontsec")) -#define ntea_on(c) ((c) && strstr((c),"ntea") && !strstr((c),"nontea")) int binary_open(const char *filename, int flags, ...) @@ -79,126 +71,10 @@ binary_pipe(int fd[2]) return (ret); } -#define HAS_CREATE_TOKEN 1 -#define HAS_NTSEC_BY_DEFAULT 2 -#define HAS_CREATE_TOKEN_WO_NTSEC 3 - -static int -has_capability(int what) -{ - static int inited; - static int has_create_token; - static int has_ntsec_by_default; - static int has_create_token_wo_ntsec; - - /* - * has_capability() basically calls uname() and checks if - * specific capabilities of Cygwin can be evaluated from that. - * This simplifies the calling functions which only have to ask - * for a capability using has_capability() instead of having - * to figure that out by themselves. - */ - if (!inited) { - struct utsname uts; - - if (!uname(&uts)) { - int major_high = 0, major_low = 0, minor = 0; - int api_major_version = 0, api_minor_version = 0; - char *c; - - sscanf(uts.release, "%d.%d.%d", &major_high, - &major_low, &minor); - if ((c = strchr(uts.release, '(')) != NULL) { - sscanf(c + 1, "%d.%d", &api_major_version, - &api_minor_version); - } - if (major_high > 1 || - (major_high == 1 && (major_low > 3 || - (major_low == 3 && minor >= 2)))) - has_create_token = 1; - if (api_major_version > 0 || api_minor_version >= 56) - has_ntsec_by_default = 1; - if (major_high > 1 || - (major_high == 1 && major_low >= 5)) - has_create_token_wo_ntsec = 1; - inited = 1; - } - } - switch (what) { - case HAS_CREATE_TOKEN: - return (has_create_token); - case HAS_NTSEC_BY_DEFAULT: - return (has_ntsec_by_default); - case HAS_CREATE_TOKEN_WO_NTSEC: - return (has_create_token_wo_ntsec); - } - return (0); -} - -int -check_nt_auth(int pwd_authenticated, struct passwd *pw) -{ - /* - * The only authentication which is able to change the user - * context on NT systems is the password authentication. So - * we deny all requsts for changing the user context if another - * authentication method is used. - * - * This doesn't apply to Cygwin versions >= 1.3.2 anymore which - * uses the undocumented NtCreateToken() call to create a user - * token if the process has the appropriate privileges and if - * CYGWIN ntsec setting is on. - */ - static int has_create_token = -1; - - if (pw == NULL) - return 0; - if (is_winnt) { - if (has_create_token < 0) { - char *cygwin = getenv("CYGWIN"); - - has_create_token = 0; - if (has_capability(HAS_CREATE_TOKEN) && - (ntsec_on(cygwin) || - (has_capability(HAS_NTSEC_BY_DEFAULT) && - !ntsec_off(cygwin)) || - has_capability(HAS_CREATE_TOKEN_WO_NTSEC))) - has_create_token = 1; - } - if (has_create_token < 1 && - !pwd_authenticated && geteuid() != pw->pw_uid) - return (0); - } - return (1); -} - int check_ntsec(const char *filename) { return (pathconf(filename, _PC_POSIX_PERMISSIONS)); -} - -void -register_9x_service(void) -{ - HINSTANCE kerneldll; - DWORD (*RegisterServiceProcess)(DWORD, DWORD); - - /* The service register mechanism in 9x/Me is pretty different from - * NT/2K/XP. In NT/2K/XP we're using a special service starter - * application to register and control sshd as service. This method - * doesn't play nicely with 9x/Me. For that reason we register here - * as service when running under 9x/Me. This function is only called - * by the child sshd when it's going to daemonize. - */ - if (is_winnt) - return; - if (!(kerneldll = LoadLibrary("KERNEL32.DLL"))) - return; - if (!(RegisterServiceProcess = (DWORD (*)(DWORD, DWORD)) - GetProcAddress(kerneldll, "RegisterServiceProcess"))) - return; - RegisterServiceProcess(0, 1); } #define NL(x) x, (sizeof (x) - 1) Index: openbsd-compat/daemon.c =================================================================== RCS file: /cvs/openssh/openbsd-compat/daemon.c,v retrieving revision 1.9 diff -u -p -r1.9 daemon.c --- openbsd-compat/daemon.c 2 Aug 2006 13:33:55 -0000 1.9 +++ openbsd-compat/daemon.c 25 Feb 2009 16:06:54 -0000 @@ -57,18 +57,8 @@ daemon(int nochdir, int noclose) case -1: return (-1); case 0: -#ifdef HAVE_CYGWIN - register_9x_service(); -#endif break; default: -#ifdef HAVE_CYGWIN - /* - * This sleep avoids a race condition which kills the - * child process if parent is started by a NT/W2K service. - */ - sleep(1); -#endif _exit(0); } -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From vinschen at redhat.com Thu Feb 26 03:35:44 2009 From: vinschen at redhat.com (Corinna Vinschen) Date: Wed, 25 Feb 2009 17:35:44 +0100 Subject: An old new idea, and a Cygwin patch (was Re: Call for testing: openssh-5.2) In-Reply-To: <20090225162218.GM18319@calimero.vinschen.de> References: <20090216135649.GH5416@calimero.vinschen.de> <20090225162218.GM18319@calimero.vinschen.de> Message-ID: <20090225163544.GN18319@calimero.vinschen.de> On Feb 25 17:22, Corinna Vinschen wrote: > Below is the patch to remove support for Windows 95/98/Me as well > as support for very old versions of Cygwin. Please apply. The patchset was missing the patch to openbsd-compat/bsd-cygwin_util.h, sorry. I attached the full patchset to this mail again. Corinna Index: auth-passwd.c =================================================================== RCS file: /cvs/openssh/auth-passwd.c,v retrieving revision 1.89 diff -u -p -r1.89 auth-passwd.c --- auth-passwd.c 26 Oct 2007 04:25:12 -0000 1.89 +++ auth-passwd.c 25 Feb 2009 16:06:53 -0000 @@ -102,7 +102,7 @@ auth_password(Authctxt *authctxt, const } #endif #ifdef HAVE_CYGWIN - if (is_winnt) { + { HANDLE hToken = cygwin_logon_user(pw, password); if (hToken == INVALID_HANDLE_VALUE) Index: auth1.c =================================================================== RCS file: /cvs/openssh/auth1.c,v retrieving revision 1.124 diff -u -p -r1.124 auth1.c --- auth1.c 9 Jul 2008 10:54:05 -0000 1.124 +++ auth1.c 25 Feb 2009 16:06:53 -0000 @@ -318,15 +318,7 @@ do_authloop(Authctxt *authctxt) } #endif /* _UNICOS */ -#ifdef HAVE_CYGWIN - if (authenticated && - !check_nt_auth(type == SSH_CMSG_AUTH_PASSWORD, - authctxt->pw)) { - packet_disconnect("Authentication rejected for uid %d.", - authctxt->pw == NULL ? -1 : authctxt->pw->pw_uid); - authenticated = 0; - } -#else +#ifndef HAVE_CYGWIN /* Special handling for root */ if (authenticated && authctxt->pw->pw_uid == 0 && !auth_root_allowed(meth->name)) { Index: auth2-kbdint.c =================================================================== RCS file: /cvs/openssh/auth2-kbdint.c,v retrieving revision 1.7 diff -u -p -r1.7 auth2-kbdint.c --- auth2-kbdint.c 1 Sep 2006 05:38:36 -0000 1.7 +++ auth2-kbdint.c 25 Feb 2009 16:06:53 -0000 @@ -58,10 +58,6 @@ userauth_kbdint(Authctxt *authctxt) xfree(devs); xfree(lang); -#ifdef HAVE_CYGWIN - if (check_nt_auth(0, authctxt->pw) == 0) - authenticated = 0; -#endif return authenticated; } Index: auth2-none.c =================================================================== RCS file: /cvs/openssh/auth2-none.c,v retrieving revision 1.19 diff -u -p -r1.19 auth2-none.c --- auth2-none.c 2 Jul 2008 12:56:09 -0000 1.19 +++ auth2-none.c 25 Feb 2009 16:06:53 -0000 @@ -61,10 +61,6 @@ userauth_none(Authctxt *authctxt) { none_enabled = 0; packet_check_eom(); -#ifdef HAVE_CYGWIN - if (check_nt_auth(1, authctxt->pw) == 0) - return (0); -#endif if (options.password_authentication) return (PRIVSEP(auth_password(authctxt, ""))); return (0); Index: auth2-passwd.c =================================================================== RCS file: /cvs/openssh/auth2-passwd.c,v retrieving revision 1.11 diff -u -p -r1.11 auth2-passwd.c --- auth2-passwd.c 5 Aug 2006 02:39:39 -0000 1.11 +++ auth2-passwd.c 25 Feb 2009 16:06:53 -0000 @@ -68,10 +68,6 @@ userauth_passwd(Authctxt *authctxt) logit("password change not supported"); else if (PRIVSEP(auth_password(authctxt, password)) == 1) authenticated = 1; -#ifdef HAVE_CYGWIN - if (check_nt_auth(1, authctxt->pw) == 0) - authenticated = 0; -#endif memset(password, 0, len); xfree(password); return authenticated; Index: auth2-pubkey.c =================================================================== RCS file: /cvs/openssh/auth2-pubkey.c,v retrieving revision 1.20 diff -u -p -r1.20 auth2-pubkey.c --- auth2-pubkey.c 4 Jul 2008 02:54:25 -0000 1.20 +++ auth2-pubkey.c 25 Feb 2009 16:06:53 -0000 @@ -170,10 +170,6 @@ done: key_free(key); xfree(pkalg); xfree(pkblob); -#ifdef HAVE_CYGWIN - if (check_nt_auth(0, authctxt->pw) == 0) - authenticated = 0; -#endif return authenticated; } Index: session.c =================================================================== RCS file: /cvs/openssh/session.c,v retrieving revision 1.380 diff -u -p -r1.380 session.c --- session.c 28 Jan 2009 05:29:49 -0000 1.380 +++ session.c 25 Feb 2009 16:06:54 -0000 @@ -571,8 +571,7 @@ do_exec_no_pty(Session *s, const char *c signal(WJSIGNAL, cray_job_termination_handler); #endif /* _UNICOS */ #ifdef HAVE_CYGWIN - if (is_winnt) - cygwin_set_impersonation_token(INVALID_HANDLE_VALUE); + cygwin_set_impersonation_token(INVALID_HANDLE_VALUE); #endif s->pid = pid; @@ -726,8 +725,7 @@ do_exec_pty(Session *s, const char *comm signal(WJSIGNAL, cray_job_termination_handler); #endif /* _UNICOS */ #ifdef HAVE_CYGWIN - if (is_winnt) - cygwin_set_impersonation_token(INVALID_HANDLE_VALUE); + cygwin_set_impersonation_token(INVALID_HANDLE_VALUE); #endif s->pid = pid; @@ -1116,7 +1114,7 @@ do_setup_env(Session *s, const char *she u_int i, envsize; char **env, *laddr; struct passwd *pw = s->pw; -#ifndef HAVE_LOGIN_CAP +#if !defined (HAVE_LOGIN_CAP) && !defined (HAVE_CYGWIN) char *path = NULL; #endif @@ -1551,9 +1549,6 @@ do_setusercontext(struct passwd *pw) #endif } -#ifdef HAVE_CYGWIN - if (is_winnt) -#endif if (getuid() != pw->pw_uid || geteuid() != pw->pw_uid) fatal("Failed to set uids to %u.", (u_int) pw->pw_uid); Index: openbsd-compat/bsd-cygwin_util.c =================================================================== RCS file: /cvs/openssh/openbsd-compat/bsd-cygwin_util.c,v retrieving revision 1.20 diff -u -p -r1.20 bsd-cygwin_util.c --- openbsd-compat/bsd-cygwin_util.c 17 Jul 2008 09:03:49 -0000 1.20 +++ openbsd-compat/bsd-cygwin_util.c 25 Feb 2009 16:06:54 -0000 @@ -39,9 +39,6 @@ #endif #include -#include -#include -#include #include #include @@ -49,11 +46,6 @@ #include #include "xmalloc.h" -#define is_winnt (GetVersion() < 0x80000000) - -#define ntsec_on(c) ((c) && strstr((c),"ntsec") && !strstr((c),"nontsec")) -#define ntsec_off(c) ((c) && strstr((c),"nontsec")) -#define ntea_on(c) ((c) && strstr((c),"ntea") && !strstr((c),"nontea")) int binary_open(const char *filename, int flags, ...) @@ -79,126 +71,10 @@ binary_pipe(int fd[2]) return (ret); } -#define HAS_CREATE_TOKEN 1 -#define HAS_NTSEC_BY_DEFAULT 2 -#define HAS_CREATE_TOKEN_WO_NTSEC 3 - -static int -has_capability(int what) -{ - static int inited; - static int has_create_token; - static int has_ntsec_by_default; - static int has_create_token_wo_ntsec; - - /* - * has_capability() basically calls uname() and checks if - * specific capabilities of Cygwin can be evaluated from that. - * This simplifies the calling functions which only have to ask - * for a capability using has_capability() instead of having - * to figure that out by themselves. - */ - if (!inited) { - struct utsname uts; - - if (!uname(&uts)) { - int major_high = 0, major_low = 0, minor = 0; - int api_major_version = 0, api_minor_version = 0; - char *c; - - sscanf(uts.release, "%d.%d.%d", &major_high, - &major_low, &minor); - if ((c = strchr(uts.release, '(')) != NULL) { - sscanf(c + 1, "%d.%d", &api_major_version, - &api_minor_version); - } - if (major_high > 1 || - (major_high == 1 && (major_low > 3 || - (major_low == 3 && minor >= 2)))) - has_create_token = 1; - if (api_major_version > 0 || api_minor_version >= 56) - has_ntsec_by_default = 1; - if (major_high > 1 || - (major_high == 1 && major_low >= 5)) - has_create_token_wo_ntsec = 1; - inited = 1; - } - } - switch (what) { - case HAS_CREATE_TOKEN: - return (has_create_token); - case HAS_NTSEC_BY_DEFAULT: - return (has_ntsec_by_default); - case HAS_CREATE_TOKEN_WO_NTSEC: - return (has_create_token_wo_ntsec); - } - return (0); -} - -int -check_nt_auth(int pwd_authenticated, struct passwd *pw) -{ - /* - * The only authentication which is able to change the user - * context on NT systems is the password authentication. So - * we deny all requsts for changing the user context if another - * authentication method is used. - * - * This doesn't apply to Cygwin versions >= 1.3.2 anymore which - * uses the undocumented NtCreateToken() call to create a user - * token if the process has the appropriate privileges and if - * CYGWIN ntsec setting is on. - */ - static int has_create_token = -1; - - if (pw == NULL) - return 0; - if (is_winnt) { - if (has_create_token < 0) { - char *cygwin = getenv("CYGWIN"); - - has_create_token = 0; - if (has_capability(HAS_CREATE_TOKEN) && - (ntsec_on(cygwin) || - (has_capability(HAS_NTSEC_BY_DEFAULT) && - !ntsec_off(cygwin)) || - has_capability(HAS_CREATE_TOKEN_WO_NTSEC))) - has_create_token = 1; - } - if (has_create_token < 1 && - !pwd_authenticated && geteuid() != pw->pw_uid) - return (0); - } - return (1); -} - int check_ntsec(const char *filename) { return (pathconf(filename, _PC_POSIX_PERMISSIONS)); -} - -void -register_9x_service(void) -{ - HINSTANCE kerneldll; - DWORD (*RegisterServiceProcess)(DWORD, DWORD); - - /* The service register mechanism in 9x/Me is pretty different from - * NT/2K/XP. In NT/2K/XP we're using a special service starter - * application to register and control sshd as service. This method - * doesn't play nicely with 9x/Me. For that reason we register here - * as service when running under 9x/Me. This function is only called - * by the child sshd when it's going to daemonize. - */ - if (is_winnt) - return; - if (!(kerneldll = LoadLibrary("KERNEL32.DLL"))) - return; - if (!(RegisterServiceProcess = (DWORD (*)(DWORD, DWORD)) - GetProcAddress(kerneldll, "RegisterServiceProcess"))) - return; - RegisterServiceProcess(0, 1); } #define NL(x) x, (sizeof (x) - 1) Index: openbsd-compat/bsd-cygwin_util.h =================================================================== RCS file: /cvs/openssh/openbsd-compat/bsd-cygwin_util.h,v retrieving revision 1.11 diff -u -p -r1.11 bsd-cygwin_util.h --- openbsd-compat/bsd-cygwin_util.h 30 Aug 2004 10:42:08 -0000 1.11 +++ openbsd-compat/bsd-cygwin_util.h 25 Feb 2009 16:32:00 -0000 @@ -35,7 +35,6 @@ #ifdef HAVE_CYGWIN #undef ERROR -#define is_winnt (GetVersion() < 0x80000000) #include #include @@ -43,9 +42,7 @@ int binary_open(const char *, int , ...); int binary_pipe(int fd[2]); -int check_nt_auth(int, struct passwd *); int check_ntsec(const char *); -void register_9x_service(void); char **fetch_windows_environment(void); void free_windows_environment(char **); Index: openbsd-compat/daemon.c =================================================================== RCS file: /cvs/openssh/openbsd-compat/daemon.c,v retrieving revision 1.9 diff -u -p -r1.9 daemon.c --- openbsd-compat/daemon.c 2 Aug 2006 13:33:55 -0000 1.9 +++ openbsd-compat/daemon.c 25 Feb 2009 16:06:54 -0000 @@ -57,18 +57,8 @@ daemon(int nochdir, int noclose) case -1: return (-1); case 0: -#ifdef HAVE_CYGWIN - register_9x_service(); -#endif break; default: -#ifdef HAVE_CYGWIN - /* - * This sleep avoids a race condition which kills the - * child process if parent is started by a NT/W2K service. - */ - sleep(1); -#endif _exit(0); } -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From peter at stuge.se Thu Feb 26 03:36:35 2009 From: peter at stuge.se (Peter Stuge) Date: Wed, 25 Feb 2009 17:36:35 +0100 Subject: miss handling of the SIGHUP signal for sshd when sshd is started with a relative path sshd_config file In-Reply-To: References: Message-ID: <20090225163635.9901.qmail@stuge.se> Hello, ?? wrote: > root at sshpa6# /opt/ssh/sbin/sshd -f ./sshd_config ### ./sshd_config is a relative path > root at sshpa6# ps -ef|grep sshd > root 12616 1 0 15:51:00 ? 0:00 /opt/ssh/sbin/sshd -f ./sshd_config > root 12618 17401 0 15:51:03 pts/tb 0:00 grep sshd > root at sshpa6# kill -HUP 12616 > root at sshpa6# ps -ef|grep sshd > root 12620 17401 0 15:51:12 pts/tb 0:00 grep sshd ### sshd is killed but not restarted as it should be. > > > So is it a bug or a normal situation? Good question. Can you check your log files to try to find more information about why sshd is not started again? //Peter From mouring at eviladmin.org Thu Feb 26 08:03:16 2009 From: mouring at eviladmin.org (Ben Lindstrom) Date: Wed, 25 Feb 2009 15:03:16 -0600 Subject: miss handling of the SIGHUP signal for sshd when sshd is started with a relative path sshd_config file In-Reply-To: References: Message-ID: <0CCE67CF-2A82-4C10-8E24-F55A02D489CD@eviladmin.org> On Feb 25, 2009, at 2:04 AM, ?? wrote: > > Hi > > I am just porting ssh-5.2 to my HPUX system. > > > but while I'm doing it, I accidently found a different handling of > the sshd for the SIGHUP signal when it is started with a "./ > sshd_config" and "/sshd_config". > > The problem is as following: > > root at sshpa6# uname -a > HP-UX sshpa6 B.11.31 U 9000/800 2404418693 unlimited-user license > > root at sshpa6# /opt/ssh/sbin/sshd -f ./sshd_config > ### ./sshd_config is a relative path > root at sshpa6# ps -ef|grep sshd > root 12616 1 0 15:51:00 ? 0:00 /opt/ssh/sbin/sshd - > f ./sshd_config > root 12618 17401 0 15:51:03 pts/tb 0:00 grep sshd > root at sshpa6# kill -HUP 12616 > root at sshpa6# ps -ef|grep sshd > root 12620 17401 0 15:51:12 pts/tb 0:00 grep sshd ### > sshd is killed but not restarted as it should be. > > So is it a bug or a normal situation? > If I had the venture a guess it is because ./xxx is a relative, and after a chdir("/") it is no longer the same location when OpenSSH is - HUP it no longer knows where the configuration file is and thus terminates itself. So yes, I would expect this behavior myself. So the simply truth is you should always do: /path/to/sshd -f /path/ to/sshd_config - Ben From tim at multitalents.net Thu Feb 26 09:02:11 2009 From: tim at multitalents.net (Tim Rice) Date: Wed, 25 Feb 2009 14:02:11 -0800 (PST) Subject: openssh-5.1p1 configure failure In-Reply-To: <914d879d0902242052p17d594d3h534ede0899dc4af9@mail.gmail.com> References: <914d879d0902192339x71f44fe2ud35613d7527df4d0@mail.gmail.com> <914d879d0902242052p17d594d3h534ede0899dc4af9@mail.gmail.com> Message-ID: On Wed, 25 Feb 2009, Basavaraj Dengi wrote: > Looking at the config log, the problem is that, > configure is not taking the selinux library path[even though I am providing > it with -L option] The way configure is currently written, --wtih-selinux=path is not possible. Try the attached patch to configure.ac. You will need to regenerate configure by running autoconf. > attached is the config.log for your reference. > > thanks for your time > > regards > basavaraj > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net -------------- next part -------------- --- configure.ac.old 2008-07-09 04:07:19.000000000 -0700 +++ configure.ac 2009-02-25 13:49:15.293233057 -0800 @@ -3299,14 +3299,39 @@ SELINUX_MSG="no" LIBSELINUX="" AC_ARG_WITH(selinux, - [ --with-selinux Enable SELinux support], + [ --with-selinux[[=PATH]] Enable SELinux support (optionally in PATH)], [ if test "x$withval" != "xno" ; then save_LIBS="$LIBS" + save_LDFLAGS="$LDFLAGS" + save_CPPFLAGS="$CPPFLAGS" + if test -n "${withval}" && \ + test "x${withval}" != "xyes"; then + if test -d "${withval}/lib"; then + if test -n "${need_dash_r}"; then + LDFLAGS="-L${withval}/lib -R${withval}/lib ${LDFLAGS}" + else + LDFLAGS="-L${withval}/lib ${LDFLAGS}" + fi + else + if test -n "${need_dash_r}"; then + LDFLAGS="-L${withval} -R${withval} ${LDFLAGS}" + else + LDFLAGS="-L${withval} ${LDFLAGS}" + fi + fi + if test -d "${withval}/include"; then + CPPFLAGS="-I${withval}/include ${CPPFLAGS}" + else + CPPFLAGS="-I${withval} ${CPPFLAGS}" + fi + fi AC_DEFINE(WITH_SELINUX,1,[Define if you want SELinux support.]) SELINUX_MSG="yes" AC_CHECK_HEADER([selinux/selinux.h], , + CPPFLAGS="$save_CPPFLAGS" AC_MSG_ERROR(SELinux support requires selinux.h header)) AC_CHECK_LIB(selinux, setexeccon, [ LIBSELINUX="-lselinux" ], + LDFLAGS="$save_LDFLAGS" AC_MSG_ERROR(SELinux support requires libselinux library)) SSHDLIBS="$SSHDLIBS $LIBSELINUX" AC_CHECK_FUNCS(getseuserbyname get_default_context_with_level) From sway2004009 at hotmail.com Thu Feb 26 13:19:20 2009 From: sway2004009 at hotmail.com (=?gb2312?B?yqnN/g==?=) Date: Thu, 26 Feb 2009 10:19:20 +0800 Subject: miss handling of the SIGHUP signal for sshd when sshd is started with a relative path sshd_config file In-Reply-To: <0CCE67CF-2A82-4C10-8E24-F55A02D489CD@eviladmin.org> References: <0CCE67CF-2A82-4C10-8E24-F55A02D489CD@eviladmin.org> Message-ID: Hi Ben, You are right. But i think it would be better if sshd can get the absolute path of the configure file before it exec. Also, i checked the syslog, it showed no sign of abnormal information about it. So i hope sshd can either change the behavior or give out some log information. -Best Regards -Sway > CC: openssh-unix-dev at mindrot.org > From: mouring at eviladmin.org > To: sway2004009 at hotmail.com > Subject: Re: miss handling of the SIGHUP signal for sshd when sshd is started with a relative path sshd_config file > Date: Wed, 25 Feb 2009 15:03:16 -0600 > > > On Feb 25, 2009, at 2:04 AM, ?? wrote: > > > > > Hi > > > > I am just porting ssh-5.2 to my HPUX system. > > > > > > but while I'm doing it, I accidently found a different handling of > > the sshd for the SIGHUP signal when it is started with a "./ > > sshd_config" and "/sshd_config". > > > > The problem is as following: > > > > root at sshpa6# uname -a > > HP-UX sshpa6 B.11.31 U 9000/800 2404418693 unlimited-user license > > > > root at sshpa6# /opt/ssh/sbin/sshd -f ./sshd_config > > ### ./sshd_config is a relative path > > root at sshpa6# ps -ef|grep sshd > > root 12616 1 0 15:51:00 ? 0:00 /opt/ssh/sbin/sshd - > > f ./sshd_config > > root 12618 17401 0 15:51:03 pts/tb 0:00 grep sshd > > root at sshpa6# kill -HUP 12616 > > root at sshpa6# ps -ef|grep sshd > > root 12620 17401 0 15:51:12 pts/tb 0:00 grep sshd ### > > sshd is killed but not restarted as it should be. > > > > So is it a bug or a normal situation? > > > > If I had the venture a guess it is because ./xxx is a relative, and > after a chdir("/") it is no longer the same location when OpenSSH is - > HUP it no longer knows where the configuration file is and thus > terminates itself. > > So yes, I would expect this behavior myself. > > So the simply truth is you should always do: /path/to/sshd -f /path/ > to/sshd_config > > - Ben _________________________________________________________________ ???????????????????????????? http://chunjie.live.com/?form=PANER01 From opensshmaillist at gmail.com Thu Feb 26 14:01:50 2009 From: opensshmaillist at gmail.com (opensshmaillist maillist) Date: Thu, 26 Feb 2009 11:01:50 +0800 Subject: why i can't send mail to the openssh maillist with my email client software Message-ID: <5b1bc2840902251901v286c85d6y1bd20d83fe56a03b@mail.gmail.com> Hi Any idea? Best Regards. From djm at mindrot.org Thu Feb 26 14:45:25 2009 From: djm at mindrot.org (Damien Miller) Date: Thu, 26 Feb 2009 14:45:25 +1100 (EST) Subject: why i can't send mail to the openssh maillist with my email client software In-Reply-To: <5b1bc2840902251901v286c85d6y1bd20d83fe56a03b@mail.gmail.com> References: <5b1bc2840902251901v286c85d6y1bd20d83fe56a03b@mail.gmail.com> Message-ID: On Thu, 26 Feb 2009, opensshmaillist maillist wrote: > Hi > > Any idea? no. (since you provided absolutely zero information that I could use to actually help you). -d From djm at mindrot.org Thu Feb 26 14:46:40 2009 From: djm at mindrot.org (Damien Miller) Date: Thu, 26 Feb 2009 14:46:40 +1100 (EST) Subject: miss handling of the SIGHUP signal for sshd when sshd is started with a relative path sshd_config file In-Reply-To: <0CCE67CF-2A82-4C10-8E24-F55A02D489CD@eviladmin.org> References: <0CCE67CF-2A82-4C10-8E24-F55A02D489CD@eviladmin.org> Message-ID: On Wed, 25 Feb 2009, Ben Lindstrom wrote: > > On Feb 25, 2009, at 2:04 AM, ?? wrote: > > > > > Hi > > > > I am just porting ssh-5.2 to my HPUX system. > > > > > > but while I'm doing it, I accidently found a different handling of > > the sshd for the SIGHUP signal when it is started with a "./ > > sshd_config" and "/sshd_config". > > > > The problem is as following: > > > > root at sshpa6# uname -a > > HP-UX sshpa6 B.11.31 U 9000/800 2404418693 unlimited-user license > > > > root at sshpa6# /opt/ssh/sbin/sshd -f ./sshd_config > > ### ./sshd_config is a relative path > > root at sshpa6# ps -ef|grep sshd > > root 12616 1 0 15:51:00 ? 0:00 /opt/ssh/sbin/sshd - > > f ./sshd_config > > root 12618 17401 0 15:51:03 pts/tb 0:00 grep sshd > > root at sshpa6# kill -HUP 12616 > > root at sshpa6# ps -ef|grep sshd > > root 12620 17401 0 15:51:12 pts/tb 0:00 grep sshd ### > > sshd is killed but not restarted as it should be. > > > > So is it a bug or a normal situation? > > > > If I had the venture a guess it is because ./xxx is a relative, and > after a chdir("/") it is no longer the same location when OpenSSH is - > HUP it no longer knows where the configuration file is and thus > terminates itself. > > So yes, I would expect this behavior myself. > > So the simply truth is you should always do: /path/to/sshd -f /path/ > to/sshd_config We use relative config paths for the regress tests IIRC, but perhaps we could realpath() them first. -d From alexl at redhat.com Thu Feb 26 20:00:38 2009 From: alexl at redhat.com (Alexander Larsson) Date: Thu, 26 Feb 2009 10:00:38 +0100 Subject: sftp SSH2_FXP_SYMLINK argument order Message-ID: <1235638838.15272.4.camel@fatty> Reading 6.10 Dealing with Symbolic links in http://www.openssh.org/txt/draft-ietf-secsh-filexfer-02.txt it seems to say that the first argument ('linkpath') specifies the name of the symlink file to create. ("linkpath' specifies the path name of the symlink to be created"). However, sftp-server.c:process_symlink() seems to reverse this. I.E. the first argument ('oldpath') is passed as the first argument to symlink(). But for symlink() the second argument specifies the new file to create. I guess its kinda hard to fix this now, as a lot of deployments may rely on the old behaviour. But maybe it would be nice to document this somewhere? From basavarajdengi at gmail.com Thu Feb 26 22:39:25 2009 From: basavarajdengi at gmail.com (Basavaraj Dengi) Date: Thu, 26 Feb 2009 17:09:25 +0530 Subject: openssh-5.1p1 configure failure In-Reply-To: References: <914d879d0902192339x71f44fe2ud35613d7527df4d0@mail.gmail.com> <914d879d0902242052p17d594d3h534ede0899dc4af9@mail.gmail.com> Message-ID: <914d879d0902260339m49c156dj1ad83aa8086ac43d@mail.gmail.com> Thank you very much for the patch file. That indeed helped me; configure, make n make install do work I was actually trying to enable selinux feature in ssh as passwordless ssh to my embedded target is not working for recent kernels. So I tried to 1) disable selinux feature using CMDLINE in the bootloader prompt 2) enable selinux feature in ssh both dint help. with recent kernel binaries ssh is not accepting emptypasswords[I did change sshd_config to accept the emptypasswords] still there is a problem regards basavaraj On Thu, Feb 26, 2009 at 3:32 AM, Tim Rice wrote: > On Wed, 25 Feb 2009, Basavaraj Dengi wrote: > > > Looking at the config log, the problem is that, > > configure is not taking the selinux library path[even though I am > providing > > it with -L option] > > The way configure is currently written, --wtih-selinux=path is not > possible. > Try the attached patch to configure.ac. You will need to regenerate > configure > by running autoconf. > > > attached is the config.log for your reference. > > > > thanks for your time > > > > regards > > basavaraj > > > > -- > Tim Rice Multitalents (707) 887-1469 > tim at multitalents.net > From djm at mindrot.org Thu Feb 26 23:26:07 2009 From: djm at mindrot.org (Damien Miller) Date: Thu, 26 Feb 2009 23:26:07 +1100 (EST) Subject: sftp SSH2_FXP_SYMLINK argument order In-Reply-To: <1235638838.15272.4.camel@fatty> References: <1235638838.15272.4.camel@fatty> Message-ID: On Thu, 26 Feb 2009, Alexander Larsson wrote: > Reading 6.10 Dealing with Symbolic links in > http://www.openssh.org/txt/draft-ietf-secsh-filexfer-02.txt it seems to > say that the first argument ('linkpath') specifies the name of the > symlink file to create. ("linkpath' specifies the path name of the > symlink to be created"). > > However, sftp-server.c:process_symlink() seems to reverse this. > I.E. the first argument ('oldpath') is passed as the first argument to > symlink(). But for symlink() the second argument specifies the new file > to create. > > I guess its kinda hard to fix this now, as a lot of deployments may rely > on the old behaviour. But maybe it would be nice to document this > somewhere? You mean like http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/PROTOCOL?rev=1.12;content-type=text%2Fx-cvsweb-markup;ln=1#l162 From prestoo at me.com Thu Feb 26 21:10:43 2009 From: prestoo at me.com (prestoo at me.com) Date: Thu, 26 Feb 2009 12:10:43 +0200 Subject: ssh -t host sleep 100 + Ctrl-Z (SIGSTOP) does not suspend process? Message-ID: <158294901135158438021011027452339999560-Webmail@me.com> Currently executing "ssh -t host sleep 100" and then pressing Ctrl-Z (to send SIGSTOP) does not seem to suspend the SSH process. Would it make sense to have Ctrl-Z suspend the SSH process, or is there some rationale for not doing that? I'm not intimately familiar with how SSH interacts with terminals on pseudo-TTY allocation, which is why I'm asking. From alexl at redhat.com Fri Feb 27 01:46:51 2009 From: alexl at redhat.com (Alexander Larsson) Date: Thu, 26 Feb 2009 15:46:51 +0100 Subject: sftp SSH2_FXP_SYMLINK argument order In-Reply-To: References: <1235638838.15272.4.camel@fatty> Message-ID: <1235659611.6327.0.camel@fatty> On Thu, 2009-02-26 at 23:26 +1100, Damien Miller wrote: > On Thu, 26 Feb 2009, Alexander Larsson wrote: > > > Reading 6.10 Dealing with Symbolic links in > > http://www.openssh.org/txt/draft-ietf-secsh-filexfer-02.txt it seems to > > say that the first argument ('linkpath') specifies the name of the > > symlink file to create. ("linkpath' specifies the path name of the > > symlink to be created"). > > > > However, sftp-server.c:process_symlink() seems to reverse this. > > I.E. the first argument ('oldpath') is passed as the first argument to > > symlink(). But for symlink() the second argument specifies the new file > > to create. > > > > I guess its kinda hard to fix this now, as a lot of deployments may rely > > on the old behaviour. But maybe it would be nice to document this > > somewhere? > > You mean like > > http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/PROTOCOL?rev=1.12;content-type=text%2Fx-cvsweb-markup;ln=1#l162 Excellent. Didn't know about this file. From smithsg at avaya.com Fri Feb 27 03:02:53 2009 From: smithsg at avaya.com (Smith, Steven G (Steven)) Date: Thu, 26 Feb 2009 09:02:53 -0700 Subject: openssh and SSLv2 ciphers Message-ID: <16D699272CDB7A4994DA0E1C5BB6FE2E016C2A65@306181ANEX3.global.avaya.com> Hi, I am trying to confirm that openssh transmissions do not use any kind of SSLv2 ciphers. I have glanced through the code briefly, and I did not find any indication that any openssl ciphers are even being used (it appears that openssl is used primarily for RSA key generation and select other things). So openssh uses its own built-in ciphers instead, right? Thanks for the assistance, Steven From peter at stuge.se Fri Feb 27 04:01:16 2009 From: peter at stuge.se (Peter Stuge) Date: Thu, 26 Feb 2009 18:01:16 +0100 Subject: openssh and SSLv2 ciphers In-Reply-To: <16D699272CDB7A4994DA0E1C5BB6FE2E016C2A65@306181ANEX3.global.avaya.com> References: <16D699272CDB7A4994DA0E1C5BB6FE2E016C2A65@306181ANEX3.global.avaya.com> Message-ID: <20090226170116.15969.qmail@stuge.se> Smith, Steven G (Steven) wrote: > I am trying to confirm that openssh transmissions do not use any > kind of SSLv2 ciphers. Please see the Ciphers keyword in ssh_config(5) and sshd_config(5). //Peter From yaniv at aknin.name Fri Feb 27 05:57:26 2009 From: yaniv at aknin.name (Yaniv Aknin) Date: Thu, 26 Feb 2009 20:57:26 +0200 Subject: OpenSSH with 'none' cipher (after reading bug #877) Message-ID: Hi, I'd like to argue in favor of bug #877 ( https://bugzilla.mindrot.org/show_bug.cgi?id=877) from a new perspective. Instead of performance, I wish to raise the issue of regulatory compliance and auditing. I read all of #877 and I understand the arguments for and against, but I felt at the end the decisive comment by Damien was mostly based on 'We don't want users to use "none" because we think it is an unacceptable tradeoff'. I can relate to that comment when said in regard to performance - indeed, the benefit of 'none' over 'arcfour' is negligible. However, It seems that a solution I'm implementing may require cleartext transport due to regulation / auditing compliance reasons. Turns out that the government suits of some countries mandated that some institutions are required to keep a cleartext copy of all communications ever sent from their premises for a while, and I can't use my SSH based solution for these customers (Please, I don't want to argue about whether it's a good or a bad idea). For my solution, I can easily make sure my session passes in the clear only over pipes which are deemed secured by those owning the information, so encryption is unnecessary. I would like to have all the authentication features of SSH though. The only piece I'm missing for this is that SSH support the none cipher. I will not repeat the rest of the arguments, but I definitely agree with the sides of the discussion in bug #877 that claimed that just like allowing password authenticated access to the Root user or non-strict host-key checking, the none cipher should be implemented and be a part of the OpenSSH source tree, and not a hack an admin/integrator will insert as an afterthought into version so-and-so, fragile, untested and vanishing with version so-and-so+1. I think providing patches is irrelevant, as there are enough implementations around there and they're simple enough as it is. I just want the feature in OpenSSH's tree please. Comments? Thoughts? Verbal-exothermic reactions? - Yaniv "vs gur abar pvcure vf bhgynjrq, only outlaws will have the none cipher." me, just now. From smithsg at avaya.com Fri Feb 27 04:19:54 2009 From: smithsg at avaya.com (Smith, Steven G (Steven)) Date: Thu, 26 Feb 2009 10:19:54 -0700 Subject: openssh and SSLv2 ciphers In-Reply-To: <20090226170116.15969.qmail@stuge.se> References: <16D699272CDB7A4994DA0E1C5BB6FE2E016C2A65@306181ANEX3.global.avaya.com> <20090226170116.15969.qmail@stuge.se> Message-ID: <16D699272CDB7A4994DA0E1C5BB6FE2E016C2AC2@306181ANEX3.global.avaya.com> Thanks for the reply, Peter. I don't think that is quite the information I am looking for. Those manual pages do list the supported ciphers for "SSH" protocol version 2, but they do not indicate where the ciphers come from (i.e. are they ciphers from openssl, or are the ciphers provided by openssh). Thanks, Steve Smith, Steven G (Steven) wrote: > I am trying to confirm that openssh transmissions do not use any > kind of SSLv2 ciphers. Please see the Ciphers keyword in ssh_config(5) and sshd_config(5). //Peter From mouring at eviladmin.org Fri Feb 27 06:26:05 2009 From: mouring at eviladmin.org (Ben Lindstrom) Date: Thu, 26 Feb 2009 13:26:05 -0600 Subject: openssh and SSLv2 ciphers In-Reply-To: <16D699272CDB7A4994DA0E1C5BB6FE2E016C2AC2@306181ANEX3.global.avaya.com> References: <16D699272CDB7A4994DA0E1C5BB6FE2E016C2A65@306181ANEX3.global.avaya.com> <20090226170116.15969.qmail@stuge.se> <16D699272CDB7A4994DA0E1C5BB6FE2E016C2AC2@306181ANEX3.global.avaya.com> Message-ID: Nearly all of them should come from OpenSSH. The only potential exceptions I'm aware of is rijndael (AES). - Ben On Feb 26, 2009, at 11:19 AM, Smith, Steven G (Steven) wrote: > Thanks for the reply, Peter. I don't think that is quite the > information I am looking for. Those manual pages do list the > supported > ciphers for "SSH" protocol version 2, but they do not indicate where > the > ciphers come from (i.e. are they ciphers from openssl, or are the > ciphers provided by openssh). > > Thanks, > Steve > > Smith, Steven G (Steven) wrote: >> I am trying to confirm that openssh transmissions do not use any >> kind of SSLv2 ciphers. > > Please see the Ciphers keyword in ssh_config(5) and sshd_config(5). > > > //Peter > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From mouring at eviladmin.org Fri Feb 27 06:28:01 2009 From: mouring at eviladmin.org (Ben Lindstrom) Date: Thu, 26 Feb 2009 13:28:01 -0600 Subject: openssh and SSLv2 ciphers In-Reply-To: References: <16D699272CDB7A4994DA0E1C5BB6FE2E016C2A65@306181ANEX3.global.avaya.com> <20090226170116.15969.qmail@stuge.se> <16D699272CDB7A4994DA0E1C5BB6FE2E016C2AC2@306181ANEX3.global.avaya.com> Message-ID: Ermm.. OpenSSL.. That is what I get for writing a quick email. - Ben On Feb 26, 2009, at 1:26 PM, Ben Lindstrom wrote: > Nearly all of them should come from OpenSSH. The only potential > exceptions I'm aware of is rijndael (AES). > > - Ben > > > > On Feb 26, 2009, at 11:19 AM, Smith, Steven G (Steven) wrote: > >> Thanks for the reply, Peter. I don't think that is quite the >> information I am looking for. Those manual pages do list the >> supported >> ciphers for "SSH" protocol version 2, but they do not indicate where >> the >> ciphers come from (i.e. are they ciphers from openssl, or are the >> ciphers provided by openssh). >> >> Thanks, >> Steve >> >> Smith, Steven G (Steven) wrote: >>> I am trying to confirm that openssh transmissions do not use any >>> kind of SSLv2 ciphers. >> >> Please see the Ciphers keyword in ssh_config(5) and sshd_config(5). >> >> >> //Peter >> >> _______________________________________________ >> openssh-unix-dev mailing list >> openssh-unix-dev at mindrot.org >> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From luciano at debian.org Fri Feb 27 07:50:26 2009 From: luciano at debian.org (Luciano Bello) Date: Thu, 26 Feb 2009 18:50:26 -0200 Subject: OpenSSH with 'none' cipher (after reading bug #877) In-Reply-To: References: Message-ID: <200902261850.27409.luciano@debian.org> El Jue 26 Feb 2009, Yaniv Aknin escribi?: > However, It seems that a solution I'm implementing may require cleartext > transport due to regulation / auditing compliance reasons. Turns out that > the government suits of some countries mandated that some institutions are > required to keep a cleartext copy of all communications ever sent from their > premises for a while, and I can't use my SSH based solution for these > customers (Please, I don't want to argue about whether it's a good or a bad > idea). What about put a copy of the sshd's private exponent in the sniffer/auditor machine? Whit this, the auditor can recalculate the share secret and decipher the communication. Of course, this broke PFS in DHE but looks like a better solution than just use plain text. luciano PD: I'm in favor of implement 'none' cipher but with the 'performance' reasons. From smithsg at avaya.com Fri Feb 27 06:44:34 2009 From: smithsg at avaya.com (Smith, Steven G (Steven)) Date: Thu, 26 Feb 2009 12:44:34 -0700 Subject: openssh and SSLv2 ciphers In-Reply-To: References: <16D699272CDB7A4994DA0E1C5BB6FE2E016C2A65@306181ANEX3.global.avaya.com> <20090226170116.15969.qmail@stuge.se> <16D699272CDB7A4994DA0E1C5BB6FE2E016C2AC2@306181ANEX3.global.avaya.com> Message-ID: <16D699272CDB7A4994DA0E1C5BB6FE2E016C2B79@306181ANEX3.global.avaya.com> Hey Ben, Thanks for the reply. Just to clarify, you are saying that almost all of the SSH ciphers come from Openssl. Is that right? Thanks, Steve > -----Original Message----- > From: Ben Lindstrom [mailto:mouring at eviladmin.org] > Sent: Thursday, February 26, 2009 12:28 PM > Cc: Smith, Steven G (Steven); openssh-unix-dev at mindrot.org > Subject: Re: openssh and SSLv2 ciphers > > Ermm.. OpenSSL.. That is what I get for writing a quick email. > > - Ben > > On Feb 26, 2009, at 1:26 PM, Ben Lindstrom wrote: > > > Nearly all of them should come from OpenSSH. The only potential > > exceptions I'm aware of is rijndael (AES). > > > > - Ben > > > > > > > > On Feb 26, 2009, at 11:19 AM, Smith, Steven G (Steven) wrote: > > > >> Thanks for the reply, Peter. I don't think that is quite the > >> information I am looking for. Those manual pages do list the > >> supported > >> ciphers for "SSH" protocol version 2, but they do not indicate where > >> the > >> ciphers come from (i.e. are they ciphers from openssl, or are the > >> ciphers provided by openssh). > >> > >> Thanks, > >> Steve > >> > >> Smith, Steven G (Steven) wrote: > >>> I am trying to confirm that openssh transmissions do not use any > >>> kind of SSLv2 ciphers. > >> > >> Please see the Ciphers keyword in ssh_config(5) and sshd_config(5). > >> > >> > >> //Peter > >> > >> _______________________________________________ > >> openssh-unix-dev mailing list > >> openssh-unix-dev at mindrot.org > >> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > > > > _______________________________________________ > > openssh-unix-dev mailing list > > openssh-unix-dev at mindrot.org > > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From gert at greenie.muc.de Fri Feb 27 08:57:53 2009 From: gert at greenie.muc.de (Gert Doering) Date: Thu, 26 Feb 2009 22:57:53 +0100 Subject: openssh and SSLv2 ciphers In-Reply-To: <16D699272CDB7A4994DA0E1C5BB6FE2E016C2B79@306181ANEX3.global.avaya.com> References: <16D699272CDB7A4994DA0E1C5BB6FE2E016C2A65@306181ANEX3.global.avaya.com> <20090226170116.15969.qmail@stuge.se> <16D699272CDB7A4994DA0E1C5BB6FE2E016C2AC2@306181ANEX3.global.avaya.com> <16D699272CDB7A4994DA0E1C5BB6FE2E016C2B79@306181ANEX3.global.avaya.com> Message-ID: <20090226215753.GP290@greenie.muc.de> Hi, On Thu, Feb 26, 2009 at 12:44:34PM -0700, Smith, Steven G (Steven) wrote: > Thanks for the reply. Just to clarify, you are saying that almost all > of the SSH ciphers come from Openssl. Is that right? Yes. But that doesn't make them "SSLv2" ciphers, as in "SSLv2 is so insecure, everybody should use SSLv3". It's just well-tested and fast implementations of 3DES, Blowfish, etc. 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 Feb 27 09:14:05 2009 From: djm at mindrot.org (Damien Miller) Date: Fri, 27 Feb 2009 09:14:05 +1100 (EST) Subject: openssh and SSLv2 ciphers In-Reply-To: <16D699272CDB7A4994DA0E1C5BB6FE2E016C2A65@306181ANEX3.global.avaya.com> References: <16D699272CDB7A4994DA0E1C5BB6FE2E016C2A65@306181ANEX3.global.avaya.com> Message-ID: On Thu, 26 Feb 2009, Smith, Steven G (Steven) wrote: > Hi, > > I am trying to confirm that openssh transmissions do not use any kind > of SSLv2 ciphers. I have glanced through the code briefly, and I did > not find any indication that any openssl ciphers are even being used > (it appears that openssl is used primarily for RSA key generation > and select other things). So openssh uses its own built-in ciphers > instead, right? OpenSSH can use some of the same ciphers as SSLv2, and these ciphers come from OpenSSL's libcrypto library but they are used somewhat differently to SSL. Indeed, OpenSSL's actual SSL/TLS library (libssl) is separate to its crypto library. -d From pavel.rosputko at gmail.com Sat Feb 28 06:40:50 2009 From: pavel.rosputko at gmail.com (Pavel Rosputko) Date: Fri, 27 Feb 2009 23:40:50 +0400 Subject: Dynamic Port Forwarding - Connection reset by peer problem Message-ID: Hi all, I use the dynamic port forwarding. I execute `ssh -D 5555 my-external.com`. Then I use localhost:5555 as a socks server. I connect to my-server.com via socks at 5555. It seems my client does not detect connection reset by peer and hangs on recv forever when my-server.com does connection reset. May it be a problem in openssh socks5' implementation? From smithsg at avaya.com Sat Feb 28 07:20:30 2009 From: smithsg at avaya.com (Smith, Steven G (Steven)) Date: Fri, 27 Feb 2009 13:20:30 -0700 Subject: openssh and SSLv2 ciphers In-Reply-To: References: <16D699272CDB7A4994DA0E1C5BB6FE2E016C2A65@306181ANEX3.global.avaya.com> Message-ID: <16D699272CDB7A4994DA0E1C5BB6FE2E016C2F4F@306181ANEX3.global.avaya.com> Thanks again to everyone who replied. Maybe I should give a better explanation for my question. We are avoiding the use of SSLv2 ciphers in our products. Previously, I did this by recompiling openssl with the "no-ssl2" flag to make sure these ciphers were completely unusable. Unfortunately, this created a nightmare of having to recompile many other RPMs (we are using RHEL 4 and RHEL 5). Just recompiling would not be that bad with SRPMs, but frequently code changes need to be made as well to remove flags and function calls that are no longer existent in the "hardened" openssl libraries. Instead, I am trying to see which applications have configuration options (such as httpd) to avoid using SSLv2. I know I can configure openssh to use certain ciphers, but I am having a hard time determining where the ciphers actually come from. Additionally, maybe the SSLv2 vulnerabilities would not really affect an openssh connection anyway. Perhaps an option would be to recompile openssl without support for the SSLv2 ciphers, but still have the SSLv2 methods and flags hang around for compatibility with these other programs. I am not sure how much work that would be. If you have any other ideas, I would be interested in hearing them. Thanks, Steven > -----Original Message----- > From: Damien Miller [mailto:djm at mindrot.org] > Sent: Thursday, February 26, 2009 3:14 PM > To: Smith, Steven G (Steven) > Cc: openssh-unix-dev at mindrot.org > Subject: Re: openssh and SSLv2 ciphers > > On Thu, 26 Feb 2009, Smith, Steven G (Steven) wrote: > > > Hi, > > > > I am trying to confirm that openssh transmissions do not use any kind > > of SSLv2 ciphers. I have glanced through the code briefly, and I did > > not find any indication that any openssl ciphers are even being used > > (it appears that openssl is used primarily for RSA key generation > > and select other things). So openssh uses its own built-in ciphers > > instead, right? > > OpenSSH can use some of the same ciphers as SSLv2, and these ciphers > come from OpenSSL's libcrypto library but they are used somewhat > differently to SSL. Indeed, OpenSSL's actual SSL/TLS library (libssl) is > separate to its crypto library. > > -d From peter at stuge.se Sat Feb 28 09:19:14 2009 From: peter at stuge.se (Peter Stuge) Date: Fri, 27 Feb 2009 23:19:14 +0100 Subject: openssh and SSLv2 ciphers In-Reply-To: <16D699272CDB7A4994DA0E1C5BB6FE2E016C2F4F@306181ANEX3.global.avaya.com> References: <16D699272CDB7A4994DA0E1C5BB6FE2E016C2A65@306181ANEX3.global.avaya.com> <16D699272CDB7A4994DA0E1C5BB6FE2E016C2F4F@306181ANEX3.global.avaya.com> Message-ID: <20090227221914.26265.qmail@stuge.se> Smith, Steven G (Steven) wrote: > Additionally, maybe the SSLv2 vulnerabilities would not really > affect an openssh connection anyway. I believe that is correct. SSH can use the same crypto code as SSL but even though SSH accomplishes some of the same things as SSL, SSH works differently "on top" of the low-level ciphers. (Both SSL and SSH can perform user authentication with PKI, but they do it differently. Both provide a trusted communications channel using cryptography but again, they do it differently.) Version 1 of the SSH protocol had it's own issues, but it has been disabled by default in OpenSSH for a long time already. //Peter From djm at mindrot.org Sat Feb 28 09:34:34 2009 From: djm at mindrot.org (Damien Miller) Date: Sat, 28 Feb 2009 09:34:34 +1100 (EST) Subject: openssh and SSLv2 ciphers In-Reply-To: <16D699272CDB7A4994DA0E1C5BB6FE2E016C2F4F@306181ANEX3.global.avaya.com> References: <16D699272CDB7A4994DA0E1C5BB6FE2E016C2A65@306181ANEX3.global.avaya.com> <16D699272CDB7A4994DA0E1C5BB6FE2E016C2F4F@306181ANEX3.global.avaya.com> Message-ID: Like I said, SSL's use of ciphers is completely separate to OpenSSH's, so I can think of no reason why compiling OpenSSL with no-ssl2 would affect OpenSSH in any way. On Fri, 27 Feb 2009, Smith, Steven G (Steven) wrote: > Thanks again to everyone who replied. Maybe I should give a better > explanation for my question. We are avoiding the use of SSLv2 ciphers > in our products. Previously, I did this by recompiling openssl with the > "no-ssl2" flag to make sure these ciphers were completely unusable. > Unfortunately, this created a nightmare of having to recompile many > other RPMs (we are using RHEL 4 and RHEL 5). Just recompiling would not > be that bad with SRPMs, but frequently code changes need to be made as > well to remove flags and function calls that are no longer existent in > the "hardened" openssl libraries. > > Instead, I am trying to see which applications have configuration > options (such as httpd) to avoid using SSLv2. I know I can configure > openssh to use certain ciphers, but I am having a hard time determining > where the ciphers actually come from. Additionally, maybe the SSLv2 > vulnerabilities would not really affect an openssh connection anyway. > > Perhaps an option would be to recompile openssl without support for the > SSLv2 ciphers, but still have the SSLv2 methods and flags hang around > for compatibility with these other programs. I am not sure how much > work that would be. > > If you have any other ideas, I would be interested in hearing them. > > Thanks, > Steven > > > > -----Original Message----- > > From: Damien Miller [mailto:djm at mindrot.org] > > Sent: Thursday, February 26, 2009 3:14 PM > > To: Smith, Steven G (Steven) > > Cc: openssh-unix-dev at mindrot.org > > Subject: Re: openssh and SSLv2 ciphers > > > > On Thu, 26 Feb 2009, Smith, Steven G (Steven) wrote: > > > > > Hi, > > > > > > I am trying to confirm that openssh transmissions do not use any > kind > > > of SSLv2 ciphers. I have glanced through the code briefly, and I did > > > not find any indication that any openssl ciphers are even being used > > > (it appears that openssl is used primarily for RSA key generation > > > and select other things). So openssh uses its own built-in ciphers > > > instead, right? > > > > OpenSSH can use some of the same ciphers as SSLv2, and these ciphers > > come from OpenSSL's libcrypto library but they are used somewhat > > differently to SSL. Indeed, OpenSSL's actual SSL/TLS library (libssl) > is > > separate to its crypto library. > > > > -d > From djm at mindrot.org Sat Feb 28 09:45:57 2009 From: djm at mindrot.org (Damien Miller) Date: Sat, 28 Feb 2009 09:45:57 +1100 (EST) Subject: Dynamic Port Forwarding - Connection reset by peer problem In-Reply-To: References: Message-ID: On Fri, 27 Feb 2009, Pavel Rosputko wrote: > Hi all, > > I use the dynamic port forwarding. I execute `ssh -D 5555 > my-external.com`. Then I use localhost:5555 as a socks server. I > connect to my-server.com via socks at 5555. It seems my client does > not detect connection reset by peer and hangs on recv forever when > my-server.com does connection reset. May it be a problem in openssh > socks5' implementation? Who knows? You didn't provide enough information to tell. You could start with: - Your platform (client and server) - The version(s) of ssh and sshd in use - Debug output from ssh (ssh -vvv ...) and sshd (sshd -ddd ...) Then we might be able to figure out what has gone wrong. -d