(unknown)

Hello,

I've noticed that ssh always opens /etc/passwd
on my Linux box before parsing command line options, and so the file is
opened even if the user is afterward presented with the usage and the
program ends.
So, this snippet in OpenSSH-4.2p1,
ssh.c: 219
  /* Get user data. */
  pw = getpwuid(original_real_uid);
  if (!pw) {
    logit("You don't exist, go away!");
    exit(1);
  }
  /* Take a copy of the returned structure. */
  pw = pwcopy(pw);

should probably be moved after options scanning, for example at
ssh: 515, after:
  /* Check that we got a host name. */
  if (!host)
    usage();

I tested this and nothing seems to be broken by it. I can submit a patch
if it is wanted.

Cornel

PKCS#11 support for openssh

Hello OpenSSH developers,

A week ago I've posted a patch that enables openssh to work 
with PKCS#11 tokens.

I didn't receive any comments regarding the patch or reply 
to my questions.

In current software world, providing a security product that 
does not support standard interface for external 
cryptographic hardware makes the product obsolete.

Please comment my patch, so I can know how to proceed.

Best Regards,
Alon Bar-Lev.

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev <at> mindrot.org
http://www.mindrot.org/mailman/listinfo/openssh-unix-dev

Re: PKCS#11 support for openssh

On Tue, 1 Nov 2005, Alon Bar-Lev wrote:

> Hello OpenSSH developers,
>
> A week ago I've posted a patch that enables openssh to work with PKCS#11 
> tokens.
>
> I didn't receive any comments regarding the patch or reply to my questions.
>
> In current software world, providing a security product that does not support 
> standard interface for external cryptographic hardware makes the product 
> obsolete.
>
> Please comment my patch, so I can know how to proceed.

I am busy at the moment, hopefully I will have time to look at it properly 
next week. Looking at it briefly, I was concerned about the assumption of 
X.509 support - we have no intention of including x.509 at present.

-d

Re: your mail

Why change this?

On Wed, 2 Nov 2005, Cornel Izbasa wrote:

> Hello,
>
> I've noticed that ssh always opens /etc/passwd
> on my Linux box before parsing command line options, and so the file is
> opened even if the user is afterward presented with the usage and the
> program ends.
> So, this snippet in OpenSSH-4.2p1,
> ssh.c: 219
>  /* Get user data. */
>  pw = getpwuid(original_real_uid);
>  if (!pw) {
>    logit("You don't exist, go away!");
>    exit(1);
>  }
>  /* Take a copy of the returned structure. */
>  pw = pwcopy(pw);
>
> should probably be moved after options scanning, for example at
> ssh: 515, after:
>  /* Check that we got a host name. */
>  if (!host)
>    usage();
>
> I tested this and nothing seems to be broken by it. I can submit a patch
> if it is wanted.
>

Re: your mail

> Why change this?

For optimization and clarity, since read_data_file() is done uselessly in
some cases because the program just prints out usage and ends.

-- current
read_data_file()
if(!sanity_check_that_doesn_t_need_the_data())
	exit()
use_data()

as opposed to

++ proposed
if(!sanity_check())
	exit()
read_data_file()
use_data()

>
> On Wed, 2 Nov 2005, Cornel Izbasa wrote:
>
> > Hello,
> >
> > I've noticed that ssh always opens /etc/passwd
> > on my Linux box before parsing command line options, and so the file is
> > opened even if the user is afterward presented with the usage and the
> > program ends.
> > So, this snippet in OpenSSH-4.2p1,
> > ssh.c: 219

Re: sftp/scp hangs at connection, but ssh is OK

On 2005-10-30 16:46:11 +0100, Martin Schröder wrote:
> I've read the FAQ and googled, but I'm still stymied:
> ssh localhost works, but scp and sftp both hang.
> 
> ssh is OpenSSH_4.2p1, OpenSSL 0.9.6c [engine] 21 dec 2001
> 
> The last lines of an "scp -4 -vvv .bashrc localhost:/tmp/" are:
> ----------------------------------
> debug2: mac_init: found hmac-ripemd160
> debug1: kex: server->client aes128-cbc hmac-ripemd160 zlib <at> openssh.com
> debug2: mac_init: found hmac-ripemd160
> debug1: kex: client->server aes128-cbc hmac-ripemd160 zlib <at> openssh.com
> debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<2048<8192) sent
> debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
> debug2: dh_gen_key: priv key bits set: 152/320
> debug2: bits set: 1606/3191
> debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
> debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
> debug3: check_host_in_hostfile: filename /home/ms/.ssh/known_hosts
> debug3: key_read: type mismatch
> debug3: check_host_in_hostfile: match line 15
> debug1: Host 'localhost' is known and matches the RSA host key.
> debug1: Found key in /home/ms/.ssh/known_hosts:15
> debug2: bits set: 1587/3191
> 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

Re: PKCS#11 support for openssh

Damien Miller wrote:
> On Tue, 1 Nov 2005, Alon Bar-Lev wrote:
> 
> I am busy at the moment, hopefully I will have time to look at it 
> properly next week. Looking at it briefly, I was concerned about the 
> assumption of X.509 support - we have no intention of including x.509 at 
> present.
> 
> -d
> 

Thanks!
It is good to know that it is somewhere in the queue...

I want to explain why I think that X.509 is related to 
smartcard support... And then I will wait until you have 
some free time... :)

But first, I must say that I don't want to offend anyone... 
and I am sorry if you already know that, or you think I am 
talking none-sense.

I think your current approach is good for small systems or 
individuals... But it does not scale. And worse When your 
standard interface is raw keys on files, you create a false 
sense of security, since you have a record of a security 
product... And most people do not know better.

Let's say that the user knows that his key was stolen, now 
he has to create a list of every system that trusted his 

Question about GSSAPI with OpenSSH 4.2p1

Hey all, perhaps someone might be able to shed a little light on this
problem.  Nothing I find in books and groups seem to address the
problem.  I'm trying to set up a series of connections with ssh that
authenticate through GSSAPI.  However, it seems that the credentials are
not getting passed.

>From the client..

debug1: Next authentication method: gssapi-with-mic
debug2: we sent a gssapi-with-mic packet, wait for reply
debug1: Delegating credentials
debug1: Delegating credentials
debug1: Authentications that can continue:
publickey,gssapi-with-mic,password,keyboard-interactive

So we can see that the client is configured to send the tickets
across...

>From the Server...

debug1: userauth-request for user <user>/<domain> service ssh-connection
method gssapi-with-mic
debug1: attempt 1 failures 1
debug2: input_userauth_request: try method gssapi-with-mic
Postponed gssapi-with-mic for <user>/<domain> from xxxx port x ssh2
debug1: Got no client credentials
Failed gssapi-with-mic for <user>/<domain> from xxxxx port x ssh2
debug1: userauth-request for user <user>/<domain> service ssh-connection
method keyboard-interactive

openssh vulnerability WITH TCP DUMP!

Hi Guys,

My Debian box has been hacked a few days ago using an OpenSSH 
vulnerability. Subsequently my box was used for sending spam and as a 
hacking platform (according to my ISP).

I was running a fairly recent version of OpenSSH (3.9p1). I reinstalled 
my box (now with 3.8p1 as supplied by Debian Stable), and started 
tcpdump to see if I would get lucky. I DID!

The aut.log file shows the following:
Nov  4 06:25:01 localhost su[5715]: + ??? root:nobody
Nov  4 06:25:01 localhost su[5715]: (pam_unix) session opened for user 
nobody by
 (uid=0)

In the auth.log from my hacked box, I also had these lines. However, I 
could not correlate them to TCP messages, so they didn't help me. Now, I 
do have a full tcp dump 

In the dump file, I found three simple messages that did the job:

First: A SYN request to the ssh port

0000  00 01 80 57 16 3d 00 90  d0 af 86 eb 08 00 45 00   ...W.=.. ......E.
0010  00 30 3c 2d 00 00 74 06  1b fd d2 f0 11 2c 0a 00   .0<-..t. .....,..
0020  00 82 d6 d3 00 16 7e c1  e4 5f 75 72 0c 80 70 02   ......~. ._ur..p.
0030  ff ff d8 83 00 00 02 04  05 b4 01 01 04 02         ........ ...... 

Next the reply from my box (SYN ACK):

Re: openssh vulnerability WITH TCP DUMP!

On Fri, 04 Nov 2005 11:54:14 +0100
Evert van de Waal <evert.vandewaal <at> imtech.nl> wrote:

> Hi Guys,
> 
> My Debian box has been hacked a few days ago using an OpenSSH 
> vulnerability. Subsequently my box was used for sending spam and as a 
> hacking platform (according to my ISP).

How do you know it was an OpenSSH vulnerability? You have provided no
evidence for this theory, indeed quite the opposite.

> The aut.log file shows the following:
> Nov  4 06:25:01 localhost su[5715]: + ??? root:nobody
> Nov  4 06:25:01 localhost su[5715]: (pam_unix) session opened for user 
> nobody by
>  (uid=0)

OpenSSH doesn't use uid nobody for anything. So, unless you had a bad
password set for your nobody account or you broke your PAM
configuration in some way, it probably wasn't OpenSSH that was used to
break in to your system. Since you didn't actually post any logs of a
break-in (just a later privilege escalation), it is impossible to tell.

> In the auth.log from my hacked box, I also had these lines. However, I 
> could not correlate them to TCP messages, so they didn't help me. Now, I 
> do have a full tcp dump 

What you posted isn't a tcpdump, it is just a hex packet dump. Have
you gone out of your way to make it hard to read your packet trace? Even