From system at TMESIS.COM  Mon Nov  3 22:40:13 2008
From: system at TMESIS.COM (Brian Schenkenberger, VAXman-)
Date: Mon, 3 Nov 2008 06:40:13 -0500
Subject: OpenSSH 5.1 not *passing* escape sequences.  [PASS:VAXman]
Message-ID: <00A82107.7D504084.3@TMESIS.COM>

OpenSSH 5.1p1 was just installed on Linux machines here.  It appears that
escape sequences are not being passed to the underlying terminal for in-
terpretation and control.  I am now seeing \033[H and \033[2J.  This will
not bode well for users expecting classic escape sequences to be painting
and controlling their terminal screens.  Is there a magical incantation to
restore proper behavior?  Or is this a bug?

Thanks.
-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker    VAXman(at)TMESIS(dot)COM
           
  "Well my son, life is like a beanstalk, isn't it?" 

From dkg at fifthhorseman.net  Tue Nov  4 06:36:53 2008
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Mon, 03 Nov 2008 14:36:53 -0500
Subject: Monkeysphere: An OpenPGP-based PKI for OpenSSH
Message-ID: <873ai8vbxm.fsf@squeak.fifthhorseman.net>

A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20081103/e9bffea8/attachment.bin 

From cristian.ionescu-idbohrn at axis.com  Tue Nov  4 05:21:39 2008
From: cristian.ionescu-idbohrn at axis.com (Cristian Ionescu-Idbohrn)
Date: Mon, 3 Nov 2008 19:21:39 +0100 (CET)
Subject: Warning: No xauth data; using fake authentication data for X11
	forwarding.
Message-ID: <0811031907400.12084@somehost>

I'm seeing that warning quite often.  I can easily reproduce it by doing
something like this:

  # for i in $(seq 50);do ssh <server> date&;done

That's a cvs/ssh server and has 'MaxStartups 50' in /etc/ssh/sshd_config.

Server sshd is:

  OpenSSH_4.3p2 Debian-9etch3 pat OpenSSH

Client ssh is:

  OpenSSH_5.1p1 Debian-3, OpenSSL 0.9.8g 19 Oct 2007

I've also seen this:

  /usr/bin/X11/xauth:  error in locking authority file /home/user/.Xauthority

occasionally.

Anything that can be done to avoid that?


Cheers,

-- 
Cristian

From josimapi at gmail.com  Thu Nov  6 02:19:32 2008
From: josimapi at gmail.com (Josele Lerele)
Date: Wed, 5 Nov 2008 16:19:32 +0100
Subject: Keyboard-interactive authentication from a PAM module
Message-ID: <4164cb590811050719o27970f2bq6edb95682ad83e3c@mail.gmail.com>

Hello,

I am developing a PAM module that is called from OpenSSH server when a
ssh-client wants to login in the machine. I want my module PAM to send a
message to the ssh-client as soon as the PAM module is called by using the
pam_info function, but I have checked that the message is not instantly
shown in the client unless I send a prompt.

I would like to find a way to send the message instantly from my PAM module
without prompting. Any suggestions?

Thanks a lot

From johan.kielbaey at gmail.com  Thu Nov  6 05:26:33 2008
From: johan.kielbaey at gmail.com (Johan Kielbaey)
Date: Wed, 5 Nov 2008 19:26:33 +0100
Subject: Bug+bugfix in sftp-server : failed to rename file on sshfs mount
Message-ID: <8b4c1ca70811051026u249dcc99x33d97c6efa7f067b@mail.gmail.com>

Hello,

Renaming a file via sftp on an sshfs mount resulted in a failure with
errorcode 38 (ENOSYS).

This is reproducable with openssh release 4.9p1 & 5.1p1 in combination
sshfs 2.2 (latest releases). Investigation revealed that sshfs only
implements the rename()-call and not the link()-call (used by
sftp-server).

Attached is a patch to perform the rename()-call upon a failed link().
The patch is against openssh-5.1p1.

Kind regards,

Johan

From mouring at eviladmin.org  Thu Nov  6 06:58:52 2008
From: mouring at eviladmin.org (Ben Lindstrom)
Date: Wed, 5 Nov 2008 13:58:52 -0600
Subject: Bug+bugfix in sftp-server : failed to rename file on sshfs mount
In-Reply-To: <8b4c1ca70811051026u249dcc99x33d97c6efa7f067b@mail.gmail.com>
References: <8b4c1ca70811051026u249dcc99x33d97c6efa7f067b@mail.gmail.com>
Message-ID: <AD20BE85-E0D0-4FD1-893B-FA9978352F45@eviladmin.org>

Without seeing the patch I can't judge it.

However, why is sshfs failure to implement things right an OpenSSH bug?

BTW you may want to file it with http://bugzilla.mindrot.org/  so it  
doesn't get lost as well (or at least skim the open and closed bugs on  
the rename() and link() discussions.

- Ben


On Nov 5, 2008, at 12:26 PM, Johan Kielbaey wrote:

> Hello,
>
> Renaming a file via sftp on an sshfs mount resulted in a failure with
> errorcode 38 (ENOSYS).
>
> This is reproducable with openssh release 4.9p1 & 5.1p1 in combination
> sshfs 2.2 (latest releases). Investigation revealed that sshfs only
> implements the rename()-call and not the link()-call (used by
> sftp-server).
>
> Attached is a patch to perform the rename()-call upon a failed link().
> The patch is against openssh-5.1p1.
>
> Kind regards,
>
> Johan
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev


From dtucker at zip.com.au  Thu Nov  6 12:13:02 2008
From: dtucker at zip.com.au (Darren Tucker)
Date: Thu, 06 Nov 2008 12:13:02 +1100
Subject: Keyboard-interactive authentication from a PAM module
In-Reply-To: <4164cb590811050719o27970f2bq6edb95682ad83e3c@mail.gmail.com>
References: <4164cb590811050719o27970f2bq6edb95682ad83e3c@mail.gmail.com>
Message-ID: <4912449E.3010007@zip.com.au>

Josele Lerele wrote:
> Hello,
> 
> I am developing a PAM module that is called from OpenSSH server when a
> ssh-client wants to login in the machine. I want my module PAM to send a
> message to the ssh-client as soon as the PAM module is called by using the
> pam_info function, but I have checked that the message is not instantly
> shown in the client unless I send a prompt.
> 
> I would like to find a way to send the message instantly from my PAM module
> without prompting. Any suggestions?

What version of OpenSSH are you using?  Modern versions will send a SSH2 
banner message if they get a conversation request from PAM without a prompt.

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
     Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

From dtucker at zip.com.au  Thu Nov  6 22:57:38 2008
From: dtucker at zip.com.au (Darren Tucker)
Date: Thu, 06 Nov 2008 22:57:38 +1100
Subject: Keyboard-interactive authentication from a PAM module
In-Reply-To: <4164cb590811060108j28e53624i48a33873ddb36f30@mail.gmail.com>
References: <4164cb590811050719o27970f2bq6edb95682ad83e3c@mail.gmail.com>	
	<4912449E.3010007@zip.com.au>
	<4164cb590811060108j28e53624i48a33873ddb36f30@mail.gmail.com>
Message-ID: <4912DBB2.8060300@zip.com.au>

Josele Lerele wrote:
> I am using version 5.1. I know you can send information through the 
> banner, but I would like to send dynamic information from the PAM 
> module.

I wasn't refering to the banner file.  The PAM code uses the banner 
protocol message to send data provided by PAM under some conditions when 
there's no prompt.

> Do you think this is possible without prompting something in the 
> client?

Depends on what PAM passes sshd.

Could you please you compile and run (as root) this little test program 
to show what PAM's doing and post the output?  (Sanity checking the code 
first is recommended.  It doesn't set noecho so you want to make sure 
there's nobody watching over shoulders, and obviously clip any sensitive 
bits from the output.)

http://www.zip.com.au/~dtucker/patches/pam-test-harness.c

A few other random questions:

- what platform is this running on?  Probably will not make a difference 
but it might help.

- what does your PAM config look like for sshd?

- is the module source publicly available?  (ie can I reproduce this 
configuration?)

-- 
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 josimapi at gmail.com  Thu Nov  6 20:08:12 2008
From: josimapi at gmail.com (Josele Lerele)
Date: Thu, 6 Nov 2008 10:08:12 +0100
Subject: Keyboard-interactive authentication from a PAM module
In-Reply-To: <4912449E.3010007@zip.com.au>
References: <4164cb590811050719o27970f2bq6edb95682ad83e3c@mail.gmail.com>
	<4912449E.3010007@zip.com.au>
Message-ID: <4164cb590811060108j28e53624i48a33873ddb36f30@mail.gmail.com>

I am using version 5.1. I know you can send information through the banner,
but I would like to send dynamic information from the PAM module. Do you
think this is possible without prompting something in the client?

2008/11/6 Darren Tucker <dtucker at zip.com.au>

> Josele Lerele wrote:
>
>> Hello,
>>
>> I am developing a PAM module that is called from OpenSSH server when a
>> ssh-client wants to login in the machine. I want my module PAM to send a
>> message to the ssh-client as soon as the PAM module is called by using the
>> pam_info function, but I have checked that the message is not instantly
>> shown in the client unless I send a prompt.
>>
>> I would like to find a way to send the message instantly from my PAM
>> module
>> without prompting. Any suggestions?
>>
>
> What version of OpenSSH are you using?  Modern versions will send a SSH2
> banner message if they get a conversation request from PAM without a prompt.
>
> --
> 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 julian.navascues at gmail.com  Fri Nov  7 03:31:48 2008
From: julian.navascues at gmail.com (=?ISO-8859-1?Q?Juli=E1n_de_Navascu=E9s?=)
Date: Thu, 6 Nov 2008 17:31:48 +0100
Subject: Keyboard-interactive authentication from a PAM module
Message-ID: <ccd8712d0811060831g6ad47a2cm185c16cbddc6f162@mail.gmail.com>

Hi again,

Im working in the same PAM module that Josele is working. First of all
thank you for your reply. I would like to answer your questions:

> - what platform is this running on? Probably will not make a difference
> but it might help.

We are developing under linux (lastest Ubuntu desktop, OpenSSH 5.1)
but in the future we would like to support any unix.

> - what does your PAM config look like for sshd?

We have a very fool temp config... just for testing:

auth   optional  our_pam_module.so
auth   sufficient  pam_succeed_if.so uid >= 0


> - is the module source publicly available? (ie can I reproduce this configuration?)

I guess you think we have a complex module... but the only thing we do is:

PAM_EXTERN int pam_sm_authenticate  ( args... )
{
   pam_info  ( pamh,  "Hello\n" );      // shouldn't it work as a
fprintf on the ssh client side?

  sleep ( n_seconds );

   return PAM_SUCCESS;
}

If we use this module in other PAM aware application ( like the switch
user command "su" ) we see first the message "Hello", then wait
n_seconds, then return PAM_SUCCESS... and auth depends on
/etc/pam.d/su and other modules.

BUT, if we try the same with our sshd (keyboard interactive
authentication via PAM) we only see our "Hello" message after the
n_secondsa and the PAM auth is finished. Also if we prompt something
after the pam_info call (prompt for a password, for example). we can
see the "Hello" message.

So... we know its possible to do it with "su", but... we are not sure
if its possible to send a message to SSH client, I mean:

SSH Client <----- "Hello" ---------| sshd | <-------- "Hello"
------------ | PAM module says Hello and sleeps...


Facts:

Keyboard interactive ( RFC:
http://www.rfc-archive.org/getrfc.php?rfc=4256 ) authentication allows
to send to the SSH client without prompting, as RFC says:

1. In the case that the server sends a `0' num-prompts field in the
    request message, the client MUST send a response message with a `0'
    num-responses field to complete the exchange.

2. The num-prompts field may be `0', in which case there will be no
    prompt/echo fields in the message, but the client SHOULD still
    display the name and instruction fields (as described below)

Question:

Is the sshd able to recieve a info message from PAM  (as a PAM aware
app in a PAM conversation) and send it immediately to the SSH client
(as a SSH server in the middle of a keyboard interactive
authentication) ???

Has anybody did this before?  I know it sounds complicated or even
absurd, but we want it (and we dont want to patch SSH server or
client).


Thanks again for your help and sorry for my bad English,

Julian





Josele Lerele wrote:
> I am using version 5.1. I know you can send information through the
> banner, but I would like to send dynamic information from the PAM
> module.

I wasn't refering to the banner file. The PAM code uses the banner
protocol message to send data provided by PAM under some conditions when
there's no prompt.

> Do you think this is possible without prompting something in the
> client?

Depends on what PAM passes sshd.

Could you please you compile and run (as root) this little test program
to show what PAM's doing and post the output? (Sanity checking the code
first is recommended. It doesn't set noecho so you want to make sure
there's nobody watching over shoulders, and obviously clip any sensitive
bits from the output.)

http://www.zip.com.au/~dtucker/patch...test-harness.c

A few other random questions:

- what platform is this running on? Probably will not make a difference
but it might help.

- what does your PAM config look like for sshd?

- is the module source publicly available? (ie can I reproduce this
configuration?)

--
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.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev at mindrot.org
https://lists.mindrot.org/mailman/li...enssh-unix-dev

From johan.kielbaey at gmail.com  Fri Nov  7 08:44:51 2008
From: johan.kielbaey at gmail.com (Johan Kielbaey)
Date: Thu, 6 Nov 2008 22:44:51 +0100
Subject: Bug+bugfix in sftp-server : failed to rename file on sshfs mount
In-Reply-To: <AD20BE85-E0D0-4FD1-893B-FA9978352F45@eviladmin.org>
References: <8b4c1ca70811051026u249dcc99x33d97c6efa7f067b@mail.gmail.com>
	<AD20BE85-E0D0-4FD1-893B-FA9978352F45@eviladmin.org>
Message-ID: <8b4c1ca70811061344g65d81ae0x96475abf9985e27d@mail.gmail.com>

2008/11/5 Ben Lindstrom <mouring at eviladmin.org>:
> Without seeing the patch I can't judge it.
>
> However, why is sshfs failure to implement things right an OpenSSH bug?

Point taken. I guess I explained myself wrong. Obviously the fact that
sshfs doesn't implement the link() call is not an OpenSSH bug. From my
understanding the SFTPv3 protocol doesn't feature creation of hard
links.

sftp-server falls back to the rename() syscall if the link() syscall
fails with certain error codes. EOPNOTSUPP is such an errorcode. Sshfs
however returns ENOSYS, which is not such as errorcode.

Allowing a fall back to the rename() call upon ENOSYS errorcode,
solves the issue for all filesystem that don't implement hard links.

An alternative solution would be to give preference to the rename()
call over the link() call all the way. If you prefer I could work on a
patch for that.

>
> BTW you may want to file it with http://bugzilla.mindrot.org/  so it doesn't
> get lost as well (or at least skim the open and closed bugs on the rename()
> and link() discussions.
>

Done. Bug# 1535

Kind regards,
Johan

From dtucker at zip.com.au  Fri Nov  7 16:29:48 2008
From: dtucker at zip.com.au (Darren Tucker)
Date: Fri, 07 Nov 2008 16:29:48 +1100
Subject: Bug+bugfix in sftp-server : failed to rename file on sshfs mount
In-Reply-To: <8b4c1ca70811061344g65d81ae0x96475abf9985e27d@mail.gmail.com>
References: <8b4c1ca70811051026u249dcc99x33d97c6efa7f067b@mail.gmail.com>	<AD20BE85-E0D0-4FD1-893B-FA9978352F45@eviladmin.org>
	<8b4c1ca70811061344g65d81ae0x96475abf9985e27d@mail.gmail.com>
Message-ID: <4913D24C.5050605@zip.com.au>

Johan Kielbaey wrote:
> 2008/11/5 Ben Lindstrom <mouring at eviladmin.org>:
>> Without seeing the patch I can't judge it.
>>
>> However, why is sshfs failure to implement things right an OpenSSH bug?
> 
> Point taken. I guess I explained myself wrong. Obviously the fact that
> sshfs doesn't implement the link() call is not an OpenSSH bug. From my
> understanding the SFTPv3 protocol doesn't feature creation of hard
> links.
> 
> sftp-server falls back to the rename() syscall if the link() syscall
> fails with certain error codes. EOPNOTSUPP is such an errorcode. Sshfs
> however returns ENOSYS, which is not such as errorcode.

So on Linux, link(2) can return EPERM, EOPNOTSUPP or ENOSYS when it's 
not supported by the filesystem, depending on the filesystem?  Yay for 
consistency.

> Allowing a fall back to the rename() call upon ENOSYS errorcode,
> solves the issue for all filesystem that don't implement hard links.
> 
> An alternative solution would be to give preference to the rename()
> call over the link() call all the way. If you prefer I could work on a
> patch for that.
> 
>> BTW you may want to file it with http://bugzilla.mindrot.org/  so it doesn't
>> get lost as well (or at least skim the open and closed bugs on the rename()
>> and link() discussions.
>>
> 
> Done. Bug# 1535

I had not been following this thread so ignore my comment on the bug.

-- 
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  Fri Nov  7 16:38:11 2008
From: dtucker at zip.com.au (Darren Tucker)
Date: Fri, 07 Nov 2008 16:38:11 +1100
Subject: Keyboard-interactive authentication from a PAM module
In-Reply-To: <ccd8712d0811060831g6ad47a2cm185c16cbddc6f162@mail.gmail.com>
References: <ccd8712d0811060831g6ad47a2cm185c16cbddc6f162@mail.gmail.com>
Message-ID: <4913D443.3060608@zip.com.au>

Juli?n de Navascu?s wrote:
[...]
> Is the sshd able to recieve a info message from PAM  (as a PAM aware
> app in a PAM conversation) and send it immediately to the SSH client
> (as a SSH server in the middle of a keyboard interactive
> authentication) ???

It should, but having said that it would only work for 
keyboard-interactive and PAM can be invoked for other auth types 
(password, for the auth stack or any, for the account stack).  Banner 
messages can be sent at any time before authentication is complete 
(that's why they're used for this).

> Has anybody did this before?  I know it sounds complicated or even
> absurd, but we want it (and we dont want to patch SSH server or
> client).
[...]

I will look at this but it would be easier if you can supply the output 
from the diag tool I asked for:

> Could you please you compile and run (as root) this little test program
> to show what PAM's doing and post the output? (Sanity checking the code
> first is recommended. It doesn't set noecho so you want to make sure
> there's nobody watching over shoulders, and obviously clip any sensitive
> bits from the output.)
> 
> http://www.zip.com.au/~dtucker/patch...test-harness.c

(addendum: if the timing is important to you please add the -v option to 
enable timestamps)

-- 
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 vinschen at redhat.com  Fri Nov  7 21:54:58 2008
From: vinschen at redhat.com (Corinna Vinschen)
Date: Fri, 7 Nov 2008 11:54:58 +0100
Subject: [PATCH/cygwin] Fix cygwin specific Makefile and a bug in the
	ssh-host-config script
Message-ID: <20081107105458.GO6478@calimero.vinschen.de>

Hi,

could somebody be so kind to check in the follwoing patch?  It fixes
two problems:

- contrib/cygwin/Makefile:

  Installs new docs and stops trying to install RFC.nroff.

- contrib/cygwin/ssh-host-config:

  Fixes a condition which tries to find out if ssh or sshd processes are
  still running.  The old version unfortunately stumbles over user names
  which contain the substring "ssh" :}


Thanks in advance,
Corinna


Index: contrib/cygwin/Makefile
===================================================================
RCS file: /cvs/openssh/contrib/cygwin/Makefile,v
retrieving revision 1.3
diff -u -p -r1.3 Makefile
--- contrib/cygwin/Makefile	14 Jul 2008 02:12:54 -0000	1.3
+++ contrib/cygwin/Makefile	7 Nov 2008 10:49:30 -0000
@@ -38,11 +38,13 @@ install-sshdoc:
 	$(INSTALL) -m 644 $(srcdir)/ChangeLog $(DESTDIR)$(sshdocdir)/ChangeLog
 	$(INSTALL) -m 644 $(srcdir)/LICENCE $(DESTDIR)$(sshdocdir)/LICENCE
 	$(INSTALL) -m 644 $(srcdir)/OVERVIEW $(DESTDIR)$(sshdocdir)/OVERVIEW
+	$(INSTALL) -m 644 $(srcdir)/PROTOCOL $(DESTDIR)$(sshdocdir)/PROTOCOL
+	$(INSTALL) -m 644 $(srcdir)/PROTOCOL.agent $(DESTDIR)$(sshdocdir)/PROTOCOL.agent
 	$(INSTALL) -m 644 $(srcdir)/README $(DESTDIR)$(sshdocdir)/README
 	$(INSTALL) -m 644 $(srcdir)/README.dns $(DESTDIR)$(sshdocdir)/README.dns
+	$(INSTALL) -m 644 $(srcdir)/README.platform $(DESTDIR)$(sshdocdir)/README.platform
 	$(INSTALL) -m 644 $(srcdir)/README.privsep $(DESTDIR)$(sshdocdir)/README.privsep
 	$(INSTALL) -m 644 $(srcdir)/README.smartcard $(DESTDIR)$(sshdocdir)/README.smartcard
-	$(INSTALL) -m 644 $(srcdir)/RFC.nroff $(DESTDIR)$(sshdocdir)/RFC.nroff
 	$(INSTALL) -m 644 $(srcdir)/TODO $(DESTDIR)$(sshdocdir)/TODO
 	$(INSTALL) -m 644 $(srcdir)/WARNING.RNG $(DESTDIR)$(sshdocdir)/WARNING.RNG
 
Index: contrib/cygwin/ssh-host-config
===================================================================
RCS file: /cvs/openssh/contrib/cygwin/ssh-host-config,v
retrieving revision 1.22
diff -u -p -r1.22 ssh-host-config
--- contrib/cygwin/ssh-host-config	14 Jul 2008 02:12:54 -0000	1.22
+++ contrib/cygwin/ssh-host-config	7 Nov 2008 10:49:30 -0000
@@ -456,7 +456,7 @@ done
 
 # Check for running ssh/sshd processes first. Refuse to do anything while
 # some ssh processes are still running
-if ps -ef | grep -v grep | grep -q ssh
+if ps -ef | grep -v grep | grep -q 'sshd*$'
 then
   echo
   csih_error "There are still ssh processes running. Please shut them down first."


-- 
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat

From julian.navascues at gmail.com  Fri Nov  7 23:27:45 2008
From: julian.navascues at gmail.com (=?ISO-8859-1?Q?Juli=E1n_de_Navascu=E9s?=)
Date: Fri, 7 Nov 2008 07:27:45 -0500
Subject: Keyboard-interactive authentication from a PAM module
In-Reply-To: <4913D443.3060608@zip.com.au>
References: <ccd8712d0811060831g6ad47a2cm185c16cbddc6f162@mail.gmail.com>
	<4913D443.3060608@zip.com.au>
Message-ID: <ccd8712d0811070427u1c8d37c4h91cc9ba0e9840a1f@mail.gmail.com>

Hi again,


sorry, I'm afraid I don't understand how this can help to this subject.
Mainly because I don't see the relation between the pam-test and the sshd or
my module. Probably you wanted me to make something different, that is what
I have run:


user at ubuntu804desktop:~/Desktop$ sudo ./pam-test-harness -T -v
[sudo] password for user:
0.00  $Id: pam-test-harness.c,v 1.31 2007/08/19 02:27:40 dtucker Exp $
0.00  conversation struct {conv=0x8049119, appdata_ptr=0x804bb78}
0.00  pam_start(login, (NULL), &conv, &pamh)
0.01   = 0 (Success)
0.01  pam_get_item(pamh, PAM_SERVICE, ...)
0.01   = 0 (Success)
0.01      PAM_SERVICE = login (unchanged)
0.01  pam_set_item(pamh, PAM_TTY, "ssh")
0.01   = 0 (Success)
0.01  pam_set_item(pamh, PAM_RHOST, "ubuntu804desktop")
0.01   = 0 (Success)
0.01  pam_set_item(pamh, PAM_RUSER, "user")
0.01   = 0 (Success)
0.01  pam_authenticate(pamh, 0x0)
0.01      conversation called with 1 messages data 0x804bb78
0.01          PROMPT_ECHO_ON: login:user
2.53          [conversation function returned]
2.53      conversation called with 1 messages data 0x804bb78
2.53          PROMPT_ECHO_OFF: Password: user
3.44          [conversation function returned]
3.44   = 0 (Success)
3.44  pam_acct_mgmt(pamh, 0x0)
3.44   = 0 (Success)
3.44  pam_open_session(pamh, 0x0)
3.45      conversation called with 1 messages data 0x804bb78
3.45          TEXT_INFO: Last login: Thu Nov  6 19:15:02 EST 2008 from
localhost on pts/5
3.45      conversation called with 1 messages data 0x804bb78
3.45          TEXT_INFO: Linux ubuntu804desktop 2.6.24-21-generic #1 SMP Tue
Oct 21 23:43:45 UTC 2008 i686

The programs included with the Ubuntu system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by
applicable law.

To access official Ubuntu documentation, please visit:
http://help.ubuntu.com/
3.45   = 0 (Success)
3.45  pam_setcred(pamh, 0x0)
3.45   = 0 (Success)
3.45  pam_get_item(pamh, PAM_SERVICE, ...)
3.45   = 0 (Success)
3.45      PAM_SERVICE = login (unchanged)
3.45  pam_get_item(pamh, PAM_USER, ...)
3.45   = 0 (Success)
3.45      PAM_USER = user (CHANGED)
3.45  pam_get_item(pamh, PAM_TTY, ...)
3.45   = 0 (Success)
3.45      PAM_TTY = ssh (unchanged)
3.45  Standard environment variables:
3.45  PAM environment variables:
3.45
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
3.45      LANG=en_US.UTF-8
3.45      MAIL=/var/mail/user
3.45  uid 0 euid 0 gid 0 egid 0
3.45  pam_close_session(pamh, 0)
3.45   = 0 (Success)
3.45  pam_end(pamh, 0)
3.45   = 0 (Success)




> It should, but having said that it would only work for
keyboard-interactive and PAM can be invoked for other auth types A >
(password, for the auth stack or any, for the account stack).  Banner
messages can be sent at any time before
> authentication is complete (that's why they're used for this).

Yes, that's fine, we only want it working with keyboard-interactive and
PAM.  I wanted to ask you in the last email: what are "banner messages" in a
PAM context?? I mean, as far as I know the only way to send information
messages from a PAM module is PAM conversation  (
http://linux.die.net/man/3/pam_conv conv function with PAM_TEXT_INFO ).  I
didn't find any other way... I'm wrong?

I have seen that pam_info uses this conv in the subsequent calls...

Thanks





On Fri, Nov 7, 2008 at 12:38 AM, Darren Tucker <dtucker at zip.com.au> wrote:

> Juli?n de Navascu?s wrote:
> [...]
>
>> Is the sshd able to recieve a info message from PAM  (as a PAM aware
>> app in a PAM conversation) and send it immediately to the SSH client
>> (as a SSH server in the middle of a keyboard interactive
>> authentication) ???
>>
>
> It should, but having said that it would only work for keyboard-interactive
> and PAM can be invoked for other auth types (password, for the auth stack or
> any, for the account stack).  Banner messages can be sent at any time before
> authentication is complete (that's why they're used for this).
>>
>>



>>>  Has anybody did this before?  I know it sounds complicated or even
>> absurd, but we want it (and we dont want to patch SSH server or
>> client).
>>
> [...]
>
> I will look at this but it would be easier if you can supply the output
> from the diag tool I asked for:
>
>  Could you please you compile and run (as root) this little test program
>> to show what PAM's doing and post the output? (Sanity checking the code
>> first is recommended. It doesn't set noecho so you want to make sure
>> there's nobody watching over shoulders, and obviously clip any sensitive
>> bits from the output.)
>>
>> http://www.zip.com.au/~dtucker/patch...test-harness.c<http://www.zip.com.au/%7Edtucker/patch...test-harness.c>
>>
>
> (addendum: if the timing is important to you please add the -v option to
> enable timestamps)
>
> --
> 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 dkg at fifthhorseman.net  Sat Nov  8 01:46:42 2008
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri, 07 Nov 2008 09:46:42 -0500
Subject: [PATCH/cygwin] Fix cygwin specific Makefile and a bug in the
	ssh-host-config script
In-Reply-To: <20081107105458.GO6478@calimero.vinschen.de> (Corinna Vinschen's
	message of "Fri\, 7 Nov 2008 11\:54\:58 +0100")
References: <20081107105458.GO6478@calimero.vinschen.de>
Message-ID: <8763mz61bh.fsf@squeak.fifthhorseman.net>

On Fri 2008-11-07 05:54:58 -0500, Corinna Vinschen wrote:

> diff -u -p -r1.22 ssh-host-config
> --- contrib/cygwin/ssh-host-config	14 Jul 2008 02:12:54 -0000	1.22
> +++ contrib/cygwin/ssh-host-config	7 Nov 2008 10:49:30 -0000
> @@ -456,7 +456,7 @@ done
>  
>  # Check for running ssh/sshd processes first. Refuse to do anything while
>  # some ssh processes are still running
> -if ps -ef | grep -v grep | grep -q ssh
> +if ps -ef | grep -v grep | grep -q 'sshd*$'
>  then
>    echo
>    csih_error "There are still ssh processes running. Please shut them down first."

Sorry: i should have offered a solution to the grep -v grep thing
instead of just pointing out the problem.  One way to avoid grep
matching itself when scanning the process table is to use a
non-self-matching regex.

So for example, instead of doing:

  ps -ef | grep -q 'sshd'

You could do:

  ps -ef | grep -q '[s]shd'

which means the same thing from a regex perspective, but does not
self-match:

[0 dkg at squeak ~]$ echo 'grep -q sshd' | grep 'sshd'
grep -q sshd
[0 dkg at squeak ~]$ echo 'grep -q [s]shd' | grep '[s]shd'
[1 dkg at squeak ~]$ 

Most non-literals like $ (meaning end of line) are sufficient for this
also, since

  grep -q sshd$

does not self-match:

[0 dkg at squeak ~]$ echo 'grep -q sshd$' | grep -q sshd$
[1 dkg at squeak ~]$ 

hth,

        --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20081107/dc5f6b98/attachment.bin 

From dkg at fifthhorseman.net  Sat Nov  8 01:23:47 2008
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri, 07 Nov 2008 09:23:47 -0500
Subject: [PATCH/cygwin] Fix cygwin specific Makefile and a bug in the
	ssh-host-config script
In-Reply-To: <20081107105458.GO6478@calimero.vinschen.de> (Corinna Vinschen's
	message of "Fri\, 7 Nov 2008 11\:54\:58 +0100")
References: <20081107105458.GO6478@calimero.vinschen.de>
Message-ID: <87skq3aa30.fsf@squeak.fifthhorseman.net>

On Fri 2008-11-07 05:54:58 -0500, Corinna Vinschen wrote:

> diff -u -p -r1.22 ssh-host-config
> --- contrib/cygwin/ssh-host-config	14 Jul 2008 02:12:54 -0000	1.22
> +++ contrib/cygwin/ssh-host-config	7 Nov 2008 10:49:30 -0000
> @@ -456,7 +456,7 @@ done
>  
>  # Check for running ssh/sshd processes first. Refuse to do anything while
>  # some ssh processes are still running
> -if ps -ef | grep -v grep | grep -q ssh
> +if ps -ef | grep -v grep | grep -q 'sshd*$'
>  then
>    echo
>    csih_error "There are still ssh processes running. Please shut them down first."

This regular expression seems to match any line that ends in
sshddddd...  That is, sshd* matches sshd followed by any number of d
characters.  Is that really what is intended?

I don't run any cygwin systems any more, so i can't be certain that
this incorrect, but it seems unlikely to me.

Also, it seems that this check (with the grep -v grep) will also
*miss* any processes owned by usernames that contain the string
"grep".

On my debian box, some sshd processes look like this due to privsep
(e.g. for the sales representative for bags and backpacks):

bagrep    26479 26476  0 01:02 ?        00:00:00 sshd: bagrep at pts/5

If you're trying to match this kind of process, it would get missed by
the above invocation.

Are you trying to match running sshd processes that have *not* dropped
privileges yet?  or all sshd processes?

Sorry for not knowing more about cygwin and not being more helpful.

     --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20081107/8e6c03e9/attachment.bin 

From mouring at eviladmin.org  Sat Nov  8 02:34:17 2008
From: mouring at eviladmin.org (Ben Lindstrom)
Date: Fri, 7 Nov 2008 09:34:17 -0600
Subject: Bug+bugfix in sftp-server : failed to rename file on sshfs mount
In-Reply-To: <8b4c1ca70811061344g65d81ae0x96475abf9985e27d@mail.gmail.com>
References: <8b4c1ca70811051026u249dcc99x33d97c6efa7f067b@mail.gmail.com>
	<AD20BE85-E0D0-4FD1-893B-FA9978352F45@eviladmin.org>
	<8b4c1ca70811061344g65d81ae0x96475abf9985e27d@mail.gmail.com>
Message-ID: <9B6F353E-8A5B-47F0-9B04-16C0675C6EAE@eviladmin.org>


On Nov 6, 2008, at 3:44 PM, Johan Kielbaey wrote:

> 2008/11/5 Ben Lindstrom <mouring at eviladmin.org>:
>> Without seeing the patch I can't judge it.
>>
>> However, why is sshfs failure to implement things right an OpenSSH  
>> bug?
>
> Point taken. I guess I explained myself wrong. Obviously the fact that
> sshfs doesn't implement the link() call is not an OpenSSH bug. From my
> understanding the SFTPv3 protocol doesn't feature creation of hard
> links.
>
> sftp-server falls back to the rename() syscall if the link() syscall
> fails with certain error codes. EOPNOTSUPP is such an errorcode. Sshfs
> however returns ENOSYS, which is not such as errorcode.
>

So what Linux filesystem returns ENOSYS?  I'm a little confused  
because normally Linux returns EOPNOTSUPP for filesystem things.

- Ben

From vinschen at redhat.com  Sat Nov  8 02:56:21 2008
From: vinschen at redhat.com (Corinna Vinschen)
Date: Fri, 7 Nov 2008 16:56:21 +0100
Subject: [PATCH/cygwin] Fix cygwin specific Makefile and a bug in the
	ssh-host-config script
In-Reply-To: <87skq3aa30.fsf@squeak.fifthhorseman.net>
References: <20081107105458.GO6478@calimero.vinschen.de>
	<87skq3aa30.fsf@squeak.fifthhorseman.net>
Message-ID: <20081107155621.GA6478@calimero.vinschen.de>

On Nov  7 09:23, Daniel Kahn Gillmor wrote:
> On Fri 2008-11-07 05:54:58 -0500, Corinna Vinschen wrote:
> 
> > diff -u -p -r1.22 ssh-host-config
> > --- contrib/cygwin/ssh-host-config	14 Jul 2008 02:12:54 -0000	1.22
> > +++ contrib/cygwin/ssh-host-config	7 Nov 2008 10:49:30 -0000
> > @@ -456,7 +456,7 @@ done
> >  
> >  # Check for running ssh/sshd processes first. Refuse to do anything while
> >  # some ssh processes are still running
> > -if ps -ef | grep -v grep | grep -q ssh
> > +if ps -ef | grep -v grep | grep -q 'sshd*$'
> >  then
> >    echo
> >    csih_error "There are still ssh processes running. Please shut them down first."
> 
> This regular expression seems to match any line that ends in
> sshddddd...  That is, sshd* matches sshd followed by any number of d
> characters.  Is that really what is intended?

Thanks for pointing this out.  That's not intended of course.

> Also, it seems that this check (with the grep -v grep) will also
> *miss* any processes owned by usernames that contain the string
> "grep".

Huh!  Another good point.  The script was apparently just lucky that
this doesn't occur very often.  Especially since the grep command
isn't found by the grep -q expression anyway due to the way ps -ef
prints the processes.

> On my debian box, some sshd processes look like this due to privsep
> (e.g. for the sales representative for bags and backpacks):
> 
> bagrep    26479 26476  0 01:02 ?        00:00:00 sshd: bagrep at pts/5
> 
> If you're trying to match this kind of process, it would get missed by
> the above invocation.

That doesn't happen on Cygwin.  ps -ef always prints the full path to
the application as the rightmost string, without any Windows .exe suffix
and without any arguments.  So what the script has to catch are the
strings ssh$ and sshd$.  The above quick fix was just the first and
easiest and (*blush*) laziest which came to mind.

So it appears a much better solution is

  if ps -ef | grep -q 'sshd\?$'

The patch to ssh-host-config would be:


Index: contrib/cygwin/ssh-host-config
===================================================================
RCS file: /cvs/openssh/contrib/cygwin/ssh-host-config,v
retrieving revision 1.22
diff -u -p -r1.22 ssh-host-config
--- contrib/cygwin/ssh-host-config	14 Jul 2008 02:12:54 -0000	1.22
+++ contrib/cygwin/ssh-host-config	7 Nov 2008 15:43:52 -0000
@@ -456,7 +456,7 @@ done
 
 # Check for running ssh/sshd processes first. Refuse to do anything while
 # some ssh processes are still running
-if ps -ef | grep -v grep | grep -q ssh
+if ps -ef | grep -q 'sshd\?$'
 then
   echo
   csih_error "There are still ssh processes running. Please shut them down first."

I just hope I didn't miss anything else...


Thanks again,
Corinna

-- 
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat

From bob at proulx.com  Sat Nov  8 05:16:14 2008
From: bob at proulx.com (Bob Proulx)
Date: Fri, 7 Nov 2008 11:16:14 -0700
Subject: [PATCH/cygwin] Fix cygwin specific Makefile and a bug in the
	ssh-host-config script
In-Reply-To: <8763mz61bh.fsf@squeak.fifthhorseman.net>
References: <20081107105458.GO6478@calimero.vinschen.de>
	<8763mz61bh.fsf@squeak.fifthhorseman.net>
Message-ID: <20081107181614.GB14614@discord.proulx.com>

Daniel Kahn Gillmor wrote:
> Corinna Vinschen wrote:
> > diff -u -p -r1.22 ssh-host-config
> > -if ps -ef | grep -v grep | grep -q ssh
> > +if ps -ef | grep -v grep | grep -q 'sshd*$'
> 
> Sorry: i should have offered a solution to the grep -v grep thing
> instead of just pointing out the problem.  One way to avoid grep
> matching itself when scanning the process table is to use a
> non-self-matching regex.
> 
> So for example, instead of doing:
> 
>   ps -ef | grep -q 'sshd'
> 
> You could do:
> 
>   ps -ef | grep -q '[s]shd'

Using the brackets to avoid the self match is a good improvement.  But
I think it is better to avoid the -f and avoid the problem that way.
I think people get into the habit of using -f and then forget about
using ps without it.

  ps -e | grep -q sshd

Doing it this way we are at least as good as before.  But of course
that matches "abcsshd" too the same as the previous.  If 'awk' is
available it can make exact matching on the final column very easy.

  ps -e | awk '$NF=="sshd"'

One way to turn this into a boolean is this way:

  if ! ps -e | awk '$NF=="sshd"{exit(1);}'

But to me the reversal of exit value is unfortunate.  Therefore I
would use the presence of output as the way to determine status.  To
my eye the next is more easily understood and has less subtleties

  if [ -n "$(ps -e | awk '$NF=="sshd"')" ]

In summary to me using 'ps -e' seems more correct that using 'ps -ef'
and then filtering out the -f part of the output.

Of course it still fails if a process is executing and the name of the
process contains spaces and the last part after the space is "sshd".
But if someone is doing that it would seem to me that they are simply
setting themselves up for trouble.

Bob

From peter at stuge.se  Sun Nov  9 07:28:36 2008
From: peter at stuge.se (Peter Stuge)
Date: Sat, 8 Nov 2008 21:28:36 +0100
Subject: Can not debug sshd in gdb
In-Reply-To: <200810302118.04315.shubin_evgeniy@mail.ru>
References: <200810302118.04315.shubin_evgeniy@mail.ru>
Message-ID: <20081108202836.6026.qmail@stuge.se>

?????????????? wrote:
> I want to set break point on function packet_read_poll2 in file
> packet.c and the program do not stop on it.

I guess this is because of privsep. Try disabling privsep in the sshd
configuration.


//Peter

From mkoeppe at gmx.de  Thu Nov  6 09:52:21 2008
From: mkoeppe at gmx.de (Martin Koeppe)
Date: Wed, 5 Nov 2008 23:52:21 +0100 (CET)
Subject: openssh on interix
Message-ID: <Pine.LNX.4.62.0811052313150.32748@vmdebian.local.koeppe-net.de>


Hi openssh developers,

I'm trying to port openssh to Interix. See [1] for more on this.

For Interix sshd needs to be patched to not use setuid()/setgid(), but 
an Interix specific function setuser(). See [2] why it is needed. 
Unfortunately, setuser() needs the clear-text password of the user to 
be fully functional (If you use password-less setuser(), then the 
user doesn't have network access rights, e.g. no access to a network 
home dir).

The problem is now: How to get the clear-text password from
   auth-passwd.c:auth_password()
to
   uidswap.c:permanently_set_uid()
where it would be needed as argument for setuser()?

See [3] for the patch I'm currently using. My first idea would be to 
use the struct passwd pw_passwd field that is passed to 
permanently_set_uid() for storing the clear-text password after 
successful (password-)authentication.

Before looking into details I just want to ask:
Would such use of struct passwd be a security issue?


Many thanks in advance

Martin


[1] http://www.debian-interix.net/
[2] http://www.suacommunity.com/forum/tm.aspx?m=4663&mpage=1&key=setuser&#7061
[3] http://www.debian-interix.net/debian-interix/pool/unreleased35/main/o/openssh/openssh_4.7p1-9_4.7p1-9+interix.2.interdiff.gz

From jengelh at medozas.de  Mon Nov 10 17:57:39 2008
From: jengelh at medozas.de (Jan Engelhardt)
Date: Mon, 10 Nov 2008 07:57:39 +0100 (CET)
Subject: Requesting PAM input with pubkey
Message-ID: <alpine.LNX.1.10.0811100755200.20181@fbirervta.pbzchgretzou.qr>

Hi,


is there a way, even when PubkeyAuthentication is enabled, that OpenSSH 
can additionally do a keyboard-interactive input to satisfy PAM auth or 
session modules that may request such?

thanks,
Jan

From vinschen at redhat.com  Tue Nov 11 00:20:18 2008
From: vinschen at redhat.com (Corinna Vinschen)
Date: Mon, 10 Nov 2008 14:20:18 +0100
Subject: [PATCH/cygwin] Fix cygwin specific Makefile and a bug in the
	ssh-host-config script
In-Reply-To: <20081107181614.GB14614@discord.proulx.com>
References: <20081107105458.GO6478@calimero.vinschen.de>
	<8763mz61bh.fsf@squeak.fifthhorseman.net>
	<20081107181614.GB14614@discord.proulx.com>
Message-ID: <20081110132018.GA4378@calimero.vinschen.de>

On Nov  7 11:16, Bob Proulx wrote:
> Daniel Kahn Gillmor wrote:
> >   ps -ef | grep -q '[s]shd'
> [...]
>   if [ -n "$(ps -e | awk '$NF=="sshd"')" ]
> 
> In summary to me using 'ps -e' seems more correct that using 'ps -ef'
> and then filtering out the -f part of the output.

The difference between ps -e and ps -ef is not the same on Cygwin as on
Linux.  The command strings are identical (full path) so the above awk
expression doesn't work on Cygwin, besides the fact that it doesn't
catch ssh processes, only sshd.

The final expression which is now used is this:

  if ps -ef | grep -q '/sshd\?$'

I pasted the entire patch again below.  Could somebody please check it in?


Thanks,
Corinna


Index: contrib/cygwin/Makefile
===================================================================
RCS file: /cvs/openssh/contrib/cygwin/Makefile,v
retrieving revision 1.3
diff -u -p -r1.3 Makefile
--- contrib/cygwin/Makefile	14 Jul 2008 02:12:54 -0000	1.3
+++ contrib/cygwin/Makefile	10 Nov 2008 13:11:53 -0000
@@ -38,11 +38,13 @@ install-sshdoc:
 	$(INSTALL) -m 644 $(srcdir)/ChangeLog $(DESTDIR)$(sshdocdir)/ChangeLog
 	$(INSTALL) -m 644 $(srcdir)/LICENCE $(DESTDIR)$(sshdocdir)/LICENCE
 	$(INSTALL) -m 644 $(srcdir)/OVERVIEW $(DESTDIR)$(sshdocdir)/OVERVIEW
+	$(INSTALL) -m 644 $(srcdir)/PROTOCOL $(DESTDIR)$(sshdocdir)/PROTOCOL
+	$(INSTALL) -m 644 $(srcdir)/PROTOCOL.agent $(DESTDIR)$(sshdocdir)/PROTOCOL.agent
 	$(INSTALL) -m 644 $(srcdir)/README $(DESTDIR)$(sshdocdir)/README
 	$(INSTALL) -m 644 $(srcdir)/README.dns $(DESTDIR)$(sshdocdir)/README.dns
+	$(INSTALL) -m 644 $(srcdir)/README.platform $(DESTDIR)$(sshdocdir)/README.platform
 	$(INSTALL) -m 644 $(srcdir)/README.privsep $(DESTDIR)$(sshdocdir)/README.privsep
 	$(INSTALL) -m 644 $(srcdir)/README.smartcard $(DESTDIR)$(sshdocdir)/README.smartcard
-	$(INSTALL) -m 644 $(srcdir)/RFC.nroff $(DESTDIR)$(sshdocdir)/RFC.nroff
 	$(INSTALL) -m 644 $(srcdir)/TODO $(DESTDIR)$(sshdocdir)/TODO
 	$(INSTALL) -m 644 $(srcdir)/WARNING.RNG $(DESTDIR)$(sshdocdir)/WARNING.RNG
 
Index: contrib/cygwin/ssh-host-config
===================================================================
RCS file: /cvs/openssh/contrib/cygwin/ssh-host-config,v
retrieving revision 1.22
diff -u -p -r1.22 ssh-host-config
--- contrib/cygwin/ssh-host-config	14 Jul 2008 02:12:54 -0000	1.22
+++ contrib/cygwin/ssh-host-config	10 Nov 2008 13:11:53 -0000
@@ -456,7 +456,7 @@ done
 
 # Check for running ssh/sshd processes first. Refuse to do anything while
 # some ssh processes are still running
-if ps -ef | grep -v grep | grep -q ssh
+if ps -ef | grep -q '/sshd\?$'
 then
   echo
   csih_error "There are still ssh processes running. Please shut them down first."


-- 
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat

From hijinks at gmail.com  Tue Nov 11 05:34:58 2008
From: hijinks at gmail.com (Mike Zupan)
Date: Mon, 10 Nov 2008 13:34:58 -0500
Subject: 1 command ssh session
Message-ID: <7227c6c70811101034x6d4b7d4al164ac8043754e1b8@mail.gmail.com>

I wrote a patch to bash to log commands.. Now when I run the following
command

ssh user at hostname.com w

It never seems to spawn a bash session. Is there some ssh internal shell
that handles commands getting passed in like this?

Thanks
Mike

From jengelh at medozas.de  Tue Nov 11 06:14:00 2008
From: jengelh at medozas.de (Jan Engelhardt)
Date: Mon, 10 Nov 2008 20:14:00 +0100 (CET)
Subject: 1 command ssh session
In-Reply-To: <7227c6c70811101034x6d4b7d4al164ac8043754e1b8@mail.gmail.com>
References: <7227c6c70811101034x6d4b7d4al164ac8043754e1b8@mail.gmail.com>
Message-ID: <alpine.LNX.1.10.0811102009370.3005@fbirervta.pbzchgretzou.qr>


On Monday 2008-11-10 19:34, Mike Zupan wrote:

>I wrote a patch to bash to log commands..

People can just use another shell and evade begin logged.

>Now when I run the following
>command
>
>ssh user at hostname.com w
>
>It never seems to spawn a bash session.

Generally a shell is spawned, otherwise something like

	ssh localhost "ls ."

would try to execute the program "ls ." instead of "ls" with "." as 
argument.

From deengert at anl.gov  Tue Nov 11 06:15:41 2008
From: deengert at anl.gov (Douglas E. Engert)
Date: Mon, 10 Nov 2008 13:15:41 -0600
Subject: openssh on interix
In-Reply-To: <Pine.LNX.4.62.0811052313150.32748@vmdebian.local.koeppe-net.de>
References: <Pine.LNX.4.62.0811052313150.32748@vmdebian.local.koeppe-net.de>
Message-ID: <4918885D.30002@anl.gov>



Martin Koeppe wrote:
> Hi openssh developers,
> 
> I'm trying to port openssh to Interix. See [1] for more on this.
> 
> For Interix sshd needs to be patched to not use setuid()/setgid(), but 
> an Interix specific function setuser(). See [2] why it is needed. 
> Unfortunately, setuser() needs the clear-text password of the user to 
> be fully functional (If you use password-less setuser(), then the 
> user doesn't have network access rights, e.g. no access to a network 
> home dir).

Sounds like what you are trying to do is run the sshd on a Windows
machine, and get the user's windows password so they can "login"
to Windows?

If the sshd could use the GSSAPI and delegated credentials, it might
be possible to pass the Kerberos ticket into the LSA.  This could give
you single sign on.
I believe with a registry setting, the Kerberos for Windows can do
something like this. You might want to ask on the kerberos at mit.edu list

http://www.vandyke.com/products/vshell/index.html
might be another possibility.

> 
> The problem is now: How to get the clear-text password from
>    auth-passwd.c:auth_password()
> to
>    uidswap.c:permanently_set_uid()
> where it would be needed as argument for setuser()?
> 
> See [3] for the patch I'm currently using. My first idea would be to 
> use the struct passwd pw_passwd field that is passed to 
> permanently_set_uid() for storing the clear-text password after 
> successful (password-)authentication.
> 
> Before looking into details I just want to ask:
> Would such use of struct passwd be a security issue?
> 
> 
> Many thanks in advance
> 
> Martin
> 
> 
> [1] http://www.debian-interix.net/
> [2] http://www.suacommunity.com/forum/tm.aspx?m=4663&mpage=1&key=setuser&#7061
> [3] http://www.debian-interix.net/debian-interix/pool/unreleased35/main/o/openssh/openssh_4.7p1-9_4.7p1-9+interix.2.interdiff.gz
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
> 
> 

-- 

  Douglas E. Engert  <DEEngert at anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444

From mloftis at wgops.com  Tue Nov 11 06:11:59 2008
From: mloftis at wgops.com (Michael Loftis)
Date: Mon, 10 Nov 2008 12:11:59 -0700
Subject: 1 command ssh session
In-Reply-To: <7227c6c70811101034x6d4b7d4al164ac8043754e1b8@mail.gmail.com>
References: <7227c6c70811101034x6d4b7d4al164ac8043754e1b8@mail.gmail.com>
Message-ID: <E31DA5A6596D8108A68E4DBE@ZOP-MACTEL.local>

No, it simply exec's it from the PATH/env given to the SSHD.  There's an 
option to force it to init a shell or something like that if you want (or 
for some reason need) the overhead.  I forget what it is but I'm sure 
someone here can enlighten.

--On November 10, 2008 1:34:58 PM -0500 Mike Zupan <hijinks at gmail.com> 
wrote:

> I wrote a patch to bash to log commands.. Now when I run the following
> command
>
> ssh user at hostname.com w
>
> It never seems to spawn a bash session. Is there some ssh internal shell
> that handles commands getting passed in like this?
>
> Thanks
> Mike
> _______________________________________________
> 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 tony at connectionlost.org  Tue Nov 11 06:53:02 2008
From: tony at connectionlost.org (Tony Alfaro)
Date: Mon, 10 Nov 2008 13:53:02 -0600
Subject: ssh weirdness - hanging sessions intermittently with no connectivity
	after for an hour or so...
Message-ID: <df8d8af20811101153p11bbc20ejcb623299a67b417@mail.gmail.com>

I just finished rebuilding my server after a penetration last week
which left my filesystem in shambles.  I've gotten most everything
running again better than before with one exception.

sshd doesn't work as well as it used to and I'm not sure why, I'm
including a sanitized log snippet, hopefully someone can point out my
stupidity for me...

If I open a putty session from another network it's 50/50 whether or
not I even get a response, and if I do, then it usually hangs after I
enter my password and then times out - OR - it will connect, negotiate
a session, and then die after about 20 minutes - in any case once dead
it takes at least 20 - 30 minutes before it will allow me to connect
again...  Any ideas?


Nov 10 13:32:53 localhost sshd[21009]: debug1: Forked child 26900.
Nov 10 13:32:53 localhost sshd[26900]: debug1: rexec start in 4 out 4
newsock 4 pipe 6 sock 7
Nov 10 13:32:53 localhost sshd[26900]: debug1: inetd sockets after dupping: 3, 3
Nov 10 13:32:53 localhost sshd[26900]: Connection from xxx.xxx.xxx.xxx port 1554
Nov 10 13:32:53 localhost sshd[26900]: debug1: Client protocol version
2.0; client software version PuTTY_Release_0.60
Nov 10 13:32:53 localhost sshd[26900]: debug1: no match: PuTTY_Release_0.60
Nov 10 13:32:53 localhost sshd[26900]: debug1: Enabling compatibility
mode for protocol 2.0
Nov 10 13:32:53 localhost sshd[26900]: debug1: Local version string
SSH-2.0-OpenSSH_4.3p2 Debian-9etch3
Nov 10 13:32:54 localhost sshd[26900]: debug1: PAM: initializing for "user"
Nov 10 13:32:54 localhost sshd[26900]: reverse mapping checking
getaddrinfo for dhcpxxx-xx-xxx-xxx.xxxx.xx.xx.xxxx.xxxxxxx.xxx failed
- POSSIBLE BREAK-IN ATTEMPT!
Nov 10 13:32:54 localhost sshd[26900]: debug1: PAM: setting PAM_RHOST
to "xxx.xx.xxx.xxx"
Nov 10 13:32:54 localhost sshd[26900]: debug1: PAM: setting PAM_TTY to "ssh"
Nov 10 13:32:54 localhost sshd[26900]: Failed none for tony from
xxx.xx.xxx.xxx port 1554 ssh2
Nov 10 13:32:57 localhost sshd[26900]: debug1: PAM: password
authentication accepted for user
Nov 10 13:32:57 localhost sshd[26900]: debug1: do_pam_account: called
Nov 10 13:32:57 localhost sshd[26900]: Accepted password for user from
xxx.xx.xxx.xxx port 1554 ssh2
Nov 10 13:32:57 localhost sshd[26900]: debug1: monitor_child_preauth:
user has been authenticated by privileged process
Nov 10 13:32:57 localhost sshd[26902]: (pam_unix) session opened for
user user by (uid=0)
Nov 10 13:32:57 localhost sshd[26902]: debug1: PAM: reinitializing credentials
Nov 10 13:32:57 localhost sshd[26902]: debug1: permanently_set_uid: 1000/1000
Nov 10 13:32:57 localhost sshd[26902]: debug1: Entering interactive
session for SSH2.
Nov 10 13:32:57 localhost sshd[26902]: debug1: server_init_dispatch_20
Nov 10 13:32:57 localhost sshd[26902]: debug1:
server_input_channel_open: ctype session rchan 256 win 16384 max 16384
Nov 10 13:32:57 localhost sshd[26902]: debug1: input_session_request
Nov 10 13:32:57 localhost sshd[26902]: debug1: channel 0: new [server-session]
Nov 10 13:32:57 localhost sshd[26902]: debug1: session_new: init
Nov 10 13:32:57 localhost sshd[26902]: debug1: session_new: session 0
Nov 10 13:32:57 localhost sshd[26902]: debug1: session_open: channel 0
Nov 10 13:32:57 localhost sshd[26902]: debug1: session_open: session
0: link with channel 0
Nov 10 13:32:57 localhost sshd[26902]: debug1:
server_input_channel_open: confirm session
Nov 10 13:32:57 localhost sshd[26902]: debug1:
server_input_channel_req: channel 0 request pty-req reply 1
Nov 10 13:32:57 localhost sshd[26902]: debug1: session_by_channel:
session 0 channel 0
Nov 10 13:32:57 localhost sshd[26902]: debug1:
session_input_channel_req: session 0 req pty-req
Nov 10 13:32:57 localhost sshd[26902]: debug1: Allocating pty.
Nov 10 13:32:57 localhost sshd[26900]: debug1: session_new: init
Nov 10 13:32:57 localhost sshd[26900]: debug1: session_new: session 0
Nov 10 13:32:57 localhost sshd[26902]: debug1: session_pty_req:
session 0 alloc /dev/pts/2
Nov 10 13:32:57 localhost sshd[26902]: debug1:
server_input_channel_req: channel 0 request shell reply 1
Nov 10 13:32:57 localhost sshd[26902]: debug1: session_by_channel:
session 0 channel 0
Nov 10 13:32:57 localhost sshd[26902]: debug1:
session_input_channel_req: session 0 req shell
Nov 10 13:32:57 localhost sshd[26902]: debug1: PAM: setting PAM_TTY to
"/dev/pts/2"
Nov 10 13:32:57 localhost sshd[26903]: debug1: Setting controlling tty
using TIOCSCTTY.
Nov 10 13:33:13 localhost sshd[26874]: debug1: Got 100/81 for keepalive
Nov 10 13:33:13 localhost sshd[26851]: Disconnecting: Timeout, your
session not responding.
Nov 10 13:33:13 localhost sshd[26851]: debug1: do_cleanup
Nov 10 13:33:13 localhost sshd[26851]: debug1: PAM: cleanup
Nov 10 13:33:13 localhost sshd[26851]: (pam_unix) session closed for user user
Nov 10 13:33:13 localhost sshd[26848]: debug1: do_cleanup
Nov 10 13:33:13 localhost sshd[26848]: debug1: PAM: cleanup
Nov 10 13:33:13 localhost sshd[26848]: debug1: session_pty_cleanup:
session 0 release /dev/pts/0

From jengelh at medozas.de  Tue Nov 11 17:49:59 2008
From: jengelh at medozas.de (Jan Engelhardt)
Date: Tue, 11 Nov 2008 07:49:59 +0100 (CET)
Subject: ssh weirdness - hanging sessions intermittently with no
	connectivity after for an hour or so...
In-Reply-To: <df8d8af20811101153p11bbc20ejcb623299a67b417@mail.gmail.com>
References: <df8d8af20811101153p11bbc20ejcb623299a67b417@mail.gmail.com>
Message-ID: <alpine.LNX.1.10.0811110740310.29870@fbirervta.pbzchgretzou.qr>


On Monday 2008-11-10 20:53, Tony Alfaro wrote:

>sshd doesn't work as well as it used to and I'm not sure why, I'm
>including a sanitized log snippet, hopefully someone can point out my
>stupidity for me...
>
>If I open a putty session from another network it's 50/50 whether or
>not I even get a response, and if I do, then it usually hangs after I
>enter my password and then times out - OR - it will connect, negotiate
>a session, and then die after about 20 minutes - in any case once dead
>it takes at least 20 - 30 minutes before it will allow me to connect
>again...  Any ideas?

It might be that there is a shitty router along the path that chokes
on TCP packets with SACK/DSACK. Been there - any packet bursts
(connection setup, or just loads of output from `ls -Rl`, or a bulk
transfer with rsync/scp/sftp) hung it.
Suggestion to try to disable SACK/DSACK.
In case your sshd is on Linux, you can use iptables's TCPOPTSTRIP to
get rid of the SACK pieces on the TCP SYN for SSH connections.

From mkoeppe at gmx.de  Tue Nov 11 09:38:40 2008
From: mkoeppe at gmx.de (Martin Koeppe)
Date: Mon, 10 Nov 2008 23:38:40 +0100 (CET)
Subject: openssh on interix
In-Reply-To: <4918885D.30002@anl.gov>
References: <Pine.LNX.4.62.0811052313150.32748@vmdebian.local.koeppe-net.de>
	<4918885D.30002@anl.gov>
Message-ID: <Pine.LNX.4.62.0811102229460.26949@vmdebian.local.koeppe-net.de>


On Mon, 10 Nov 2008, Douglas E. Engert wrote:

> Martin Koeppe wrote:
>> Hi openssh developers,
>> 
>> I'm trying to port openssh to Interix. See [1] for more on this.
>> 
>> For Interix sshd needs to be patched to not use setuid()/setgid(), but an 
>> Interix specific function setuser(). See [2] why it is needed. 
>> Unfortunately, setuser() needs the clear-text password of the user to be 
>> fully functional (If you use password-less setuser(), then the user doesn't 
>> have network access rights, e.g. no access to a network home dir).
>
> Sounds like what you are trying to do is run the sshd on a Windows
> machine, and get the user's windows password so they can "login"
> to Windows?

It's only partly right. Interix can be thought of a unix-like kernel 
running within the windows kernel. So you have all the unix syscalls
and unix libc functions available. You also get unix-like file system 
semantics. I'd like to port sshd to this unix-like environment.
The goal is not just to have "any" ssh login on windows, it's to 
enhance my port of Debian to interix.

While setuid() is also available and basically functional, the right 
way to change to the user is - on interix - not setuid(), but 
setuser(). If setuser() gets no password, local access is granted, but 
for network access a new session would be needed. But if the password 
could be used for setuser(), then setuser() would allow network access 
to the new session. And sshd has the needed password in auth_passwd(), 
but not in permanently_set_uid().


> If the sshd could use the GSSAPI and delegated credentials, it might
> be possible to pass the Kerberos ticket into the LSA.  This could give
> you single sign on.
> I believe with a registry setting, the Kerberos for Windows can do
> something like this. You might want to ask on the kerberos at mit.edu list

>From within the interix environment the only way to contact the LSA is 
over the built-in interix kerrnel functions like setuser(). Interix 
programs don't have access to the Win32 API.

Martin


> http://www.vandyke.com/products/vshell/index.html
> might be another possibility.
>
>> 
>> The problem is now: How to get the clear-text password from
>>    auth-passwd.c:auth_password()
>> to
>>    uidswap.c:permanently_set_uid()
>> where it would be needed as argument for setuser()?
>> 
>> See [3] for the patch I'm currently using. My first idea would be to use 
>> the struct passwd pw_passwd field that is passed to permanently_set_uid() 
>> for storing the clear-text password after successful 
>> (password-)authentication.
>> 
>> Before looking into details I just want to ask:
>> Would such use of struct passwd be a security issue?
>> 
>> 
>> Many thanks in advance
>> 
>> Martin
>> 
>> 
>> [1] http://www.debian-interix.net/
>> [2] 
>> http://www.suacommunity.com/forum/tm.aspx?m=4663&mpage=1&key=setuser&#7061
>> [3] 
>> http://www.debian-interix.net/debian-interix/pool/unreleased35/main/o/openssh/openssh_4.7p1-9_4.7p1-9+interix.2.interdiff.gz
>> _______________________________________________
>> openssh-unix-dev mailing list
>> openssh-unix-dev at mindrot.org
>> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>> 
>> 
>
> -- 
>
> Douglas E. Engert  <DEEngert at anl.gov>
> Argonne National Laboratory
> 9700 South Cass Avenue
> Argonne, Illinois  60439
> (630) 252-5444
>

From vinschen at redhat.com  Tue Nov 11 23:27:42 2008
From: vinschen at redhat.com (Corinna Vinschen)
Date: Tue, 11 Nov 2008 13:27:42 +0100
Subject: openssh on interix
In-Reply-To: <Pine.LNX.4.62.0811102229460.26949@vmdebian.local.koeppe-net.de>
References: <Pine.LNX.4.62.0811052313150.32748@vmdebian.local.koeppe-net.de>
	<4918885D.30002@anl.gov>
	<Pine.LNX.4.62.0811102229460.26949@vmdebian.local.koeppe-net.de>
Message-ID: <20081111122742.GG6478@calimero.vinschen.de>

On Nov 10 23:38, Martin Koeppe wrote:
> 
> On Mon, 10 Nov 2008, Douglas E. Engert wrote:
> 
> > Martin Koeppe wrote:
> >> Hi openssh developers,
> >> 
> >> I'm trying to port openssh to Interix. See [1] for more on this.
> >> 
> >> For Interix sshd needs to be patched to not use setuid()/setgid(), but an 
> >> Interix specific function setuser(). See [2] why it is needed. 
> >> Unfortunately, setuser() needs the clear-text password of the user to be 
> >> fully functional (If you use password-less setuser(), then the user doesn't 
> >> have network access rights, e.g. no access to a network home dir).
> >
> > Sounds like what you are trying to do is run the sshd on a Windows
> > machine, and get the user's windows password so they can "login"
> > to Windows?
> 
> It's only partly right. Interix can be thought of a unix-like kernel 
> running within the windows kernel. So you have all the unix syscalls
> and unix libc functions available. You also get unix-like file system 
> semantics. I'd like to port sshd to this unix-like environment.
> The goal is not just to have "any" ssh login on windows, it's to 
> enhance my port of Debian to interix.

This is all the same problem Cygwin's port to OpenSSH has.  However, on
Interix/SUA the user can store the password in the registry using the
`regpwd' tool.  I have no idea how the password is stored and how to
access it from privileged Interix processes, though.  Isn't there some
documentation?  Or is the password only accessible by daemons created by
Microsoft's developers?  Maybe you should try asking this on the MS
newsgroup dedicated to SUA:

  microsoft.public.servicesforunix.general


Corinna

-- 
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat

From carlopradissitto at gmail.com  Tue Nov 11 22:39:37 2008
From: carlopradissitto at gmail.com (Carlo Pradissitto)
Date: Tue, 11 Nov 2008 12:39:37 +0100
Subject: Fwd: Permissions in chroot SFTP
In-Reply-To: <4a73f9240811110327w582ec095y122b35ba3138763e@mail.gmail.com>
References: <4a73f9240811110327w582ec095y122b35ba3138763e@mail.gmail.com>
Message-ID: <4a73f9240811110339t6269e975r7052dc0baee1b440@mail.gmail.com>

Hi,
I configured openssh 5.1p1 for sftp server.

Here the specifications in sshd_config file:

Subsystem     sftp   internal-sftp
Match Group sftp
    ForceCommand internal-sftp
    ChrootDirectory /home/%u
    AllowTcpForwarding no

When a user is logged in, he can't upload his document and he receives
this message:

carlo at Music:~$ sftp user at 213.217.147.123
Connecting to 213.217.147.123...
user at 213.217.147.123's password:
sftp> put prova
Uploading prova to /prova
Couldn't get handle: Permission denied
sftp>

Here the directory permissions:

[root at sftp-server ~]# ls -la /home/user/
total 24
drwxr-xr-x   6 root sftp 4096 Nov 10 18:05 .
drwxr-xr-x  54 root root 4096 Nov 10 16:48 ..

OK, my user is a sftp group member, and the sftp group hasn't
sufficient permissions to write in user's home directory.

I add the write permission for the sftp group:

[root at sftp-server ~]# chmod 770 /home/user/
[root at sftp-server ~]# ls -la /home/user/
total 24
drwxrwx---   6 root sftp 4096 Nov 10 18:05 .
drwxr-xr-x  54 root root 4096 Nov 10 16:48 ..


But now the user can't access:

carlo at Music:~$ sftp user at 213.217.145.321
Connecting to 213.217.147.123...
user at 213.217.145.321's password:
Read from remote host 213.217.145.321: Connection reset by peer
Couldn't read packet: Connection reset by peer

Here the error message in /var/log/messages of sftp-server:

Nov 11 11:33:02 sftp-server sshd[10254]: Accepted password for user
from 213.217.145.329 port 38685 ssh2
Nov 11 11:33:02 sftp-server sshd[10256]: fatal: bad ownership or modes
for chroot directory "/home/user"

I get the same result if I change the ownership of user directory:

[root at sftp-server ~]# chown user.sftp /home/user/
[root at sftp-server ~]# ls -la /home/user/
total 24
drwxrwx---   6 user sftp 4096 Nov 10 18:05 .
drwxr-xr-x  54 root root 4096 Nov 10 16:48 ..

carlo at Music:~$ sftp user at 213.217.145.321
Connecting to 213.217.147.123...
user at 213.217.145.321's password:
Read from remote host 213.217.145.321: Connection reset by peer
Couldn't read packet: Connection reset by peer

Nov 11 11:38:11 sftp-server sshd[10267]: Accepted password for user
from 213.217.145.329 port 39285 ssh2
Nov 11 11:38:11 sftp-server sshd[10269]: fatal: bad ownership or modes
for chroot directory "/home/user"

I get the same result if I change the ownership of user directory this way:

[root at sftp-server ~]# chown user.root /home/user/

What can I do in order to grant user access and allow write
permissions in his home directory?

Thanks


--
Carlo Pradissitto

Servizi e Supporto IT

I-WAY S.r.l.
Piazza Caduti di via Fani, 2
03100 Frosinone

Mobile: +393939318571

Tel/Fax: 07751880765

E-mail: c.pradissitto at i-way.it



--
Carlo Pradissitto

Servizi e Supporto IT

I-WAY S.r.l.
Piazza Caduti di via Fani, 2
03100 Frosinone

Mobile: +393939318571

Tel/Fax: 07751880765

E-mail: c.pradissitto at i-way.it

From carlopradissitto at gmail.com  Wed Nov 12 00:19:38 2008
From: carlopradissitto at gmail.com (Carlo Pradissitto)
Date: Tue, 11 Nov 2008 14:19:38 +0100
Subject: Permissions in chroot SFTP
Message-ID: <4a73f9240811110519q1acf322co3e1cad9fda263098@mail.gmail.com>

Hi,
I configured openssh 5.1p1 for sftp server.

Here the specifications in sshd_config file:

Subsystem     sftp   internal-sftp
Match Group sftp
    ForceCommand internal-sftp
    ChrootDirectory /home/%u
    AllowTcpForwarding no

When a user is logged in, he can't upload his document and he receives
this message:

carlo at Music:~$ sftp user at 213.217.147.123
Connecting to 213.217.147.123...
user at 213.217.147.123's password:
sftp> put prova
Uploading prova to /prova
Couldn't get handle: Permission denied
sftp>

Here the directory permissions:

[root at sftp-server ~]# ls -la /home/user/
total 24
drwxr-xr-x   6 root sftp 4096 Nov 10 18:05 .
drwxr-xr-x  54 root root 4096 Nov 10 16:48 ..

OK, my user is a sftp group member, and the sftp group hasn't
sufficient permissions to write in user's home directory.

I add the write permission for the sftp group:

[root at sftp-server ~]# chmod 770 /home/user/
[root at sftp-server ~]# ls -la /home/user/
total 24
drwxrwx---   6 root sftp 4096 Nov 10 18:05 .
drwxr-xr-x  54 root root 4096 Nov 10 16:48 ..


But now the user can't access:

carlo at Music:~$ sftp user at 213.217.145.321
Connecting to 213.217.147.123...
user at 213.217.145.321's password:
Read from remote host 213.217.145.321: Connection reset by peer
Couldn't read packet: Connection reset by peer

Here the error message in /var/log/messages of sftp-server:

Nov 11 11:33:02 sftp-server sshd[10254]: Accepted password for user
from 213.217.145.329 port 38685 ssh2
Nov 11 11:33:02 sftp-server sshd[10256]: fatal: bad ownership or modes
for chroot directory "/home/user"

I get the same result if I change the ownership of user directory:

[root at sftp-server ~]# chown user.sftp /home/user/
[root at sftp-server ~]# ls -la /home/user/
total 24
drwxrwx---   6 user sftp 4096 Nov 10 18:05 .
drwxr-xr-x  54 root root 4096 Nov 10 16:48 ..

carlo at Music:~$ sftp user at 213.217.145.321
Connecting to 213.217.147.123...
user at 213.217.145.321's password:
Read from remote host 213.217.145.321: Connection reset by peer
Couldn't read packet: Connection reset by peer

Nov 11 11:38:11 sftp-server sshd[10267]: Accepted password for user
from 213.217.145.329 port 39285 ssh2
Nov 11 11:38:11 sftp-server sshd[10269]: fatal: bad ownership or modes
for chroot directory "/home/user"

I get the same result if I change the ownership of user directory this way:

[root at sftp-server ~]# chown user.root /home/user/

What can I do in order to grant user access and allow write
permissions in his home directory?

Thanks

-- 
Carlo Pradissitto

Servizi e Supporto IT

I-WAY S.r.l.
Piazza Caduti di via Fani, 2
03100 Frosinone

Mobile: +393939318571

Tel/Fax: 07751880765

E-mail: c.pradissitto at i-way.it

From carlopradissitto at gmail.com  Tue Nov 11 22:45:11 2008
From: carlopradissitto at gmail.com (Carlo Pradissitto)
Date: Tue, 11 Nov 2008 12:45:11 +0100
Subject: Directory permissions in chroot SFTP
Message-ID: <4a73f9240811110345h29e0c822i6e5922affb153185@mail.gmail.com>

Hi,
I configured openssh 5.1p1 for sftp server.

Here the specifications in sshd_config file:

Subsystem     sftp   internal-sftp
Match Group sftp
    ForceCommand internal-sftp
    ChrootDirectory /home/%u
    AllowTcpForwarding no

When a user is logged in, he can't upload his document and he receives
this message:

carlo at Music:~$ sftp user at 213.217.147.123
Connecting to 213.217.147.123...
user at 213.217.147.123's password:
sftp> put prova
Uploading prova to /prova
Couldn't get handle: Permission denied
sftp>

Here the directory permissions:

[root at sftp-server ~]# ls -la /home/user/
total 24
drwxr-xr-x   6 root sftp 4096 Nov 10 18:05 .
drwxr-xr-x  54 root root 4096 Nov 10 16:48 ..

OK, my user is a sftp group member, and the sftp group hasn't
sufficient permissions to write in user's home directory.

I add the write permission for the sftp group:

[root at sftp-server ~]# chmod 770 /home/user/
[root at sftp-server ~]# ls -la /home/user/
total 24
drwxrwx---   6 root sftp 4096 Nov 10 18:05 .
drwxr-xr-x  54 root root 4096 Nov 10 16:48 ..


But now the user can't access:

carlo at Music:~$ sftp user at 213.217.145.321
Connecting to 213.217.147.123...
user at 213.217.145.321's password:
Read from remote host 213.217.145.321: Connection reset by peer
Couldn't read packet: Connection reset by peer

Here the error message in /var/log/messages of sftp-server:

Nov 11 11:33:02 sftp-server sshd[10254]: Accepted password for user
from 213.217.145.329 port 38685 ssh2
Nov 11 11:33:02 sftp-server sshd[10256]: fatal: bad ownership or modes
for chroot directory "/home/user"

I get the same result if I change the ownership of user directory:

[root at sftp-server ~]# chown user.sftp /home/user/
[root at sftp-server ~]# ls -la /home/user/
total 24
drwxrwx---   6 user sftp 4096 Nov 10 18:05 .
drwxr-xr-x  54 root root 4096 Nov 10 16:48 ..

carlo at Music:~$ sftp user at 213.217.145.321
Connecting to 213.217.147.123...
user at 213.217.145.321's password:
Read from remote host 213.217.145.321: Connection reset by peer
Couldn't read packet: Connection reset by peer

Nov 11 11:38:11 sftp-server sshd[10267]: Accepted password for user
from 213.217.145.329 port 39285 ssh2
Nov 11 11:38:11 sftp-server sshd[10269]: fatal: bad ownership or modes
for chroot directory "/home/user"

I get the same result if I change the ownership of user directory this way:

[root at sftp-server ~]# chown user.root /home/user/

What can I do in order to grant user access and allow write
permissions in his home directory?

Thanks


-- 
Carlo Pradissitto

Servizi e Supporto IT

I-WAY S.r.l.
Piazza Caduti di via Fani, 2
03100 Frosinone

Mobile: +393939318571

Tel/Fax: 07751880765

E-mail: c.pradissitto at i-way.it

From peter at stuge.se  Wed Nov 12 02:46:54 2008
From: peter at stuge.se (Peter Stuge)
Date: Tue, 11 Nov 2008 16:46:54 +0100
Subject: Fwd: Permissions in chroot SFTP
In-Reply-To: <4a73f9240811110339t6269e975r7052dc0baee1b440@mail.gmail.com>
References: <4a73f9240811110327w582ec095y122b35ba3138763e@mail.gmail.com>
	<4a73f9240811110339t6269e975r7052dc0baee1b440@mail.gmail.com>
Message-ID: <20081111154654.12617.qmail@stuge.se>

Carlo Pradissitto wrote:
> I get the same result if I change the ownership of user directory
> this way:
> 
> [root at sftp-server ~]# chown user.root /home/user/
> 
> What can I do in order to grant user access and allow write
> permissions in his home directory?

Start with 755 user:sftp (or 700) and then try user:root.


//Peter

From carlopradissitto at gmail.com  Wed Nov 12 03:27:21 2008
From: carlopradissitto at gmail.com (Carlo Pradissitto)
Date: Tue, 11 Nov 2008 17:27:21 +0100
Subject: Fwd: Permissions in chroot SFTP
In-Reply-To: <20081111154654.12617.qmail@stuge.se>
References: <4a73f9240811110327w582ec095y122b35ba3138763e@mail.gmail.com>
	<4a73f9240811110339t6269e975r7052dc0baee1b440@mail.gmail.com>
	<20081111154654.12617.qmail@stuge.se>
Message-ID: <4a73f9240811110827o3151226ata7dbda9235b519f5@mail.gmail.com>

Case 1
[root at sftp-server ~]# cd /home/
[root at sftp-server home]# chown user.sftp user/
[root at sftp-server home]# chmod 755 user/

carlo at Music:~$ sftp user at 213.217.147.123
Connecting to 213.217.147.123...
user at 213.217.147.123's password:
Read from remote host 213.217.147.123: Connection reset by peer
Couldn't read packet: Connection reset by peer


Case 2
[root at sftp-server home]# chown user.root user/

carlo at Music:~$ sftp user at 213.217.147.123
Connecting to 213.217.147.123...
user at 213.217.147.123's password:
Read from remote host 213.217.147.123: Connection reset by peer
Couldn't read packet: Connection reset by peer


Case 3
[root at sftp-server home]# chown root.sftp user/

carlo at Music:~$ sftp user at 213.217.147.123
Connecting to 213.217.147.123...
user at 213.217.147.123's password:
sftp> put prova
Uploading prova to /prova
Couldn't get handle: Permission denied


2008/11/11 Peter Stuge <peter at stuge.se>:
> Carlo Pradissitto wrote:
>> I get the same result if I change the ownership of user directory
>> this way:
>>
>> [root at sftp-server ~]# chown user.root /home/user/
>>
>> What can I do in order to grant user access and allow write
>> permissions in his home directory?
>
> Start with 755 user:sftp (or 700) and then try user:root.
>
>
> //Peter
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>



-- 
Carlo Pradissitto

Servizi e Supporto IT

I-WAY S.r.l.
Piazza Caduti di via Fani, 2
03100 Frosinone

Mobile: +393939318571

Tel/Fax: 07751880765

E-mail: c.pradissitto at i-way.it

From deengert at anl.gov  Wed Nov 12 03:51:45 2008
From: deengert at anl.gov (Douglas E. Engert)
Date: Tue, 11 Nov 2008 10:51:45 -0600
Subject: openssh on interix
In-Reply-To: <Pine.LNX.4.62.0811102229460.26949@vmdebian.local.koeppe-net.de>
References: <Pine.LNX.4.62.0811052313150.32748@vmdebian.local.koeppe-net.de>
	<4918885D.30002@anl.gov>
	<Pine.LNX.4.62.0811102229460.26949@vmdebian.local.koeppe-net.de>
Message-ID: <4919B821.6020301@anl.gov>



Martin Koeppe wrote:
> 
> On Mon, 10 Nov 2008, Douglas E. Engert wrote:
> 
>> Martin Koeppe wrote:
>>> Hi openssh developers,
>>>
>>> I'm trying to port openssh to Interix. See [1] for more on this.
>>>
>>> For Interix sshd needs to be patched to not use setuid()/setgid(), 
>>> but an Interix specific function setuser(). See [2] why it is needed. 
>>> Unfortunately, setuser() needs the clear-text password of the user to 
>>> be fully functional (If you use password-less setuser(), then the 
>>> user doesn't have network access rights, e.g. no access to a network 
>>> home dir).
>>
>> Sounds like what you are trying to do is run the sshd on a Windows
>> machine, and get the user's windows password so they can "login"
>> to Windows?
> 
> It's only partly right. Interix can be thought of a unix-like kernel 
> running within the windows kernel. So you have all the unix syscalls
> and unix libc functions available. You also get unix-like file system 
> semantics. I'd like to port sshd to this unix-like environment.
> The goal is not just to have "any" ssh login on windows, it's to enhance 
> my port of Debian to interix.
> 
> While setuid() is also available and basically functional, the right way 
> to change to the user is - on interix - not setuid(), but setuser(). If 
> setuser() gets no password, local access is granted, but for network 
> access a new session would be needed. But if the password could be used 
> for setuser(), then setuser() would allow network access to the new 
> session. And sshd has the needed password in auth_passwd(), but not in 
> permanently_set_uid().
> 
> 
>> If the sshd could use the GSSAPI and delegated credentials, it might
>> be possible to pass the Kerberos ticket into the LSA.  This could give
>> you single sign on.
>> I believe with a registry setting, the Kerberos for Windows can do
>> something like this. You might want to ask on the kerberos at mit.edu list
> 
>> From within the interix environment the only way to contact the LSA is 
> over the built-in interix kerrnel functions like setuser(). Interix 
> programs don't have access to the Win32 API.

But you did say that you wanted "newtwork access rights. i.e. no access
to a network home dir". I took that to imply that the Intrex is using the
underlying Windows file systems and that it uses the username and password
via the setuser() to get Widows credentials. The other way to get credentials
is to to pass in a Kerberos TGT, and I think Vista can allow this and KfW
can use it. So Intrix should be able to do this too.

> 
> Martin
> 
> 
>> http://www.vandyke.com/products/vshell/index.html
>> might be another possibility.
>>
>>>
>>> The problem is now: How to get the clear-text password from
>>>    auth-passwd.c:auth_password()
>>> to
>>>    uidswap.c:permanently_set_uid()
>>> where it would be needed as argument for setuser()?
>>>
>>> See [3] for the patch I'm currently using. My first idea would be to 
>>> use the struct passwd pw_passwd field that is passed to 
>>> permanently_set_uid() for storing the clear-text password after 
>>> successful (password-)authentication.
>>>
>>> Before looking into details I just want to ask:
>>> Would such use of struct passwd be a security issue?
>>>
>>>
>>> Many thanks in advance
>>>
>>> Martin
>>>
>>>
>>> [1] http://www.debian-interix.net/
>>> [2] 
>>> http://www.suacommunity.com/forum/tm.aspx?m=4663&mpage=1&key=setuser&#7061 
>>>
>>> [3] 
>>> http://www.debian-interix.net/debian-interix/pool/unreleased35/main/o/openssh/openssh_4.7p1-9_4.7p1-9+interix.2.interdiff.gz 
>>>
>>> _______________________________________________
>>> openssh-unix-dev mailing list
>>> openssh-unix-dev at mindrot.org
>>> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>>>
>>>
>>
>> -- 
>>
>> Douglas E. Engert  <DEEngert at anl.gov>
>> Argonne National Laboratory
>> 9700 South Cass Avenue
>> Argonne, Illinois  60439
>> (630) 252-5444
>>
> 
> 

-- 

  Douglas E. Engert  <DEEngert at anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444

From deengert at anl.gov  Wed Nov 12 03:55:38 2008
From: deengert at anl.gov (Douglas E. Engert)
Date: Tue, 11 Nov 2008 10:55:38 -0600
Subject: openssh on interix
In-Reply-To: <20081111122742.GG6478@calimero.vinschen.de>
References: <Pine.LNX.4.62.0811052313150.32748@vmdebian.local.koeppe-net.de>	<4918885D.30002@anl.gov>	<Pine.LNX.4.62.0811102229460.26949@vmdebian.local.koeppe-net.de>
	<20081111122742.GG6478@calimero.vinschen.de>
Message-ID: <4919B90A.5050705@anl.gov>



Corinna Vinschen wrote:
> On Nov 10 23:38, Martin Koeppe wrote:
>> On Mon, 10 Nov 2008, Douglas E. Engert wrote:
>>
>>> Martin Koeppe wrote:
>>>> Hi openssh developers,
>>>>

> This is all the same problem Cygwin's port to OpenSSH has.  However, on
> Interix/SUA the user can store the password in the registry using the
> `regpwd' tool.  I have no idea how the password is stored and how to
> access it from privileged Interix processes, though.  Isn't there some
> documentation?  Or is the password only accessible by daemons created by
> Microsoft's developers?  Maybe you should try asking this on the MS
> newsgroup dedicated to SUA:
> 
>   microsoft.public.servicesforunix.general

Keep in mind that there may not be any passwords to store. Only
delegated credentials when the user uses a smart card...

> 
> Corinna
> 

-- 

  Douglas E. Engert  <DEEngert at anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444

From peter at stuge.se  Wed Nov 12 04:15:43 2008
From: peter at stuge.se (Peter Stuge)
Date: Tue, 11 Nov 2008 18:15:43 +0100
Subject: Fwd: Permissions in chroot SFTP
In-Reply-To: <4a73f9240811110827o3151226ata7dbda9235b519f5@mail.gmail.com>
References: <4a73f9240811110327w582ec095y122b35ba3138763e@mail.gmail.com>
	<4a73f9240811110339t6269e975r7052dc0baee1b440@mail.gmail.com>
	<20081111154654.12617.qmail@stuge.se>
	<4a73f9240811110827o3151226ata7dbda9235b519f5@mail.gmail.com>
Message-ID: <20081111171543.10707.qmail@stuge.se>

Carlo Pradissitto wrote:
> Case 1
> [root at sftp-server home]# chown user.sftp user/
> [root at sftp-server home]# chmod 755 user/
> 
> carlo at Music:~$ sftp user at 213.217.147.123
> Connecting to 213.217.147.123...
> user at 213.217.147.123's password:
> Read from remote host 213.217.147.123: Connection reset by peer
> Couldn't read packet: Connection reset by peer
> 
> 
> Case 2
> [root at sftp-server home]# chown user.root user/
> 
> carlo at Music:~$ sftp user at 213.217.147.123
> Connecting to 213.217.147.123...
> user at 213.217.147.123's password:
> Read from remote host 213.217.147.123: Connection reset by peer
> Couldn't read packet: Connection reset by peer

Ok. I suggest running sshd -ddd on the server side to get clear
messages about which directories need which permissions.


//Peter

From carlopradissitto at gmail.com  Wed Nov 12 19:47:42 2008
From: carlopradissitto at gmail.com (Carlo Pradissitto)
Date: Wed, 12 Nov 2008 09:47:42 +0100
Subject: Fwd: Permissions in chroot SFTP
In-Reply-To: <20081111171543.10707.qmail@stuge.se>
References: <4a73f9240811110327w582ec095y122b35ba3138763e@mail.gmail.com>
	<4a73f9240811110339t6269e975r7052dc0baee1b440@mail.gmail.com>
	<20081111154654.12617.qmail@stuge.se>
	<4a73f9240811110827o3151226ata7dbda9235b519f5@mail.gmail.com>
	<20081111171543.10707.qmail@stuge.se>
Message-ID: <4a73f9240811120047jc6f5773xd82d3a6e0fb638c3@mail.gmail.com>

Do you read the answer? I don't...

[root at sftp-server ~]# chmod 770 /col-ftp/utenti/prch.ftp

carlo at Music:~$ sftp prch at 213.217.147.123
Connecting to 213.217.147.123...
prch at 213.217.147.123's password:
Read from remote host 213.217.147.123: Connection reset by peer
Couldn't read packet: Connection reset by peer


debug3: fd 5 is not O_NONBLOCK
debug1: Server will not fork when running in debugging mode.
debug3: send_rexec_state: entering fd = 8 config len 345
debug3: ssh_msg_send: type 0
debug3: send_rexec_state: done
debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 8
debug1: inetd sockets after dupping: 3, 3
Connection from 213.217.147.119 port 47264
debug1: Client protocol version 2.0; client software version
OpenSSH_4.3p2 Debian-8ubuntu1.5
debug1: match: OpenSSH_4.3p2 Debian-8ubuntu1.5 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
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
debug2: Network child is on pid 12665
debug3: preauth child monitor started
debug3: mm_request_receive entering
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-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,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: mm_request_receive_expect entering: type 1
debug3: mm_request_receive entering
debug3: monitor_read: checking request 0
debug3: mm_answer_moduli: got parameters: 1024 1024 8192
debug3: mm_request_send entering: type 1
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: 137/256
debug2: bits set: 501/1024
debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT
debug2: bits set: 525/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 0x1006f4f0(271)
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 prch service ssh-connection method none
debug1: attempt 0 failures 0
debug3: mm_getpwnamallow entering
debug3: mm_request_send entering: type 6
debug3: mm_getpwnamallow: waiting for MONITOR_ANS_PWNAM
debug3: mm_request_receive_expect entering: type 7
debug3: mm_request_receive entering
debug3: monitor_read: checking request 6
debug3: mm_answer_pwnamallow
debug3: Trying to reverse map address 213.217.147.119.
debug2: parse_server_config: config reprocess config len 345
debug3: checking match for 'Group sftp' user prch host 213.217.147.119
addr 213.217.147.119
debug1: user prch matched group list sftp at line 116
debug3: match found
debug3: reprocess config:117 setting ForceCommand internal-sftp
debug3: reprocess config:118 setting ChrootDirectory /col-ftp/utenti/%u.ftp
debug3: reprocess config:119 setting AllowTcpForwarding no
debug3: auth_shadow_acctexpired: today 14195 sp_expire -1 days left -14196
debug3: account expiration disabled
debug3: mm_answer_pwnamallow: sending MONITOR_ANS_PWNAM: 1
debug3: mm_request_send entering: type 7
debug2: monitor_read: 6 used once, disabling now
debug3: mm_request_receive entering
debug2: input_userauth_request: setting up authctxt for prch
debug3: mm_inform_authserv entering
debug3: mm_request_send entering: type 3
debug2: input_userauth_request: try method none
debug3: mm_auth_password entering
debug3: mm_request_send entering: type 10
debug3: mm_auth_password: waiting for MONITOR_ANS_AUTHPASSWORD
debug3: mm_request_receive_expect entering: type 11
debug3: mm_request_receive entering
debug3: monitor_read: checking request 3
debug3: mm_answer_authserv: service=ssh-connection, style=
debug2: monitor_read: 3 used once, disabling now
debug3: mm_request_receive entering
debug3: monitor_read: checking request 10
debug3: mm_answer_authpassword: sending result 0
debug3: mm_request_send entering: type 11
Failed none for prch from 213.217.147.119 port 47264 ssh2
debug3: mm_request_receive entering
debug3: mm_auth_password: user not authenticated
debug1: userauth-request for user prch 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=prch devs=
debug1: kbdint_alloc: devices ''
debug2: auth2_challenge_start: devices
debug1: userauth-request for user prch service ssh-connection method password
debug1: attempt 2 failures 1
debug2: input_userauth_request: try method password
debug3: mm_auth_password entering
debug3: mm_request_send entering: type 10
debug3: mm_auth_password: waiting for MONITOR_ANS_AUTHPASSWORD
debug3: mm_request_receive_expect entering: type 11
debug3: mm_request_receive entering
debug3: monitor_read: checking request 10
debug3: auth_shadow_pwexpired: today 14195 sp_lstchg 14193 sp_max 99999
debug3: mm_answer_authpassword: sending result 1
debug3: mm_request_send entering: type 11
Accepted password for prch from 213.217.147.119 port 47264 ssh2
debug1: monitor_child_preauth: prch 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_auth_password: user authenticated
debug3: mm_send_keystate: Sending new keys: 0x1006f8c0 0x1006f7f8
debug3: mm_newkeys_to_blob: converting 0x1006f8c0
debug3: mm_newkeys_to_blob: converting 0x1006f7f8
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: 0x100769b0(118)
debug2: mac_setup: found hmac-md5
debug3: mm_get_keystate: Waiting for second key
debug3: mm_newkeys_from_blob: 0x100769b0(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
User child is on pid 12666
debug3: mm_request_receive entering
debug3: safely_chroot: checking '/'
debug3: safely_chroot: checking '/col-ftp/'
debug3: safely_chroot: checking '/col-ftp/utenti/'
debug3: safely_chroot: checking '/col-ftp/utenti/prch.ftp'
bad ownership or modes for chroot directory "/col-ftp/utenti/prch.ftp"
debug1: do_cleanup
debug1: do_cleanup

2008/11/11 Peter Stuge <peter at stuge.se>:
> Carlo Pradissitto wrote:
>> Case 1
>> [root at sftp-server home]# chown user.sftp user/
>> [root at sftp-server home]# chmod 755 user/
>>
>> carlo at Music:~$ sftp user at 213.217.147.123
>> Connecting to 213.217.147.123...
>> user at 213.217.147.123's password:
>> Read from remote host 213.217.147.123: Connection reset by peer
>> Couldn't read packet: Connection reset by peer
>>
>>
>> Case 2
>> [root at sftp-server home]# chown user.root user/
>>
>> carlo at Music:~$ sftp user at 213.217.147.123
>> Connecting to 213.217.147.123...
>> user at 213.217.147.123's password:
>> Read from remote host 213.217.147.123: Connection reset by peer
>> Couldn't read packet: Connection reset by peer
>
> Ok. I suggest running sshd -ddd on the server side to get clear
> messages about which directories need which permissions.
>
>
> //Peter
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>



-- 
Carlo Pradissitto

Servizi e Supporto IT

I-WAY S.r.l.
Piazza Caduti di via Fani, 2
03100 Frosinone

Mobile: +393939318571

Tel/Fax: 07751880765

E-mail: c.pradissitto at i-way.it

From djm at mindrot.org  Thu Nov 13 00:01:27 2008
From: djm at mindrot.org (Damien Miller)
Date: Thu, 13 Nov 2008 00:01:27 +1100 (EST)
Subject: 1 command ssh session
In-Reply-To: <E31DA5A6596D8108A68E4DBE@ZOP-MACTEL.local>
References: <7227c6c70811101034x6d4b7d4al164ac8043754e1b8@mail.gmail.com>
	<E31DA5A6596D8108A68E4DBE@ZOP-MACTEL.local>
Message-ID: <alpine.BSO.1.10.0811122352350.28508@fuyu.mindrot.org>

On Mon, 10 Nov 2008, Michael Loftis wrote:

> No, it simply exec's it from the PATH/env given to the SSHD.  There's an 
> option to force it to init a shell or something like that if you want (or 
> for some reason need) the overhead.  I forget what it is but I'm sure 
> someone here can enlighten.

This is quite incorrect. The code that starts the session looks like
this (from session.c):

 1311|  /*
 1312|   * Get the shell from the password data.  An empty shell field is
 1313|   * legal, and means /bin/sh.
 1314|   */
 1315|  shell = (pw->pw_shell[0] == '\0') ? _PATH_BSHELL : pw->pw_shell;
...
 1411|  /* Get the last component of the shell name. */
 1412|  if ((shell0 = strrchr(shell, '/')) != NULL)
 1413|          shell0++;
 1414|  else
 1415|          shell0 = shell;
...
 1444|  /*
 1445|   * Execute the command using the user's shell.  This uses the -c
 1446|   * option to execute the command.
 1447|   */
 1448|  argv[0] = (char *) shell0;
 1449|  argv[1] = "-c";
 1450|  argv[2] = (char *) command;
 1451|  argv[3] = NULL;
 1452|  execve(shell, argv, env);
 1453|  perror(shell);
 1454|  exit(1);

I.e. it will use the user's shell from /etc/passwd or /bin/sh if none is
specified.

-d

From djm at mindrot.org  Thu Nov 13 00:17:33 2008
From: djm at mindrot.org (Damien Miller)
Date: Thu, 13 Nov 2008 00:17:33 +1100 (EST)
Subject: Directory permissions in chroot SFTP
In-Reply-To: <4a73f9240811110345h29e0c822i6e5922affb153185@mail.gmail.com>
References: <4a73f9240811110345h29e0c822i6e5922affb153185@mail.gmail.com>
Message-ID: <alpine.BSO.1.10.0811130008360.28508@fuyu.mindrot.org>



On Tue, 11 Nov 2008, Carlo Pradissitto wrote:

> Hi,
> I configured openssh 5.1p1 for sftp server.
> 
> Here the specifications in sshd_config file:
> 
> Subsystem     sftp   internal-sftp
> Match Group sftp
>     ForceCommand internal-sftp
>     ChrootDirectory /home/%u
>     AllowTcpForwarding no
> 
> When a user is logged in, he can't upload his document and he receives
> this message:
> 
> carlo at Music:~$ sftp user at 213.217.147.123
> Connecting to 213.217.147.123...
> user at 213.217.147.123's password:
> sftp> put prova
> Uploading prova to /prova
> Couldn't get handle: Permission denied
> sftp>

>From the sshd_config manual page:

> ChrootDirectory
>     Specifies a path to chroot(2) to after authentication. This path,
>     and all its components, must be root-owned directories that are
>     not writable by any other user or group.


> Here the directory permissions:
> 
> [root at sftp-server ~]# ls -la /home/user/
> total 24
> drwxr-xr-x   6 root sftp 4096 Nov 10 18:05 .
> drwxr-xr-x  54 root root 4096 Nov 10 16:48 ..
> 
> OK, my user is a sftp group member, and the sftp group hasn't
> sufficient permissions to write in user's home directory.

Your permissions are correct.

> I add the write permission for the sftp group:
> 
> [root at sftp-server ~]# chmod 770 /home/user/
> [root at sftp-server ~]# ls -la /home/user/
> total 24
> drwxrwx---   6 root sftp 4096 Nov 10 18:05 .
> drwxr-xr-x  54 root root 4096 Nov 10 16:48 ..
> 
> 
> But now the user can't access:
> 
> carlo at Music:~$ sftp user at 213.217.145.321
> Connecting to 213.217.147.123...
> user at 213.217.145.321's password:
> Read from remote host 213.217.145.321: Connection reset by peer
> Couldn't read packet: Connection reset by peer
> 
> Here the error message in /var/log/messages of sftp-server:
> 
> Nov 11 11:33:02 sftp-server sshd[10254]: Accepted password for user
> from 213.217.145.329 port 38685 ssh2
> Nov 11 11:33:02 sftp-server sshd[10256]: fatal: bad ownership or modes
> for chroot directory "/home/user"

Right, this is on purpose. We ban this because allowing a user write
access to a chroot target is dangerously similar to equivalence with
allowing write access to the root of a filesystem.

If you want the default directory that users start in to be writable
then you must create their home directory under the chroot. After
sshd(8) has chrooted to the ChrootDirectory, it will chdir to the
home directory as normal. So, for a passwd line like:

djm:*:1000:1000:Damien Miller:/home/djm:/bin/ksh

Create a home directory "/chroot/djm/home/djm". Make the terminal "djm"
directory user-owned and writable (everything else must be root-owned).
Set "ChrootDirectory /chroot" in /etc/config.

A variant of this that yields less deep directory trees would be to set
the passwd file up as:

djm:*:1000:1000:Damien Miller:/upload:/bin/ksh

Create "/chroot/djm/upload", with "upload" the only user-owned and writable
component. 

-d

From carlopradissitto at gmail.com  Thu Nov 13 00:34:00 2008
From: carlopradissitto at gmail.com (Carlo Pradissitto)
Date: Wed, 12 Nov 2008 14:34:00 +0100
Subject: Directory permissions in chroot SFTP
In-Reply-To: <alpine.BSO.1.10.0811130008360.28508@fuyu.mindrot.org>
References: <4a73f9240811110345h29e0c822i6e5922affb153185@mail.gmail.com>
	<alpine.BSO.1.10.0811130008360.28508@fuyu.mindrot.org>
Message-ID: <4a73f9240811120534o542c6bf4h196b08e3aa544dea@mail.gmail.com>

Hi Damien,
Thanks a lot!

Carlo

2008/11/12 Damien Miller <djm at mindrot.org>

>
>
> On Tue, 11 Nov 2008, Carlo Pradissitto wrote:
>
> > Hi,
> > I configured openssh 5.1p1 for sftp server.
> >
> > Here the specifications in sshd_config file:
> >
> > Subsystem     sftp   internal-sftp
> > Match Group sftp
> >     ForceCommand internal-sftp
> >     ChrootDirectory /home/%u
> >     AllowTcpForwarding no
> >
> > When a user is logged in, he can't upload his document and he receives
> > this message:
> >
> > carlo at Music:~$ sftp user at 213.217.147.123
> > Connecting to 213.217.147.123...
> > user at 213.217.147.123's password:
> > sftp> put prova
> > Uploading prova to /prova
> > Couldn't get handle: Permission denied
> > sftp>
>
> From the sshd_config manual page:
>
> > ChrootDirectory
> >     Specifies a path to chroot(2) to after authentication. This path,
> >     and all its components, must be root-owned directories that are
> >     not writable by any other user or group.
>
>
> > Here the directory permissions:
> >
> > [root at sftp-server ~]# ls -la /home/user/
> > total 24
> > drwxr-xr-x   6 root sftp 4096 Nov 10 18:05 .
> > drwxr-xr-x  54 root root 4096 Nov 10 16:48 ..
> >
> > OK, my user is a sftp group member, and the sftp group hasn't
> > sufficient permissions to write in user's home directory.
>
> Your permissions are correct.
>
> > I add the write permission for the sftp group:
> >
> > [root at sftp-server ~]# chmod 770 /home/user/
> > [root at sftp-server ~]# ls -la /home/user/
> > total 24
> > drwxrwx---   6 root sftp 4096 Nov 10 18:05 .
> > drwxr-xr-x  54 root root 4096 Nov 10 16:48 ..
> >
> >
> > But now the user can't access:
> >
> > carlo at Music:~$ sftp user at 213.217.145.321
> > Connecting to 213.217.147.123...
> > user at 213.217.145.321's password:
> > Read from remote host 213.217.145.321: Connection reset by peer
> > Couldn't read packet: Connection reset by peer
> >
> > Here the error message in /var/log/messages of sftp-server:
> >
> > Nov 11 11:33:02 sftp-server sshd[10254]: Accepted password for user
> > from 213.217.145.329 port 38685 ssh2
> > Nov 11 11:33:02 sftp-server sshd[10256]: fatal: bad ownership or modes
> > for chroot directory "/home/user"
>
> Right, this is on purpose. We ban this because allowing a user write
> access to a chroot target is dangerously similar to equivalence with
> allowing write access to the root of a filesystem.
>
> If you want the default directory that users start in to be writable
> then you must create their home directory under the chroot. After
> sshd(8) has chrooted to the ChrootDirectory, it will chdir to the
> home directory as normal. So, for a passwd line like:
>
> djm:*:1000:1000:Damien Miller:/home/djm:/bin/ksh
>
> Create a home directory "/chroot/djm/home/djm". Make the terminal "djm"
> directory user-owned and writable (everything else must be root-owned).
> Set "ChrootDirectory /chroot" in /etc/config.
>
> A variant of this that yields less deep directory trees would be to set
> the passwd file up as:
>
> djm:*:1000:1000:Damien Miller:/upload:/bin/ksh
>
> Create "/chroot/djm/upload", with "upload" the only user-owned and writable
> component.
>
> -d
>



-- 
Carlo Pradissitto

Servizi e Supporto IT

I-WAY S.r.l.
Piazza Caduti di via Fani, 2
03100 Frosinone

Mobile: +393939318571

Tel/Fax: 07751880765

E-mail: c.pradissitto at i-way.it

From mkoeppe at gmx.de  Wed Nov 12 21:42:31 2008
From: mkoeppe at gmx.de (Martin Koeppe)
Date: Wed, 12 Nov 2008 11:42:31 +0100 (CET)
Subject: openssh on interix
In-Reply-To: <4919B821.6020301@anl.gov>
References: <Pine.LNX.4.62.0811052313150.32748@vmdebian.local.koeppe-net.de>
	<4918885D.30002@anl.gov>
	<Pine.LNX.4.62.0811102229460.26949@vmdebian.local.koeppe-net.de>
	<4919B821.6020301@anl.gov>
Message-ID: <Pine.LNX.4.62.0811121112210.2745@vmdebian.local.koeppe-net.de>


On Tue, 11 Nov 2008, Douglas E. Engert wrote:

>>> If the sshd could use the GSSAPI and delegated credentials, it might
>>> be possible to pass the Kerberos ticket into the LSA.  This could give
>>> you single sign on.
>>> I believe with a registry setting, the Kerberos for Windows can do
>>> something like this. You might want to ask on the kerberos at mit.edu list
>> 
>>> From within the interix environment the only way to contact the LSA is 
>> over the built-in interix kerrnel functions like setuser(). Interix 
>> programs don't have access to the Win32 API.
>
> But you did say that you wanted "newtwork access rights. i.e. no access
> to a network home dir". I took that to imply that the Intrex is using the
> underlying Windows file systems and that it uses the username and password
> via the setuser() to get Widows credentials. The other way to get credentials
> is to to pass in a Kerberos TGT, and I think Vista can allow this and KfW
> can use it. So Intrix should be able to do this too.

This would be a really good solution, but interix doesn't have any 
alternative for setuser(). So Kerberos can't be used.
See here for more details:
http://www.suacommunity.com/forum/tm.aspx?high=&m=5046&mpage=1#15834
The poster Rodney is not an MS guy, but he wrote several core parts of 
interix before MS bought it.


Corinna Vinschen wrote:

> This is all the same problem Cygwin's port to OpenSSH has. 
> However, on Interix/SUA the user can store the password in the 
> registry using the `regpwd' tool.  I have no idea how the password 
> is stored and how to access it from privileged Interix processes, 
> though.  Isn't there some documentation?  Or is the password only 
> accessible by daemons created by Microsoft's developers?  Maybe you 
> should try asking this on the MS newsgroup dedicated to SUA:
>
>   microsoft.public.servicesforunix.general

The password is accessible from non-MS tools, too. Rodney has build an 
(closed source) openssh which uses private keys and finally the regpwd 
stored passwords.

But: I currently don't need fully passwordless logins. I would be 
happy to login with password and automatically get network share 
access, similar to when logging in to a windows box locally on the 
glass. The only thing to be done for that is transferring the password 
to permanently_set_uid() within sshd. (I tested this successfully with 
a fixed password compiled into permanently_set_uid().) I think it 
would be overkill to call regpwd in auth_passwd() and then retrieve 
the password in permanently_set_uid() again. I would write a patch for 
openssh for official inclusion, but I'm not familiar with the overall 
design of openssh to know how to do it correctly. So any help there 
would be appreciated.

Martin

From jmknoble at pobox.com  Thu Nov 13 09:41:37 2008
From: jmknoble at pobox.com (Jim Knoble)
Date: Wed, 12 Nov 2008 17:41:37 -0500
Subject: Fwd: Permissions in chroot SFTP
In-Reply-To: <4a73f9240811110339t6269e975r7052dc0baee1b440@mail.gmail.com>
References: <4a73f9240811110327w582ec095y122b35ba3138763e@mail.gmail.com>
	<4a73f9240811110339t6269e975r7052dc0baee1b440@mail.gmail.com>
Message-ID: <20081112224137.GO14307@crawfish.ais.com>

Circa 2008-11-11 06:39 dixit Carlo Pradissitto:

: I configured openssh 5.1p1 for sftp server.
: 
: Here the specifications in sshd_config file:
: 
: Subsystem     sftp   internal-sftp
: Match Group sftp
:     ForceCommand internal-sftp
:     ChrootDirectory /home/%u
:     AllowTcpForwarding no
: 
: When a user is logged in, he can't upload his document and he receives
: this message:
: 
: carlo at Music:~$ sftp user at 213.217.147.123
: Connecting to 213.217.147.123...
: user at 213.217.147.123's password:
: sftp> put prova
: Uploading prova to /prova
: Couldn't get handle: Permission denied
: sftp>

  [...]

You don't want the user to have write permissions to the chroot
directory.  If you do, the user has the potential to gain root
privileges inside the chroot.

Best is to make the chroot directory owned by root, as sshd is trying to
tell you.  Create a user-writable directory under the chroot directory
instead.

-- 
jim knoble  |  jmknoble at pobox.com  |  http://www.pobox.com/~jmknoble/
(GnuPG key ID: C6F31FFA  >>>>>>  http://www.pobox.com/~jmknoble/keys/ )
(GnuPG fingerprint: 99D8:1D89:8C66:08B5:5C34::5527:A543:8C33:C6F3:1FFA)
+----------------------------------------------------------------------+
|[L]iberty, as we all know, cannot flourish in a country that is perma-|
| nently on a war footing, or even a near-war footing.  --Aldous Huxley|
+----------------------------------------------------------------------+

From tpikonen at gmail.com  Fri Nov 14 06:47:10 2008
From: tpikonen at gmail.com (Teemu Ikonen)
Date: Thu, 13 Nov 2008 20:47:10 +0100
Subject: ChrootDirectory on a per key basis
In-Reply-To: <49049595.9060404@gmail.com>
References: <49049595.9060404@gmail.com>
Message-ID: <97fdf2d70811131147j78b7ebf8kfe5d8e9118e82baa@mail.gmail.com>

On Sun, Oct 26, 2008 at 5:06 PM, Teemu Ikonen <tpikonen at gmail.com> wrote:
> Damien Miller wrote:
>> No, letting users chroot to arbitrary directories introduces
>> serious security problems. Think about hard-linking /bin/su into
>> a chroot on the same filesystem where an attacker has filled in
>> a friendly /etc/passwd.
>
> OK, so adding chrootdir option to authorized keys is a bad idea.
>
> Another way to achieve my objective, which is additional sftp file access
> restrictions to connections authorized with certain keys, would be to modify
> sftp-server to accept a directory parameter. The authorized_keys could then
> have 'command="sftp-server -d /home/user/stuff"' option to restrict access
> to /home/user/stuff.

Hi again,

I implemented this in sftp-server.c, see the attached patch. The
access restriction is made by checking every received file argument
with a modified version of realpath() (named fakepath), which resolves
the given file name to a real path and fails if this path leads
outside of the directory given in the command line argument.

Comments on the patch (security and otherwise) would be very much welcome.

Teemu
-------------- next part --------------
A non-text attachment was scrubbed...
Name: restricted-sftp.diff
Type: text/x-patch
Size: 11380 bytes
Desc: not available
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20081113/d564f1b7/attachment-0001.bin 

From peter at stuge.se  Fri Nov 14 07:47:45 2008
From: peter at stuge.se (Peter Stuge)
Date: Thu, 13 Nov 2008 21:47:45 +0100
Subject: ChrootDirectory on a per key basis
In-Reply-To: <49049595.9060404@gmail.com>
References: <49049595.9060404@gmail.com>
Message-ID: <20081113204745.8539.qmail@stuge.se>

Teemu Ikonen wrote:
>  > No, letting users chroot to arbitrary directories introduces
>  > serious security problems.
> 
> OK, so adding chrootdir option to authorized keys is a bad idea.

I think it could be made ok. Non-root filesystem, maybe even mounted
noexec, not letting the user change authorized_keys.


//Peter

From paul4352 at yahoo.co.uk  Sat Nov 15 03:45:44 2008
From: paul4352 at yahoo.co.uk (Paul)
Date: Fri, 14 Nov 2008 16:45:44 +0000
Subject: Max-Session lifetime?
Message-ID: <491DAB38.6010901@yahoo.co.uk>

Hello,

A quick question. Is there any way to implement a Max-Session lifetime 
in SSH?

I know there is an idle timeout available, but I am really looking for 
some mechanism to force a reauthentication and stop people holding onto 
login sessions for weeks at a time.

thanks

Paul




From janklodvan at gmail.com  Wed Nov 19 02:28:11 2008
From: janklodvan at gmail.com (Jan Klod)
Date: Tue, 18 Nov 2008 17:28:11 +0200
Subject: OpenSSH performance with VIA padlock
Message-ID: <200811181728.11855.janklodvan@gmail.com>

Hello list,
please spend a minute considering these facts and maybe there is something to 
improve:

1) VIA Eden based board can write AES256 encrypted information on HDD at > 
60MB/s
2) iperf shows NIC speed 69MB/s
3) openssl tests have even better results
4) openssh can transfer AES256 encrypted information at < 27MB/s (and worse 
with HDD encryption)

It is better with openssh 5.x, than 4.6, but still I see no reason why results 
are so bad... Please, could someone explain? I don't believe, padlock is used 
properly...

Jan

From roger_no_spam at hotmail.com  Wed Nov 19 02:22:04 2008
From: roger_no_spam at hotmail.com (Roger No-Spam)
Date: Tue, 18 Nov 2008 16:22:04 +0100
Subject: Alleged OpenSSH vulnerability
Message-ID: <BLU149-W6582142E10AFE6091B1CF8AC120@phx.gbl>


Hi,There is an alleged OpenSSH vulnerability, see http://www.cpni.gov.uk/Products/alerts/3718.aspx.According to this vulnerability an attacker can potentially recover 32 bits of plaintext from an arbitrary block of ciphertext.
After having read the vulnerability note in more detail, my understanding is that the 32 bits of plaintext do not come from the exchange between the client and server of the attacked connection, but comes from random data inserted into the connection by the attacker. This means that no cleartext data is revealed from the connection. The only 'vulnerability' that I can see in this scenario is that the attacker would get 4 bytes of known cipher and cleartext that in turn could be used to facilitate crypto analysis (i.e. breaking the key of the 'real' connection). Does anyone know how much help 4 bytes would give in the crypto analysis?I'm a bit surprised that I cannot find any severity info for this vulnerability. To me, this vulnerability appears a bit theoretical and academic and should not pose any real threat to most users./RogerPS. Not sure if this is the appropriate forum. If questions like should be sent somewhere else, please let me know.
_________________________________________________________________
H?stst?da med nya dammsugarp?sar.
http://www.inkclub.com/msn9

From imorgan at nas.nasa.gov  Wed Nov 19 03:47:58 2008
From: imorgan at nas.nasa.gov (Iain Morgan)
Date: Tue, 18 Nov 2008 08:47:58 -0800
Subject: OpenSSH performance with VIA padlock
In-Reply-To: <200811181728.11855.janklodvan@gmail.com>
References: <200811181728.11855.janklodvan@gmail.com>
Message-ID: <20081118164758.GA5824@linux55.nas.nasa.gov>

On Tue, Nov 18, 2008 at 17:28:11 +0200, Jan Klod wrote:
> Hello list,
> please spend a minute considering these facts and maybe there is something to 
> improve:
> 
> 1) VIA Eden based board can write AES256 encrypted information on HDD at > 
> 60MB/s
> 2) iperf shows NIC speed 69MB/s
> 3) openssl tests have even better results
> 4) openssh can transfer AES256 encrypted information at < 27MB/s (and worse 
> with HDD encryption)
> 
> It is better with openssh 5.x, than 4.6, but still I see no reason why results 
> are so bad... Please, could someone explain? I don't believe, padlock is used 
> properly...
> 
> Jan

Remember, cycles are also taken up by the message digest. You don't
mention which MAC you are using nor do you give any of the OpenSSL speed
numbers for AES or any of the digests.

Also, what performance do you get for a memory-to-memory transfer over
the loopback?

-- 
Iain Morgan

From Jan.Pechanec at Sun.COM  Wed Nov 19 03:51:30 2008
From: Jan.Pechanec at Sun.COM (Jan Pechanec)
Date: Tue, 18 Nov 2008 17:51:30 +0100 (CET)
Subject: OpenSSH performance with VIA padlock
In-Reply-To: <200811181728.11855.janklodvan@gmail.com>
References: <200811181728.11855.janklodvan@gmail.com>
Message-ID: <Pine.GSO.4.64.0811181740050.23084@fossa.czech.sun.com>

On Tue, 18 Nov 2008, Jan Klod wrote:

>Hello list,
>please spend a minute considering these facts and maybe there is something to 
>improve:
>
>1) VIA Eden based board can write AES256 encrypted information on HDD at > 
>60MB/s
>2) iperf shows NIC speed 69MB/s
>3) openssl tests have even better results
>4) openssh can transfer AES256 encrypted information at < 27MB/s (and worse 
>with HDD encryption)
>
>It is better with openssh 5.x, than 4.6, but still I see no reason why results 
>are so bad... Please, could someone explain? I don't believe, padlock is used 
>properly...
	
	after the initial key exchange, the processing of SSH packets is not 
about encryption/decryption only but also about HMAC. MD5/SHA-* are much 
faster in software than AES but if AES goes to HW and HMAC stays in SW it 
can make a significant impact on the overall numbers when compared to 
OpenSSL speed, for example.

	also, the packet (1 cipher block) length is decrypted independently 
from the rest of the packet in OpenSSH. Usually, working with small blocks 
is much slower in HW than in SW due to inherent overhead of offloading 
anything to HW. In general, the size of blocks offloaded is very important - 
your benchmark numbers might be affected by different block sizes used.

	those 2 things mentioned above might be the reason why you see 1/2 
of what you have expected.

	J.

-- 
Jan Pechanec

From janklodvan at gmail.com  Wed Nov 19 06:21:28 2008
From: janklodvan at gmail.com (Jan Klod)
Date: Tue, 18 Nov 2008 21:21:28 +0200
Subject: OpenSSH performance with VIA padlock
In-Reply-To: <20081118164758.GA5824@linux55.nas.nasa.gov>
References: <200811181728.11855.janklodvan@gmail.com>
	<20081118164758.GA5824@linux55.nas.nasa.gov>
Message-ID: <200811182121.28878.janklodvan@gmail.com>

On Tuesday 18 November 2008 18:47:58 you wrote:
> On Tue, Nov 18, 2008 at 17:28:11 +0200, Jan Klod wrote:
> > Hello list,
> > please spend a minute considering these facts and maybe there is
> > something to improve:
> >
> > 1) VIA Eden based board can write AES256 encrypted information on HDD at
> > > 60MB/s
Yes, this one I am very sure about. Padlock was used in that case!

> > 2) iperf shows NIC speed 69MB/s
> > 3) openssl tests have even better results
> > 4) openssh can transfer AES256 encrypted information at < 27MB/s (and
> > worse with HDD encryption)
> >
> > It is better with openssh 5.x, than 4.6, but still I see no reason why
> > results are so bad... Please, could someone explain? I don't believe,
> > padlock is used properly...
> >
> > Jan
>
> Remember, cycles are also taken up by the message digest. You don't
> mention which MAC you are using nor do you give any of the OpenSSL speed
> numbers for AES or any of the digests.
>
> Also, what performance do you get for a memory-to-memory transfer over
> the loopback?

mount -t ramfs ramfs /mnt/ram0
mount -t ramfs ramfs /mnt/ram1
dd if=/dev/sda of=/mnt/ram0/1 bs=512K count=400
400+0 records in
400+0 records out
209715200 bytes (210 MB) copied, 3.37567 s, 62.1 MB/s

dd if=/mnt/ram0/1 of=/mnt/ram1/1 bs=512K count=400
400+0 records in
400+0 records out
209715200 bytes (210 MB) copied, 1.31667 s, 159 MB/s

scp -c aes256-cbc -o MACs=hmac-md5 /mnt/del VIA:/mnt
100% ?200MB ?22.2MB/s

scp -c aes256-cbc -o MACs=hmac-sha1 /mnt/del VIA:/mnt
100% ?200MB ?18.2MB/s

scp -c aes256-cbc -o MACs=hmac-sha1-96 /mnt/del VIA:/mnt
100% ?200MB ?18.2MB/s

Those scp speeds are becoming slower as transfers are lasting longer, though. 
That is a final value. Since md5, which is not supported by VIA padlock is 
faster than sha1 (which is said to be supported), it is more than suspicios, 
that hardware accelerator is not used...

zcat /proc/config.gz | grep PADLOCK
CONFIG_CRYPTO_DEV_PADLOCK=y
CONFIG_CRYPTO_DEV_PADLOCK_AES=y
CONFIG_CRYPTO_DEV_PADLOCK_SHA=y

openssl speed:
The 'numbers' are in 1000s of bytes per second processed.
type ? ? ? ? ? ? 16 bytes ? ? 64 bytes ? ?256 bytes ? 1024 bytes ? 8192 bytes
md5 ? ? ? ? ? ? ? 4335.51k ? ?15169.19k ? ?43828.91k ? ?82976.77k ? 112391.51k
hmac(md5) ? ? ? ? 5269.63k ? ?17989.14k ? ?49426.43k ? ?87639.72k ? 113415.51k
sha1 ? ? ? ? ? ? ?3996.45k ? ?12144.02k ? ?28099.67k ? ?41740.97k ? ?48594.07k
sha256 ? ? ? ? ? ?2486.99k ? ? 5744.75k ? ?10174.81k ? ?12615.68k ? ?13537.21k
sha512 ? ? ? ? ? ?1755.15k ? ? 7005.40k ? ?12058.54k ? ?18123.09k ? ?21217.55k
aes-128 cbc ? ? ?12835.45k ? ?16641.41k ? ?18044.67k ? ?18433.37k ? ?18512.29k
aes-192 cbc ? ? ?11315.21k ? ?14180.52k ? ?15334.57k ? ?15637.16k ? ?15742.29k
aes-256 cbc ? ? ?10224.77k ? ?12465.86k ? ?13237.33k ? ?13445.46k ? ?13480.06k

Well... I was wrong saying, that I have openssl aes HW accel. working. 

I am using 2.6.25 kernel with PaX, no other patches. Please, do you have any 
idea at this point, why padlock is not used? What should I try?

From imorgan at nas.nasa.gov  Wed Nov 19 07:33:19 2008
From: imorgan at nas.nasa.gov (Iain Morgan)
Date: Tue, 18 Nov 2008 12:33:19 -0800
Subject: OpenSSH performance with VIA padlock
In-Reply-To: <200811182121.28878.janklodvan@gmail.com>
References: <200811181728.11855.janklodvan@gmail.com>
	<20081118164758.GA5824@linux55.nas.nasa.gov>
	<200811182121.28878.janklodvan@gmail.com>
Message-ID: <20081118203319.GL20880@linux55.nas.nasa.gov>

On Tue, Nov 18, 2008 at 21:21:28 +0200, Jan Klod wrote:
> On Tuesday 18 November 2008 18:47:58 you wrote:
> > On Tue, Nov 18, 2008 at 17:28:11 +0200, Jan Klod wrote:
> > > Hello list,
> > > please spend a minute considering these facts and maybe there is
> > > something to improve:
> > >
> > > 1) VIA Eden based board can write AES256 encrypted information on HDD at
> > > > 60MB/s
> Yes, this one I am very sure about. Padlock was used in that case!
> 
> > > 2) iperf shows NIC speed 69MB/s
> > > 3) openssl tests have even better results
> > > 4) openssh can transfer AES256 encrypted information at < 27MB/s (and
> > > worse with HDD encryption)
> > >
> > > It is better with openssh 5.x, than 4.6, but still I see no reason why
> > > results are so bad... Please, could someone explain? I don't believe,
> > > padlock is used properly...
> > >
> > > Jan
> >
> > Remember, cycles are also taken up by the message digest. You don't
> > mention which MAC you are using nor do you give any of the OpenSSL speed
> > numbers for AES or any of the digests.
> >
> > Also, what performance do you get for a memory-to-memory transfer over
> > the loopback?
> 
> mount -t ramfs ramfs /mnt/ram0
> mount -t ramfs ramfs /mnt/ram1
> dd if=/dev/sda of=/mnt/ram0/1 bs=512K count=400
> 400+0 records in
> 400+0 records out
> 209715200 bytes (210 MB) copied, 3.37567 s, 62.1 MB/s
> 
> dd if=/mnt/ram0/1 of=/mnt/ram1/1 bs=512K count=400
> 400+0 records in
> 400+0 records out
> 209715200 bytes (210 MB) copied, 1.31667 s, 159 MB/s
> 
> scp -c aes256-cbc -o MACs=hmac-md5 /mnt/del VIA:/mnt
> 100% ?200MB ?22.2MB/s
> 
> scp -c aes256-cbc -o MACs=hmac-sha1 /mnt/del VIA:/mnt
> 100% ?200MB ?18.2MB/s
> 
> scp -c aes256-cbc -o MACs=hmac-sha1-96 /mnt/del VIA:/mnt
> 100% ?200MB ?18.2MB/s
> 
> Those scp speeds are becoming slower as transfers are lasting longer, though. 
> That is a final value. Since md5, which is not supported by VIA padlock is 
> faster than sha1 (which is said to be supported), it is more than suspicios, 
> that hardware accelerator is not used...
> 
> zcat /proc/config.gz | grep PADLOCK
> CONFIG_CRYPTO_DEV_PADLOCK=y
> CONFIG_CRYPTO_DEV_PADLOCK_AES=y
> CONFIG_CRYPTO_DEV_PADLOCK_SHA=y
> 
> openssl speed:
> The 'numbers' are in 1000s of bytes per second processed.
> type ? ? ? ? ? ? 16 bytes ? ? 64 bytes ? ?256 bytes ? 1024 bytes ? 8192 bytes
> md5 ? ? ? ? ? ? ? 4335.51k ? ?15169.19k ? ?43828.91k ? ?82976.77k ? 112391.51k
> hmac(md5) ? ? ? ? 5269.63k ? ?17989.14k ? ?49426.43k ? ?87639.72k ? 113415.51k
> sha1 ? ? ? ? ? ? ?3996.45k ? ?12144.02k ? ?28099.67k ? ?41740.97k ? ?48594.07k
> sha256 ? ? ? ? ? ?2486.99k ? ? 5744.75k ? ?10174.81k ? ?12615.68k ? ?13537.21k
> sha512 ? ? ? ? ? ?1755.15k ? ? 7005.40k ? ?12058.54k ? ?18123.09k ? ?21217.55k
> aes-128 cbc ? ? ?12835.45k ? ?16641.41k ? ?18044.67k ? ?18433.37k ? ?18512.29k
> aes-192 cbc ? ? ?11315.21k ? ?14180.52k ? ?15334.57k ? ?15637.16k ? ?15742.29k
> aes-256 cbc ? ? ?10224.77k ? ?12465.86k ? ?13237.33k ? ?13445.46k ? ?13480.06k
> 
> Well... I was wrong saying, that I have openssl aes HW accel. working. 
> 
> I am using 2.6.25 kernel with PaX, no other patches. Please, do you have any 
> idea at this point, why padlock is not used? What should I try?

By a 'memory-to-memory' transfer, I was meaning something like:

$ dd if=/dev/zero bs=1024 count=102400 | ssh localhost 'cat > /dev/null'

Note also that your openssl speed output indicates about 13MB/s for
AES-128 which is _slower_ than what you have reported for your scp's.
(You may need to use the -engine with openssl.)

You might want to also try umac-64 at openssh.com for your MAC.

-- 
Iain Morgan

From ihabaf at gmail.com  Tue Nov 18 19:16:36 2008
From: ihabaf at gmail.com (Ehab ahmed)
Date: Tue, 18 Nov 2008 11:16:36 +0300
Subject: problem logging to AIX server
Message-ID: <dfce9d560811180016s2a7fe67fo41906bac25692fb1@mail.gmail.com>

Hello,
we have the following problem when trying to ssh to our AIX server (it
happens some times)
**
*sshd[507944]: mkstemp(): Do not specify an existing file.*
**
this is the version of ssh we have

openssh.base.server     4.3.0.5301  COMMITTED  Open Secure Shell Server

the AIX  version is 5.3 TL6 SP5

any ideas about the source of this problem

From peter at stuge.se  Wed Nov 19 18:17:26 2008
From: peter at stuge.se (Peter Stuge)
Date: Wed, 19 Nov 2008 08:17:26 +0100
Subject: problem logging to AIX server
In-Reply-To: <dfce9d560811180016s2a7fe67fo41906bac25692fb1@mail.gmail.com>
References: <dfce9d560811180016s2a7fe67fo41906bac25692fb1@mail.gmail.com>
Message-ID: <20081119071726.8238.qmail@stuge.se>

Hello,

Ehab ahmed wrote:
> Hello,
> we have the following problem when trying to ssh to our AIX server (it
> happens some times)
> **
> *sshd[507944]: mkstemp(): Do not specify an existing file.*
> **
> this is the version of ssh we have
> 
> openssh.base.server     4.3.0.5301  COMMITTED  Open Secure Shell Server
> 
> the AIX  version is 5.3 TL6 SP5
> 
> any ideas about the source of this problem

It seems to be an implementation deficiency in the AIX libc that
provides mkstemp().

If you haven't already studied what mkstemp() is used for, it is
supposed to create temporary files with guaranteed unique filenames
using a method guaranteed to be free of race conditions. Apparently
that is not the case in your system.

Complain to IBM.


//Peter

From Sergiu.Partenie at ps.net  Wed Nov 19 04:10:13 2008
From: Sergiu.Partenie at ps.net (Partenie, Sergiu)
Date: Tue, 18 Nov 2008 11:10:13 -0600
Subject: Axway XFB sftp server & no-more-sessions@openssh.com
Message-ID: <0AB291C134AC9A4CB5203465FDC939C1033457F9@PSCDALPEXCH03.perotsystems.net>

Hello all,

First of all, thank you for such great software.

I have a bug (and a fix) to report for 5.1p:

The "Axway XFB.Gateway" SFTP server will drop sftp sessions initiated from the OpenSSH 5.1p (HP-UX) sftp if it receives the "no-more-sessions at openssh.com" flag.
It can be reproduced also with the sftp sessions initiated from a OpenSSH 5.1p sftp on a Linux machine.

As a workaround we are using now "-oControlMaster=yes" for each sftp connection in order to disable the sending of "no-more-sessions at openssh.com" flag.

Can you please add for future versions in "compat.c" that for connections to servers who identify themselves as "XFB.Gateway Unix" a flag should be set that "no-more-sessions at openssh.com" is not sent to that server ?

Thanks a lot !

excerpts from sftp -vvv (without "-oControlMaster=yes")
=========
...
debug1: Remote protocol version 2.0, remote software version XFB.Gateway Unix
debug1: no match: XFB.Gateway Unix
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.1p1+sftpfilecontrol-v1.2-hpn13v5
...
debug1: Authentication succeeded (publickey).
debug2: fd 5 setting O_NONBLOCK
debug2: fd 6 setting O_NONBLOCK
debug1: Final hpn_buffer_size = 2097152
debug1: HPN Disabled: 1, HPN Buffer Size: 2097152
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
debug1: Sending subsystem: sftp
debug2: channel 0: request subsystem confirm 1
debug2: fd 4 setting TCP_NODELAY
debug2: callback done
debug2: channel 0: open confirm rwindow 32768 rmax 16384
debug1: channel 0: free: client-session, nchannels 1
debug3: channel 0: status: The following connections are open:
  #0 client-session (t4 r660 i0/9 o0/0 fd 5/6 cfd -1)
 
debug3: channel 0: close_fds r 5 w 6 e 7 c -1
debug1: fd 0 clearing O_NONBLOCK
debug1: fd 1 clearing O_NONBLOCK
Connection to XX.XX.XX.XX closed by remote host.
Transferred: sent 2152, received 1088 bytes, in 0.1 seconds
Bytes per second: sent 16388.3, received 8285.6
debug1: Exit status -1
Connection closed
===========


From djm at mindrot.org  Wed Nov 19 20:21:36 2008
From: djm at mindrot.org (Damien Miller)
Date: Wed, 19 Nov 2008 20:21:36 +1100 (EST)
Subject: Axway XFB sftp server & no-more-sessions@openssh.com
In-Reply-To: <0AB291C134AC9A4CB5203465FDC939C1033457F9@PSCDALPEXCH03.perotsystems.net>
References: <0AB291C134AC9A4CB5203465FDC939C1033457F9@PSCDALPEXCH03.perotsystems.net>
Message-ID: <alpine.BSO.1.10.0811192018570.16202@fuyu.mindrot.org>

On Tue, 18 Nov 2008, Partenie, Sergiu wrote:

> Hello all,
>
> First of all, thank you for such great software.
>
> I have a bug (and a fix) to report for 5.1p:
>
> The "Axway XFB.Gateway" SFTP server will drop sftp sessions
> initiated from the OpenSSH 5.1p (HP-UX) sftp if it receives the
> "no-more-sessions at openssh.com" flag It can be reproduced also with the
> sftp sessions initiated from a OpenSSH 5.1p sftp on a Linux machine
>
> As a workaround we are using now "-oControlMaster=yes" for
> each sftp connection in order to disable the sending of
> "no-more-sessions at openssh.com" flag.
>
> Can you please add for future versions in "compat.c" that for
> connections to servers who identify themselves as "XFB.Gateway Unix" a
> flag should be set that "no-more-sessions at openssh.com" is not sent to
> that server ?

Due to bugs in other servers, OpenSSH 5.2 will not send this extension
message (nor the eow at openssh.com channel half-closed notification) to
any server that doesn't identify itself as OpenSSH. Vendors are required
to gracefully refuse messages that they do not understand, so the "Axway
XFB.Gateway" is actually what is at fault here.

If any other ssh vendors what to receive these messages, then they should
let us know so they can be whitelisted in compat.c

-d

From Sergiu.Partenie at ps.net  Wed Nov 19 20:56:31 2008
From: Sergiu.Partenie at ps.net (Partenie, Sergiu)
Date: Wed, 19 Nov 2008 03:56:31 -0600
Subject: Axway XFB sftp server & no-more-sessions@openssh.com
References: <0AB291C134AC9A4CB5203465FDC939C1033457F9@PSCDALPEXCH03.perotsystems.net>
	<alpine.BSO.1.10.0811192018570.16202@fuyu.mindrot.org>
Message-ID: <0AB291C134AC9A4CB5203465FDC939C1033457FC@PSCDALPEXCH03.perotsystems.net>

> Due to bugs in other servers, OpenSSH 5.2 will not send this extension
> message (nor the eow at openssh.com channel half-closed notification) to
> any server that doesn't identify itself as OpenSSH. Vendors are required
> to gracefully refuse messages that they do not understand, so the "Axway
> XFB.Gateway" is actually what is at fault here.
> 
> If any other ssh vendors what to receive these messages, then they should
> let us know so they can be whitelisted in compat.c

Thank you very much for the good news !
Indeed, the 3rd party SSH vendors are at fault here and they should fix their stuff, but realistically speaking, many new releases of OpenSSH will be delivered until the commercial vendors will fix their problems and the existing installations will be updated.

Thanks again, keep up the good work !

From hanpedro at gmail.com  Wed Nov 19 20:39:12 2008
From: hanpedro at gmail.com (??????)
Date: Wed, 19 Nov 2008 18:39:12 +0900
Subject: HELPA
Message-ID: <000401c94a2a$af5e3b40$0e1ab1c0$@com>

I have a problem in ssh login without password
 
Systems:  vmware-centos 5.2:  192.168.0.4  vista copssh: 192.168.0.2

[192.168.0.4 $] ssh-keygen -t dsa
[192.168.0.4 $] scp -p id_dsa.pub tester at 192.168.0.2:.ssh

[192.168.0.2 $] cat .ssh/id_dsa.pub >> .ssh/authorized_keys
[192.168.0.2 $] chmod 700 .ssh
[192.168.0.2 $] chmod 600 .ssh/authorized_keys

[192.168.0.4 $] ssh id at 192.168.0.2
Permission denied (publickey).

But with password, I can connect to 192.168.0.2.

The sshd_conf is as follows;
 

192.168.0.4(centos 5.2) sshd_conf:
 
Protocol 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
SyslogFacility AUTHPRIV
#LogLevel INFO
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
PasswordAuthentication no
ChallengeResponseAuthentication no
GSSAPIAuthentication yes
GSSAPICleanupCredentials yes
UsePAM yes
AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY
LC_MESSAGES AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE
LC_MEASUREMENT AcceptEnv LC_IDENTIFICATION LC_ALL X11Forwarding yes
Subsystem sftp /usr/libexec/openssh/sftp-server
192.168.0.2 (copssh) sshd_conf:
 
Protocol 2
SyslogFacility AUTHPRIV
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
PasswordAuthentication no
ChallengeResponseAuthentication no
AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY
LC_MESSAGES AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE
LC_MEASUREMENT AcceptEnv LC_IDENTIFICATION LC_ALL X11Forwarding yes
Subsystem sftp /usr/libexec/openssh/sftp-server
 
 
ssh -vvv id at 192.168.0.2:
 
......
......
debug1: Host '192.168.0.2' is known and matches the RSA host key.
debug1: Found key in /home/hanpedro/.ssh/known_hosts:2
debug2: bits set: 495/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: /home/hanpedro/.ssh/id_rsa ((nil))
debug2: key: /home/hanpedro/.ssh/id_dsa ((nil))
debug1: Authentications that can continue: publickey
debug3: start over, passed a different list publickey
debug3: preferred gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /home/hanpedro/.ssh/id_rsa
debug3: no such identity: /home/hanpedro/.ssh/id_rsa
debug1: Trying private key: /home/hanpedro/.ssh/id_dsa
debug3: no such identity: /home/hanpedro/.ssh/id_dsa
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey).
 

What am I wrong?
Any comment would be appreciated.



From dtucker at zip.com.au  Wed Nov 19 23:20:42 2008
From: dtucker at zip.com.au (Darren Tucker)
Date: Wed, 19 Nov 2008 23:20:42 +1100
Subject: OpenSSH performance with VIA padlock
In-Reply-To: <200811181728.11855.janklodvan@gmail.com>
References: <200811181728.11855.janklodvan@gmail.com>
Message-ID: <4924049A.8060809@zip.com.au>

Jan Klod wrote:
> Hello list,
> please spend a minute considering these facts and maybe there is something to 
> improve:
> 
> 1) VIA Eden based board can write AES256 encrypted information on HDD at > 
> 60MB/s
> 2) iperf shows NIC speed 69MB/s
> 3) openssl tests have even better results
> 4) openssh can transfer AES256 encrypted information at < 27MB/s (and worse 
> with HDD encryption)
> 
> It is better with openssh 5.x, than 4.6, but still I see no reason why results 
> are so bad... Please, could someone explain? I don't believe, padlock is used 
> properly...

Did you enable OpenSSL engine support when you built OpenSSH? 
(./configure  --with-ssl-engine).

Try this with 5.1p1, apparently some earlier versions didn't work 
properly (I have no such hardware to test).

Also as someone else mentioned, try a faster MAC such as umac64.

-- 
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 tomoyuki at pobox.com  Wed Nov 19 23:32:44 2008
From: tomoyuki at pobox.com (Tomoyuki Murakami)
Date: Wed, 19 Nov 2008 21:32:44 +0900 (JST)
Subject: HELPA
In-Reply-To: <000401c94a2a$af5e3b40$0e1ab1c0$@com>
References: <000401c94a2a$af5e3b40$0e1ab1c0$@com>
Message-ID: <20081119.213244.193695072.tomoyuki@pobox.com>


>>> On Wed, 19 Nov 2008 18:39:12 +0900,
>>>  "??????" <hanpedro at gmail.com> wrote:

hanpedro> Systems:  vmware-centos 5.2:  192.168.0.4  vista copssh: 192.168.0.2

you did,
hanpedro> [192.168.0.4 $] ssh-keygen -t dsa
hanpedro> [192.168.0.4 $] scp -p id_dsa.pub tester at 192.168.0.2:.ssh
                                            ~~~~~~~
but trying,
hanpedro> [192.168.0.4 $] ssh id at 192.168.0.2
                              ~~~
hanpedro> 192.168.0.4(centos 5.2) sshd_conf:
...
sshd_conf of client side machine has no effect in this issue.

any way, please try
[192.168.0.4 $] scp -p id_dsa.pub id at 192.168.0.2:.ssh
                                  ~~
[192.168.0.2 $] cd ~id
[192.168.0.2 $] cat .ssh/id_dsa.pub >> .ssh/authorized_keys
[192.168.0.2 $] chmod 700 .ssh
[192.168.0.2 $] chmod 600 .ssh/authorized_keys

and ...
hanpedro> debug1: Next authentication method: publickey
hanpedro> debug1: Trying private key: /home/hanpedro/.ssh/id_rsa
hanpedro> debug3: no such identity: /home/hanpedro/.ssh/id_rsa
hanpedro> debug1: Trying private key: /home/hanpedro/.ssh/id_dsa
hanpedro> debug3: no such identity: /home/hanpedro/.ssh/id_dsa
hanpedro> debug2: we did not send a packet, disable method
hanpedro> debug1: No more authentication methods to try.
hanpedro> Permission denied (publickey).

when this happens again,
re-check your id_dsa is in your client side(192.168.0.4)
 $HOME/.ssh/.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 305 bytes
Desc: not available
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20081119/e2856d4b/attachment-0001.bin 

From janklodvan at gmail.com  Thu Nov 20 01:10:27 2008
From: janklodvan at gmail.com (Jan Klod)
Date: Wed, 19 Nov 2008 16:10:27 +0200
Subject: OpenSSH performance with VIA padlock
In-Reply-To: <4924049A.8060809@zip.com.au>
References: <200811181728.11855.janklodvan@gmail.com>
	<4924049A.8060809@zip.com.au>
Message-ID: <200811191610.27998.janklodvan@gmail.com>

On Wednesday 19 November 2008 14:20:42 you wrote:
> Jan Klod wrote:
> > Hello list,
> > please spend a minute considering these facts and maybe there is
> > something to improve:
> >
> > 1) VIA Eden based board can write AES256 encrypted information on HDD at
> > > 60MB/s
> > 2) iperf shows NIC speed 69MB/s
> > 3) openssl tests have even better results
> > 4) openssh can transfer AES256 encrypted information at < 27MB/s (and
> > worse with HDD encryption)
> >
> > It is better with openssh 5.x, than 4.6, but still I see no reason why
> > results are so bad... Please, could someone explain? I don't believe,
> > padlock is used properly...
>
> Did you enable OpenSSL engine support when you built OpenSSH?
> (./configure  --with-ssl-engine).
enabled

> Try this with 5.1p1, apparently some earlier versions didn't work
> properly (I have no such hardware to test).
same ver.

> Also as someone else mentioned, try a faster MAC such as umac64.
Why should I, if I have padlock, which supports sha1/sha265?!

openssl with -engine padlock: only aes gives much better results, the rest 
remains as before.

Apparently ssl is the problem! Where should I ask?

From andrew.hayden at gmail.com  Thu Nov 20 16:17:25 2008
From: andrew.hayden at gmail.com (Andrew Hayden)
Date: Wed, 19 Nov 2008 21:17:25 -0800
Subject: Possibility of implementing signal support from post in 2003?
Message-ID: <579b277f0811192117m7cbdcb14qd0c40cdf15a13780@mail.gmail.com>

Hi,

Back in 2003 the developer of JSch, a Java SSH2 implementation, posted
a thread regarding support for sending signals to remote processes
here:

http://marc.info/?l=openssh-unix-dev&m=104295745607575&w=2

The thread culminated in a patch provided by Markus Friedl, which
Atsuhiko Yamanaka tested and reported as working (unofficially), which
added support for this capability in the method
"session_input_channel_req".  I had a quick look through CVS and I see
this has never been applied (unless I'm missing something).

I'm developing an application based on JSch and I'd really like to see
this functionality added.  I have absolutely zero experience with the
OpenSSH codebase, and wouldn't quite know where to start with this in
terms of assessing its security and performance implications, though
from what I can see they would be pretty straightforward.  Is there
any possibility that this patch will get implemented, or this general
capability added, in the near future?  I don't have the ability to
patch OpenSSH in my particular environment (work), and would need this
in an official release to be blessed by security, etceteras.

Even if the answer is "no", thank you for your time, and apologies for
dragging an ancient thread up to the surface.

Sincerely,

Andrew Hayden

From djm at mindrot.org  Thu Nov 20 21:11:29 2008
From: djm at mindrot.org (Damien Miller)
Date: Thu, 20 Nov 2008 21:11:29 +1100 (EST)
Subject: OpenSSH performance with VIA padlock
In-Reply-To: <200811191610.27998.janklodvan@gmail.com>
References: <200811181728.11855.janklodvan@gmail.com>
	<4924049A.8060809@zip.com.au>
	<200811191610.27998.janklodvan@gmail.com>
Message-ID: <alpine.BSO.1.10.0811202108490.16202@fuyu.mindrot.org>

On Wed, 19 Nov 2008, Jan Klod wrote:
> > Did you enable OpenSSL engine support when you built OpenSSH?
> > (./configure  --with-ssl-engine).
> enabled
> 
> > Try this with 5.1p1, apparently some earlier versions didn't work
> > properly (I have no such hardware to test).
> same ver.
> 
> > Also as someone else mentioned, try a faster MAC such as umac64.
> Why should I, if I have padlock, which supports sha1/sha265?!

It doesn't; Padlock's SHA implementation has a design flaw that make it
difficult to use with most hashing APIs (OpenSSL included) without the
most gross of hacks.

> openssl with -engine padlock: only aes gives much better results, the rest 
> remains as before.
> 
> Apparently ssl is the problem! Where should I ask?

You can't use Google?

-d

From dtucker at zip.com.au  Thu Nov 20 21:17:58 2008
From: dtucker at zip.com.au (Darren Tucker)
Date: Thu, 20 Nov 2008 21:17:58 +1100
Subject: Possibility of implementing signal support from post in 2003?
In-Reply-To: <579b277f0811192117m7cbdcb14qd0c40cdf15a13780@mail.gmail.com>
References: <579b277f0811192117m7cbdcb14qd0c40cdf15a13780@mail.gmail.com>
Message-ID: <20081120101758.GA10815@gate.dtucker.net>

On Wed, Nov 19, 2008 at 09:17:25PM -0800, Andrew Hayden wrote:
> Back in 2003 the developer of JSch, a Java SSH2 implementation, posted
> a thread regarding support for sending signals to remote processes
> here:
> 
> http://marc.info/?l=openssh-unix-dev&m=104295745607575&w=2
> 
> The thread culminated in a patch provided by Markus Friedl, which
> Atsuhiko Yamanaka tested and reported as working (unofficially), which
> added support for this capability in the method
> "session_input_channel_req".  I had a quick look through CVS and I see
> this has never been applied (unless I'm missing something).

The enhancement request is here (with an updated patch).
https://bugzilla.mindrot.org/show_bug.cgi?id=1424

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

From dtucker at zip.com.au  Thu Nov 20 21:21:59 2008
From: dtucker at zip.com.au (Darren Tucker)
Date: Thu, 20 Nov 2008 21:21:59 +1100
Subject: OpenSSH performance with VIA padlock
In-Reply-To: <200811191610.27998.janklodvan@gmail.com>
References: <200811181728.11855.janklodvan@gmail.com>
	<4924049A.8060809@zip.com.au>
	<200811191610.27998.janklodvan@gmail.com>
Message-ID: <20081120102159.GB10815@gate.dtucker.net>

On Wed, Nov 19, 2008 at 04:10:27PM +0200, Jan Klod wrote:
> On Wednesday 19 November 2008 14:20:42 dtucker wrote:
[...]
> > Also as someone else mentioned, try a faster MAC such as umac64.
> Why should I, if I have padlock, which supports sha1/sha265?!

Your objective is to make it go faster, right?  This might help.

If it does that's a datapoint indicating that the MAC is the bottleneck
and if it doesn't then it's another datapoint indicating the the MAC is
*not* the bottleneck.

Anyway, I see Damien has also added some info to this thread.

-- 
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 js021104 at cox.net  Fri Nov 21 12:32:07 2008
From: js021104 at cox.net (j.s.)
Date: Thu, 20 Nov 2008 17:32:07 -0800
Subject: 'make install' failed on Sparc5, Solaris2.7
Message-ID: <49260F97.1080704@cox.net>

Hello,

System info: Sparcstation 5, Solaris 2.7, openssl-0.9.8i.

I've tried to install
openssh-3.9p1
openssh-4.9p1
openssh-5.1p1

all failed the similar way. The following is the last portion of the 
'make install' printout.

./install-sh -c -m 0755 -s ssh /usr/local/bin/ssh
BFD: /usr/local/bin/stkuaiGw: warning: allocated section `.interp' not 
in segment
./install-sh -c -m 0755 -s scp /usr/local/bin/scp
BFD: /usr/local/bin/stC4aqIw: warning: allocated section `.interp' not 
in segment
./install-sh -c -m 0755 -s ssh-add /usr/local/bin/ssh-add
BFD: /usr/local/bin/stISa4Kw: warning: allocated section `.interp' not 
in segment
./install-sh -c -m 0755 -s ssh-agent /usr/local/bin/ssh-agent
BFD: /usr/local/bin/stoAaaNw: warning: allocated section `.interp' not 
in segment
./install-sh -c -m 0755 -s ssh-keygen /usr/local/bin/ssh-keygen
BFD: /usr/local/bin/stcsaiPw: warning: allocated section `.interp' not 
in segment
./install-sh -c -m 0755 -s ssh-keyscan /usr/local/bin/ssh-keyscan
BFD: /usr/local/bin/stwgaWRw: warning: allocated section `.interp' not 
in segment
./install-sh -c -m 0755 -s sshd /usr/local/sbin/sshd
BFD: /usr/local/sbin/stoAa4Tw: warning: allocated section `.interp' not 
in segment
if test ! -z "" ; then \
./install-sh -c -m 0755 -s ssh-rand-helper 
/usr/local/libexec/ssh-rand-helper ; \
fi
./install-sh -c -m 4711 -s ssh-keysign /usr/local/libexec/ssh-keysign
BFD: /usr/local/libexec/st9raiWw: warning: allocated section `.interp' 
not in segment
./install-sh -c -m 0755 -s sftp /usr/local/bin/sftp
BFD: /usr/local/bin/stpbaqYw: warning: allocated section `.interp' not 
in segment
./install-sh -c -m 0755 -s sftp-server /usr/local/libexec/sftp-server
BFD: /usr/local/libexec/stVUay0w: warning: allocated section `.interp' 
not in segment
./install-sh -c -m 644 ssh.1.out /usr/local/man/man1/ssh.1
./install-sh -c -m 644 scp.1.out /usr/local/man/man1/scp.1
./install-sh -c -m 644 ssh-add.1.out /usr/local/man/man1/ssh-add.1
./install-sh -c -m 644 ssh-agent.1.out /usr/local/man/man1/ssh-agent.1
./install-sh -c -m 644 ssh-keygen.1.out /usr/local/man/man1/ssh-keygen.1
./install-sh -c -m 644 ssh-keyscan.1.out /usr/local/man/man1/ssh-keyscan.1
./install-sh -c -m 644 sshd_config.5.out /usr/local/man/man5/sshd_config.5
./install-sh -c -m 644 ssh_config.5.out /usr/local/man/man5/ssh_config.5
./install-sh -c -m 644 sshd.8.out /usr/local/man/man8/sshd.8
if [ ! -z "" ]; then \
./install-sh -c -m 644 ssh-rand-helper.8.out 
/usr/local/man/man8/ssh-rand-helper.8 ; \
fi
./install-sh -c -m 644 sftp.1.out /usr/local/man/man1/sftp.1
./install-sh -c -m 644 sftp-server.8.out /usr/local/man/man8/sftp-server.8
./install-sh -c -m 644 ssh-keysign.8.out /usr/local/man/man8/ssh-keysign.8
rm -f /usr/local/bin/slogin
ln -s ./ssh /usr/local/bin/slogin
rm -f /usr/local/man/man1/slogin.1
ln -s ./ssh.1 /usr/local/man/man1/slogin.1
if [ ! -d /usr/local/etc ]; then \
./mkinstalldirs /usr/local/etc; \
fi
/usr/local/etc/ssh_config already exists, install will not overwrite
/usr/local/etc/sshd_config already exists, install will not overwrite
/usr/local/etc/moduli already exists, install will not overwrite
/usr/local/etc/ssh_host_key already exists, skipping.
/usr/local/etc/ssh_host_dsa_key already exists, skipping.
/usr/local/etc/ssh_host_rsa_key already exists, skipping.
/usr/local/sbin/sshd -t -f /usr/local/etc/sshd_config
sshd: Cannot find ELF
make: *** [check-config] Killed


Thank you.
Shan Jiang


From jdehaan at zwartkasteel.nl  Fri Nov 21 16:05:49 2008
From: jdehaan at zwartkasteel.nl (Jan de Haan)
Date: Fri, 21 Nov 2008 06:05:49 +0100
Subject: 'make install' failed on Sparc5, Solaris2.7
In-Reply-To: <49260F97.1080704@cox.net>
References: <49260F97.1080704@cox.net>
Message-ID: <7f69402e0811202105n3201f823gc1ae9e83b32545a7@mail.gmail.com>

A bit of Googleing turned up this:
http://www.brandonhutchinson.com/cannot_find_ELF_when_installing_OpenSSH.html

Sincerely,

Jan.

On Fri, Nov 21, 2008 at 2:32 AM, j.s. <js021104 at cox.net> wrote:

> Hello,
>
> System info: Sparcstation 5, Solaris 2.7, openssl-0.9.8i.
>
> I've tried to install
> openssh-3.9p1
> openssh-4.9p1
> openssh-5.1p1
>
> all failed the similar way. The following is the last portion of the
> 'make install' printout.
>
> ./install-sh -c -m 0755 -s ssh /usr/local/bin/ssh
> BFD: /usr/local/bin/stkuaiGw: warning: allocated section `.interp' not
> in segment
> ./install-sh -c -m 0755 -s scp /usr/local/bin/scp
> BFD: /usr/local/bin/stC4aqIw: warning: allocated section `.interp' not
> in segment
> ./install-sh -c -m 0755 -s ssh-add /usr/local/bin/ssh-add
> BFD: /usr/local/bin/stISa4Kw: warning: allocated section `.interp' not
> in segment
> ./install-sh -c -m 0755 -s ssh-agent /usr/local/bin/ssh-agent
> BFD: /usr/local/bin/stoAaaNw: warning: allocated section `.interp' not
> in segment
> ./install-sh -c -m 0755 -s ssh-keygen /usr/local/bin/ssh-keygen
> BFD: /usr/local/bin/stcsaiPw: warning: allocated section `.interp' not
> in segment
> ./install-sh -c -m 0755 -s ssh-keyscan /usr/local/bin/ssh-keyscan
> BFD: /usr/local/bin/stwgaWRw: warning: allocated section `.interp' not
> in segment
> ./install-sh -c -m 0755 -s sshd /usr/local/sbin/sshd
> BFD: /usr/local/sbin/stoAa4Tw: warning: allocated section `.interp' not
> in segment
> if test ! -z "" ; then \
> ./install-sh -c -m 0755 -s ssh-rand-helper
> /usr/local/libexec/ssh-rand-helper ; \
> fi
> ./install-sh -c -m 4711 -s ssh-keysign /usr/local/libexec/ssh-keysign
> BFD: /usr/local/libexec/st9raiWw: warning: allocated section `.interp'
> not in segment
> ./install-sh -c -m 0755 -s sftp /usr/local/bin/sftp
> BFD: /usr/local/bin/stpbaqYw: warning: allocated section `.interp' not
> in segment
> ./install-sh -c -m 0755 -s sftp-server /usr/local/libexec/sftp-server
> BFD: /usr/local/libexec/stVUay0w: warning: allocated section `.interp'
> not in segment
> ./install-sh -c -m 644 ssh.1.out /usr/local/man/man1/ssh.1
> ./install-sh -c -m 644 scp.1.out /usr/local/man/man1/scp.1
> ./install-sh -c -m 644 ssh-add.1.out /usr/local/man/man1/ssh-add.1
> ./install-sh -c -m 644 ssh-agent.1.out /usr/local/man/man1/ssh-agent.1
> ./install-sh -c -m 644 ssh-keygen.1.out /usr/local/man/man1/ssh-keygen.1
> ./install-sh -c -m 644 ssh-keyscan.1.out /usr/local/man/man1/ssh-keyscan.1
> ./install-sh -c -m 644 sshd_config.5.out /usr/local/man/man5/sshd_config.5
> ./install-sh -c -m 644 ssh_config.5.out /usr/local/man/man5/ssh_config.5
> ./install-sh -c -m 644 sshd.8.out /usr/local/man/man8/sshd.8
> if [ ! -z "" ]; then \
> ./install-sh -c -m 644 ssh-rand-helper.8.out
> /usr/local/man/man8/ssh-rand-helper.8 ; \
> fi
> ./install-sh -c -m 644 sftp.1.out /usr/local/man/man1/sftp.1
> ./install-sh -c -m 644 sftp-server.8.out /usr/local/man/man8/sftp-server.8
> ./install-sh -c -m 644 ssh-keysign.8.out /usr/local/man/man8/ssh-keysign.8
> rm -f /usr/local/bin/slogin
> ln -s ./ssh /usr/local/bin/slogin
> rm -f /usr/local/man/man1/slogin.1
> ln -s ./ssh.1 /usr/local/man/man1/slogin.1
> if [ ! -d /usr/local/etc ]; then \
> ./mkinstalldirs /usr/local/etc; \
> fi
> /usr/local/etc/ssh_config already exists, install will not overwrite
> /usr/local/etc/sshd_config already exists, install will not overwrite
> /usr/local/etc/moduli already exists, install will not overwrite
> /usr/local/etc/ssh_host_key already exists, skipping.
> /usr/local/etc/ssh_host_dsa_key already exists, skipping.
> /usr/local/etc/ssh_host_rsa_key already exists, skipping.
> /usr/local/sbin/sshd -t -f /usr/local/etc/sshd_config
> sshd: Cannot find  ELF
> make: *** [check-config] Killed
>
>
> Thank you.
> Shan Jiang
>
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>

From dtucker at zip.com.au  Fri Nov 21 20:53:21 2008
From: dtucker at zip.com.au (Darren Tucker)
Date: Fri, 21 Nov 2008 20:53:21 +1100
Subject: 'make install' failed on Sparc5, Solaris2.7
In-Reply-To: <49260F97.1080704@cox.net>
References: <49260F97.1080704@cox.net>
Message-ID: <49268511.20106@zip.com.au>

j.s. wrote:
> Hello,
> 
> System info: Sparcstation 5, Solaris 2.7, openssl-0.9.8i.
> 
> I've tried to install
> openssh-3.9p1
> openssh-4.9p1
> openssh-5.1p1
> 
> all failed the similar way. The following is the last portion of the 
> 'make install' printout.
> 
> ./install-sh -c -m 0755 -s ssh /usr/local/bin/ssh
> BFD: /usr/local/bin/stkuaiGw: warning: allocated section `.interp' not 
> in segment

It's a GNU binutils linker bug:
http://sourceware.org/ml/binutils/2002-07/msg00148.html
http://marc.info/?l=openssh-unix-dev&m=103335295922022&w=2

Upgrade to binutils-2.13 or newer, or switch to the native linker as 
someone else suggested.

-- 
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 cvs.openbsd.org  Fri Nov 21 21:19:03 2008
From: djm at cvs.openbsd.org (Damien Miller)
Date: Fri, 21 Nov 2008 03:19:03 -0700 (MST)
Subject: OpenSSH security advisory: cbc.adv
Message-ID: <200811211019.mALAJ3Ms014517@cvs.openbsd.org>

OpenSSH Security Advisory: cbc.adv

Regarding the "Plaintext Recovery Attack Against SSH" reported as
CPNI-957037[1]:

The OpenSSH team has been made aware of an attack against the SSH
protocol version 2 by researchers at the University of London.
Unfortunately, due to the report lacking any detailed technical
description of the attack and CPNI's unwillingness to share necessary
information, we are unable to properly assess its impact.

Based on the description contained in the CPNI report and a slightly
more detailed description forwarded by CERT this issue appears to be
substantially similar to a known weakness in the SSH binary packet
protocol first described in 2002 by Bellare, Kohno and Namprempre[2].
The new component seems to be an attack that can recover 14 bits of
plaintext with a success probability of 2^-14, though we suspect this
underestimates the work required by a practical attack.

For most SSH usage scenarios, this attack has a very low likelihood of
being carried out successfully - each attempt has a low probability
of success and each failure will cause connection termination with a
fatal error. It is therefore very unlikely for an interactive session
to be usefully attacked using this protocol weakness: an attacker would
expect around 32768 connection-killing attempts before they are likely
to succeed. This level of disruption would certainly be noticed and it
is highly unlikely that any user would retry the connection enough times
for the attack to succeed.

The usage pattern where the attack is most likely to succeed is where an
automated connection is configured to retry indefinitely in the event of
errors. In this case, it might be possible to recover as much as 14 bits
of plaintext per hour (assuming a very fast 10 connections per second).
Implementing a limit on the number of connection retries (e.g. 256) is
sufficient to render the attack infeasible for this case.

AES CTR mode and arcfour ciphers are not vulnerable to this attack at
all. These may be preferentially selected by placing the following
directive in sshd_config and ssh_config:

Ciphers aes128-ctr,aes256-ctr,arcfour256,arcfour,aes128-cbc,aes256-cbc

A future version of OpenSSH may make CTR mode ciphers the default and/or
implement other countermeasures, but at present we do not feel that this
issue is serious enough to make an emergency release.

-d

[1] http://www.cpni.gov.uk/Docs/Vulnerability_Advisory_SSH.txt
[2] http://www.cs.washington.edu/homes/yoshi/papers/TISSEC04/


From jmknoble at pobox.com  Sat Nov 22 07:00:41 2008
From: jmknoble at pobox.com (Jim Knoble)
Date: Fri, 21 Nov 2008 15:00:41 -0500
Subject: OpenSSH security advisory: cbc.adv
In-Reply-To: <200811211019.mALAJ3Ms014517@cvs.openbsd.org>
References: <200811211019.mALAJ3Ms014517@cvs.openbsd.org>
Message-ID: <20081121200041.GB16695@crawfish.ais.com>

Circa 2008-11-21 05:19 dixit Damien Miller:

: OpenSSH Security Advisory: cbc.adv
: 
: Regarding the "Plaintext Recovery Attack Against SSH" reported as
: CPNI-957037[1]:

  [...]

: AES CTR mode and arcfour ciphers are not vulnerable to this attack at
: all. These may be preferentially selected by placing the following
: directive in sshd_config and ssh_config:
: 
: Ciphers aes128-ctr,aes256-ctr,arcfour256,arcfour,aes128-cbc,aes256-cbc

As I recall, the 'arcfour' cipher (no keysize in the name) has its own
potential vulnerability, in that it fails to discard the initial 1536
bytes of the kesystream <http://www.ietf.org/rfc/rfc4345.txt>.  The
'arcfour128' cipher is the one which mixes the keystream before using
it.

The following 'Ciphers' spec is probably what Damien intended:

Ciphers aes128-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,aes256-cbc

--jim

-- 
jim knoble  |  jmknoble at pobox.com  |  http://www.pobox.com/~jmknoble/
(GnuPG key ID: C6F31FFA  >>>>>>  http://www.pobox.com/~jmknoble/keys/ )
(GnuPG fingerprint: 99D8:1D89:8C66:08B5:5C34::5527:A543:8C33:C6F3:1FFA)
+----------------------------------------------------------------------+
|[L]iberty, as we all know, cannot flourish in a country that is perma-|
| nently on a war footing, or even a near-war footing.  --Aldous Huxley|
+----------------------------------------------------------------------+

From djm at mindrot.org  Sat Nov 22 10:53:57 2008
From: djm at mindrot.org (Damien Miller)
Date: Sat, 22 Nov 2008 10:53:57 +1100 (EST)
Subject: OpenSSH security advisory: cbc.adv
In-Reply-To: <20081121200041.GB16695@crawfish.ais.com>
References: <200811211019.mALAJ3Ms014517@cvs.openbsd.org>
	<20081121200041.GB16695@crawfish.ais.com>
Message-ID: <alpine.BSO.1.10.0811221012140.16202@fuyu.mindrot.org>

On Fri, 21 Nov 2008, Jim Knoble wrote:

> Circa 2008-11-21 05:19 dixit Damien Miller:
> 
> : OpenSSH Security Advisory: cbc.adv
> : 
> : Regarding the "Plaintext Recovery Attack Against SSH" reported as
> : CPNI-957037[1]:
> 
>   [...]
> 
> : AES CTR mode and arcfour ciphers are not vulnerable to this attack at
> : all. These may be preferentially selected by placing the following
> : directive in sshd_config and ssh_config:
> : 
> : Ciphers aes128-ctr,aes256-ctr,arcfour256,arcfour,aes128-cbc,aes256-cbc
> 
> As I recall, the 'arcfour' cipher (no keysize in the name) has its own
> potential vulnerability, in that it fails to discard the initial 1536
> bytes of the kesystream <http://www.ietf.org/rfc/rfc4345.txt>.  The
> 'arcfour128' cipher is the one which mixes the keystream before using
> it.
> 
> The following 'Ciphers' spec is probably what Damien intended:
> 
> Ciphers aes128-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,aes256-cbc

No, I intended to leave the "arcfour" cipher in there because I don't
want security advice to break working configurations - "arcfour" has
always been in the default ssh protocol 2 proposal and lots of people
use it.

With regard to early keystream correlation, I don't think this is quite
so serious in SSH - arcfour is keyed with 256 bits of good-quality key
material derived from D-H. We could leak half these bits and still be a
solid position.

SSH's use is very different to WEPs. In WEP, the key is almost certainly
weak to begin with (it is human-entered). WEP also reuses the key over
and over, with different (sometimes weak) IVs - this reuse repeatedly
exposes the early keystream and is (with the weak IVs) what allows the
Fluhrer, Shamir and Mantin attack to recover the key. SSH uses the
negotiated keys only once.

I'd like to get rid of "arcfour" from the standard proposal, but haven't
thought of a nice way to transition people away from it.

-d

From jmknoble at pobox.com  Sat Nov 22 17:06:08 2008
From: jmknoble at pobox.com (Jim Knoble)
Date: Sat, 22 Nov 2008 01:06:08 -0500
Subject: OpenSSH security advisory: cbc.adv
In-Reply-To: <alpine.BSO.1.10.0811221012140.16202@fuyu.mindrot.org>
References: <200811211019.mALAJ3Ms014517@cvs.openbsd.org>
	<20081121200041.GB16695@crawfish.ais.com>
	<alpine.BSO.1.10.0811221012140.16202@fuyu.mindrot.org>
Message-ID: <20081122060607.GD16695@crawfish.ais.com>

Circa 2008-11-21 18:53 dixit Damien Miller:

: On Fri, 21 Nov 2008, Jim Knoble wrote:
: > Circa 2008-11-21 05:19 dixit Damien Miller:
: > : OpenSSH Security Advisory: cbc.adv
: > : 
: > : Regarding the "Plaintext Recovery Attack Against SSH" reported as
: > : CPNI-957037[1]:
  [...]
: > The following 'Ciphers' spec is probably what Damien intended:
: > 
: > Ciphers aes128-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,aes256-cbc
: 
: No, I intended to leave the "arcfour" cipher in there because I don't
: want security advice to break working configurations - "arcfour" has
: always been in the default ssh protocol 2 proposal and lots of people
: use it.

I stand corrected.

: With regard to early keystream correlation, I don't think this is quite
: so serious in SSH - arcfour is keyed with 256 bits of good-quality key
: material derived from D-H. We could leak half these bits and still be a
: solid position.
: 
: SSH's use is very different to WEPs. In WEP, the key is almost certainly
: weak to begin with (it is human-entered). WEP also reuses the key over
: and over, with different (sometimes weak) IVs - this reuse repeatedly
: exposes the early keystream and is (with the weak IVs) what allows the
: Fluhrer, Shamir and Mantin attack to recover the key. SSH uses the
: negotiated keys only once.

Thanks for clarifying this, Damien.  The risks as you describe them
above make 'arcfour' a reasonably secure choice.  As you note, keeping
things from breaking is more than a bit important.

Best,
jim

-- 
jim knoble  |  jmknoble at pobox.com  |  http://www.pobox.com/~jmknoble/
(GnuPG key ID: C6F31FFA  >>>>>>  http://www.pobox.com/~jmknoble/keys/ )
(GnuPG fingerprint: 99D8:1D89:8C66:08B5:5C34::5527:A543:8C33:C6F3:1FFA)
+----------------------------------------------------------------------+
|[L]iberty, as we all know, cannot flourish in a country that is perma-|
| nently on a war footing, or even a near-war footing.  --Aldous Huxley|
+----------------------------------------------------------------------+

From mkoeppe at gmx.de  Sun Nov 23 12:39:02 2008
From: mkoeppe at gmx.de (Martin Koeppe)
Date: Sun, 23 Nov 2008 02:39:02 +0100 (CET)
Subject: openssh on interix
In-Reply-To: <Pine.LNX.4.62.0811121112210.2745@vmdebian.local.koeppe-net.de>
References: <Pine.LNX.4.62.0811052313150.32748@vmdebian.local.koeppe-net.de>
	<4918885D.30002@anl.gov>
	<Pine.LNX.4.62.0811102229460.26949@vmdebian.local.koeppe-net.de>
	<4919B821.6020301@anl.gov>
	<Pine.LNX.4.62.0811121112210.2745@vmdebian.local.koeppe-net.de>
Message-ID: <Pine.LNX.4.62.0811230226340.26710@vmdebian.local.koeppe-net.de>


On Wed, 12 Nov 2008, Martin Koeppe wrote:

> Corinna Vinschen wrote:
>
>> This is all the same problem Cygwin's port to OpenSSH has. However, on 
>> Interix/SUA the user can store the password in the registry using the 
>> `regpwd' tool.  I have no idea how the password is stored and how to access 
>> it from privileged Interix processes, though.  Isn't there some 
>> documentation?  Or is the password only accessible by daemons created by 
>> Microsoft's developers?  Maybe you should try asking this on the MS 
>> newsgroup dedicated to SUA:
>> 
>>   microsoft.public.servicesforunix.general
>
> The password is accessible from non-MS tools, too. Rodney has build an 
> (closed source) openssh which uses private keys and finally the regpwd stored 
> passwords.

The regpwd stored passwords are stored in the same (Windows standard) 
way as e.g. Dial-in passwords or service account passwords are stored, 
i.e. under:

HKLM\Security\Policy\Secrets\

In Interix in security.h there are setsecret() and getsecret() 
available for storing and retrieving the passwords. There is also a 
man page for these 2 functions.

The tool Cain from http://www.oxid.it may be helpful, too.

Martin

From janklodvan at gmail.com  Sun Nov 23 08:44:40 2008
From: janklodvan at gmail.com (Jan Klod)
Date: Sat, 22 Nov 2008 23:44:40 +0200
Subject: OpenSSH performance with VIA padlock
In-Reply-To: <20081120102159.GB10815@gate.dtucker.net>
References: <200811181728.11855.janklodvan@gmail.com>
	<200811191610.27998.janklodvan@gmail.com>
	<20081120102159.GB10815@gate.dtucker.net>
Message-ID: <200811222344.40290.janklodvan@gmail.com>

On Thursday 20 November 2008 12:21:59 Darren Tucker wrote:
> On Wed, Nov 19, 2008 at 04:10:27PM +0200, Jan Klod wrote:
> > On Wednesday 19 November 2008 14:20:42 dtucker wrote:
>
> [...]
>
> > > Also as someone else mentioned, try a faster MAC such as umac64.
> >
> > Why should I, if I have padlock, which supports sha1/sha265?!
>
> Your objective is to make it go faster, right?  This might help.
>
> If it does that's a datapoint indicating that the MAC is the bottleneck
> and if it doesn't then it's another datapoint indicating the the MAC is
> *not* the bottleneck.
MAC *is* the bottleneck.
I have no luck with those patches from Michal's site somehow. It is easy to 
get virtually working sha1 HW accel, but hell know about its reliability from 
many aspects. Though, when openssh is started with patched openssl, there is 
no acceleration at all.
I'm confused: should I keep trying to get it work, as it could at least double 
communications speed...

> Anyway, I see Damien has also added some info to this thread.



From djm at cvs.openbsd.org  Mon Nov 24 08:58:55 2008
From: djm at cvs.openbsd.org (Damien Miller)
Date: Sun, 23 Nov 2008 14:58:55 -0700 (MST)
Subject: Revised: OpenSSH security advisory: cbc.adv
Message-ID: <200811232158.mANLwtV9026506@cvs.openbsd.org>

Hi,

There was an error in the original advisory. The estimate of 32768
attempts to carry out a successful attack is incorrect. The correct
estimate is 11356 attempts. A revised version is now available at:
http://www.openssh.com/txt/cbc.adv

The advisory and its recommendations are otherwise unchanged.

-d


From garry.boyce at eds.com  Tue Nov 25 05:02:05 2008
From: garry.boyce at eds.com (Garry Boyce)
Date: Mon, 24 Nov 2008 13:02:05 -0500
Subject: ssh-agent clustering
Message-ID: <000001c94e5e$c3258c40$5833d20a@amer.corp.eds.com>

Hi.. I've looked through all the documentation and searched numerous
websites and I can't find any viable current way to cluster ssh-agents.

The functionality gap I see is to allow a situation where 2 ssh-agents are
running on 2 different trusted machines. If one of those machines goes down
passwordless logins should be allowed to continue through the backup
ssh-agent. And when the machine comes back up the newly restarted agent
should be able to resync with the backup agent. This way 2 machines would
have to go down before passwords would have to be re-entered.

I'm wondering the implications of this kind of functionality and wondering
if this were to be implemented would it be something the development team
would be apt to consider for inclusion.

Thanks,
Garry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 1834 bytes
Desc: not available
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20081124/968cf834/attachment-0001.bin 

From peter at stuge.se  Tue Nov 25 07:34:28 2008
From: peter at stuge.se (Peter Stuge)
Date: Mon, 24 Nov 2008 21:34:28 +0100
Subject: ssh-agent clustering
In-Reply-To: <000001c94e5e$c3258c40$5833d20a@amer.corp.eds.com>
References: <000001c94e5e$c3258c40$5833d20a@amer.corp.eds.com>
Message-ID: <20081124203428.8037.qmail@stuge.se>

Garry Boyce wrote:
> Hi.. I've looked through all the documentation and searched
> numerous websites and I can't find any viable current way to
> cluster ssh-agents.

What technical solution do you have in mind?


//Peter

From djm at mindrot.org  Tue Nov 25 07:46:19 2008
From: djm at mindrot.org (Damien Miller)
Date: Tue, 25 Nov 2008 07:46:19 +1100 (EST)
Subject: ssh-agent clustering
In-Reply-To: <20081124203428.8037.qmail@stuge.se>
References: <000001c94e5e$c3258c40$5833d20a@amer.corp.eds.com>
	<20081124203428.8037.qmail@stuge.se>
Message-ID: <alpine.BSO.1.10.0811250741400.16202@fuyu.mindrot.org>

On Mon, 24 Nov 2008, Peter Stuge wrote:

> Garry Boyce wrote:
> > Hi.. I've looked through all the documentation and searched
> > numerous websites and I can't find any viable current way to
> > cluster ssh-agents.
> 
> What technical solution do you have in mind?

One thing that might be useful it to support multiple agent sockets in
an SSH_AUTH_SOCK environment variable, e.g:

SSH_AUTH_SOCK=/tmp/ssh-sVvxW987/agent.987:/tmp/superhappyagent-8s3h9d2/sock.123

and have the clients try each in turn. I was thinking about this to support
a PKCS#11 agent, but you could use it for failover too.

On the other hand, I don't think there should be any resynchronisation
between agents as this would violate a security goal of the agent: that you
can put keys in, but never get them out in a usable form.

-d

From jdehaan at zwartkasteel.nl  Tue Nov 25 07:46:02 2008
From: jdehaan at zwartkasteel.nl (Jan de Haan)
Date: Mon, 24 Nov 2008 21:46:02 +0100
Subject: ssh-agent clustering
In-Reply-To: <000001c94e5e$c3258c40$5833d20a@amer.corp.eds.com>
References: <000001c94e5e$c3258c40$5833d20a@amer.corp.eds.com>
Message-ID: <7f69402e0811241246s10a1f752m35e241c1f5263f23@mail.gmail.com>

Hi Garry,
  I did something with about the same functionality once, by starting the
ssh-agent
on the central system at boot time with the users credentials and loading
the
passphraseless key automatically from a directory that the user couldn't
read.
The only thing you need to do is dump the agent's environment variables when
it starts and source them when the user actually logs in.

Sincerely,

Jan de Haan.

On Mon, Nov 24, 2008 at 7:02 PM, Garry Boyce <garry.boyce at eds.com> wrote:

> Hi.. I've looked through all the documentation and searched numerous
> websites and I can't find any viable current way to cluster ssh-agents.
>
> The functionality gap I see is to allow a situation where 2 ssh-agents are
> running on 2 different trusted machines. If one of those machines goes down
> passwordless logins should be allowed to continue through the backup
> ssh-agent. And when the machine comes back up the newly restarted agent
> should be able to resync with the backup agent. This way 2 machines would
> have to go down before passwords would have to be re-entered.
>
> I'm wondering the implications of this kind of functionality and wondering
> if this were to be implemented would it be something the development team
> would be apt to consider for inclusion.
>
> Thanks,
> Garry
>
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>
>

From dkg at fifthhorseman.net  Tue Nov 25 07:03:48 2008
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Mon, 24 Nov 2008 15:03:48 -0500
Subject: ssh-agent clustering
In-Reply-To: <000001c94e5e$c3258c40$5833d20a@amer.corp.eds.com> (Garry Boyce's
	message of "Mon\, 24 Nov 2008 13\:02\:05 -0500")
References: <000001c94e5e$c3258c40$5833d20a@amer.corp.eds.com>
Message-ID: <87zljo6gd7.fsf@squeak.fifthhorseman.net>

A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20081124/52ab92e8/attachment.bin 

From garry.boyce at eds.com  Tue Nov 25 10:24:11 2008
From: garry.boyce at eds.com (Boyce, Garry)
Date: Mon, 24 Nov 2008 18:24:11 -0500
Subject: ssh-agent clustering
Message-ID: <763901c94e8b$c434069c$278784c6@amer.corp.eds.com>

That sounds about right. How would you rate complexity?

-----Original Message-----
From: Daniel Kahn Gillmor <dkg at fifthhorseman.net>
Sent: Monday, November 24, 2008 5:51 PM
To: Portable OpenSSH Development List <openssh-unix-dev at mindrot.org>
Subject: Re: ssh-agent clustering

On Mon 2008-11-24 13:02:05 -0500, Garry Boyce wrote:

> Hi.. I've looked through all the documentation and searched numerous
> websites and I can't find any viable current way to cluster
> ssh-agents.

It sounds to me like what you're looking to implement could be done
without modifying existing ssh-agent implementations.

You'd want to build some sort of intermediate agent that maintains
tunnels to various external agents, and monitors the state of those
tunnels.  It would accept ssh agent requests itself, and forward them
on to the relevant remote agents.  When one tunnel goes down, it would
redirect new requests to the highest-priority still-functioning tunnel.

Your ssh processes would talk only to the intermediate agent, and
would not know what kind of things were happening behind the scenes.

        --dkg

From peter at stuge.se  Tue Nov 25 14:21:23 2008
From: peter at stuge.se (Peter Stuge)
Date: Tue, 25 Nov 2008 04:21:23 +0100
Subject: ssh-agent clustering
In-Reply-To: <763901c94e8b$c434069c$278784c6@amer.corp.eds.com>
References: <763901c94e8b$c434069c$278784c6@amer.corp.eds.com>
Message-ID: <20081125032123.26781.qmail@stuge.se>

Boyce, Garry wrote:
> That sounds about right. How would you rate complexity?

Fairly low.


//Peter

From garry.boyce at eds.com  Wed Nov 26 03:01:50 2008
From: garry.boyce at eds.com (Garry Boyce)
Date: Tue, 25 Nov 2008 11:01:50 -0500
Subject: ssh-agent clustering
In-Reply-To: <87zljo6gd7.fsf@squeak.fifthhorseman.net>
References: <000001c94e5e$c3258c40$5833d20a@amer.corp.eds.com>
	<87zljo6gd7.fsf@squeak.fifthhorseman.net>
Message-ID: <000901c94f17$20c60420$5833d20a@amer.corp.eds.com>

Sounds like this fits the bill:
http://www.idaemons.org/projects/ssh-agent-proxy/

Do you agree? 

-----Original Message-----
From: openssh-unix-dev-bounces+garry.boyce=eds.com at mindrot.org
[mailto:openssh-unix-dev-bounces+garry.boyce=eds.com at mindrot.org] On Behalf
Of Daniel Kahn Gillmor
Sent: Monday, November 24, 2008 3:04 PM
To: Portable OpenSSH Development List
Subject: Re: ssh-agent clustering

On Mon 2008-11-24 13:02:05 -0500, Garry Boyce wrote:

> Hi.. I've looked through all the documentation and searched numerous 
> websites and I can't find any viable current way to cluster 
> ssh-agents.

It sounds to me like what you're looking to implement could be done without
modifying existing ssh-agent implementations.

You'd want to build some sort of intermediate agent that maintains tunnels
to various external agents, and monitors the state of those tunnels.  It
would accept ssh agent requests itself, and forward them on to the relevant
remote agents.  When one tunnel goes down, it would redirect new requests to
the highest-priority still-functioning tunnel.

Your ssh processes would talk only to the intermediate agent, and would not
know what kind of things were happening behind the scenes.

        --dkg


From peter at stuge.se  Wed Nov 26 03:05:17 2008
From: peter at stuge.se (Peter Stuge)
Date: Tue, 25 Nov 2008 17:05:17 +0100
Subject: ssh-agent clustering
In-Reply-To: <000901c94f17$20c60420$5833d20a@amer.corp.eds.com>
References: <000001c94e5e$c3258c40$5833d20a@amer.corp.eds.com>
	<87zljo6gd7.fsf@squeak.fifthhorseman.net>
	<000901c94f17$20c60420$5833d20a@amer.corp.eds.com>
Message-ID: <20081125160518.32485.qmail@stuge.se>

Garry Boyce wrote:
> Sounds like this fits the bill:
> http://www.idaemons.org/projects/ssh-agent-proxy/
> 
> Do you agree?

Yes, except the order in which it enumerates backing agents doesn't
seem to be so well defined.


//Peter

From garry.boyce at eds.com  Wed Nov 26 03:19:10 2008
From: garry.boyce at eds.com (Garry Boyce)
Date: Tue, 25 Nov 2008 11:19:10 -0500
Subject: ssh-agent clustering
In-Reply-To: <20081125160518.32485.qmail@stuge.se>
References: <000001c94e5e$c3258c40$5833d20a@amer.corp.eds.com><87zljo6gd7.fsf@squeak.fifthhorseman.net><000901c94f17$20c60420$5833d20a@amer.corp.eds.com>
	<20081125160518.32485.qmail@stuge.se>
Message-ID: <000a01c94f19$8c971ca0$5833d20a@amer.corp.eds.com>

I suppose it should probably be re-written in C for inclusion into openssh
core.. That is if they will include it..

Of course I wouldn't bother re-writing it if noone's going to incorporate
it..

Thoughts? 

-----Original Message-----
From: openssh-unix-dev-bounces+garry.boyce=eds.com at mindrot.org
[mailto:openssh-unix-dev-bounces+garry.boyce=eds.com at mindrot.org] On Behalf
Of Peter Stuge
Sent: Tuesday, November 25, 2008 11:05 AM
To: 'Portable OpenSSH Development List'
Subject: Re: ssh-agent clustering

Garry Boyce wrote:
> Sounds like this fits the bill:
> http://www.idaemons.org/projects/ssh-agent-proxy/
> 
> Do you agree?

Yes, except the order in which it enumerates backing agents doesn't seem to
be so well defined.


//Peter
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev at mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev


From dkg at fifthhorseman.net  Wed Nov 26 04:33:14 2008
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Tue, 25 Nov 2008 12:33:14 -0500
Subject: ssh-agent clustering
In-Reply-To: <000a01c94f19$8c971ca0$5833d20a@amer.corp.eds.com> (Garry Boyce's
	message of "Tue\, 25 Nov 2008 11\:19\:10 -0500")
References: <000001c94e5e$c3258c40$5833d20a@amer.corp.eds.com>
	<87zljo6gd7.fsf@squeak.fifthhorseman.net>
	<000901c94f17$20c60420$5833d20a@amer.corp.eds.com>
	<20081125160518.32485.qmail@stuge.se>
	<000a01c94f19$8c971ca0$5833d20a@amer.corp.eds.com>
Message-ID: <87iqqb678l.fsf@squeak.fifthhorseman.net>

On Tue 2008-11-25 11:19:10 -0500, Garry Boyce wrote:

> I suppose it should probably be re-written in C for inclusion into
> openssh core.. That is if they will include it..
>
> Of course I wouldn't bother re-writing it if noone's going to
> incorporate it..

Why would it need to be included in OpenSSH core?  What's wrong with
having it as a separate package?  

I agree that the ruby dependency might make some sysadmins
uncomfortable, but that's a reason to rewrite it without the ruby
dependency (C or Perl would probably be more acceptable to a wider
group of sysadmins).  I don't see it as a reason to include it in
OpenSSH itself.  Discrete packages are a good thing.

        --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20081125/0543da4f/attachment.bin 

From peter at stuge.se  Wed Nov 26 06:25:52 2008
From: peter at stuge.se (Peter Stuge)
Date: Tue, 25 Nov 2008 20:25:52 +0100
Subject: ssh-agent clustering
In-Reply-To: <87iqqb678l.fsf@squeak.fifthhorseman.net>
References: <000001c94e5e$c3258c40$5833d20a@amer.corp.eds.com>
	<87zljo6gd7.fsf@squeak.fifthhorseman.net>
	<000901c94f17$20c60420$5833d20a@amer.corp.eds.com>
	<20081125160518.32485.qmail@stuge.se>
	<000a01c94f19$8c971ca0$5833d20a@amer.corp.eds.com>
	<87iqqb678l.fsf@squeak.fifthhorseman.net>
Message-ID: <20081125192552.13735.qmail@stuge.se>

Daniel Kahn Gillmor wrote:
> I agree that the ruby dependency might make some sysadmins
> uncomfortable, but that's a reason to rewrite it without the ruby
> dependency (C or Perl would probably be more acceptable to a wider
> group of sysadmins).  I don't see it as a reason to include it in
> OpenSSH itself.

OpenSSH libssh.a has code for the hardest parts (not very hard, but
still) dealing with agent connections. Especially if writing a C
version it makes no sense to not reuse that code.


//Peter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20081125/eadeb29a/attachment.bin 

From josimapi at gmail.com  Wed Nov 26 23:00:03 2008
From: josimapi at gmail.com (Josele Lerele)
Date: Wed, 26 Nov 2008 13:00:03 +0100
Subject: OpenSSH with PermitPAMUserChange feature?
Message-ID: <4164cb590811260400g55691498v4b78cff46f68dc97@mail.gmail.com>

Hello,

>From what I have read in this post
https://bugzilla.mindrot.org/show_bug.cgi?id=1215
SSH doesn't allow to log in with a user that is not part of the system. At
least that's what I have understood from the bugzilla post. I have tried to
test whether this patch was added to the latest version of OpenSSH, but it
hasn't. I haven't even found the PermitPAMUserChange flag in the
configuration file.

Am I right?

This feature is critical for my implementation, because my PAM module needs
a user that is not in the system during authentication and then it changes
to be one of it. One of my targets was not to change the server code, so
that when intalling the program I only had to add a PAM module instead of
adding a patch to the ssh server too.

Does somebody knows if there is a workaround in PAM to solve this issue that
I could implement?


Thanks a lot for your help

Regards

From imorgan at nas.nasa.gov  Thu Nov 27 07:56:59 2008
From: imorgan at nas.nasa.gov (Iain Morgan)
Date: Wed, 26 Nov 2008 12:56:59 -0800
Subject: [RFE] Request support for FIPS mode support
Message-ID: <20081126205659.GA27466@linux55.nas.nasa.gov>

Greetings,

As those working in the government sector (US and Canada) already know,
compliance with FIPS 140-2 is a significant issue. While there are a few
patches out there that add support for FIPS mode to OpenSSH, it is not
currently in the mainstream.

With the recent validation of the 1.2 version of the OpenSSL FIPS
cryptographic object module, is there any chance that support could be
added in for the next OpenSSH release? That would simplify things
tremendously for those who have to deal with FIPS 140-2.

I should note that in some cases, the need for FIPS mode support has
forced some government organizations to look more closely at SSH.com's
product, which was FIPS validated a few years ago.

I know there have been ocassional inquiries regarding this issue and
there is even an open bug (bz#1197) regarding it, but I would like to
encourage the developers to add this support and I would also like to
encourage those on the mailing list who are also interested in this
issue to chime in.

Thanks

-- 
Iain Morgan

From lutz at lutz-jaenicke.de  Thu Nov 27 19:06:00 2008
From: lutz at lutz-jaenicke.de (Lutz Jaenicke)
Date: Thu, 27 Nov 2008 09:06:00 +0100
Subject: OpenSSH security advisory: cbc.adv
In-Reply-To: <200811211019.mALAJ3Ms014517@cvs.openbsd.org>
References: <200811211019.mALAJ3Ms014517@cvs.openbsd.org>
Message-ID: <492E54E8.3090702@lutz-jaenicke.de>

Damien Miller wrote:
> OpenSSH Security Advisory: cbc.adv
> [text deleted]
>
> AES CTR mode and arcfour ciphers are not vulnerable to this attack at
> all. These may be preferentially selected by placing the following
> directive in sshd_config and ssh_config:
>
> Ciphers aes128-ctr,aes256-ctr,arcfour256,arcfour,aes128-cbc,aes256-cbc
>   
Hi,

I have been reading the documentation and had a look into the source
but finally did not manage to understand the selection method.
(For SSL it is the server that selects "based on the clients preferences"
which means that depending on the server settings the client's or the
server's preference will be used.)
Where can I find respective documentation (or the location in the source
to find out myself :-)

Best regards,
    Lutz

From markus.r.friedl at arcor.de  Thu Nov 27 19:35:04 2008
From: markus.r.friedl at arcor.de (Markus Friedl)
Date: Thu, 27 Nov 2008 09:35:04 +0100
Subject: OpenSSH security advisory: cbc.adv
In-Reply-To: <492E54E8.3090702@lutz-jaenicke.de>
References: <200811211019.mALAJ3Ms014517@cvs.openbsd.org>
	<492E54E8.3090702@lutz-jaenicke.de>
Message-ID: <20081127083504.GA14085@folly>

On Thu, Nov 27, 2008 at 09:06:00AM +0100, Lutz Jaenicke wrote:
> I have been reading the documentation and had a look into the source
> but finally did not manage to understand the selection method.
> (For SSL it is the server that selects "based on the clients preferences"

same applies to ssh.

From vinschen at redhat.com  Thu Nov 27 20:31:47 2008
From: vinschen at redhat.com (Corinna Vinschen)
Date: Thu, 27 Nov 2008 10:31:47 +0100
Subject: [PATCH/cygwin] Fix cygwin specific Makefile and a bug in the
	ssh-host-config script
In-Reply-To: <20081110132018.GA4378@calimero.vinschen.de>
References: <20081107105458.GO6478@calimero.vinschen.de>
	<8763mz61bh.fsf@squeak.fifthhorseman.net>
	<20081107181614.GB14614@discord.proulx.com>
	<20081110132018.GA4378@calimero.vinschen.de>
Message-ID: <20081127093147.GB9487@calimero.vinschen.de>

Ping?  Any chance somebody could apply the patch below?


Thanks,
Corinna

On Nov 10 14:20, Corinna Vinschen wrote:
> On Nov  7 11:16, Bob Proulx wrote:
> > Daniel Kahn Gillmor wrote:
> > >   ps -ef | grep -q '[s]shd'
> > [...]
> >   if [ -n "$(ps -e | awk '$NF=="sshd"')" ]
> > 
> > In summary to me using 'ps -e' seems more correct that using 'ps -ef'
> > and then filtering out the -f part of the output.
> 
> The difference between ps -e and ps -ef is not the same on Cygwin as on
> Linux.  The command strings are identical (full path) so the above awk
> expression doesn't work on Cygwin, besides the fact that it doesn't
> catch ssh processes, only sshd.
> 
> The final expression which is now used is this:
> 
>   if ps -ef | grep -q '/sshd\?$'
> 
> I pasted the entire patch again below.  Could somebody please check it in?
> 
> 
> Thanks,
> Corinna
> 
> 
> Index: contrib/cygwin/Makefile
> ===================================================================
> RCS file: /cvs/openssh/contrib/cygwin/Makefile,v
> retrieving revision 1.3
> diff -u -p -r1.3 Makefile
> --- contrib/cygwin/Makefile	14 Jul 2008 02:12:54 -0000	1.3
> +++ contrib/cygwin/Makefile	10 Nov 2008 13:11:53 -0000
> @@ -38,11 +38,13 @@ install-sshdoc:
>  	$(INSTALL) -m 644 $(srcdir)/ChangeLog $(DESTDIR)$(sshdocdir)/ChangeLog
>  	$(INSTALL) -m 644 $(srcdir)/LICENCE $(DESTDIR)$(sshdocdir)/LICENCE
>  	$(INSTALL) -m 644 $(srcdir)/OVERVIEW $(DESTDIR)$(sshdocdir)/OVERVIEW
> +	$(INSTALL) -m 644 $(srcdir)/PROTOCOL $(DESTDIR)$(sshdocdir)/PROTOCOL
> +	$(INSTALL) -m 644 $(srcdir)/PROTOCOL.agent $(DESTDIR)$(sshdocdir)/PROTOCOL.agent
>  	$(INSTALL) -m 644 $(srcdir)/README $(DESTDIR)$(sshdocdir)/README
>  	$(INSTALL) -m 644 $(srcdir)/README.dns $(DESTDIR)$(sshdocdir)/README.dns
> +	$(INSTALL) -m 644 $(srcdir)/README.platform $(DESTDIR)$(sshdocdir)/README.platform
>  	$(INSTALL) -m 644 $(srcdir)/README.privsep $(DESTDIR)$(sshdocdir)/README.privsep
>  	$(INSTALL) -m 644 $(srcdir)/README.smartcard $(DESTDIR)$(sshdocdir)/README.smartcard
> -	$(INSTALL) -m 644 $(srcdir)/RFC.nroff $(DESTDIR)$(sshdocdir)/RFC.nroff
>  	$(INSTALL) -m 644 $(srcdir)/TODO $(DESTDIR)$(sshdocdir)/TODO
>  	$(INSTALL) -m 644 $(srcdir)/WARNING.RNG $(DESTDIR)$(sshdocdir)/WARNING.RNG
>  
> Index: contrib/cygwin/ssh-host-config
> ===================================================================
> RCS file: /cvs/openssh/contrib/cygwin/ssh-host-config,v
> retrieving revision 1.22
> diff -u -p -r1.22 ssh-host-config
> --- contrib/cygwin/ssh-host-config	14 Jul 2008 02:12:54 -0000	1.22
> +++ contrib/cygwin/ssh-host-config	10 Nov 2008 13:11:53 -0000
> @@ -456,7 +456,7 @@ done
>  
>  # Check for running ssh/sshd processes first. Refuse to do anything while
>  # some ssh processes are still running
> -if ps -ef | grep -v grep | grep -q ssh
> +if ps -ef | grep -q '/sshd\?$'
>  then
>    echo
>    csih_error "There are still ssh processes running. Please shut them down first."
> 
> 
> -- 
> Corinna Vinschen
> Cygwin Project Co-Leader
> Red Hat
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

-- 
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat

From lutz at lutz-jaenicke.de  Fri Nov 28 09:11:44 2008
From: lutz at lutz-jaenicke.de (Lutz Jaenicke)
Date: Thu, 27 Nov 2008 23:11:44 +0100
Subject: OpenSSH security advisory: cbc.adv
In-Reply-To: <20081127083504.GA14085@folly>
References: <200811211019.mALAJ3Ms014517@cvs.openbsd.org>	<492E54E8.3090702@lutz-jaenicke.de>
	<20081127083504.GA14085@folly>
Message-ID: <492F1B20.6000501@lutz-jaenicke.de>

Markus Friedl wrote:
> On Thu, Nov 27, 2008 at 09:06:00AM +0100, Lutz Jaenicke wrote:
>   
>> I have been reading the documentation and had a look into the source
>> but finally did not manage to understand the selection method.
>> (For SSL it is the server that selects "based on the clients preferences"
>>     

Thanks.
So the modification proposed for the server's cipher config will influence
the ciphers supported but it will not affect the preference in the selection
process. The preference is controlled via the client's configuration
(at least with the current software version)!?

Best regards,
    Lutz

From markus.r.friedl at arcor.de  Fri Nov 28 19:23:05 2008
From: markus.r.friedl at arcor.de (Markus Friedl)
Date: Fri, 28 Nov 2008 09:23:05 +0100
Subject: OpenSSH security advisory: cbc.adv
In-Reply-To: <492F1B20.6000501@lutz-jaenicke.de>
References: <200811211019.mALAJ3Ms014517@cvs.openbsd.org>
	<492E54E8.3090702@lutz-jaenicke.de> <20081127083504.GA14085@folly>
	<492F1B20.6000501@lutz-jaenicke.de>
Message-ID: <20081128082304.GA13257@folly>

On Thu, Nov 27, 2008 at 11:11:44PM +0100, Lutz Jaenicke wrote:
> Markus Friedl wrote:
> >On Thu, Nov 27, 2008 at 09:06:00AM +0100, Lutz Jaenicke wrote:
> >  
> >>I have been reading the documentation and had a look into the source
> >>but finally did not manage to understand the selection method.
> >>(For SSL it is the server that selects "based on the clients preferences"
> >>    
> 
> Thanks.
> So the modification proposed for the server's cipher config will influence
> the ciphers supported but it will not affect the preference in the selection
> process. The preference is controlled via the client's configuration
> (at least with the current software version)!?

yes, the protocol works like this. the client chooses.
so you have to remove all CBC ciphers from the servers
config file.

-m

From vinschen at redhat.com  Fri Nov 28 20:51:21 2008
From: vinschen at redhat.com (Corinna Vinschen)
Date: Fri, 28 Nov 2008 10:51:21 +0100
Subject: openssh on interix
In-Reply-To: <Pine.LNX.4.62.0811230226340.26710@vmdebian.local.koeppe-net.de>
References: <Pine.LNX.4.62.0811052313150.32748@vmdebian.local.koeppe-net.de>
	<4918885D.30002@anl.gov>
	<Pine.LNX.4.62.0811102229460.26949@vmdebian.local.koeppe-net.de>
	<4919B821.6020301@anl.gov>
	<Pine.LNX.4.62.0811121112210.2745@vmdebian.local.koeppe-net.de>
	<Pine.LNX.4.62.0811230226340.26710@vmdebian.local.koeppe-net.de>
Message-ID: <20081128095120.GC12905@calimero.vinschen.de>

On Nov 23 02:39, Martin Koeppe wrote:
> On Wed, 12 Nov 2008, Martin Koeppe wrote:
> > Corinna Vinschen wrote:
> >> This is all the same problem Cygwin's port to OpenSSH has. However, on 
> >> Interix/SUA the user can store the password in the registry using the 
> >> `regpwd' tool.  I have no idea how the password is stored and how to access 
> >> it from privileged Interix processes, though.  
> >> [...]
> The regpwd stored passwords are stored in the same (Windows standard) 
> way as e.g. Dial-in passwords or service account passwords are stored, 
> i.e. under:
> 
> HKLM\Security\Policy\Secrets\

Thanks for the hint.  I'm embarrassed that I never before realized how
to use this functionality even though I read the LSA man pages a lot.

I now implemented this for Cygwin.  The next major version 1.7.0 will
come with a `passwd -R' option which is what `regpwd' does on Interix.

Cygwin's set(e)uid call now additionally tests for an existing encrypted
password in the above registry area and uses it if available.  The order
of authentication methods used in set(e)uid is now as follows (for those
interested in stuff like that):

  - Did the user logon with password and is the token available?

    -> use available token to switch user context

  - If not, did the user store the password in the aforementioned LSA 
    registry area?

    -> use that password to logon with password authentication under
       the hood and use resulting token if successful

  - If not, is the Cygwin-specifc LSA authentication package installed?

    -> Use Cygwin LSA authentication to create user token and use that
       token

  - If not, has the current privileged user the right to create
    handcrafted user tokens immediately?

    -> If yes, collect all user information and call NtCreateToken.
       Use that token to switch user context.

  - EPERM



Corinna

-- 
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat

From han at mijncomputer.nl  Sat Nov 29 08:30:15 2008
From: han at mijncomputer.nl (Han Boetes)
Date: Fri, 28 Nov 2008 22:30:15 +0100
Subject: feature request: single line mode.
Message-ID: <20081128213038.GY21385@boetes.org>

Hi,

I have this feature request for slow connections, I don't even
know if it is possible but here goes:

On slow connections making typos is very annoying because of low
latency. Could you add a feature which only sends complete lines,
like with an IRC client where nothing get's sent until you hit
return?

Or would this not be an ssh feature at all but rather a terminal
emulator feature?

Thanks in advance for thinking with me.


# Han

From dan at nf15.lightwave.net.ru  Sat Nov 29 10:00:25 2008
From: dan at nf15.lightwave.net.ru (Dan Yefimov)
Date: Sat, 29 Nov 2008 02:00:25 +0300
Subject: feature request: single line mode.
In-Reply-To: <20081128213038.GY21385@boetes.org>
References: <20081128213038.GY21385@boetes.org>
Message-ID: <49307809.50405@nf15.lightwave.net.ru>

On 29.11.2008 0:30, Han Boetes wrote:
> Hi,
>
> I have this feature request for slow connections, I don't even
> know if it is possible but here goes:
>
> On slow connections making typos is very annoying because of low
> latency. Could you add a feature which only sends complete lines,
> like with an IRC client where nothing get's sent until you hit
> return?
>
> Or would this not be an ssh feature at all but rather a terminal
> emulator feature?
>
This is in fact a terminal feature. The matter is that currently SSH switches a 
terminal to raw (unbuffered) mode (AFAIK). If SSH didn't do that, many 
full-screen programs (VIM, for example) would show an erratic behaviour.
-- 

Sincerely Your, Dan.

From dkg at fifthhorseman.net  Sat Nov 29 14:11:16 2008
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri, 28 Nov 2008 22:11:16 -0500
Subject: feature request: single line mode.
In-Reply-To: <20081128213038.GY21385@boetes.org> (Han Boetes's message of
	"Fri\, 28 Nov 2008 22\:30\:15 +0100")
References: <20081128213038.GY21385@boetes.org>
Message-ID: <87prkfusyz.fsf@squeak.fifthhorseman.net>

A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20081128/a07477ed/attachment.bin 

From bob at proulx.com  Sun Nov 30 15:31:11 2008
From: bob at proulx.com (Bob Proulx)
Date: Sat, 29 Nov 2008 22:31:11 -0600
Subject: feature request: single line mode.
In-Reply-To: <87prkfusyz.fsf@squeak.fifthhorseman.net>
References: <20081128213038.GY21385@boetes.org>
	<87prkfusyz.fsf@squeak.fifthhorseman.net>
Message-ID: <20081130043111.GA13906@discord.proulx.com>

Daniel Kahn Gillmor wrote:
> Han Boetes wrote:
> > On slow connections making typos is very annoying because of low
> > latency. Could you add a feature which only sends complete lines,
> > like with an IRC client where nothing get's sent until you hit
> > return?

The very first solution that I thought of when I read the question was
to use emacs.  There are various subprocess modes available such as
shell mode, ssh mode, terminal mode, that all run locally until the
full line is available and then sending the result to the subprocess.
But I don't expect this to be of comfort to you because if you were an
emacs person you would have already thought of it and if not then this
probably isn't going to turn you into one.  :-)

> You might be able to do this with something like rlwrap:
>  http://utopia.knoware.nl/~hlub/uck/rlwrap/man.html
> I haven't tried it though.

I thought that was an excellent suggestion and decided to actually try
it myself.  This worked pretty well for me.

  rlwrap -a ssh -t hostname.example.com sh -i

Do not expect programs such as screen editors (e.g. vi or emacs) to
function normally.  The local rlwrap process won't know to switch from
canonical mode to raw mode and will buffer input to the remote
commands until the newline.  You may need to type blind and then add
an extra enter to push the input through.

But of course this was the environment in which the classic ed was
developed and ed works very nicely.  :-)  If you are not going to use
ed or screen editor then it would be better to not use the ssh -t
option and not use a tty on the remote end.  Without a tty programs
will typically buffer all of their output until they exit.

  rlwrap -a ssh hostname.example.com sh -i

Fun!
Bob

From mkoeppe at gmx.de  Sun Nov 30 23:21:31 2008
From: mkoeppe at gmx.de (Martin Koeppe)
Date: Sun, 30 Nov 2008 13:21:31 +0100 (CET)
Subject: openssh on interix
In-Reply-To: 20081128095120.GC12905@calimero.vinschen.de
References: 20081128095120.GC12905@calimero.vinschen.de
Message-ID: <Pine.LNX.4.62.0811301258010.7002@vmdebian.local.koeppe-net.de>


On 2008-11-28, Corinna Vinschen wrote:
> On Nov 23 02:39, Martin Koeppe wrote:
>> On Wed, 12 Nov 2008, Martin Koeppe wrote:
>>> Corinna Vinschen wrote:
>>>> This is all the same problem Cygwin's port to OpenSSH has. 
>>>> However, on Interix/SUA the user can store the password in the 
>>>> registry using the `regpwd' tool.  I have no idea how the 
>>>> password is stored and how to access it from privileged Interix 
>>>> processes, though. [...]
>> The regpwd stored passwords are stored in the same (Windows 
>> standard) way as e.g. Dial-in passwords or service account 
>> passwords are stored, i.e. under:
>>
>> HKLM\Security\Policy\Secrets\
>
> Thanks for the hint.  I'm embarrassed that I never before realized 
> how to use this functionality even though I read the LSA man pages a 
> lot.
>
> I now implemented this for Cygwin.  The next major version 1.7.0 will
> come with a `passwd -R' option which is what `regpwd' does on Interix.

Will `passwd -R' and `regpwd' be comnpatible, i.e. store the password 
unter the same reg value, so that I could use `passwd -R' on cygwin to 
store the password and then use it from interix daemons or vice versa?

regpwd uses this format:
HKLM\Security\Policy\Secrets\DOMAIN_USERNAME_microsoft_sfu_utility
where DOMAIN is the PC name (=local domain) or the NETBIOS domain 
name.
The password itself is converted to Unicode (UCS-2LE) before being 
stored.

If cygwin used this format, too, users had to maintain only one entry.

Martin


> Cygwin's set(e)uid call now additionally tests for an existing encrypted
> password in the above registry area and uses it if available.  The order
> of authentication methods used in set(e)uid is now as follows (for those
> interested in stuff like that):
>
>  - Did the user logon with password and is the token available?
>
>    -> use available token to switch user context
>
>  - If not, did the user store the password in the aforementioned LSA
>    registry area?
>
>    -> use that password to logon with password authentication under
>       the hood and use resulting token if successful
>
>  - If not, is the Cygwin-specifc LSA authentication package installed?
>
>    -> Use Cygwin LSA authentication to create user token and use that
>       token
>
>  - If not, has the current privileged user the right to create
>    handcrafted user tokens immediately?
>
>    -> If yes, collect all user information and call NtCreateToken.
>       Use that token to switch user context.
>
>  - EPERM
>
>
>
> Corinna