From peter at stuge.se  Sun Jan  1 02:23:06 2012
From: peter at stuge.se (Peter Stuge)
Date: Sat, 31 Dec 2011 16:23:06 +0100
Subject: A probable useful feature
In-Reply-To: <CAA7iwgVeUJJLU-R-C_8xqNbFi=NNi2ux0R5t3GU81ztViD9icw@mail.gmail.com>
References: <CAA7iwgVeUJJLU-R-C_8xqNbFi=NNi2ux0R5t3GU81ztViD9icw@mail.gmail.com>
Message-ID: <20111231152306.15272.qmail@stuge.se>

Vahab Shalchian wrote:
> Some monitoring softwares like Manage Engine Application Manager use a
> monitoring user which logins to a servers every 5 minutes via SSH so
> sometimes we need to be able to exclude this user from being recorded to
> wtmp,utmp files.

I think you should filter this away when reading those files instead.

As an alternative, perhaps you can configure the user to not be
allowed to allocate a pty, in which case you may not get as much
records of the login in *tmp.


//Peter

From nkadel at gmail.com  Sun Jan  1 07:52:42 2012
From: nkadel at gmail.com (Nico Kadel-Garcia)
Date: Sat, 31 Dec 2011 15:52:42 -0500
Subject: A probable useful feature
In-Reply-To: <20111231152306.15272.qmail@stuge.se>
References: <CAA7iwgVeUJJLU-R-C_8xqNbFi=NNi2ux0R5t3GU81ztViD9icw@mail.gmail.com>
 <20111231152306.15272.qmail@stuge.se>
Message-ID: <CAOCN9rxoD_Fvoxph3J7_bpUofbhfmj3QORN_+PeBT4UHWUTqFw@mail.gmail.com>

On Sat, Dec 31, 2011 at 10:23 AM, Peter Stuge <peter at stuge.se> wrote:
> Vahab Shalchian wrote:
>> Some monitoring softwares like Manage Engine Application Manager use a
>> monitoring user which logins to a servers every 5 minutes via SSH so
>> sometimes we need to be able to exclude this user from being recorded to
>> wtmp,utmp files.
>
> I think you should filter this away when reading those files instead.
>
> As an alternative, perhaps you can configure the user to not be
> allowed to allocate a pty, in which case you may not get as much
> records of the login in *tmp.

Configuring SSH for remote monitoring access is CPU intensive on both
ends, and carries significant network overhead. This is inherent in a
highly secure protocol with lots of flexibility.

If you don't need the flexibility, you might instead prefer SNMP
properly configured or NRPE, both of which rely on locally running
daemons and thus do not create a new login event such as you are
seeing.

From kevin.brott at gmail.com  Tue Jan  3 12:26:01 2012
From: kevin.brott at gmail.com (Kevin Brott)
Date: Mon, 2 Jan 2012 17:26:01 -0800
Subject: A probable useful feature
In-Reply-To: <CAA7iwgVeUJJLU-R-C_8xqNbFi=NNi2ux0R5t3GU81ztViD9icw@mail.gmail.com>
References: <CAA7iwgVeUJJLU-R-C_8xqNbFi=NNi2ux0R5t3GU81ztViD9icw@mail.gmail.com>
Message-ID: <CAMv58ratrpn2-wv3eDgXBy5U4j=zyokUOuUdA+b-qagp0W8yBQ@mail.gmail.com>

On Sat, Dec 31, 2011 at 01:40, Vahab Shalchian <v.shalchian at gmail.com>wrote:

> Hi,
>
> As I mentioned in the following post :
>
>
> http://www.linuxquestions.org/questions/linux-security-4/exclude-a-from-being-logged-in-var-log-wtmp-920865/
>
> Some monitoring softwares like Manage Engine Application Manager use a
> monitoring user which logins to a servers every 5 minutes via SSH so
> sometimes we need to be able to exclude this user from being recorded to
> wtmp,utmp files.
>
> Is it possible to include this feature in the next releases of SSH.
>
> Many thanks.
> Vahab Shalchian
>

Consider opening an initial connection to each server monitored at the
start of the day/monitoring-cycle using connection mastering - run all your
subsequent connections against the connection master and ?tmp files will
only log the initial connection.  Of course this means the monitoring
system will have a proportional number of open connections/sockets
constantly - so in Very Large Enterprise settings - this 'might not scale
well'.  In smaller deployments the overhead is negligible.  YMMV.

-- 
# include <stddisclaimer.h>
/* Kevin  Brott <Kevin.Brott at gmail.com> */

From matthew at royhousehold.net  Wed Jan  4 11:56:52 2012
From: matthew at royhousehold.net (Matthew Roy)
Date: Tue, 3 Jan 2012 19:56:52 -0500
Subject: ECDSA, SSHFP, and "Error calculating host key fingerprint."
Message-ID: <CAGG2-sBbwEV_YH=VJpJsSA6xD2UaKgktEJnQ0QK2kGkPvWCsgg@mail.gmail.com>

When connecting to a host that provides an ECDSA host key and the
client has "VerifyHostKeyDNS" set to 'yes' or 'ask' SSH outputs a
mysterious and undocumented message "Error calculating host key
fingerprint." This error actually seems to be generated by
verify_host_key_dns(const char *hostname, struct sockaddr *address,
Key *hostkey, int *flags) in dns.c, but neither that fact nor the
reason for the error is mentioned in the manual. Is it possible to
refine the error message so it is more clear what's going on or to
punt and note it in the man pages?

This may become a moot issue when the currently proposed update to RFC
4255[1] gets approved and ECDSA SSHFP records are supported, but for
now it seems like something should provide the user a better
explanation of what's going on and assurance that all is in fact well.

Matthew Roy


[1] https://datatracker.ietf.org/doc/draft-os-ietf-sshfp-ecdsa-sha2/

From naddy at mips.inka.de  Thu Jan  5 08:59:08 2012
From: naddy at mips.inka.de (Christian Weisgerber)
Date: Wed, 4 Jan 2012 21:59:08 +0000 (UTC)
Subject: Interop problem with IPSSH-6.6.0, CR/NL?
Message-ID: <je2i3c$b3r$1@lorvorc.mips.inka.de>

I have a curious problem connecting with OpenSSH (5.1p1 on FreeBSD,
6.0-beta on OpenBSD) to some managed switches running "IPSSH-6.6.0".

When I connect to the switch with the SSH2 protocol, I can't use
the switch's CLI, because I can't terminate a command line.  I press
<Enter> and nothing happens.  Same for ^M (CR) and ^J (NL).

When I connect to the switch with SSH1 (or by Telnet or the serial
console port), this doesn't happen.  <Enter> aka ^M successfully
terminates a line.  Interestingly, ^J is ignored.

I *suspect* that for a SSH2 connection, CR is somewhere mapped to
NL, along the lines of the ICRNL termios setting, and NL is then
ignored by the switch.  I don't know if the problem lies with OpenSSH
or the switch--you wouldn't notice this when connecting to a Unix
host.

-- 
Christian "naddy" Weisgerber                          naddy at mips.inka.de

From peter at stuge.se  Thu Jan  5 10:01:02 2012
From: peter at stuge.se (Peter Stuge)
Date: Thu, 5 Jan 2012 00:01:02 +0100
Subject: Interop problem with IPSSH-6.6.0, CR/NL?
In-Reply-To: <je2i3c$b3r$1@lorvorc.mips.inka.de>
References: <je2i3c$b3r$1@lorvorc.mips.inka.de>
Message-ID: <20120104230102.25494.qmail@stuge.se>

Christian Weisgerber wrote:
> I have a curious problem connecting with OpenSSH (5.1p1 on FreeBSD,
> 6.0-beta on OpenBSD) to some managed switches running "IPSSH-6.6.0".

Are you working on the console of FreeBSD and OpenBSD machines?


> I *suspect* that for a SSH2 connection, CR is somewhere mapped to
> NL, along the lines of the ICRNL termios setting, and NL is then
> ignored by the switch.  I don't know if the problem lies with OpenSSH
> or the switch--you wouldn't notice this when connecting to a Unix
> host.

Neither client nor server should be doing any translation. Maybe it's
a terminal problem. Suggest trying with various different client
terminals, on more operating systems.


//Peter

From djm at mindrot.org  Fri Jan  6 06:24:05 2012
From: djm at mindrot.org (Damien Miller)
Date: Fri, 6 Jan 2012 06:24:05 +1100 (EST)
Subject: Interop problem with IPSSH-6.6.0, CR/NL?
In-Reply-To: <je2i3c$b3r$1@lorvorc.mips.inka.de>
References: <je2i3c$b3r$1@lorvorc.mips.inka.de>
Message-ID: <alpine.BSO.2.00.1201060623420.13971@natsu.mindrot.org>

On Wed, 4 Jan 2012, Christian Weisgerber wrote:

> I have a curious problem connecting with OpenSSH (5.1p1 on FreeBSD,
> 6.0-beta on OpenBSD) to some managed switches running "IPSSH-6.6.0".
> 
> When I connect to the switch with the SSH2 protocol, I can't use
> the switch's CLI, because I can't terminate a command line.  I press
> <Enter> and nothing happens.  Same for ^M (CR) and ^J (NL).
> 
> When I connect to the switch with SSH1 (or by Telnet or the serial
> console port), this doesn't happen.  <Enter> aka ^M successfully
> terminates a line.  Interestingly, ^J is ignored.
> 
> I *suspect* that for a SSH2 connection, CR is somewhere mapped to
> NL, along the lines of the ICRNL termios setting, and NL is then
> ignored by the switch.  I don't know if the problem lies with OpenSSH
> or the switch--you wouldn't notice this when connecting to a Unix
> host.

Could you send a "ssh -vvv" output?

-d

From naddy at mips.inka.de  Fri Jan  6 07:25:19 2012
From: naddy at mips.inka.de (Christian Weisgerber)
Date: Thu, 5 Jan 2012 21:25:19 +0100
Subject: Interop problem with IPSSH-6.6.0, CR/NL?
In-Reply-To: <alpine.BSO.2.00.1201060623420.13971@natsu.mindrot.org>
References: <je2i3c$b3r$1@lorvorc.mips.inka.de>
 <alpine.BSO.2.00.1201060623420.13971@natsu.mindrot.org>
Message-ID: <20120105202519.GA27189@lorvorc.mips.inka.de>

Damien Miller:

> Could you send a "ssh -vvv" output?

$ ssh -vvv admin at sw2
OpenSSH_6.0-beta, OpenSSL 1.0.0e 6 Sep 2011
debug1: Reading configuration data /home/naddy/.ssh/config
debug1: /home/naddy/.ssh/config line 28: Applying options for *
debug2: mac_setup: found umac-64 at openssh.com
debug3: mac ok: umac-64 at openssh.com [umac-64 at openssh.com,hmac-md5,hmac-sha1,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160]
debug2: mac_setup: found hmac-md5
debug3: mac ok: hmac-md5 [umac-64 at openssh.com,hmac-md5,hmac-sha1,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160]
debug2: mac_setup: found hmac-sha1
debug3: mac ok: hmac-sha1 [umac-64 at openssh.com,hmac-md5,hmac-sha1,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160]
debug2: mac_setup: found hmac-sha2-256
debug3: mac ok: hmac-sha2-256 [umac-64 at openssh.com,hmac-md5,hmac-sha1,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160]
debug2: mac_setup: found hmac-sha2-512
debug3: mac ok: hmac-sha2-512 [umac-64 at openssh.com,hmac-md5,hmac-sha1,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160]
debug2: mac_setup: found hmac-ripemd160
debug3: mac ok: hmac-ripemd160 [umac-64 at openssh.com,hmac-md5,hmac-sha1,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160]
debug3: macs ok: [umac-64 at openssh.com,hmac-md5,hmac-sha1,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160]
debug1: Reading configuration data /etc/ssh/ssh_config
debug2: ssh_connect: needpriv 0
debug1: Connecting to sw2 [172.16.0.252] port 22.
debug1: Connection established.
debug1: identity file /home/naddy/.ssh/id_rsa type -1
debug1: identity file /home/naddy/.ssh/id_rsa-cert type -1
debug1: identity file /home/naddy/.ssh/id_dsa type -1
debug1: identity file /home/naddy/.ssh/id_dsa-cert type -1
debug1: identity file /home/naddy/.ssh/id_ecdsa type -1
debug1: identity file /home/naddy/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 1.99, remote software version IPSSH-6.6.0
debug1: no match: IPSSH-6.6.0
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.0-beta
debug2: fd 3 setting O_NONBLOCK
debug3: load_hostkeys: loading entries for host "sw2" from file "/home/naddy/.ssh/known_hosts"
debug3: load_hostkeys: found key type DSA in file /home/naddy/.ssh/known_hosts:12
debug3: load_hostkeys: loaded 1 keys
debug3: order_hostkeyalgs: prefer hostkeyalgs: ssh-dss-cert-v01 at openssh.com,ssh-dss-cert-v00 at openssh.com,ssh-dss
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-dss-cert-v01 at openssh.com,ssh-dss-cert-v00 at openssh.com,ssh-dss,ecdsa-sha2-nistp256-cert-v01 at openssh.com,ecdsa-sha2-nistp384-cert-v01 at openssh.com,ecdsa-sha2-nistp521-cert-v01 at openssh.com,ssh-rsa-cert-v01 at openssh.com,ssh-rsa-cert-v00 at openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-rsa
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at lysator.liu.se
debug2: kex_parse_kexinit: umac-64 at openssh.com,hmac-md5,hmac-sha1,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160
debug2: kex_parse_kexinit: umac-64 at openssh.com,hmac-md5,hmac-sha1,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160
debug2: kex_parse_kexinit: none,zlib at openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib at openssh.com,zlib
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: kex_parse_kexinit: diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc,des-cbc,des-cbc,arcfour
debug2: kex_parse_kexinit: aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc,des-cbc,des-cbc,arcfour
debug2: kex_parse_kexinit: hmac-sha1,hmac-sha1-96,hmac-md5,hmac-md5-96
debug2: kex_parse_kexinit: hmac-sha1,hmac-sha1-96,hmac-md5,hmac-md5-96
debug2: kex_parse_kexinit: none
debug2: kex_parse_kexinit: none
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: mac_setup: found hmac-md5
debug1: kex: server->client aes128-cbc hmac-md5 none
debug2: mac_setup: found hmac-md5
debug1: kex: client->server aes128-cbc hmac-md5 none
debug2: dh_gen_key: priv key bits set: 139/256
debug2: bits set: 515/1024
debug1: sending SSH2_MSG_KEXDH_INIT
debug1: expecting SSH2_MSG_KEXDH_REPLY
debug1: Server host key: DSA 6e:3c:a1:10:ab:02:7f:73:d8:aa:7e:40:d0:51:6e:f8
debug3: load_hostkeys: loading entries for host "sw2" from file "/home/naddy/.ssh/known_hosts"
debug3: load_hostkeys: found key type DSA in file /home/naddy/.ssh/known_hosts:12
debug3: load_hostkeys: loaded 1 keys
debug3: load_hostkeys: loading entries for host "172.16.0.252" from file "/home/naddy/.ssh/known_hosts"
debug3: load_hostkeys: found key type DSA in file /home/naddy/.ssh/known_hosts:12
debug3: load_hostkeys: loaded 1 keys
debug1: Host 'sw2' is known and matches the DSA host key.
debug1: Found key in /home/naddy/.ssh/known_hosts:12
debug2: bits set: 495/1024
debug1: ssh_dss_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/naddy/.ssh/id_rsa (0x2018a3780)
debug2: key: .ssh/id_openbsd (0x2018a2e40)
debug2: key: .ssh/id_freebsd (0x2018a2280)
debug2: key: /home/naddy/.ssh/id_rsa (0x0)
debug2: key: /home/naddy/.ssh/id_dsa (0x0)
debug2: key: /home/naddy/.ssh/id_ecdsa (0x0)
Authenticated with partial success.
debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/naddy/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug1: Offering RSA public key: .ssh/id_openbsd
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug1: Offering DSA public key: .ssh/id_freebsd
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/naddy/.ssh/id_rsa
debug3: no such identity: /home/naddy/.ssh/id_rsa
debug1: Trying private key: /home/naddy/.ssh/id_dsa
debug3: no such identity: /home/naddy/.ssh/id_dsa
debug1: Trying private key: /home/naddy/.ssh/id_ecdsa
debug3: no such identity: /home/naddy/.ssh/id_ecdsa
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
admin at sw2's password: 
debug3: packet_send2: adding 64 (len 57 padlen 7 extra_pad 64)
debug2: we sent a password packet, wait for reply
debug1: Authentication succeeded (password).
Authenticated to sw2 ([172.16.0.252]:22).
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug1: Entering interactive session.
debug2: callback start
debug2: client_session2_setup: id 0
debug2: fd 3 setting TCP_NODELAY
debug3: packet_set_tos: set IP_TOS 0x10
debug2: channel 0: request pty-req confirm 1
debug2: channel 0: request shell confirm 1
debug2: callback done
debug2: channel 0: open confirm rwindow 65536 rmax 32768
debug2: channel_input_status_confirm: type 99 id 0
debug2: PTY allocation request accepted on channel 0
debug2: channel_input_status_confirm: type 99 id 0
debug2: shell request accepted on channel 0

TP-LINK>

-- 
Christian "naddy" Weisgerber                          naddy at mips.inka.de

From djm at mindrot.org  Fri Jan  6 11:35:22 2012
From: djm at mindrot.org (Damien Miller)
Date: Fri, 6 Jan 2012 11:35:22 +1100 (EST)
Subject: Interop problem with IPSSH-6.6.0, CR/NL?
In-Reply-To: <20120105202519.GA27189@lorvorc.mips.inka.de>
References: <je2i3c$b3r$1@lorvorc.mips.inka.de>
 <alpine.BSO.2.00.1201060623420.13971@natsu.mindrot.org>
 <20120105202519.GA27189@lorvorc.mips.inka.de>
Message-ID: <alpine.BSO.2.00.1201061131170.13971@natsu.mindrot.org>

On Thu, 5 Jan 2012, Christian Weisgerber wrote:

> Damien Miller:
> 
> > Could you send a "ssh -vvv" output?
> 
> $ ssh -vvv admin at sw2
...
> debug2: channel 0: request pty-req confirm 1
...
> debug2: PTY allocation request accepted on channel 0

So, this isn't like the Netscreen PTY bugs that we discussed here a couple
of months ago. My guess is that your switch is choking on something, but
it is impossible to tell what.

I'd suggest that you try fiddling with ttymodes.h and prune it to the
minimum set of modes that you can. If that works, then you can binary
search to see what is causing the far end to choke.

Do you have any idea what the last version of OpenSSH to interop correctly
with these devices was? Or has it always been broken? :)

-d

From naddy at mips.inka.de  Sat Jan  7 02:40:25 2012
From: naddy at mips.inka.de (Christian Weisgerber)
Date: Fri, 6 Jan 2012 16:40:25 +0100
Subject: Interop problem with IPSSH-6.6.0, CR/NL?
In-Reply-To: <alpine.BSO.2.00.1201061131170.13971@natsu.mindrot.org>
References: <je2i3c$b3r$1@lorvorc.mips.inka.de>
 <alpine.BSO.2.00.1201060623420.13971@natsu.mindrot.org>
 <20120105202519.GA27189@lorvorc.mips.inka.de>
 <alpine.BSO.2.00.1201061131170.13971@natsu.mindrot.org>
Message-ID: <20120106154025.GA29490@lorvorc.mips.inka.de>

Damien Miller:

> I'd suggest that you try fiddling with ttymodes.h and prune it to the
> minimum set of modes that you can.

It turns out to be... *drum roll*... ICRNL.

Unix TTYs default to ICRNL on, ssh correctly forwards this, and the
PTY code in the switch apparently honors it, mapping CR to NL.  Too
bad the CLI code then just ignores NL.  Why this only happens with
SSH2 but not the SSH1 protocol is a mystery.

A simple "stty -icrnl" before ssh'ing to the switch works around
the problem.

> Do you have any idea what the last version of OpenSSH to interop correctly
> with these devices was? Or has it always been broken? :)

These are TP-Link JetStream switches.  They've only been available
for half a year, and I've had them only for a week. ;-)

-- 
Christian "naddy" Weisgerber                          naddy at mips.inka.de

From bg at sics.se  Wed Jan 11 02:34:20 2012
From: bg at sics.se (=?iso-8859-1?Q?Bj=F6rn_Gr=F6nvall?=)
Date: Tue, 10 Jan 2012 16:34:20 +0100
Subject: Configuration file TCPKeepAlive option does not work reliably
Message-ID: <F99478C7-F975-40E0-84D8-AB001D332BE6@sics.se>

Hi!

There are configuration knobs (TCPKeepAlive) to enable/disable the use of TCP keepalives both in the ssh client and server. Unfortunately some UNIX systems default to SO_KEEPALIVE=on and some to =off. This may even be settable on a per host basis (OpenBSD default net.inet.tcp.always_keepalive=1 ???).

For the TCPKeepAlive configuration knob I would like to propose changes along the lines showed in the attached patch (there is perhaps more elegant ways to do this). The patch will always set SO_KEEPALIVE according to the ssh configuration files regardless of the local UNIX TCP defaults.

If there are questions or comments I'm available on this email address bg at sics.se (I'm not on any ssh email list).

Cheers,
/b


-------------- next part --------------



From bg at sics.se  Wed Jan 11 21:15:30 2012
From: bg at sics.se (=?iso-8859-1?Q?Bj=F6rn_Gr=F6nvall?=)
Date: Wed, 11 Jan 2012 11:15:30 +0100
Subject: Configuration file TCPKeepAlive option does not work reliably
In-Reply-To: <F99478C7-F975-40E0-84D8-AB001D332BE6@sics.se>
References: <F99478C7-F975-40E0-84D8-AB001D332BE6@sics.se>
Message-ID: <FE7B7336-EF1B-41E8-8053-6E752365C7DA@sics.se>

On request from John Hawkinson I'm reposting this with additional information and not relying on attachments.

Hi!

There are configuration knobs (TCPKeepAlive) to enable/disable the use of TCP keepalives both in the ssh client and server. Unfortunately some UNIX systems default to SO_KEEPALIVE=on and some to =off. This may even be settable on a per host basis (OpenBSD default net.inet.tcp.always_keepalive=1 ???).

For the TCPKeepAlive configuration knob I would like to propose changes along the lines showed in the attached patch (there is perhaps more elegant ways to do this). The patch will always set SO_KEEPALIVE according to the ssh configuration files regardless of the local UNIX TCP defaults.

If there are questions or comments I'm available on this email address bg at sics.se (I'm not on any ssh email list).

Additional information comes here:

> You don't explain *why* you propose this change.

I am a mobile user and at all times have a ssh login on a particular machine, TCP keepalives drops the TCP connection if my laptop is not connected for some 2h.

Therefore, in the server /etc/ssh/sshd_config I have (amongst other things):

TCPKeepAlive no
ClientAliveInterval 90000

This turns off TCP keepalives and enables a ClientAlive probe after 25h of inactivity.

Unfortunately the code implicitly ASSUMES that all systems default to SO_KEEPALIVE=off which is not true. E.g Free and OpenBSD has sysctls net.inet.tcp.always_keepalive that defaults to SO_KEEPALIVE=on. If I write 'TCPKeepAlive no' in a configuration file SO_KEEPALIVE will not be changed to off because the relevant call to setsockopt will never happen. The code is written to change  SO_KEEPALIVE to on, never to change SO_KEEPALIVE to off.

> (Your patch is also missing.)

Guess the MTA removed attachments :-(, anyways I paste the diff inline but that may make whitespace changes and that's why I always attach patches (I also try it as an attachment again).

--- sshconnect.c~       2011-11-30 13:47:36.000000000 +0100
+++ sshconnect.c        2012-01-06 18:21:50.138571927 +0100
@@ -431,10 +431,11 @@
       debug("Connection established.");

       /* Set SO_KEEPALIVE if requested. */
-       if (want_keepalive &&
-           setsockopt(sock, SOL_SOCKET, SO_KEEPALIVE, (void *)&on,
+       on = want_keepalive ? 1 : 0;
+       if (setsockopt(sock, SOL_SOCKET, SO_KEEPALIVE, (void *)&on,
           sizeof(on)) < 0)
               error("setsockopt SO_KEEPALIVE: %.100s", strerror(errno));
+       on = 1;

       /* Set the connection. */
       packet_set_connection(sock, sock);
--- sshd.c~     2011-11-30 13:47:36.000000000 +0100
+++ sshd.c      2012-01-06 18:21:37.312969797 +0100
@@ -1910,9 +1910,11 @@
       packet_set_server();

       /* Set SO_KEEPALIVE if requested. */
-       if (options.tcp_keep_alive && packet_connection_is_on_socket() &&
+       on = options.tcp_keep_alive ? 1 : 0;
+       if (packet_connection_is_on_socket() &&
           setsockopt(sock_in, SOL_SOCKET, SO_KEEPALIVE, &on, sizeof(on)) < 0)
               error("setsockopt SO_KEEPALIVE: %.100s", strerror(errno));
+       on = 1;

       if ((remote_port = get_remote_port()) < 0) {
               debug("get_remote_port failed");




ssh-sample-keepalive.patch (attached again):
-------------- next part --------------








From richih.mailinglist at gmail.com  Wed Jan 11 23:02:39 2012
From: richih.mailinglist at gmail.com (Richard Hartmann)
Date: Wed, 11 Jan 2012 13:02:39 +0100
Subject: Full replay logs of OpenSSH sessions
Message-ID: <CAD77+gTqM4o3XOrO9YQnu1q_=Q5DAnfBeZ+z+tkf6pHu01fNfw@mail.gmail.com>

Hi all,

I am not 100% sure if this is a -dev or a -user topic, but I am
leaning towards the former. Feel free to cuss at me and tell me to ask
-user, instead.


I used to run a patchset that allowed full logs of everything taking
place via OpenSSH. This also allowed me to replay any session, live or
after the fact.

I am fully aware of the security implications of logging everything,
especially regarding passwords.

Still, in this specific case, I need full logs due to due diligence
requirements.


Is anyone aware of such a patchset or another way to achieve this goal?


Thanks,
Richard

From nkadel at gmail.com  Thu Jan 12 01:08:27 2012
From: nkadel at gmail.com (Nico Kadel-Garcia)
Date: Wed, 11 Jan 2012 09:08:27 -0500
Subject: Full replay logs of OpenSSH sessions
In-Reply-To: <CAD77+gTqM4o3XOrO9YQnu1q_=Q5DAnfBeZ+z+tkf6pHu01fNfw@mail.gmail.com>
References: <CAD77+gTqM4o3XOrO9YQnu1q_=Q5DAnfBeZ+z+tkf6pHu01fNfw@mail.gmail.com>
Message-ID: <CAOCN9rzWLC+mHygQCtVq_wW+0YntrrYnxUTy5Qh67XTYrE3diA@mail.gmail.com>

On Wed, Jan 11, 2012 at 7:02 AM, Richard Hartmann
<richih.mailinglist at gmail.com> wrote:
> Hi all,
>
> I am not 100% sure if this is a -dev or a -user topic, but I am
> leaning towards the former. Feel free to cuss at me and tell me to ask
> -user, instead.
>
>
> I used to run a patchset that allowed full logs of everything taking
> place via OpenSSH. This also allowed me to replay any session, live or
> after the fact.
>
> I am fully aware of the security implications of logging everything,
> especially regarding passwords.
>
> Still, in this specific case, I need full logs due to due diligence
> requirements.
>
>
> Is anyone aware of such a patchset or another way to achieve this goal?

Talk to Centrify, at www.centrify.com. They've got a fascinating
toolkit for integrating Active Directory authentication with Linux and
UNIX authentication, and due diligence tools for monitoring nsessions.
Can't remember if they modified the sshd this way, but they certainly
had tweaked logins for such keystroke monitoring.

You might also have a word with Sandstorm Enterprises, the company
that makes NetInterceptor about man-in-the-middle against SSH. Their
tools are pricey, but scarey useful for due diligence monitoring and
debugging. I'm not sure whether they can carry out man-in-the-middle
SSH sessions without easy detection.

From richih.mailinglist at gmail.com  Thu Jan 12 01:45:42 2012
From: richih.mailinglist at gmail.com (Richard Hartmann)
Date: Wed, 11 Jan 2012 15:45:42 +0100
Subject: Full replay logs of OpenSSH sessions
In-Reply-To: <CAOCN9rzWLC+mHygQCtVq_wW+0YntrrYnxUTy5Qh67XTYrE3diA@mail.gmail.com>
References: <CAD77+gTqM4o3XOrO9YQnu1q_=Q5DAnfBeZ+z+tkf6pHu01fNfw@mail.gmail.com>
 <CAOCN9rzWLC+mHygQCtVq_wW+0YntrrYnxUTy5Qh67XTYrE3diA@mail.gmail.com>
Message-ID: <CAD77+gSy+sJxd6Ks90NZ+Akr3qGOw45w5RxR0LELDkwDMMW7Og@mail.gmail.com>

Thanks, but I am not sure I want either a Windows-centric base product
or something that tries to intercept stuff.

FWIW, I am attaching the patchset I found in my backups. Maybe someone
is interested in this and willing to take it from here?


Richard

PS: http://code.google.com/p/auditing-sshd/ exists, but they don't
allow replay of full session logs.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openssh-4.3p2-logging.diff
Type: text/x-patch
Size: 11981 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20120111/c1a6f133/attachment-0001.bin>

From keisial at gmail.com  Thu Jan 12 08:03:04 2012
From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=)
Date: Wed, 11 Jan 2012 22:03:04 +0100
Subject: Full replay logs of OpenSSH sessions
In-Reply-To: <CAD77+gSy+sJxd6Ks90NZ+Akr3qGOw45w5RxR0LELDkwDMMW7Og@mail.gmail.com>
References: <CAD77+gTqM4o3XOrO9YQnu1q_=Q5DAnfBeZ+z+tkf6pHu01fNfw@mail.gmail.com>
 <CAOCN9rzWLC+mHygQCtVq_wW+0YntrrYnxUTy5Qh67XTYrE3diA@mail.gmail.com>
 <CAD77+gSy+sJxd6Ks90NZ+Akr3qGOw45w5RxR0LELDkwDMMW7Og@mail.gmail.com>
Message-ID: <4F0DF908.2020004@gmail.com>

On 11/01/12 15:45, Richard Hartmann wrote:
> FWIW, I am attaching the patchset I found in my backups. Maybe someone
> is interested in this and willing to take it from here?
(...)
> + The "script" patch logs tty output of ssh sessions.
If you are only interested in terminal-like sessions, I think setting 
the user shell
to a script that logged the passed commands (if any) and passed control 
to script(1)
(writing to a location the user can't write) may fullfil your needs, and 
you don't need
to patch ssh.


From keisial at gmail.com  Thu Jan 12 08:04:21 2012
From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=)
Date: Wed, 11 Jan 2012 22:04:21 +0100
Subject: Interop problem with IPSSH-6.6.0, CR/NL?
In-Reply-To: <20120106154025.GA29490@lorvorc.mips.inka.de>
References: <je2i3c$b3r$1@lorvorc.mips.inka.de>
 <alpine.BSO.2.00.1201060623420.13971@natsu.mindrot.org>
 <20120105202519.GA27189@lorvorc.mips.inka.de>
 <alpine.BSO.2.00.1201061131170.13971@natsu.mindrot.org>
 <20120106154025.GA29490@lorvorc.mips.inka.de>
Message-ID: <4F0DF955.70003@gmail.com>

On 06/01/12 16:40, Christian Weisgerber wrote:
>> Do you have any idea what the last version of OpenSSH to interop correctly
>> with these devices was? Or has it always been broken? :)
> These are TP-Link JetStream switches.  They've only been available
> for half a year, and I've had them only for a week. ;-)
I think you report to them how their client is ignoring NL.


From toralf.foerster at gmx.de  Thu Jan 12 19:46:16 2012
From: toralf.foerster at gmx.de (Toralf =?utf-8?q?F=C3=B6rster?=)
Date: Thu, 12 Jan 2012 09:46:16 +0100
Subject: scp should not report 100% until the last byte is transferred
Message-ID: <201201120946.17495.toralf.foerster@gmx.de>

Hello,

just my opinion, but yesterday I run into a case, where after 7 hours of 
transferring a file (a little bit greater than 1 GB) the scp reported 100% and 
after that exited with an error (AIX 7.1):

$ tsocks scp foo user at host:/tmp
...
100% 1101MB  44.2KB/s 448.0KB/s 7:05:38    
scp: /tmp/foo: File too large

Probably it should not be rounded up to 100% ?

-- 
MfG/Sincerely
Toralf F?rster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3

From peter at stuge.se  Thu Jan 12 21:17:16 2012
From: peter at stuge.se (Peter Stuge)
Date: Thu, 12 Jan 2012 11:17:16 +0100
Subject: scp should not report 100% until the last byte is transferred
In-Reply-To: <201201120946.17495.toralf.foerster@gmx.de>
References: <201201120946.17495.toralf.foerster@gmx.de>
Message-ID: <20120112101716.3299.qmail@stuge.se>

Toralf F?rster wrote:
> just my opinion, but yesterday I run into a case, where after 7 hours of 
> transferring a file (a little bit greater than 1 GB) the scp reported 100% and 
> after that exited with an error (AIX 7.1):
> 
> $ tsocks scp foo user at host:/tmp
> ...
> 100% 1101MB  44.2KB/s 448.0KB/s 7:05:38    
> scp: /tmp/foo: File too large
> 
> Probably it should not be rounded up to 100% ?

The scp protocol is very primitive, and I'm not sure that an error
can be detected at all until after 100% has been sent.

Recommend use SFTP.


//Peter

From philipp.marek at linbit.com  Thu Jan 12 21:40:30 2012
From: philipp.marek at linbit.com (Philipp Marek)
Date: Thu, 12 Jan 2012 11:40:30 +0100
Subject: scp should not report 100% until the last byte is transferred
In-Reply-To: <201201120946.17495.toralf.foerster@gmx.de>
References: <201201120946.17495.toralf.foerster@gmx.de>
Message-ID: <201201121140.30299.philipp.marek@linbit.com>

On Thursday, 12. Jan 2012, Toralf F?rster wrote:
> just my opinion, but yesterday I run into a case, where after 7 hours of
> transferring a file (a little bit greater than 1 GB) the scp reported
> 100% and after that exited with an error (AIX 7.1):
> 
> $ tsocks scp foo user at host:/tmp
> ...
> 100% 1101MB  44.2KB/s 448.0KB/s 7:05:38
> scp: /tmp/foo: File too large
> 
> Probably it should not be rounded up to 100% ?
Perhaps another part of the problem is that it doesn't wait for byte 
position acknowledgments from the remote side ...

I've seen it fill up the TCP buffers, and then stay at 100% for ~30 seconds 
until the buffers were drained over the slow connection.


Regards,

Phil

From richih.mailinglist at gmail.com  Thu Jan 12 21:43:57 2012
From: richih.mailinglist at gmail.com (Richard Hartmann)
Date: Thu, 12 Jan 2012 11:43:57 +0100
Subject: Full replay logs of OpenSSH sessions
In-Reply-To: <4F0DF908.2020004@gmail.com>
References: <CAD77+gTqM4o3XOrO9YQnu1q_=Q5DAnfBeZ+z+tkf6pHu01fNfw@mail.gmail.com>
 <CAOCN9rzWLC+mHygQCtVq_wW+0YntrrYnxUTy5Qh67XTYrE3diA@mail.gmail.com>
 <CAD77+gSy+sJxd6Ks90NZ+Akr3qGOw45w5RxR0LELDkwDMMW7Og@mail.gmail.com>
 <4F0DF908.2020004@gmail.com>
Message-ID: <CAD77+gQbF-t-Ksov74xSom=LcgHQB5XJmciq_FsvYaNKzDRKsQ@mail.gmail.com>

2012/1/11 ?ngel Gonz?lez <keisial at gmail.com>:

> If you are only interested in terminal-like sessions, I think setting the
> user shell
> to a script that logged the passed commands (if any) and passed control to
> script(1)
> (writing to a location the user can't write) may fullfil your needs, and you
> don't need
> to patch ssh.

I am not aware of any script that allows this properly and I would
like to avoid hooking into a point that may cause unintended effects.
By doing things in the background so to speak, i.e. ssh directly, I
can avoid piping things through anything that might choke on control
chars or similar.


Richard

From x.issuer at gmail.com  Fri Jan 13 05:58:21 2012
From: x.issuer at gmail.com (iam iranian)
Date: Thu, 12 Jan 2012 22:28:21 +0330
Subject: Request for obfuscating the handshake
Message-ID: <CAEN6Lm6RjsqGey63T2dtvCvN4Yi5bhQbA8fpRfpJTN6i31uv6g@mail.gmail.com>

Dear OpenSSH team,

First of all thanks a lot for your good work on developing such a usable
peace of software. Nice job.
As you may know, we have some issues using OpenSSH in Iran. Recently the
government did some packet filtering on some protocols, including SSH. We
don't know what exactly they've done but it appears to be some routing rule
that prevents SSH protocol to initiate a connection. Its like that the
handshake packet is dropped.
Fortunately there is a patch on OpenSSH done by Bruce Leidl (
https://github.com/brl/obfuscated-openssh) that obfuscates the handshake
packet and luckily it helps us pass through this annoying packet filtering.
But sadly this patch isn't implemented in the main project.

We, a group of Iranian OpenSSH users, recommend you to include this useful
patch in the main project because:
0. As Bruce Leidl explains it's true that the communication is secured
during a session, but before starting a session since the encryption keys
have not yet been determined, there is no encryption and the handshake
packets are insecure.
1. It's always better to have more options. In this case, having the
handshake packet obfuscated is an important choice to make.
2. The patch nicely adds the ability of obfuscating the handshake and makes
no harm to the rest of the project. So why not?
3. We really want you to do it.

Thank you very much and best regards.

From dan at doxpara.com  Fri Jan 13 07:41:04 2012
From: dan at doxpara.com (Dan Kaminsky)
Date: Thu, 12 Jan 2012 12:41:04 -0800
Subject: Request for obfuscating the handshake
In-Reply-To: <CAEN6Lm6RjsqGey63T2dtvCvN4Yi5bhQbA8fpRfpJTN6i31uv6g@mail.gmail.com>
References: <CAEN6Lm6RjsqGey63T2dtvCvN4Yi5bhQbA8fpRfpJTN6i31uv6g@mail.gmail.com>
Message-ID: <CAEW7ACkO12faigojevzifX1EV_ysNgG2uRYPOk7dUUkVanREWw@mail.gmail.com>

Anything in the mainline OpenSSH code will be adapted to by your
adversaries.  (Put another way, if you want your code to remain functional,
it has to remain a patch.)


On Thu, Jan 12, 2012 at 10:58 AM, iam iranian <x.issuer at gmail.com> wrote:

> Dear OpenSSH team,
>
> First of all thanks a lot for your good work on developing such a usable
> peace of software. Nice job.
> As you may know, we have some issues using OpenSSH in Iran. Recently the
> government did some packet filtering on some protocols, including SSH. We
> don't know what exactly they've done but it appears to be some routing rule
> that prevents SSH protocol to initiate a connection. Its like that the
> handshake packet is dropped.
> Fortunately there is a patch on OpenSSH done by Bruce Leidl (
> https://github.com/brl/obfuscated-openssh) that obfuscates the handshake
> packet and luckily it helps us pass through this annoying packet filtering.
> But sadly this patch isn't implemented in the main project.
>
> We, a group of Iranian OpenSSH users, recommend you to include this useful
> patch in the main project because:
> 0. As Bruce Leidl explains it's true that the communication is secured
> during a session, but before starting a session since the encryption keys
> have not yet been determined, there is no encryption and the handshake
> packets are insecure.
> 1. It's always better to have more options. In this case, having the
> handshake packet obfuscated is an important choice to make.
> 2. The patch nicely adds the ability of obfuscating the handshake and makes
> no harm to the rest of the project. So why not?
> 3. We really want you to do it.
>
> Thank you very much and best regards.
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>

From keisial at gmail.com  Fri Jan 13 10:28:06 2012
From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=)
Date: Fri, 13 Jan 2012 00:28:06 +0100
Subject: Request for obfuscating the handshake
In-Reply-To: <CAEN6Lm6RjsqGey63T2dtvCvN4Yi5bhQbA8fpRfpJTN6i31uv6g@mail.gmail.com>
References: <CAEN6Lm6RjsqGey63T2dtvCvN4Yi5bhQbA8fpRfpJTN6i31uv6g@mail.gmail.com>
Message-ID: <4F0F6C86.70805@gmail.com>

Hello Sir,
I have been reading the protocol description and, although there are some
'arbitrary' choices (eg. the stream cipher, the hash, the value of
OBFUSCATE_HASH_ITERATIONS, or why not include the counter in the 
iterations),
the easiest way is _probably_ to follow the public description (this is 
only obfuscation).

But I think the weakest point is that your government can easily block 
it by not
allowing a connection sending random bytes. And there is no provision 
for it to look
like 'something else'. I think the best hiding is what the tor projet 
strives to do,
enmasquerading as a HTTPS handshake.
Which is probably overkill to consider as an addition for openssh.
I started thinking about something like a HTTP POST, which triggered the 
detection
from a point where the characters mathed some kind of crazy condition, 
such as the
difference of two characters with the next two were a prime number, thus 
forcing to
read an arbitrary-length content (and the payload common enough it would 
appear
in 'legitimate' content, too).

I wonder, does the new filters also block ssh if there's a banner? (eg. 
it shows a
Shakespeare poem before connecting you). Not that it matters much (they 
can easily
close it), but they could have forgotten that.
I pondered if there were an easy way to skip the cleartext (eg. 
automatically assuming
that you received a SSH-2.0 banner) but the negotiation options are even 
more obvious,
so a stream cipher does seem required.

Steganographying ssh is an interesting problem.

Good luck for you all



From peter at stuge.se  Fri Jan 13 12:13:04 2012
From: peter at stuge.se (Peter Stuge)
Date: Fri, 13 Jan 2012 02:13:04 +0100
Subject: Full replay logs of OpenSSH sessions
In-Reply-To: <CAD77+gQbF-t-Ksov74xSom=LcgHQB5XJmciq_FsvYaNKzDRKsQ@mail.gmail.com>
References: <CAD77+gTqM4o3XOrO9YQnu1q_=Q5DAnfBeZ+z+tkf6pHu01fNfw@mail.gmail.com>
 <CAOCN9rzWLC+mHygQCtVq_wW+0YntrrYnxUTy5Qh67XTYrE3diA@mail.gmail.com>
 <CAD77+gSy+sJxd6Ks90NZ+Akr3qGOw45w5RxR0LELDkwDMMW7Og@mail.gmail.com>
 <4F0DF908.2020004@gmail.com>
 <CAD77+gQbF-t-Ksov74xSom=LcgHQB5XJmciq_FsvYaNKzDRKsQ@mail.gmail.com>
Message-ID: <20120113011304.27616.qmail@stuge.se>

Richard Hartmann wrote:
> By doing things in the background so to speak, i.e. ssh directly,

ssh doesn't really have much to do with this.

Maybe you can use http://sourceforge.net/projects/snoopylogger/


//Peter

From nkadel at gmail.com  Fri Jan 13 16:20:59 2012
From: nkadel at gmail.com (Nico Kadel-Garcia)
Date: Fri, 13 Jan 2012 00:20:59 -0500
Subject: Full replay logs of OpenSSH sessions
In-Reply-To: <20120113011304.27616.qmail@stuge.se>
References: <CAD77+gTqM4o3XOrO9YQnu1q_=Q5DAnfBeZ+z+tkf6pHu01fNfw@mail.gmail.com>
 <CAOCN9rzWLC+mHygQCtVq_wW+0YntrrYnxUTy5Qh67XTYrE3diA@mail.gmail.com>
 <CAD77+gSy+sJxd6Ks90NZ+Akr3qGOw45w5RxR0LELDkwDMMW7Og@mail.gmail.com>
 <4F0DF908.2020004@gmail.com>
 <CAD77+gQbF-t-Ksov74xSom=LcgHQB5XJmciq_FsvYaNKzDRKsQ@mail.gmail.com>
 <20120113011304.27616.qmail@stuge.se>
Message-ID: <CAOCN9rwfqv74DCu6htWomSUcwQHG8ZJdKVAn9tgNWSfZ_-Jsww@mail.gmail.com>

On Thu, Jan 12, 2012 at 8:13 PM, Peter Stuge <peter at stuge.se> wrote:
> Richard Hartmann wrote:
>> By doing things in the background so to speak, i.e. ssh directly,
>
> ssh doesn't really have much to do with this.
>
> Maybe you can use http://sourceforge.net/projects/snoopylogger/

"In the background" is the problem. Richard wants to want tio embed a
recording keystroke monitor in SSH itself, which is anathema to the
very concept of a secure encryption channel. Such a tools is an
exceedingly dangerous one, cnrouraging surrpititious use of SSH to
localhost monitoring.

I've already pointed him to the man-in-the-middle tools from Sandstorm
Enterprises, and the logging shells provided by Centrify. I really
don't think SSH servers are a good place to put this: protecting the
recorded data from inappropriate access or unauthorzed recording,
especially with tunneled SSH sessions, becomes an open source security
nightmare very quickly.

From peter at stuge.se  Fri Jan 13 16:53:05 2012
From: peter at stuge.se (Peter Stuge)
Date: Fri, 13 Jan 2012 06:53:05 +0100
Subject: Full replay logs of OpenSSH sessions
In-Reply-To: <CAOCN9rwfqv74DCu6htWomSUcwQHG8ZJdKVAn9tgNWSfZ_-Jsww@mail.gmail.com>
References: <CAD77+gTqM4o3XOrO9YQnu1q_=Q5DAnfBeZ+z+tkf6pHu01fNfw@mail.gmail.com>
 <CAOCN9rzWLC+mHygQCtVq_wW+0YntrrYnxUTy5Qh67XTYrE3diA@mail.gmail.com>
 <CAD77+gSy+sJxd6Ks90NZ+Akr3qGOw45w5RxR0LELDkwDMMW7Og@mail.gmail.com>
 <4F0DF908.2020004@gmail.com>
 <CAD77+gQbF-t-Ksov74xSom=LcgHQB5XJmciq_FsvYaNKzDRKsQ@mail.gmail.com>
 <20120113011304.27616.qmail@stuge.se>
 <CAOCN9rwfqv74DCu6htWomSUcwQHG8ZJdKVAn9tgNWSfZ_-Jsww@mail.gmail.com>
Message-ID: <20120113055305.31907.qmail@stuge.se>

Nico Kadel-Garcia wrote:
> >> By doing things in the background so to speak, i.e. ssh directly,
> >
> > ssh doesn't really have much to do with this.
> >
> > Maybe you can use http://sourceforge.net/projects/snoopylogger/
> 
> "In the background" is the problem. Richard wants to want tio embed a
> recording keystroke monitor in SSH itself, which is anathema to the
> very concept of a secure encryption channel.

Well yes and no.. But politics aside, I think sshd is a terrible
place to introduce this surveillance from a purely technical point
of view.

SSH is an agnostic transport. It's not the only way to log in to a
system and it's not the only way to execute commands on a system.

Also, using SSH says nothing about what goes on *inside* the channel.

Please look at the protocol a little. There is very very little that
has anything to do with logging in, in the protocol.

There are sessions and channels. Surveillance of sessions is easy
enough, because all that happens is that they get created,
authenticated, and torn down. Everything about the sessions is
structured and specified in the protocol.

Channels are a completely different matter however. They have no
structure whatsoever, and nothing is known in sshd about the
structure of what goes on in the majority of channels.

If you're going to do surveillance of users, then at least do it
somewhere where it makes sense.


//Peter

From richih.mailinglist at gmail.com  Fri Jan 13 20:48:57 2012
From: richih.mailinglist at gmail.com (Richard Hartmann)
Date: Fri, 13 Jan 2012 09:48:57 +0000
Subject: Full replay logs of OpenSSH sessions
In-Reply-To: <20120113055305.31907.qmail@stuge.se>
References: <CAD77+gTqM4o3XOrO9YQnu1q_=Q5DAnfBeZ+z+tkf6pHu01fNfw@mail.gmail.com>
 <CAOCN9rzWLC+mHygQCtVq_wW+0YntrrYnxUTy5Qh67XTYrE3diA@mail.gmail.com>
 <CAD77+gSy+sJxd6Ks90NZ+Akr3qGOw45w5RxR0LELDkwDMMW7Og@mail.gmail.com>
 <4F0DF908.2020004@gmail.com>
 <CAD77+gQbF-t-Ksov74xSom=LcgHQB5XJmciq_FsvYaNKzDRKsQ@mail.gmail.com>
 <20120113011304.27616.qmail@stuge.se>
 <CAOCN9rwfqv74DCu6htWomSUcwQHG8ZJdKVAn9tgNWSfZ_-Jsww@mail.gmail.com>
 <20120113055305.31907.qmail@stuge.se>
Message-ID: <CAD77+gSW+iSKrRAnOQKQGz-GOFii1u09i=533OQAqFhHRkPd9Q@mail.gmail.com>

On Fri, Jan 13, 2012 at 05:53, Peter Stuge <peter at stuge.se> wrote:

> Nico Kadel-Garcia wrote:

>> "In the background" is the problem. Richard wants to want tio embed a
>> recording keystroke monitor in SSH itself, which is anathema to the
>> very concept of a secure encryption channel.
>
> Well yes and no.. But politics aside, I think sshd is a terrible
> place to introduce this surveillance from a purely technical point
> of view.

I agree that this can be a very dangerous thing to do, but as with
other tools, admin discretion and informed users are needed. Everyone
who will ever access this machine (legally) _wants_ this to happen on
this one machine.

Focusing on the technical part, there are three places which make some
sense, imo:

* In the *ty:
Maybe the best place, but there is nothing current I could find.
ttyrpld [1] is ancient and unmaintained, and UML tty logging is not
working outside of a UML guest.

* In the shell:
Needs to wrap around all shells or forces us to patch at least zsh and
bash and then thoroughly disable chsh.

* In ssh:
I know that raw logging can catch crap, but back when we used the
posted patch, it worked wonderfully for what we needed to do.


At the risk of drifting off topic, if anyone has a suggestion for
_unavoidable full session logs_ (no X required) outside of SSH with
FLOSS tools, please pipe up.


Thanks,
Richard

[1] http://ttyrpld.sourceforge.net/desc.php

From peter at stuge.se  Fri Jan 13 21:35:12 2012
From: peter at stuge.se (Peter Stuge)
Date: Fri, 13 Jan 2012 11:35:12 +0100
Subject: Full replay logs of OpenSSH sessions
In-Reply-To: <CAD77+gSW+iSKrRAnOQKQGz-GOFii1u09i=533OQAqFhHRkPd9Q@mail.gmail.com>
References: <CAD77+gTqM4o3XOrO9YQnu1q_=Q5DAnfBeZ+z+tkf6pHu01fNfw@mail.gmail.com>
 <CAOCN9rzWLC+mHygQCtVq_wW+0YntrrYnxUTy5Qh67XTYrE3diA@mail.gmail.com>
 <CAD77+gSy+sJxd6Ks90NZ+Akr3qGOw45w5RxR0LELDkwDMMW7Og@mail.gmail.com>
 <4F0DF908.2020004@gmail.com>
 <CAD77+gQbF-t-Ksov74xSom=LcgHQB5XJmciq_FsvYaNKzDRKsQ@mail.gmail.com>
 <20120113011304.27616.qmail@stuge.se>
 <CAOCN9rwfqv74DCu6htWomSUcwQHG8ZJdKVAn9tgNWSfZ_-Jsww@mail.gmail.com>
 <20120113055305.31907.qmail@stuge.se>
 <CAD77+gSW+iSKrRAnOQKQGz-GOFii1u09i=533OQAqFhHRkPd9Q@mail.gmail.com>
Message-ID: <20120113103512.3056.qmail@stuge.se>

Richard Hartmann wrote:
> * In the shell:
> Needs to wrap around all shells or forces us to patch at least zsh and
> bash and then thoroughly disable chsh.

Did you look at snoopy?


//Peter

From pustjens at dds.nl  Fri Jan 13 21:48:57 2012
From: pustjens at dds.nl (Mark Pustjens)
Date: Fri, 13 Jan 2012 11:48:57 +0100 (CET)
Subject: [PATCH 1/1] Ported gnome-ssh-askpass2 to gtk3.
Message-ID: <alpine.LNX.2.02.1201131144200.1763@localhost.localdomain>

Hello List,

This is for the portable release.

I wanted gnome-ssh-askpass to be a gtk+3 app, so I made a quick port.

Mark
---
  contrib/Makefile             |    7 +-
  contrib/gnome-ssh-askpass3.c |  220 ++++++++++++++++++++++++++++++++++++++++++
  2 files changed, 226 insertions(+), 1 deletions(-)
  create mode 100644 contrib/gnome-ssh-askpass3.c

diff --git a/contrib/Makefile b/contrib/Makefile
index 8b34eb2..b9168df 100644
--- a/contrib/Makefile
+++ b/contrib/Makefile
@@ -11,5 +11,10 @@ gnome-ssh-askpass2: gnome-ssh-askpass2.c
  		gnome-ssh-askpass2.c -o gnome-ssh-askpass2 \
  		`pkg-config --libs gtk+-2.0 x11`

+gnome-ssh-askpass3: gnome-ssh-askpass3.c
+	$(CC) `pkg-config --cflags gtk+-3.0` \
+		gnome-ssh-askpass3.c -o gnome-ssh-askpass3 \
+		`pkg-config --libs gtk+-3.0 x11`
+
  clean:
-	rm -f *.o gnome-ssh-askpass1 gnome-ssh-askpass2 gnome-ssh-askpass
+	rm -f *.o gnome-ssh-askpass1 gnome-ssh-askpass2 gnome-ssh-askpass3 gnome-ssh-askpass
diff --git a/contrib/gnome-ssh-askpass3.c b/contrib/gnome-ssh-askpass3.c
new file mode 100644
index 0000000..79d522e
--- /dev/null
+++ b/contrib/gnome-ssh-askpass3.c
@@ -0,0 +1,220 @@
+/*
+ * Copyright (c) 2000-2002 Damien Miller.  All rights reserved.
+ * Ported to gtk+3 by Mark Pustjens.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *    notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *    notice, this list of conditions and the following disclaimer in the
+ *    documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
+ * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
+ * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
+ * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
+ * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
+ * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+/* GTK2 support by Nalin Dahyabhai <nalin at redhat.com> */
+
+/*
+ * This is a simple GNOME SSH passphrase grabber. To use it, set the
+ * environment variable SSH_ASKPASS to point to the location of
+ * gnome-ssh-askpass before calling "ssh-add < /dev/null".
+ *
+ * There is only two run-time options: if you set the environment variable
+ * "GNOME_SSH_ASKPASS_GRAB_SERVER=true" then gnome-ssh-askpass will grab
+ * the X server. If you set "GNOME_SSH_ASKPASS_GRAB_POINTER=true", then the
+ * pointer will be grabbed too. These may have some benefit to security if
+ * you don't trust your X server. We grab the keyboard always.
+ */
+
+#define GRAB_TRIES	16
+#define GRAB_WAIT	250 /* milliseconds */
+
+/*
+ * Compile with:
+ *
+ * cc -Wall `pkg-config --cflags gtk+-3.0` \
+ *    gnome-ssh-askpass3.c -o gnome-ssh-askpass \
+ *    `pkg-config --libs gtk+-3.0`
+ *
+ */
+
+#include <stdlib.h>
+#include <stdio.h>
+#include <string.h>
+#include <unistd.h>
+#include <X11/Xlib.h>
+#include <gtk/gtk.h>
+#include <gdk/gdkx.h>
+
+static void
+report_failed_grab (const char *what)
+{
+	GtkWidget *err;
+
+	err = gtk_message_dialog_new(NULL, 0,
+				     GTK_MESSAGE_ERROR,
+				     GTK_BUTTONS_CLOSE,
+				     "Could not grab %s. "
+				     "A malicious client may be eavesdropping "
+				     "on your session.", what);
+	gtk_window_set_position(GTK_WINDOW(err), GTK_WIN_POS_CENTER);
+
+	gtk_dialog_run(GTK_DIALOG(err));
+
+	gtk_widget_destroy(err);
+}
+
+static void
+ok_dialog(GtkWidget *entry, gpointer dialog)
+{
+	g_return_if_fail(GTK_IS_DIALOG(dialog));
+	gtk_dialog_response(GTK_DIALOG(dialog), GTK_RESPONSE_OK);
+}
+
+static int
+passphrase_dialog(char *message)
+{
+	const char *failed;
+	char *passphrase, *local;
+	int result, grab_tries, grab_server, grab_pointer;
+	GtkWidget *dialog, *entry;
+	GdkGrabStatus status;
+
+	grab_server = (getenv("GNOME_SSH_ASKPASS_GRAB_SERVER") != NULL);
+	grab_pointer = (getenv("GNOME_SSH_ASKPASS_GRAB_POINTER") != NULL);
+	grab_tries = 0;
+
+	dialog = gtk_message_dialog_new(NULL, 0,
+					GTK_MESSAGE_QUESTION,
+					GTK_BUTTONS_OK_CANCEL,
+					"%s",
+					message);
+
+	entry = gtk_entry_new();
+	gtk_box_pack_start(GTK_BOX(gtk_message_dialog_get_message_area(GTK_MESSAGE_DIALOG(dialog))), entry, FALSE,
+	    FALSE, 0);
+	gtk_entry_set_visibility(GTK_ENTRY(entry), FALSE);
+	gtk_widget_grab_focus(entry);
+	gtk_widget_show(entry);
+
+	gtk_window_set_title(GTK_WINDOW(dialog), "OpenSSH");
+	gtk_window_set_position (GTK_WINDOW(dialog), GTK_WIN_POS_CENTER);
+	gtk_window_set_keep_above(GTK_WINDOW(dialog), TRUE);
+
+	/* Make <enter> close dialog */
+	gtk_dialog_set_default_response(GTK_DIALOG(dialog), GTK_RESPONSE_OK);
+	g_signal_connect(G_OBJECT(entry), "activate",
+			 G_CALLBACK(ok_dialog), dialog);
+
+	gtk_window_set_keep_above(GTK_WINDOW(dialog), TRUE);
+
+	/* Grab focus */
+	gtk_widget_show_now(dialog);
+	if (grab_pointer) {
+		for(;;) {
+			status = gdk_pointer_grab(
+			   gtk_widget_get_window(GTK_WIDGET(dialog)), TRUE, 0, NULL,
+			   NULL, GDK_CURRENT_TIME);
+			if (status == GDK_GRAB_SUCCESS)
+				break;
+			usleep(GRAB_WAIT * 1000);
+			if (++grab_tries > GRAB_TRIES) {
+				failed = "mouse";
+				goto nograb;
+			}
+		}
+	}
+	for(;;) {
+		status = gdk_keyboard_grab(gtk_widget_get_window(GTK_WIDGET(dialog)),
+		   FALSE, GDK_CURRENT_TIME);
+		if (status == GDK_GRAB_SUCCESS)
+			break;
+		usleep(GRAB_WAIT * 1000);
+		if (++grab_tries > GRAB_TRIES) {
+			failed = "keyboard";
+			goto nograbkb;
+		}
+	}
+	if (grab_server) {
+		gdk_x11_grab_server();
+	}
+
+	result = gtk_dialog_run(GTK_DIALOG(dialog));
+
+	/* Ungrab */
+	if (grab_server)
+		XUngrabServer(GDK_DISPLAY_XDISPLAY(gdk_display_get_default()));
+	if (grab_pointer)
+		gdk_pointer_ungrab(GDK_CURRENT_TIME);
+	gdk_keyboard_ungrab(GDK_CURRENT_TIME);
+	gdk_flush();
+
+	/* Report passphrase if user selected OK */
+	passphrase = g_strdup(gtk_entry_get_text(GTK_ENTRY(entry)));
+	if (result == GTK_RESPONSE_OK) {
+		local = g_locale_from_utf8(passphrase, strlen(passphrase),
+					   NULL, NULL, NULL);
+		if (local != NULL) {
+			puts(local);
+			memset(local, '\0', strlen(local));
+			g_free(local);
+		} else {
+			puts(passphrase);
+		}
+	}
+ 
+	/* Zero passphrase in memory */
+	memset(passphrase, '\b', strlen(passphrase));
+	gtk_entry_set_text(GTK_ENTRY(entry), passphrase);
+	memset(passphrase, '\0', strlen(passphrase));
+	g_free(passphrase);
+ 
+	gtk_widget_destroy(dialog);
+	return (result == GTK_RESPONSE_OK ? 0 : -1);
+
+	/* At least one grab failed - ungrab what we got, and report
+	   the failure to the user.  Note that XGrabServer() cannot
+	   fail.  */
+ nograbkb:
+	gdk_pointer_ungrab(GDK_CURRENT_TIME);
+ nograb:
+	if (grab_server)
+		XUngrabServer(GDK_DISPLAY_XDISPLAY(gdk_display_get_default()));
+	gtk_widget_destroy(dialog);
+ 
+	report_failed_grab(failed);
+
+	return (-1);
+}
+
+int
+main(int argc, char **argv)
+{
+	char *message;
+	int result;
+
+	gtk_init(&argc, &argv);
+
+	if (argc > 1) {
+		message = g_strjoinv(" ", argv + 1);
+	} else {
+		message = g_strdup("Enter your OpenSSH passphrase:");
+	}
+
+	setvbuf(stdout, 0, _IONBF, 0);
+	result = passphrase_dialog(message);
+	g_free(message);
+
+	return (result);
+}
-- 
1.7.8.3


Greetings/Groetjes

Mark Pustjens

-- 
Words are the litmus paper of the minds. If you find yourself in the power
of someone who will use the word "commence" in cold blood, go somewhere
else very quickly. But if they say "Enter", don't stop to pack.
   (Small Gods)

From richih.mailinglist at gmail.com  Fri Jan 13 23:02:50 2012
From: richih.mailinglist at gmail.com (Richard Hartmann)
Date: Fri, 13 Jan 2012 12:02:50 +0000
Subject: Full replay logs of OpenSSH sessions
In-Reply-To: <20120113103512.3056.qmail@stuge.se>
References: <CAD77+gTqM4o3XOrO9YQnu1q_=Q5DAnfBeZ+z+tkf6pHu01fNfw@mail.gmail.com>
 <CAOCN9rzWLC+mHygQCtVq_wW+0YntrrYnxUTy5Qh67XTYrE3diA@mail.gmail.com>
 <CAD77+gSy+sJxd6Ks90NZ+Akr3qGOw45w5RxR0LELDkwDMMW7Og@mail.gmail.com>
 <4F0DF908.2020004@gmail.com>
 <CAD77+gQbF-t-Ksov74xSom=LcgHQB5XJmciq_FsvYaNKzDRKsQ@mail.gmail.com>
 <20120113011304.27616.qmail@stuge.se>
 <CAOCN9rwfqv74DCu6htWomSUcwQHG8ZJdKVAn9tgNWSfZ_-Jsww@mail.gmail.com>
 <20120113055305.31907.qmail@stuge.se>
 <CAD77+gSW+iSKrRAnOQKQGz-GOFii1u09i=533OQAqFhHRkPd9Q@mail.gmail.com>
 <20120113103512.3056.qmail@stuge.se>
Message-ID: <CAD77+gTJ=TwnVicpxAwzYF2Gk=jPBBy=r_n7q7_gaPDaQijCeg@mail.gmail.com>

On Fri, Jan 13, 2012 at 10:35, Peter Stuge <peter at stuge.se> wrote:

> Did you look at snoopy?

Yes. It logs executions, not in- and output.


Richard

From openssh at roumenpetrov.info  Mon Jan 16 06:38:46 2012
From: openssh at roumenpetrov.info (Roumen Petrov)
Date: Sun, 15 Jan 2012 21:38:46 +0200
Subject: X.509 certificate integration continue with PKCS11 and FIPS capable
 OpenSSL
Message-ID: <4F132B46.10906@roumenpetrov.info>

Hello list members,

I would like to inform that version 7.1 of X.509 certificate support) is 
ready.

The just published update from "Integration" series offer direct support 
of X.509 certificates based on RSA keys from PKCS11module. Another 
integration update is that now you could you use FIPS capable OpenSSL 
library in FIPS mode.


As result of above mentioned  features  x509v3-sign-rsa public key 
algorithm now prefer sha1 to md5. This mean that by default option 
X509KeyAlgorithm is switched from
   X509KeyAlgorithm x509v3-sign-rsa,rsa-md5
   X509KeyAlgorithm x509v3-sign-rsa,rsa-sha1
to
   X509KeyAlgorithm x509v3-sign-rsa,rsa-sha1
   X509KeyAlgorithm x509v3-sign-rsa,rsa-md5 (not available in FIPS mode)

Note client and server use the first listed in for X509KeyAlgorithm for 
signing and accept all listed as is documented in ssh_config(5) and 
sshd_config(5) manual pages.

So if you user version before 5.3(released on 21 Jan 2006 ) you must update.
Third party clients and servers could check for PKIX in ssh 
identification string to adjust at run time prefered signature hash.


Regards,
Roumen Petrov


-- 
Get X.509 certificates support in OpenSSH:
http://roumenpetrov.info/openssh/

From scott_n at xypro.com  Tue Jan 17 11:10:14 2012
From: scott_n at xypro.com (Scott Neugroschl)
Date: Mon, 16 Jan 2012 16:10:14 -0800
Subject: sftp-server vs. internal-sftp
Message-ID: <78DD71C304F38B41885A242996B96F73035561D8@xyservd.XYPRO-23.LOCAL>

Hi guys,

 

Given that internal-sftp is the only way to support chrooted users, is
there any particular reason

why sftp-server is still the default SFTP subsystem?

 

---

Scott Neugroschl | XYPRO Technology Corporation

4100 Guardian Street | Suite 100 |Simi Valley, CA 93063 | Phone 805
583-2874|Fax 805 583-0124 |

 


From john.m.olsson at ericsson.com  Fri Jan 20 00:38:43 2012
From: john.m.olsson at ericsson.com (John Olsson M)
Date: Thu, 19 Jan 2012 14:38:43 +0100
Subject: ChrootDirectory per SSH Subsystem?
Message-ID: <A4ABB1C0A2EA784DA4EA6EDF7762E2DD19571DE7@ESESSCMS0360.eemea.ericsson.se>

Hi,

According to the sshd_config manual page the option ChrootDirectory can be used to force a chroot:ed environment for the SSHD server. But as I understand the manual page this is a global setting and it is not possible to specify this per SSH subsystem.

We are building a system where we need users to be able to log on from remote machines via SSH, but with the tweaks that we (for security reasons) for SFTP-sessions only want to show a virtual filesystem and "standard" SSH subsystem leads to our own shell offering only our own commands. Unfortunately, there is a conflict between what we want to show via an SFTP session and what the shell needs to be able to access.

What is your take on this? Is getting the desired behavior above an RTFM? Or are we entering the land of patching the source code? If the latter, do you have feeling for if is a small or huge undertaking (both implementing and maintaining)?

Would such an enhancement be something that could be accepted into the main development trunk, or do you have concerns over the concept of being able to override the global setting per SSH subsystem?


/John

From keisial at gmail.com  Fri Jan 20 02:38:37 2012
From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=)
Date: Thu, 19 Jan 2012 16:38:37 +0100
Subject: ChrootDirectory per SSH Subsystem?
In-Reply-To: <A4ABB1C0A2EA784DA4EA6EDF7762E2DD19571DE7@ESESSCMS0360.eemea.ericsson.se>
References: <A4ABB1C0A2EA784DA4EA6EDF7762E2DD19571DE7@ESESSCMS0360.eemea.ericsson.se>
Message-ID: <4F1838FD.90300@gmail.com>

On 19/01/12 14:38, John Olsson M wrote:
> Hi,
>
> According to the sshd_config manual page the option ChrootDirectory can be used to force a chroot:ed environment for the SSHD server. But as I understand the manual page this is a global setting and it is not possible to specify this per SSH subsystem.
>
> We are building a system where we need users to be able to log on from remote machines via SSH, but with the tweaks that we (for security reasons) for SFTP-sessions only want to show a virtual filesystem and "standard" SSH subsystem leads to our own shell offering only our own commands. Unfortunately, there is a conflict between what we want to show via an SFTP session and what the shell needs to be able to access.
>
> What is your take on this? Is getting the desired behavior above an RTFM? Or are we entering the land of patching the source code? If the latter, do you have feeling for if is a small or huge undertaking (both implementing and maintaining)?
>
> Would such an enhancement be something that could be accepted into the main development trunk, or do you have concerns over the concept of being able to override the global setting per SSH subsystem?
>
>
> /John
Place a couple of wrappers around the commands, doing the chroot for you?


From guyverdh at hotmail.com  Fri Jan 20 02:55:50 2012
From: guyverdh at hotmail.com (L B)
Date: Thu, 19 Jan 2012 09:55:50 -0600
Subject: Full replay logs of OpenSSH sessions
Message-ID: <BAY153-W3807AD715B21FD6EDBBF0C9860@phx.gbl>


I know that this suggestion isn't part of openssh, but I use it daily and it works.

Install or use one of the later revs of sudo which incorporates the sudoreplay feature.

Make sure the sudoers file is configured to enable capture of i/o.  

These are the entries I use..

Defaults log_output,log_input
Defaults!/usr/bin/sudoreplay !log_output,!log_input
Defaults!/usr/sbin/reboot !log_output

Then sudo to yourself, and proceed to ssh to wherever you'd like to go.
Your entire session will be captured.

To list your logs, use

sudo sudoreplay -l

to replay a session, use

sudo sudoreplay sessionid


Hope this helps.

 		 	   		  

From john.m.olsson at ericsson.com  Fri Jan 20 03:16:01 2012
From: john.m.olsson at ericsson.com (John Olsson M)
Date: Thu, 19 Jan 2012 17:16:01 +0100
Subject: ChrootDirectory per SSH Subsystem?
In-Reply-To: <4F1838FD.90300@gmail.com>
References: <A4ABB1C0A2EA784DA4EA6EDF7762E2DD19571DE7@ESESSCMS0360.eemea.ericsson.se>
 <4F1838FD.90300@gmail.com>
Message-ID: <A4ABB1C0A2EA784DA4EA6EDF7762E2DD19571DEA@ESESSCMS0360.eemea.ericsson.se>

> Place a couple of wrappers around the commands, doing the chroot for you?

Hmmm. I'm not sure I follow you. Our command shell (which is not like a standard *nix shell) needs to operate in a non-chrooted environment. But the file system shown by the SFTP subsystem needs to operate in a chroot:ed environemnt and only expose that subset of directories and files.


I think it is time to provide a bit more information now. :)

Lets call our own shell "cliss" and basically only users defined in an LDAP server is allowed to log on to port 22 (on another port we provide access to the Linux system, but only for locally defined users). We have extended the standard LDAP schema an additional attribute representing "roles"** and a user can be assigned one or more of them. The cliss shell provides a prompt from which an "information model" can be manipulated via transactions (much like routers works today) and setting/toggling an attribute results in actions happening on the machine. Access to the diferent parts of the information model is controlled via the roles stored in the LDAP server for the user (a role can give you either read-access or read/write-access to an one ore more object(s) or attribute(s) in the model).

The information model will also provide a file system view (the virtual filesystem mentioned earlier) where access control is controlled via the roles. Since we need to transfer files to and from the machine we also need to provide an SFTP view of the virtual filesystem and this is done via FUSE (since we need to enforce the role access rights and not by uid and/or gid).

Due to that cliss needs to be able to access all of the Linux file system (you do *all* configuration of the machine (basic stuff like IP-address and net mask as well as application specific things) via the information model), but at the same time should SFTP only expose the same virtual filesystem as found in the information model.


Additionally we have the restriction that port 22 _must_ be used for both SFTP access and cliss.


Based on this, what do we need to do to achive this? Is there some tricky way to configure the OpenSSH server or do we have to patch the source code? If the latter case, is this concept of being able to specify Chroot-jail per SSH subsystem something that is acceptable to include in standard OpenSSH server configuration file?


** Due to that we can not assume anything about the meaning of a certain GID we can not use them, instead we have the role concept where we can guarantee the meaning and thus build security across a vast number of machines from that. But otherwise there is really no difference between GID and role.

-----Original Message-----
From: ?ngel Gonz?lez [mailto:keisial at gmail.com] 
Sent: den 19 januari 2012 16:39
To: John Olsson M
Cc: 'openssh-unix-dev at mindrot.org'
Subject: Re: ChrootDirectory per SSH Subsystem?

On 19/01/12 14:38, John Olsson M wrote:
> Hi,
>
> According to the sshd_config manual page the option ChrootDirectory can be used to force a chroot:ed environment for the SSHD server. But as I understand the manual page this is a global setting and it is not possible to specify this per SSH subsystem.
>
> We are building a system where we need users to be able to log on from remote machines via SSH, but with the tweaks that we (for security reasons) for SFTP-sessions only want to show a virtual filesystem and "standard" SSH subsystem leads to our own shell offering only our own commands. Unfortunately, there is a conflict between what we want to show via an SFTP session and what the shell needs to be able to access.
>
> What is your take on this? Is getting the desired behavior above an RTFM? Or are we entering the land of patching the source code? If the latter, do you have feeling for if is a small or huge undertaking (both implementing and maintaining)?
>
> Would such an enhancement be something that could be accepted into the main development trunk, or do you have concerns over the concept of being able to override the global setting per SSH subsystem?
>
>
> /John
Place a couple of wrappers around the commands, doing the chroot for you?


From jmpoure at gooze.eu  Fri Jan 20 04:20:15 2012
From: jmpoure at gooze.eu (Jean-Michel =?ISO-8859-1?Q?Pour=E9?= - GOOZE)
Date: Thu, 19 Jan 2012 18:20:15 +0100
Subject: pkcs and host keys
In-Reply-To: <alpine.BSO.2.00.1109031104380.14401@natsu.mindrot.org>
References: <CAPKO79sZLa+yAzWEXh=Py0ahytpK8-S8N3ASkQEaFB69LzjD0Q@mail.gmail.com>
 <alpine.BSO.2.00.1109031104380.14401@natsu.mindrot.org>
Message-ID: <1326993615.4661.10.camel@acer>

Dear Damien Miller and friends,

> No, I haven't started working on it yet for lack of smartcard
> hardware.
> I (or someone else) will probably get around to it sooner or later,
> but
> it will go quicker if I can get a supported USB smartcard on OpenBSD. 

GOOZE would be glad to support such a project donating 10 ePass2003 to
interested OpenSSH developers. 

The ePass2003 is fully supported under GNU/Linux, FreeBSD and Windows:
http://www.gooze.eu/epass-2003

Cryptographic algorithms:
* RSA 1024/2048bit.
* DES/3DES.
* SHA1/SHA2.
* MD5.

Certification:
* FIPS 140-2 Level 2 (pending).
* Common Criteria EAL 5+ (chip level).
* Certified as CCID compliant by libccid project (Ludovic Rousseau).

Drivers:
* OpenSC GIT drivers are available.

Documentation:
* http://www.gooze.eu/howto/smartcard-quickstarter-guide

We already shipped the ePass2003 to FreeBSD port maintainers (libccid
and opensc). If you are interested to receive a free ePass2003, please
fill a request here:
http://www.gooze.eu/feitian-epass-2003-free-software-developer-kit

We would love to collaborate with OpenSSH developers and offer free
hardware. Just let us know!

Kind regards,
-- 
                  Jean-Michel Pour? - Gooze - http://www.gooze.eu
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6022 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20120119/b4ab8118/attachment.bin>

From william at 25thandClement.com  Fri Jan 20 04:57:15 2012
From: william at 25thandClement.com (William Ahern)
Date: Thu, 19 Jan 2012 09:57:15 -0800
Subject: pkcs and host keys
In-Reply-To: <1326993615.4661.10.camel@acer>
References: <CAPKO79sZLa+yAzWEXh=Py0ahytpK8-S8N3ASkQEaFB69LzjD0Q@mail.gmail.com>
 <alpine.BSO.2.00.1109031104380.14401@natsu.mindrot.org>
 <1326993615.4661.10.camel@acer>
Message-ID: <20120119175715.GA16818@wilbur.25thandClement.com>

On Thu, Jan 19, 2012 at 06:20:15PM +0100, Jean-Michel Pour? - GOOZE wrote:
> Dear Damien Miller and friends,
> 
> > No, I haven't started working on it yet for lack of smartcard
> > hardware.
> > I (or someone else) will probably get around to it sooner or later,
> > but
> > it will go quicker if I can get a supported USB smartcard on OpenBSD. 
> 
> GOOZE would be glad to support such a project donating 10 ePass2003 to
> interested OpenSSH developers. 
> 
> The ePass2003 is fully supported under GNU/Linux, FreeBSD and Windows:
> http://www.gooze.eu/epass-2003
> 

The OpenSC stack is horrendously ugly, for various reasons. I've never been
able to get it to work (with three different cards), and apparently neither
has Apple, who attempted to integrate it but failed (I've never been able to
get a smart card to work in OS X).

In my opinion (not that anyone should care), I'd say that the best bang for
a developer's buck would be to only support smartcards that follow the
Personal Identity Verification (PIV) NIST standard, which specifies the wire
protocol for basic crypto operations like signing, etc. All new US
government crypto tokens must support this, AFAIU, and it's becoming quite
common.

Does the ePass2003 support PIV?

From jmpoure at gooze.eu  Fri Jan 20 05:23:41 2012
From: jmpoure at gooze.eu (Jean-Michel =?ISO-8859-1?Q?Pour=E9?= - GOOZE)
Date: Thu, 19 Jan 2012 19:23:41 +0100
Subject: pkcs and host keys
In-Reply-To: <20120119175715.GA16818@wilbur.25thandClement.com>
References: <CAPKO79sZLa+yAzWEXh=Py0ahytpK8-S8N3ASkQEaFB69LzjD0Q@mail.gmail.com>
 <alpine.BSO.2.00.1109031104380.14401@natsu.mindrot.org>
 <1326993615.4661.10.camel@acer>
 <20120119175715.GA16818@wilbur.25thandClement.com>
Message-ID: <1326997421.3062.9.camel@acer>

Dear William,

> able to get it to work (with three different cards), and apparently
neither
> has Apple, who attempted to integrate it but failed (I've never been
> able to
> get a smart card to work in OS X).

That's a pity you did not buy the right products. But never say "never".

A lot of smartcards/tokens have partial OpenSC implementation.
Smartcards and tokens are also usually quite expensive, because vendors
like to change hardware and drivers. 

This is not the case of our products, which work perfectly and
unexpensive.

Just have a look at our tutorials:
http://www.gooze.eu/tutorials

OpenSSH client with pkcs12 works like a charm.

Under GNU/linux and FreeBSD, there were a couple of nasty bugs,
including libmtp disconnecting the smartcard/token. Or libusb with a
race condition. But this was fixed. Check our guide:
http://www.gooze.eu/howto/smartcard-quickstarter-guide/gnu-linux-installation

If you send me your address privately, I can donate you a couple of free
products so you change your mind.

> In my opinion (not that anyone should care), I'd say that the best
> bang for
> a developer's buck would be to only support smartcards that follow the
> Personal Identity Verification (PIV) NIST standard, which specifies
> the wire
> protocol for basic crypto operations like signing, etc. All new US
> government crypto tokens must support this, AFAIU, and it's becoming
> quite
> common.

PIV are outdated and frankly the ePass2003 is based on a SINGLE
integrated ST Microelectronics chip with EAL5+ certification. This is
quite a revolutionary token which weights only 6 gramms. Because of high
integration, it is way much cheaper. Only 14.90? per unit, people buying
100 units, the cost is only 9,9?

We will soon offer cables for plugging the token directly on motherboard
internal USB ports. So securing a server key could become very easy and
cheap.

Kind regards,
Jean-Michel
-- 
                  Jean-Michel Pour? - Gooze - http://www.gooze.eu
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6022 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20120119/3d516615/attachment.bin>

From william at 25thandClement.com  Fri Jan 20 06:54:07 2012
From: william at 25thandClement.com (William Ahern)
Date: Thu, 19 Jan 2012 11:54:07 -0800
Subject: pkcs and host keys
In-Reply-To: <1326997421.3062.9.camel@acer>
References: <CAPKO79sZLa+yAzWEXh=Py0ahytpK8-S8N3ASkQEaFB69LzjD0Q@mail.gmail.com>
 <alpine.BSO.2.00.1109031104380.14401@natsu.mindrot.org>
 <1326993615.4661.10.camel@acer>
 <20120119175715.GA16818@wilbur.25thandClement.com>
 <1326997421.3062.9.camel@acer>
Message-ID: <20120119195407.GA8965@wilbur.25thandClement.com>

On Thu, Jan 19, 2012 at 07:23:41PM +0100, Jean-Michel Pour? - GOOZE wrote:
> Dear William,
> 
> > able to get it to work (with three different cards), and apparently
> neither
> > has Apple, who attempted to integrate it but failed (I've never been
> > able to
> > get a smart card to work in OS X).
> 
> That's a pity you did not buy the right products. But never say "never".

The first product I ever bought was the Schlumberger Cryptoflex, which at
the time was *the* best supported chip for OpenSC. It was still a disaster.
I couldn't even be sure it was using the builtin operations (via the PKCS11
interface) instead of just the fancy flash drive PKCS12 mode. 10 years later
the whole industry is still a disaster from a software perspective.

When my concern is the privacy and integrity of my token and its private
key, having to deal with a huge, broken software stack does not build
confidence. If I have to question the ingegrity of the software stack, I
might as well just rely on my .ssh/id_dsa key.

> A lot of smartcards/tokens have partial OpenSC implementation.
> Smartcards and tokens are also usually quite expensive, because vendors
> like to change hardware and drivers. 
> 
> This is not the case of our products, which work perfectly and
> unexpensive.

How can you guarantee--or at least address the concern--that your vendor
won't discontinue the chip and start selling a new chip that requires a new
driver? For example, is the ePass2003 backwards compatible with the ePass?
Granted, I suppose 9 years is a good run. But what about, for example, the
ePass201x? I wouldn't be surprised if SHA-1 is severely broken in the next 5
years, so the ePass2003 seems like it should be near its end-of-life if it
can't do SHA-2, or the SHA-3 (which should be published soon).

This has been the problem with these cards all along. The chips come and go,
and each new chip has a totally different interface. It's ridiculous. The
industry is driven by fad after fad, each vendor simultaneously trying to
lock-in their customers while trying to address the dismal state of
interoperability caused by vendor lock-in in general.

<snip>
> PIV are outdated and frankly the ePass2003 is based on a SINGLE
> integrated ST Microelectronics chip with EAL5+ certification.

Does ISO 7816-8 provide a similar specification to PIV (and NIST SPs 800-73
and 800-78)? And if so, is it more widely supported by other chips? CCID is
by itself insufficient, though I've wondered if you could build a
maintainable stack using a domain specific script language tuned to CCID so
that "drivers" could be plain-text and much simpler to write.

> This is quite a revolutionary token which weights only 6 gramms.

I have no doubt that it's a great token. (I've almost purchased the
ePass2003 from Gooze several times, and as far as I can tell your shop is
definitely the best around.) But the issue, IMO, isn't which token is the
best. It's how best to support tokens in general with a minimal amount of
support code.

I don't mean to come across as combative. I'm just passionate about the
adoption of crypto tokens, but don't see it happening until the software
issues are resolved.


From keisial at gmail.com  Fri Jan 20 08:38:07 2012
From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=)
Date: Thu, 19 Jan 2012 22:38:07 +0100
Subject: ChrootDirectory per SSH Subsystem?
In-Reply-To: <A4ABB1C0A2EA784DA4EA6EDF7762E2DD19571DEA@ESESSCMS0360.eemea.ericsson.se>
References: <A4ABB1C0A2EA784DA4EA6EDF7762E2DD19571DE7@ESESSCMS0360.eemea.ericsson.se>
 <4F1838FD.90300@gmail.com>
 <A4ABB1C0A2EA784DA4EA6EDF7762E2DD19571DEA@ESESSCMS0360.eemea.ericsson.se>
Message-ID: <4F188D3F.2070609@gmail.com>

El 19/01/12 17:16, John Olsson M wrote:
>> Place a couple of wrappers around the commands, doing the chroot for you?
> Hmmm. I'm not sure I follow you. Our command shell (which is not like a standard *nix shell) needs to operate in a non-chrooted environment. But the file system shown by the SFTP subsystem needs to operate in a chroot:ed environemnt and only expose that subset of directories and files.
(...)
What I was proposing was that you would have something like:
Subsystem sftp /usr/local/libexec/cliss-sftp-server

With cliss-sftp-server doing something like:
mkdir -p "/tmp/cliss-mount-$USER"
test -d "/tmp/cliss-mount-$USER/bin" || sudo -u "$USER" cliss.mount none 
"/tmp/cliss-mount-$USER" || exit 1
exec chroot --userspec="$USER" "/tmp/cliss-mount-$USER" 
/usr/libexec/ssh/sftp-server

(it can't be implemented as a shell script, since you would want to make 
it suid, but you get the idea)


From mouring at offwriting.org  Fri Jan 20 09:00:39 2012
From: mouring at offwriting.org (Ben Lindstrom)
Date: Thu, 19 Jan 2012 16:00:39 -0600
Subject: ChrootDirectory per SSH Subsystem?
In-Reply-To: <A4ABB1C0A2EA784DA4EA6EDF7762E2DD19571DE7@ESESSCMS0360.eemea.ericsson.se>
References: <A4ABB1C0A2EA784DA4EA6EDF7762E2DD19571DE7@ESESSCMS0360.eemea.ericsson.se>
Message-ID: <CF0FAD4C-BCF1-4834-8AD6-4D7C5CFFD061@offwriting.org>


On Jan 19, 2012, at 7:38 AM, John Olsson M wrote:

> Hi,
> 
> According to the sshd_config manual page the option ChrootDirectory can be used to force a chroot:ed environment for the SSHD server. But as I understand the manual page this is a global setting and it is not possible to specify this per SSH subsystem.
> 
> We are building a system where we need users to be able to log on from remote machines via SSH, but with the tweaks that we (for security reasons) for SFTP-sessions only want to show a virtual filesystem and "standard" SSH subsystem leads to our own shell offering only our own commands. Unfortunately, there is a conflict between what we want to show via an SFTP session and what the shell needs to be able to access.
> 
> What is your take on this? Is getting the desired behavior above an RTFM? Or are we entering the land of patching the source code? If the latter, do you have feeling for if is a small or huge undertaking (both implementing and maintaining)?
> 
> Would such an enhancement be something that could be accepted into the main development trunk, or do you have concerns over the concept of being able to override the global setting per SSH subsystem?

What you really want is for someone to extend:

     Match   Introduces a conditional block.  If all of the criteria on the Match line are satisfied, the keywords on the following lines override
             those set in the global section of the config file, until either another Match line or the end of the file.

             The arguments to Match are one or more criteria-pattern pairs.  The available criteria are User, Group, Host, and Address.  The match
             patterns may consist of single entries or comma-separated lists and may use the wildcard and negation operators described in the
             PATTERNS section of ssh_config(5).

So it can be used to support Subsystem.   e.g.

Match Subsystem sftp
	ChrootDirectory /path/to/chroot/

Which of course it doesn't at this point.  But I can see it being a very useful addition in cases where you want new subsystem be limited in the drive exposure.

Mind you like all things it isn't perfect if you allow something that is a real shell, but like with all tools one has to understand how to deploy them.

- Ben



From john.m.olsson at ericsson.com  Fri Jan 20 18:29:40 2012
From: john.m.olsson at ericsson.com (John Olsson M)
Date: Fri, 20 Jan 2012 08:29:40 +0100
Subject: ChrootDirectory per SSH Subsystem?
In-Reply-To: <4F188D3F.2070609@gmail.com>
References: <A4ABB1C0A2EA784DA4EA6EDF7762E2DD19571DE7@ESESSCMS0360.eemea.ericsson.se>
 <4F1838FD.90300@gmail.com>
 <A4ABB1C0A2EA784DA4EA6EDF7762E2DD19571DEA@ESESSCMS0360.eemea.ericsson.se>
 <4F188D3F.2070609@gmail.com>
Message-ID: <A4ABB1C0A2EA784DA4EA6EDF7762E2DD19571DEE@ESESSCMS0360.eemea.ericsson.se>

Thank you! I'll look into your suggestion to see if it is good-enough short-term solution for us or not.

-----Original Message-----
From: ?ngel Gonz?lez [mailto:keisial at gmail.com] 
Sent: den 19 januari 2012 22:38
To: John Olsson M
Cc: 'openssh-unix-dev at mindrot.org'
Subject: Re: ChrootDirectory per SSH Subsystem?

El 19/01/12 17:16, John Olsson M wrote:
>> Place a couple of wrappers around the commands, doing the chroot for you?
> Hmmm. I'm not sure I follow you. Our command shell (which is not like a standard *nix shell) needs to operate in a non-chrooted environment. But the file system shown by the SFTP subsystem needs to operate in a chroot:ed environemnt and only expose that subset of directories and files.
(...)
What I was proposing was that you would have something like:
Subsystem sftp /usr/local/libexec/cliss-sftp-server

With cliss-sftp-server doing something like:
mkdir -p "/tmp/cliss-mount-$USER"
test -d "/tmp/cliss-mount-$USER/bin" || sudo -u "$USER" cliss.mount none "/tmp/cliss-mount-$USER" || exit 1 exec chroot --userspec="$USER" "/tmp/cliss-mount-$USER" 
/usr/libexec/ssh/sftp-server

(it can't be implemented as a shell script, since you would want to make it suid, but you get the idea)


From john.m.olsson at ericsson.com  Fri Jan 20 18:29:46 2012
From: john.m.olsson at ericsson.com (John Olsson M)
Date: Fri, 20 Jan 2012 08:29:46 +0100
Subject: ChrootDirectory per SSH Subsystem?
In-Reply-To: <CF0FAD4C-BCF1-4834-8AD6-4D7C5CFFD061@offwriting.org>
References: <A4ABB1C0A2EA784DA4EA6EDF7762E2DD19571DE7@ESESSCMS0360.eemea.ericsson.se>
 <CF0FAD4C-BCF1-4834-8AD6-4D7C5CFFD061@offwriting.org>
Message-ID: <A4ABB1C0A2EA784DA4EA6EDF7762E2DD19571DEF@ESESSCMS0360.eemea.ericsson.se>

> What you really want is for someone to extend:
>
>     Match   Introduces a conditional block.
--snip--
> So it can be used to support Subsystem.   e.g.
> 
> Match Subsystem sftp
>	ChrootDirectory /path/to/chroot/
>
> Which of course it doesn't at this point.  But I can see it being a very
> useful addition in cases where you want new subsystem be limited in the
> drive exposure.

Yes! That is exactly what I was looking for. :)

Before diving into the source code and trying to figure out how to accomplish that does anyone have any feeling for the size of such an undertaking? Anything special one should consider/have in mind when implementing it?


> Mind you like all things it isn't perfect if you allow something that is
> a real shell, but like with all tools one has to understand how to
> deploy them.

I agree with you 100% here. :)


/John

-----Original Message-----
From: Ben Lindstrom [mailto:mouring at offwriting.org] 
Sent: den 19 januari 2012 23:01
To: John Olsson M
Cc: 'openssh-unix-dev at mindrot.org'
Subject: Re: ChrootDirectory per SSH Subsystem?


On Jan 19, 2012, at 7:38 AM, John Olsson M wrote:

> Hi,
> 
> According to the sshd_config manual page the option ChrootDirectory can be used to force a chroot:ed environment for the SSHD server. But as I understand the manual page this is a global setting and it is not possible to specify this per SSH subsystem.
> 
> We are building a system where we need users to be able to log on from remote machines via SSH, but with the tweaks Match Subsystem sftp
	ChrootDirectory /path/to/chroot/

Which of course it doesn't at this point.  But I can see it being a very useful addition in cases where you want new subsystem be limited in the drive exposure.

Mind you like all things it isn't perfect if you allow something that is a real shell, but like with all tools one has to understand how to deploy them.So it can be used to support Subsystem.   e.g.

Match Subsystem sftp
	ChrootDirectory /path/to/chroot/

Which of course it doesn't at this point.  But I can see it being a very useful addition in cases where you want new subsystem be limited in the drive exposure.that we (for security reasons) for SFTP-sessions only want to show a virtual filesystem and "standard" SSH subsystem leads to our own shell offering only our own commands. Unfortunately, there is a conflict between what we want to show via an SFTP session and what the shell needs to be able to access.
> 
> What is your take on this? Is getting the desired behavior above an RTFM? Or are we entering the land of patching the source code? If the latter, do you have feeling for if is a small or huge undertaking (both implementing and maintaining)?
> 
> Would such an enhancement be something that could be accepted into the main development trunk, or do you have concerns over the concept of being able to override the global setting per SSH subsystem?

What you really want is for someone to extend:

     Match   Introduces a conditional block.  If all of the criteria on the Match line are satisfied, the keywords on the following lines override
             those set in the global section of the config file, until either another Match line or the end of the file.

             The arguments to Match are one or more criteria-pattern pairs.  The available criteria are User, Group, Host, and Address.  The match
             patterns may consist of single entries or comma-separated lists and may use the wildcard and negation operators described in the
             PATTERNS section of ssh_config(5).

So it can be used to support Subsystem.   e.g.

Match Subsystem sftp
	ChrootDirectory /path/to/chroot/

Which of course it doesn't at this point.  But I can see it being a very useful addition in cases where you want new subsystem be limited in the drive exposure.

Mind you like all things it isn't perfect if you allow something that is a real shell, but like with all tools one has to understand how to deploy them.

- Ben



From jmpoure at gooze.eu  Fri Jan 20 20:08:20 2012
From: jmpoure at gooze.eu (Jean-Michel =?ISO-8859-1?Q?Pour=E9?= - GOOZE)
Date: Fri, 20 Jan 2012 10:08:20 +0100
Subject: Donation of 10 ePass2003 to the OpenSSH project
Message-ID: <1327050500.3172.24.camel@acer>

Dear all,

There were a lot of discussions about smartcards and tokens, and we
would like to make a simple offer: donate to each OpenSSH developer an
ePass2003.

The ePass2003 relies on one single chip and the most advanced OpenSC
token available to date. It is also the cheapest token of all times.

Read a description here:
http://www.gooze.eu/epass-2003

Documentation:
http://www.gooze.eu/howto/smartcard-quickstarter-guide

CD download:
http://download.gooze.eu/pki/iso/

The ePass2003 would be the ideal companion of OpenSSH to protect the
server key. If you are interested by the ePass2003 and you are an
OpenSSH contributor (not only user, you should be a past contributor),
you may request a free ePass2003 here:
http://www.gooze.eu/feitian-epass-2003-free-software-developer-kit

Hoping the best to help the OpenSSH community.

Kind regards,
-- 
                  Jean-Michel Pour? - Gooze - http://www.gooze.eu
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6022 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20120120/a42f5463/attachment.bin>

From dan at doxpara.com  Fri Jan 20 20:18:47 2012
From: dan at doxpara.com (Dan Kaminsky)
Date: Fri, 20 Jan 2012 04:18:47 -0500
Subject: Regarding Pubkey Enumeration
Message-ID: <CAEW7ACnWhVJeVNLgeTHT=b=+HFmEG6EdsUt=EMzaMDdT1e9DTw@mail.gmail.com>

HD Moore from MetaSploit has noted that, given a pubkey (and not the
corresponding private key, as might be found in authorized_keys), he can
determine if he'd be able to log into an account.

It's a small thing, but he's using it for very interesting
recon/deanonymization.  He'll be releasing a paper shortly, not overplaying
the characteristic, but certainly showing it can be used to do cute things.

I expect this is easily fixable -- simply provide the challenge for a
pubkey whether or not it'd actually be able to log in successfully.  But
it's worth exploring this space -- perhaps some clients behave badly.

--Dan

From djm at mindrot.org  Sat Jan 21 08:27:12 2012
From: djm at mindrot.org (Damien Miller)
Date: Sat, 21 Jan 2012 08:27:12 +1100 (EST)
Subject: Regarding Pubkey Enumeration
In-Reply-To: <CAEW7ACnWhVJeVNLgeTHT=b=+HFmEG6EdsUt=EMzaMDdT1e9DTw@mail.gmail.com>
References: <CAEW7ACnWhVJeVNLgeTHT=b=+HFmEG6EdsUt=EMzaMDdT1e9DTw@mail.gmail.com>
Message-ID: <alpine.BSO.2.00.1201210824500.17846@natsu.mindrot.org>

This is a deliberate feature - it allows testing whether a pubkey can
log in without the need to unwrap a private key, an action that may
require a passphrase or token PIN.

It's been discussed a bit here and elsewhere in the past and we've
always concluded that it isn't worth turning off or providing a knob
for.

On Fri, 20 Jan 2012, Dan Kaminsky wrote:

> HD Moore from MetaSploit has noted that, given a pubkey (and not the
> corresponding private key, as might be found in authorized_keys), he can
> determine if he'd be able to log into an account.
> 
> It's a small thing, but he's using it for very interesting
> recon/deanonymization.  He'll be releasing a paper shortly, not overplaying
> the characteristic, but certainly showing it can be used to do cute things.
> 
> I expect this is easily fixable -- simply provide the challenge for a
> pubkey whether or not it'd actually be able to log in successfully.  But
> it's worth exploring this space -- perhaps some clients behave badly.
> 
> --Dan
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
> 

From djm at mindrot.org  Sat Jan 21 08:28:28 2012
From: djm at mindrot.org (Damien Miller)
Date: Sat, 21 Jan 2012 08:28:28 +1100 (EST)
Subject: Donation of 10 ePass2003 to the OpenSSH project
In-Reply-To: <1327050500.3172.24.camel@acer>
References: <1327050500.3172.24.camel@acer>
Message-ID: <alpine.BSO.2.00.1201210827200.17846@natsu.mindrot.org>

On Fri, 20 Jan 2012, Jean-Michel Pour? - GOOZE wrote:

> Dear all,
> 
> There were a lot of discussions about smartcards and tokens, and we
> would like to make a simple offer: donate to each OpenSSH developer an
> ePass2003.
> 
> The ePass2003 relies on one single chip and the most advanced OpenSC
> token available to date. It is also the cheapest token of all times.
> 
> Read a description here:
> http://www.gooze.eu/epass-2003
> 
> Documentation:
> http://www.gooze.eu/howto/smartcard-quickstarter-guide
> 
> CD download:
> http://download.gooze.eu/pki/iso/
> 
> The ePass2003 would be the ideal companion of OpenSSH to protect the
> server key. If you are interested by the ePass2003 and you are an
> OpenSSH contributor (not only user, you should be a past contributor),
> you may request a free ePass2003 here:
> http://www.gooze.eu/feitian-epass-2003-free-software-developer-kit
> 
> Hoping the best to help the OpenSSH community.

Hi,

So the last time I tried to take advantage of an offer of the Feitian
tokens for open source developers I was told that I was ineligible because
I'm located in Australia.

If this requirement exists no more then we're interested.

-d

From dan at doxpara.com  Sat Jan 21 08:39:29 2012
From: dan at doxpara.com (Dan Kaminsky)
Date: Fri, 20 Jan 2012 16:39:29 -0500
Subject: Regarding Pubkey Enumeration
In-Reply-To: <alpine.BSO.2.00.1201210824500.17846@natsu.mindrot.org>
References: <CAEW7ACnWhVJeVNLgeTHT=b=+HFmEG6EdsUt=EMzaMDdT1e9DTw@mail.gmail.com>
 <alpine.BSO.2.00.1201210824500.17846@natsu.mindrot.org>
Message-ID: <BEBD54FA-FE1B-474B-91CC-633EF8899446@doxpara.com>

Eh, you wouldn't support a feature that only displayed a password prompt if the username was valid.  Same thing, very similar experience even.

Sent from my iPhone

On Jan 20, 2012, at 4:27 PM, Damien Miller <djm at mindrot.org> wrote:

> This is a deliberate feature - it allows testing whether a pubkey can
> log in without the need to unwrap a private key, an action that may
> require a passphrase or token PIN.
> 
> It's been discussed a bit here and elsewhere in the past and we've
> always concluded that it isn't worth turning off or providing a knob
> for.
> 
> On Fri, 20 Jan 2012, Dan Kaminsky wrote:
> 
>> HD Moore from MetaSploit has noted that, given a pubkey (and not the
>> corresponding private key, as might be found in authorized_keys), he can
>> determine if he'd be able to log into an account.
>> 
>> It's a small thing, but he's using it for very interesting
>> recon/deanonymization.  He'll be releasing a paper shortly, not overplaying
>> the characteristic, but certainly showing it can be used to do cute things.
>> 
>> I expect this is easily fixable -- simply provide the challenge for a
>> pubkey whether or not it'd actually be able to log in successfully.  But
>> it's worth exploring this space -- perhaps some clients behave badly.
>> 
>> --Dan
>> _______________________________________________
>> openssh-unix-dev mailing list
>> openssh-unix-dev at mindrot.org
>> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>> 

From djm at mindrot.org  Sat Jan 21 08:43:51 2012
From: djm at mindrot.org (Damien Miller)
Date: Sat, 21 Jan 2012 08:43:51 +1100 (EST)
Subject: Regarding Pubkey Enumeration
In-Reply-To: <BEBD54FA-FE1B-474B-91CC-633EF8899446@doxpara.com>
References: <CAEW7ACnWhVJeVNLgeTHT=b=+HFmEG6EdsUt=EMzaMDdT1e9DTw@mail.gmail.com>
 <alpine.BSO.2.00.1201210824500.17846@natsu.mindrot.org>
 <BEBD54FA-FE1B-474B-91CC-633EF8899446@doxpara.com>
Message-ID: <alpine.BSO.2.00.1201210842420.17846@natsu.mindrot.org>

On Fri, 20 Jan 2012, Dan Kaminsky wrote:

> Eh, you wouldn't support a feature that only displayed a password prompt if the username was valid.  Same thing, very similar experience even.

It isn't the same thing at all. Usernames are short, low-entropy and highly
common between systems. Public keys are none of these.

-d

From dan at doxpara.com  Sat Jan 21 08:50:08 2012
From: dan at doxpara.com (Dan Kaminsky)
Date: Fri, 20 Jan 2012 16:50:08 -0500
Subject: Regarding Pubkey Enumeration
In-Reply-To: <alpine.BSO.2.00.1201210842420.17846@natsu.mindrot.org>
References: <CAEW7ACnWhVJeVNLgeTHT=b=+HFmEG6EdsUt=EMzaMDdT1e9DTw@mail.gmail.com>
 <alpine.BSO.2.00.1201210824500.17846@natsu.mindrot.org>
 <BEBD54FA-FE1B-474B-91CC-633EF8899446@doxpara.com>
 <alpine.BSO.2.00.1201210842420.17846@natsu.mindrot.org>
Message-ID: <EF7D0FA6-A773-4D44-B842-D486DB9282F4@doxpara.com>



Sent from my iPhone

On Jan 20, 2012, at 4:43 PM, Damien Miller <djm at mindrot.org> wrote:

> On Fri, 20 Jan 2012, Dan Kaminsky wrote:
> 
>> Eh, you wouldn't support a feature that only displayed a password prompt if the username was valid.  Same thing, very similar experience even.
> 
> It isn't the same thing at all. Usernames are short, low-entropy and highly
> common between systems. Public keys are none of these.
> 

HD is raiding authorized_keys files to successfully get around this limitation -- there's a reason we call them public keys.  Also the very fact that public keys are only conditionally common between systems is an issue, as it's strongly deanonymizing nodes.

It's the same UI to type in a password vs. a pass phrase, and we don't bypass the former just because there's no value that could work.  It's odd indeed for public key security to be visibly weaker than password.

> -d

From djm at mindrot.org  Sat Jan 21 09:04:12 2012
From: djm at mindrot.org (Damien Miller)
Date: Sat, 21 Jan 2012 09:04:12 +1100 (EST)
Subject: Regarding Pubkey Enumeration
In-Reply-To: <EF7D0FA6-A773-4D44-B842-D486DB9282F4@doxpara.com>
References: <CAEW7ACnWhVJeVNLgeTHT=b=+HFmEG6EdsUt=EMzaMDdT1e9DTw@mail.gmail.com>
 <alpine.BSO.2.00.1201210824500.17846@natsu.mindrot.org>
 <BEBD54FA-FE1B-474B-91CC-633EF8899446@doxpara.com>
 <alpine.BSO.2.00.1201210842420.17846@natsu.mindrot.org>
 <EF7D0FA6-A773-4D44-B842-D486DB9282F4@doxpara.com>
Message-ID: <alpine.BSO.2.00.1201210853080.17846@natsu.mindrot.org>

On Fri, 20 Jan 2012, Dan Kaminsky wrote:

> 
> On Jan 20, 2012, at 4:43 PM, Damien Miller <djm at mindrot.org> wrote:
> 
> > On Fri, 20 Jan 2012, Dan Kaminsky wrote:
> > 
> >> Eh, you wouldn't support a feature that only displayed a password prompt if the username was valid.  Same thing, very similar experience even.
> > 
> > It isn't the same thing at all. Usernames are short, low-entropy and highly
> > common between systems. Public keys are none of these.
> > 
>
> HD is raiding authorized_keys files to successfully get around this
> limitation -- there's a reason we call them public keys. Also the very
> fact that public keys are only conditionally common between systems is
> an issue, as it's strongly deanonymizing nodes.

If you have popped an account, then there are myriad sources of data
that you can use to determined linked hosts (known_hosts, lastlog, shell
history, [uw]tmp, etc.).

> It's the same UI to type in a password vs. a pass phrase, and we don't
> bypass the former just because there's no value that could work. It's
> odd indeed for public key security to be visibly weaker than password.

That's because it isn't by any normal definition. The most you've shown
is that, given a public key that is never transmitted in the clear by
SSH, you can test hosts to find where its private half might be accepted.
I'm struggling to see why this is interesting.

-d


From dan at doxpara.com  Sat Jan 21 09:13:24 2012
From: dan at doxpara.com (Dan Kaminsky)
Date: Fri, 20 Jan 2012 17:13:24 -0500
Subject: Regarding Pubkey Enumeration
In-Reply-To: <alpine.BSO.2.00.1201210853080.17846@natsu.mindrot.org>
References: <CAEW7ACnWhVJeVNLgeTHT=b=+HFmEG6EdsUt=EMzaMDdT1e9DTw@mail.gmail.com>
 <alpine.BSO.2.00.1201210824500.17846@natsu.mindrot.org>
 <BEBD54FA-FE1B-474B-91CC-633EF8899446@doxpara.com>
 <alpine.BSO.2.00.1201210842420.17846@natsu.mindrot.org>
 <EF7D0FA6-A773-4D44-B842-D486DB9282F4@doxpara.com>
 <alpine.BSO.2.00.1201210853080.17846@natsu.mindrot.org>
Message-ID: <649C4D39-2B43-4E3D-BFCA-4EE396D30420@doxpara.com>



Sent from my iPhone

On Jan 20, 2012, at 5:04 PM, Damien Miller <djm at mindrot.org> wrote:

> On Fri, 20 Jan 2012, Dan Kaminsky wrote:
> 
>> 
>> On Jan 20, 2012, at 4:43 PM, Damien Miller <djm at mindrot.org> wrote:
>> 
>>> On Fri, 20 Jan 2012, Dan Kaminsky wrote:
>>> 
>>>> Eh, you wouldn't support a feature that only displayed a password prompt if the username was valid.  Same thing, very similar experience even.
>>> 
>>> It isn't the same thing at all. Usernames are short, low-entropy and highly
>>> common between systems. Public keys are none of these.
>>> 
>> 
>> HD is raiding authorized_keys files to successfully get around this
>> limitation -- there's a reason we call them public keys. Also the very
>> fact that public keys are only conditionally common between systems is
>> an issue, as it's strongly deanonymizing nodes.
> 
> If you have popped an account, then there are myriad sources of data
> that you can use to determined linked hosts (known_hosts, lastlog, shell
> history, [uw]tmp, etc.).

Yeah, those only work on transitive links, Alice to Bob to Charlie. They do nothing for Alice to Bob leaking info about Alice on Charlie. 

> 
>> It's the same UI to type in a password vs. a pass phrase, and we don't
>> bypass the former just because there's no value that could work. It's
>> odd indeed for public key security to be visibly weaker than password.
> 
> That's because it isn't by any normal definition. The most you've shown
> is that, given a public key that is never transmitted in the clear by
> SSH, you can test hosts to find where its private half might be accepted.
> I'm struggling to see why this is interesting.

It's a small find (and not mine -- it's HD Moore's). But he'll be releasing a paper shortly about how it's been really useful to take keys grabbed out of authorized_keys files and iterate across other hosts to do relationship mapping. I'll see if I can't get him to give you a preview. He's got a point; this is useful stuff even if outside the Code Execution  realm. 


> 
> -d
> 

From jmpoure at gooze.eu  Sat Jan 21 09:13:47 2012
From: jmpoure at gooze.eu (Jean-Michel =?ISO-8859-1?Q?Pour=E9?= - GOOZE)
Date: Fri, 20 Jan 2012 23:13:47 +0100
Subject: Donation of 10 ePass2003 to the OpenSSH project
In-Reply-To: <alpine.BSO.2.00.1201210827200.17846@natsu.mindrot.org>
References: <1327050500.3172.24.camel@acer>
 <alpine.BSO.2.00.1201210827200.17846@natsu.mindrot.org>
Message-ID: <1327097627.4303.5.camel@acer>

Le samedi 21 janvier 2012 ? 08:28 +1100, Damien Miller a ?crit :
> So the last time I tried to take advantage of an offer of the Feitian
> tokens for open source developers I was told that I was ineligible
> because
> I'm located in Australia.
> 
> If this requirement exists no more then we're interested. 

Dear Damien,

The ePass2003 is eligible for export to most countries, including
Australia, US, Japan and Canada. Please apply here:
http://www.gooze.eu/feitian-epass-2003-free-software-developer-kit

Kind regards,
-- 
                  Jean-Michel Pour? - Gooze - http://www.gooze.eu
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6022 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20120120/f26c92df/attachment-0001.bin>

From keisial at gmail.com  Sat Jan 21 11:13:38 2012
From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=)
Date: Sat, 21 Jan 2012 01:13:38 +0100
Subject: Regarding Pubkey Enumeration
In-Reply-To: <alpine.BSO.2.00.1201210853080.17846@natsu.mindrot.org>
References: <CAEW7ACnWhVJeVNLgeTHT=b=+HFmEG6EdsUt=EMzaMDdT1e9DTw@mail.gmail.com>
 <alpine.BSO.2.00.1201210824500.17846@natsu.mindrot.org>
 <BEBD54FA-FE1B-474B-91CC-633EF8899446@doxpara.com>
 <alpine.BSO.2.00.1201210842420.17846@natsu.mindrot.org>
 <EF7D0FA6-A773-4D44-B842-D486DB9282F4@doxpara.com>
 <alpine.BSO.2.00.1201210853080.17846@natsu.mindrot.org>
Message-ID: <4F1A0332.5030804@gmail.com>

On 20/01/12 23:04, Damien Miller wrote:
> On Fri, 20 Jan 2012, Dan Kaminsky wrote:
>
>> HD is raiding authorized_keys files to successfully get around this 
>> limitation -- there's a reason we call them public keys. Also the 
>> very fact that public keys are only conditionally common between 
>> systems is an issue, as it's strongly deanonymizing nodes. 
> If you have popped an account, then there are myriad sources of data
> that you can use to determined linked hosts (known_hosts, lastlog, shell
> history, [uw]tmp, etc.).
>
>> It's the same UI to type in a password vs. a pass phrase, and we don't
>> bypass the former just because there's no value that could work. It's
>> odd indeed for public key security to be visibly weaker than password.
> That's because it isn't by any normal definition. The most you've shown
> is that, given a public key that is never transmitted in the clear by
> SSH, you can test hosts to find where its private half might be accepted.
> I'm struggling to see why this is interesting.
>
> -d
Isn't that public key also sent in SSH2_MSG_USERAUTH_REQUEST?

When you connect to a low-trust server, it could be enumerating the 
presented
public key identities, and then testing if any of those is accepted by a 
target server.

Suppose that there is a page critizising a technologic company, which 
suspects
it's run by one of its multiple employees. The company could test the 
server with
the public keys of their employees until it finds one that matches. Even 
if he used
a different public key, the company server could fetch keys not copied 
to it from the
user agents to find it out (this assumes the username is known and 
IdentitiesOnly
wasn't set).

On the other hand, that also allows a unificated login, where servers 
will accept a
user key if-and-only-if they would be accepted by a central server.



From djm at mindrot.org  Sat Jan 21 23:53:32 2012
From: djm at mindrot.org (Damien Miller)
Date: Sat, 21 Jan 2012 23:53:32 +1100 (EST)
Subject: Regarding Pubkey Enumeration
In-Reply-To: <4F1A0332.5030804@gmail.com>
References: <CAEW7ACnWhVJeVNLgeTHT=b=+HFmEG6EdsUt=EMzaMDdT1e9DTw@mail.gmail.com>
 <alpine.BSO.2.00.1201210824500.17846@natsu.mindrot.org>
 <BEBD54FA-FE1B-474B-91CC-633EF8899446@doxpara.com>
 <alpine.BSO.2.00.1201210842420.17846@natsu.mindrot.org>
 <EF7D0FA6-A773-4D44-B842-D486DB9282F4@doxpara.com>
 <alpine.BSO.2.00.1201210853080.17846@natsu.mindrot.org>
 <4F1A0332.5030804@gmail.com>
Message-ID: <alpine.BSO.2.00.1201212339540.1915@natsu.mindrot.org>

On Sat, 21 Jan 2012, ?ngel Gonz?lez wrote:

> Isn't that public key also sent in SSH2_MSG_USERAUTH_REQUEST?

That's the packet that contains the public key when authenticating or
testing whether a key has a chance of being accepted.

> When you connect to a low-trust server, it could be enumerating the presented
> public key identities, and then testing if any of those is accepted by a
> target server.

First, this attack would work without public key confirmation. Your client
would still need to try every key that it knows about to connect, and your
compromised server would have the same opportunity to collect them. The
most that turning off key compromisation might buy you in this situation
is to provide a little more pressure on users who need to enter PINs or
use key confirmation ("ssh-add -c") to explicitly configure which keys
are used by annoying them with more PIN/confirm dialogs.

You can already limit which identities are used in public key authentication
by setting IdentityFile(s) for a particular host. If you don't like the idea
of keys in your agent being sprayed around, then the mechanism already exists
to avoid it.

> Suppose that there is a page critizising a technologic company, which
> suspects it's run by one of its multiple employees. The company could
> test the server with the public keys of their employees until it finds
> one that matches. Even if he used a different public key, the company
> server could fetch keys not copied to it from the user agents to find
> it out (this assumes the username is known and IdentitiesOnly wasn't
> set).

If the company has access to the user's ssh-agent then it is game
over anyway - they have the private keys. 

-d

From mfriedl at gmail.com  Sun Jan 22 03:11:39 2012
From: mfriedl at gmail.com (Markus Friedl)
Date: Sat, 21 Jan 2012 17:11:39 +0100
Subject: Regarding Pubkey Enumeration
In-Reply-To: <CAEW7ACnWhVJeVNLgeTHT=b=+HFmEG6EdsUt=EMzaMDdT1e9DTw@mail.gmail.com>
References: <CAEW7ACnWhVJeVNLgeTHT=b=+HFmEG6EdsUt=EMzaMDdT1e9DTw@mail.gmail.com>
Message-ID: <CACANGen_3hwr6W+HF-_Z1eRhRRie364LEmEVM2e5uy-TzjEL2Q@mail.gmail.com>

after twelve years, i still think that always sending
  SSH2_MSG_USERAUTH_PK_OK
for users that don't have an account is the only useful option.
back then i decided against this, because it adds complexity
and wastes CPU cycles.

sending PK_OK for uses with an account is evil as it
would force them typing the passphrase for public
keys that the server does not accept at all.

-m


On Fri, Jan 20, 2012 at 10:18 AM, Dan Kaminsky <dan at doxpara.com> wrote:
> HD Moore from MetaSploit has noted that, given a pubkey (and not the
> corresponding private key, as might be found in authorized_keys), he can
> determine if he'd be able to log into an account.
>
> It's a small thing, but he's using it for very interesting
> recon/deanonymization. ?He'll be releasing a paper shortly, not overplaying
> the characteristic, but certainly showing it can be used to do cute things.
>
> I expect this is easily fixable -- simply provide the challenge for a
> pubkey whether or not it'd actually be able to log in successfully. ?But
> it's worth exploring this space -- perhaps some clients behave badly.
>
> --Dan
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

From keisial at gmail.com  Sun Jan 22 05:08:18 2012
From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=)
Date: Sat, 21 Jan 2012 19:08:18 +0100
Subject: Regarding Pubkey Enumeration
In-Reply-To: <alpine.BSO.2.00.1201212339540.1915@natsu.mindrot.org>
References: <CAEW7ACnWhVJeVNLgeTHT=b=+HFmEG6EdsUt=EMzaMDdT1e9DTw@mail.gmail.com>
 <alpine.BSO.2.00.1201210824500.17846@natsu.mindrot.org>
 <BEBD54FA-FE1B-474B-91CC-633EF8899446@doxpara.com>
 <alpine.BSO.2.00.1201210842420.17846@natsu.mindrot.org>
 <EF7D0FA6-A773-4D44-B842-D486DB9282F4@doxpara.com>
 <alpine.BSO.2.00.1201210853080.17846@natsu.mindrot.org>
 <4F1A0332.5030804@gmail.com>
 <alpine.BSO.2.00.1201212339540.1915@natsu.mindrot.org>
Message-ID: <4F1AFF12.3070602@gmail.com>

On 21/01/12 13:53, Damien Miller wrote:
> On Sat, 21 Jan 2012, ?ngel Gonz?lez wrote:
>> Isn't that public key also sent in SSH2_MSG_USERAUTH_REQUEST?
> That's the packet that contains the public key when authenticating or
> testing whether a key has a chance of being accepted.
I'll take that as a 'yes'.

>> When you connect to a low-trust server, it could be enumerating the presented
>> public key identities, and then testing if any of those is accepted by a
>> target server.
> First, this attack would work without public key confirmation. Your client
> would still need to try every key that it knows about to connect, and your
> compromised server would have the same opportunity to collect them.
Learning the user public keys would be useless to find out the (potential)
relationship with the server if the target server didn't acknowledge 
that a key
was acceptable without a challenge signed with the private key.


> The most that turning off key compromisation might buy you in this situation
> is to provide a little more pressure on users who need to enter PINs or
> use key confirmation ("ssh-add -c") to explicitly configure which keys
> are used by annoying them with more PIN/confirm dialogs.
Good point. If it was to be removed, I think it'd have to be replaced with
providing a truncated hash of the public key, which a length such that it
would be unlikely for a single user to own several colliding keys, but 
still
likely when checking keys stolen from many users.


> You can already limit which identities are used in public key authentication
> by setting IdentityFile(s) for a particular host. If you don't like the idea
> of keys in your agent being sprayed around, then the mechanism already exists
> to avoid it.
Indeed, it requires to repeat the settings several times (you can only 
match by
Host) but the ability is already there.


>> Suppose that there is a page critizising a technologic company, which
>> suspects it's run by one of its multiple employees. The company could
>> test the server with the public keys of their employees until it finds
>> one that matches. Even if he used a different public key, the company
>> server could fetch keys not copied to it from the user agents to find
>> it out (this assumes the username is known and IdentitiesOnly wasn't
>> set).
> If the company has access to the user's ssh-agent then it is game
> over anyway - they have the private keys.
>
> -d
The scenary was that the company had access to the server, but not to the
private key or the agent, which would be eg. in a laptop owned by the 
employee.


From aris at 0xbadc0de.be  Mon Jan 23 23:32:56 2012
From: aris at 0xbadc0de.be (Aris Adamantiadis)
Date: Mon, 23 Jan 2012 13:32:56 +0100
Subject: Regarding Pubkey Enumeration
In-Reply-To: <4F1A0332.5030804@gmail.com>
References: <CAEW7ACnWhVJeVNLgeTHT=b=+HFmEG6EdsUt=EMzaMDdT1e9DTw@mail.gmail.com>
 <alpine.BSO.2.00.1201210824500.17846@natsu.mindrot.org>
 <BEBD54FA-FE1B-474B-91CC-633EF8899446@doxpara.com>
 <alpine.BSO.2.00.1201210842420.17846@natsu.mindrot.org>
 <EF7D0FA6-A773-4D44-B842-D486DB9282F4@doxpara.com>
 <alpine.BSO.2.00.1201210853080.17846@natsu.mindrot.org>
 <4F1A0332.5030804@gmail.com>
Message-ID: <4F1D5378.3060502@0xbadc0de.be>

Le 21/01/12 01:13, ?ngel Gonz?lez a ?crit :
> Suppose that there is a page critizising a technologic company, which
> suspects
> it's run by one of its multiple employees. The company could test the
> server with
> the public keys of their employees until it finds one that matches. Even
> if he used
> a different public key, the company server could fetch keys not copied
> to it from the
> user agents to find it out (this assumes the username is known and
> IdentitiesOnly
> wasn't set).

I don't understand the big deal with that "attack" (which as Damien told
was already obvious to anyone having SSH experience). The scenario
you're providing is far, far etched and gives no advantages to other
techniques (like studying the network usage logs of that employee,
seeing that he often connects to remotes hosts in SSH).
You would only catch the guys who don't connect from their office, but
still have their ssh public key on their company computer (why ?)

When you're in a pentest environment, and all you have is a public key,
a user name and an IP address + a hint that the three match together,
you're not *that* much advanced. Passwords can be bruteforced, not
private keys.

Moreover, I find strange that nobody ever complained that openssh client
leaks the whole list of your available public keys to every server you
try to connect to, even if you don't complete authentication.

Aris

From nkadel at gmail.com  Tue Jan 24 00:33:20 2012
From: nkadel at gmail.com (Nico Kadel-Garcia)
Date: Mon, 23 Jan 2012 08:33:20 -0500
Subject: Regarding Pubkey Enumeration
In-Reply-To: <4F1D5378.3060502@0xbadc0de.be>
References: <CAEW7ACnWhVJeVNLgeTHT=b=+HFmEG6EdsUt=EMzaMDdT1e9DTw@mail.gmail.com>
 <alpine.BSO.2.00.1201210824500.17846@natsu.mindrot.org>
 <BEBD54FA-FE1B-474B-91CC-633EF8899446@doxpara.com>
 <alpine.BSO.2.00.1201210842420.17846@natsu.mindrot.org>
 <EF7D0FA6-A773-4D44-B842-D486DB9282F4@doxpara.com>
 <alpine.BSO.2.00.1201210853080.17846@natsu.mindrot.org>
 <4F1A0332.5030804@gmail.com> <4F1D5378.3060502@0xbadc0de.be>
Message-ID: <CAOCN9rzh89YQwU6oXV+EZRLZTJfpiWGVi4n7KAKgyfktzWmwuw@mail.gmail.com>

On Mon, Jan 23, 2012 at 7:32 AM, Aris Adamantiadis <aris at 0xbadc0de.be> wrote:
> Le 21/01/12 01:13, ?ngel Gonz?lez a ?crit :
>> Suppose that there is a page critizising a technologic company, which
>> suspects
>> it's run by one of its multiple employees. The company could test the
>> server with
>> the public keys of their employees until it finds one that matches. Even
>> if he used
>> a different public key, the company server could fetch keys not copied
>> to it from the
>> user agents to find it out (this assumes the username is known and
>> IdentitiesOnly
>> wasn't set).
>
> I don't understand the big deal with that "attack" (which as Damien told
> was already obvious to anyone having SSH experience). The scenario
> you're providing is far, far etched and gives no advantages to other
> techniques (like studying the network usage logs of that employee,
> seeing that he often connects to remotes hosts in SSH).
> You would only catch the guys who don't connect from their office, but
> still have their ssh public key on their company computer (why ?)

Hardly. Logs that are sophisticated enough, and go back far enough, to
pin SSH traffic to a particular external host from a particular
identifiable client are awkward to maintain. They're also unreliable
in a DHCP based network setup, since especially for laptops that go
home, the IP addresses are likely to change from day to day for
employee machines and would have to be cross-correlated with the DHCP
logs.

> When you're in a pentest environment, and all you have is a public key,
> a user name and an IP address + a hint that the three match together,
> you're not *that* much advanced. Passwords can be bruteforced, not
> private keys.

Many private keys are poorly passphrase protected. Since the default
behavior of ssh-keygen allows passphrase free keys, there are one
*hell* of a lot of people who don't bother and make the common
assumption "if someone has access to my network, I have much bigger
problems" and refuse to provide any passphrase protection. (I've been
encountering that problem since the original ssh-1 was published, and
it's particularly egregious for Subversion svn+ssh users.)

Every time I audit for passphrase free keys, I tend to catch at least
20% of the private keys being used without passphrase, even in NFS
based environments. It's an ongoing problem. Even among those that are
protected, far too many have the same password as the login password,
which is often accessible by other means. (I just went through that
problem with someone storing their username and password in autofs
mounting tables for CIFS.)

> Moreover, I find strange that nobody ever complained that openssh client
> leaks the whole list of your available public keys to every server you
> try to connect to, even if you don't complete authentication.

Does it? I thought it went down the list one at a time, hadn't looked
at that chunk of the code in..... well, it's been a long time.

Potential confusion about which key to use is why I like to use the
'Host" option in $HOME/.ssh/config. It lets me select a login key
versus a Subversion svn+ssh access key, for example, for specific
servers.

From aris at 0xbadc0de.be  Tue Jan 24 00:40:00 2012
From: aris at 0xbadc0de.be (Aris Adamantiadis)
Date: Mon, 23 Jan 2012 14:40:00 +0100
Subject: Regarding Pubkey Enumeration
In-Reply-To: <CAOCN9rzh89YQwU6oXV+EZRLZTJfpiWGVi4n7KAKgyfktzWmwuw@mail.gmail.com>
References: <CAEW7ACnWhVJeVNLgeTHT=b=+HFmEG6EdsUt=EMzaMDdT1e9DTw@mail.gmail.com>
 <alpine.BSO.2.00.1201210824500.17846@natsu.mindrot.org>
 <BEBD54FA-FE1B-474B-91CC-633EF8899446@doxpara.com>
 <alpine.BSO.2.00.1201210842420.17846@natsu.mindrot.org>
 <EF7D0FA6-A773-4D44-B842-D486DB9282F4@doxpara.com>
 <alpine.BSO.2.00.1201210853080.17846@natsu.mindrot.org>
 <4F1A0332.5030804@gmail.com> <4F1D5378.3060502@0xbadc0de.be>
 <CAOCN9rzh89YQwU6oXV+EZRLZTJfpiWGVi4n7KAKgyfktzWmwuw@mail.gmail.com>
Message-ID: <4F1D6330.3040608@0xbadc0de.be>

Le 23/01/12 14:33, Nico Kadel-Garcia a ?crit :
> Hardly. Logs that are sophisticated enough, and go back far enough, to
> pin SSH traffic to a particular external host from a particular
> identifiable client are awkward to maintain. They're also unreliable
> in a DHCP based network setup, since especially for laptops that go
> home, the IP addresses are likely to change from day to day for
> employee machines and would have to be cross-correlated with the DHCP
> logs.
Ok, this may be hard.
> 
>> When you're in a pentest environment, and all you have is a public key,
>> a user name and an IP address + a hint that the three match together,
>> you're not *that* much advanced. Passwords can be bruteforced, not
>> private keys.
> 
> Many private keys are poorly passphrase protected. Since the default
> behavior of ssh-keygen allows passphrase free keys, there are one
> *hell* of a lot of people who don't bother and make the common
> assumption "if someone has access to my network, I have much bigger
> problems" and refuse to provide any passphrase protection. (I've been
> encountering that problem since the original ssh-1 was published, and
> it's particularly egregious for Subversion svn+ssh users.)
I think if you're in a situation where you're able to retrieve public
key + private key (encrypted or not), you do not need any hint from the
server anymore.
> 
> Every time I audit for passphrase free keys, I tend to catch at least
> 20% of the private keys being used without passphrase, even in NFS
> based environments. It's an ongoing problem. Even among those that are
> protected, far too many have the same password as the login password,
> which is often accessible by other means. (I just went through that
> problem with someone storing their username and password in autofs
> mounting tables for CIFS.)
Yep. But this implies that you have access to the encrypted private key,
so we're outside of the hypothesis "what you can do when you only have
the public key".
> 
>> Moreover, I find strange that nobody ever complained that openssh client
>> leaks the whole list of your available public keys to every server you
>> try to connect to, even if you don't complete authentication.
> 
> Does it? I thought it went down the list one at a time, hadn't looked
> at that chunk of the code in..... well, it's been a long time.
Indeed. It tries a public key at a time, before getting thrown out from
the server (in the times of the debian PRNG debacle, this number was 3).
> 
> Potential confusion about which key to use is why I like to use the
> 'Host" option in $HOME/.ssh/config. It lets me select a login key
> versus a Subversion svn+ssh access key, for example, for specific
> servers.
This is the proper way of managing your keys.

Aris

From nkadel at gmail.com  Tue Jan 24 00:51:29 2012
From: nkadel at gmail.com (Nico Kadel-Garcia)
Date: Mon, 23 Jan 2012 08:51:29 -0500
Subject: Regarding Pubkey Enumeration
In-Reply-To: <4F1D6330.3040608@0xbadc0de.be>
References: <CAEW7ACnWhVJeVNLgeTHT=b=+HFmEG6EdsUt=EMzaMDdT1e9DTw@mail.gmail.com>
 <alpine.BSO.2.00.1201210824500.17846@natsu.mindrot.org>
 <BEBD54FA-FE1B-474B-91CC-633EF8899446@doxpara.com>
 <alpine.BSO.2.00.1201210842420.17846@natsu.mindrot.org>
 <EF7D0FA6-A773-4D44-B842-D486DB9282F4@doxpara.com>
 <alpine.BSO.2.00.1201210853080.17846@natsu.mindrot.org>
 <4F1A0332.5030804@gmail.com> <4F1D5378.3060502@0xbadc0de.be>
 <CAOCN9rzh89YQwU6oXV+EZRLZTJfpiWGVi4n7KAKgyfktzWmwuw@mail.gmail.com>
 <4F1D6330.3040608@0xbadc0de.be>
Message-ID: <CAOCN9rzXYCGe=F_K0G8WxTkk9RzioKV7NrsEN+xMM8Amn00oUQ@mail.gmail.com>

On Mon, Jan 23, 2012 at 8:40 AM, Aris Adamantiadis <aris at 0xbadc0de.be> wrote:
> Le 23/01/12 14:33, Nico Kadel-Garcia a ?crit :

>>> When you're in a pentest environment, and all you have is a public key,
>>> a user name and an IP address + a hint that the three match together,
>>> you're not *that* much advanced. Passwords can be bruteforced, not
>>> private keys.
>>
>> Many private keys are poorly passphrase protected. Since the default
>> behavior of ssh-keygen allows passphrase free keys, there are one
>> *hell* of a lot of people who don't bother and make the common
>> assumption "if someone has access to my network, I have much bigger
>> problems" and refuse to provide any passphrase protection. (I've been
>> encountering that problem since the original ssh-1 was published, and
>> it's particularly egregious for Subversion svn+ssh users.)

> I think if you're in a situation where you're able to retrieve public
> key + private key (encrypted or not), you do not need any hint from the
> server anymore.

Well, yes. I just wanted to encourage folks to be careful about the
idea that one is safe because "private keys cannot be bruteforced".
Robust OpenBSD and OpenSSH software security needs to be coupled with
good security practices for private key protection to be effective,
and it's startlingly rare.

>> Potential confusion about which key to use is why I like to use the
>> 'Host" option in $HOME/.ssh/config. It lets me select a login key
>> versus a Subversion svn+ssh access key, for example, for specific
>> servers.
>
> This is the proper way of managing your keys.

It's useful. It becomes awkward in a large, deployed environment where
the hostnames change frequently. It's why I really like GSSAPI for
genuine single-sign-on behavior, and can use Kerberos credentials
rather than SSH key management: And in an NFS home directory
environment, I can block the use of an authorized_keys file, too, and
insist on Kerberos that can be expired and more actively managed.

Kerberized key access would in fact eliminate this alleged
vulnerability to public key testing. Its availability in OpenSSH 5 is
a very real security improvement of that package, because the keys are
no longer under the management of a local user likely to mishandle
them, or which a snooping employer could test against.

From lists at spuddy.org  Tue Jan 24 02:46:55 2012
From: lists at spuddy.org (Stephen Harris)
Date: Mon, 23 Jan 2012 10:46:55 -0500
Subject: Patterns in HostName ?
Message-ID: <20120123154655.GA25272@mercury.spuddy.org>

I have a Unix host that's DHCPd, so resolv.conf is rewritten.  Because
of company policies, it's not allowed to change the client dhcp config
to override the search path.

I also need to login to a large number of machines in a specific
subdomain; eg in a lab environment.

Is it possible to do something like
  Host *.lab
    Hostname %h.sub.domain.example.com

so if I "ssh host1.lab" then it'll go to "host1.lab.sub.domain.example.com" ?

I could probably kludge it with proxycommand and "nc" but that really
feels nasty :-)

-- 

rgds
Stephen

From keisial at gmail.com  Tue Jan 24 04:00:43 2012
From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=)
Date: Mon, 23 Jan 2012 18:00:43 +0100
Subject: Patterns in HostName ?
In-Reply-To: <20120123154655.GA25272@mercury.spuddy.org>
References: <20120123154655.GA25272@mercury.spuddy.org>
Message-ID: <4F1D923B.8020500@gmail.com>

On 23/01/12 16:46, Stephen Harris wrote:
> I have a Unix host that's DHCPd, so resolv.conf is rewritten.  Because
> of company policies, it's not allowed to change the client dhcp config
> to override the search path.
>
> I also need to login to a large number of machines in a specific
> subdomain; eg in a lab environment.
>
> Is it possible to do something like
>    Host *.lab
>      Hostname %h.sub.domain.example.com
>
> so if I "ssh host1.lab" then it'll go to "host1.lab.sub.domain.example.com" ?
It should work fine


From lists at spuddy.org  Tue Jan 24 04:02:25 2012
From: lists at spuddy.org (Stephen Harris)
Date: Mon, 23 Jan 2012 12:02:25 -0500
Subject: Patterns in HostName ?
In-Reply-To: <4F1D923B.8020500@gmail.com>
References: <20120123154655.GA25272@mercury.spuddy.org>
 <4F1D923B.8020500@gmail.com>
Message-ID: <20120123170224.GB27279@mercury.spuddy.org>

On Mon, Jan 23, 2012 at 06:00:43PM +0100, ?ngel Gonz?lez wrote:
> On 23/01/12 16:46, Stephen Harris wrote:

> >Is it possible to do something like
> >   Host *.lab
> >     Hostname %h.sub.domain.example.com
> >
> >so if I "ssh host1.lab" then it'll go to 
> >"host1.lab.sub.domain.example.com" ?
> It should work fine

In what version of OpenSSH?
  % ssh a.lab
  ssh: %h.sub.domain.example.com: Name or service not known

-- 

rgds
Stephen

From nicholas.dokos at hp.com  Tue Jan 24 04:16:25 2012
From: nicholas.dokos at hp.com (Nick Dokos)
Date: Mon, 23 Jan 2012 12:16:25 -0500
Subject: Patterns in HostName ?
In-Reply-To: Message from Stephen Harris <lists@spuddy.org>
 of "Mon, 23 Jan 2012 12:02:25 EST." <20120123170224.GB27279@mercury.spuddy.org>
References: <20120123154655.GA25272@mercury.spuddy.org>
 <4F1D923B.8020500@gmail.com> <20120123170224.GB27279@mercury.spuddy.org>
Message-ID: <4072.1327338985@alphaville>

Stephen Harris <lists at spuddy.org> wrote:

> On Mon, Jan 23, 2012 at 06:00:43PM +0100, ?ngel Gonz?lez wrote:
> > On 23/01/12 16:46, Stephen Harris wrote:
> 
> > >Is it possible to do something like
> > >   Host *.lab
> > >     Hostname %h.sub.domain.example.com
> > >
> > >so if I "ssh host1.lab" then it'll go to 
> > >"host1.lab.sub.domain.example.com" ?
> > It should work fine
> 
> In what version of OpenSSH?
>   % ssh a.lab
>   ssh: %h.sub.domain.example.com: Name or service not known
> 

Works for me in

OpenSSH_5.8p1 Debian-1ubuntu3, OpenSSL 0.9.8o 01 Jun 2010

Maybe trying 'ssh -v a.lab' will give you a hint of where it's going wrong?

Nick


From lists at spuddy.org  Tue Jan 24 04:45:13 2012
From: lists at spuddy.org (Stephen Harris)
Date: Mon, 23 Jan 2012 12:45:13 -0500
Subject: Patterns in HostName ?
In-Reply-To: <4072.1327338985@alphaville>
References: <20120123154655.GA25272@mercury.spuddy.org>
 <4F1D923B.8020500@gmail.com> <20120123170224.GB27279@mercury.spuddy.org>
 <4072.1327338985@alphaville>
Message-ID: <20120123174513.GA28921@mercury.spuddy.org>

On Mon, Jan 23, 2012 at 12:16:25PM -0500, Nick Dokos wrote:
> Stephen Harris <lists at spuddy.org> wrote:

> > In what version of OpenSSH?
> >   % ssh a.lab
> >   ssh: %h.sub.domain.example.com: Name or service not known
> > 
> 
> Works for me in
> 
> OpenSSH_5.8p1 Debian-1ubuntu3, OpenSSL 0.9.8o 01 Jun 2010

OK, looks like it was a 5.6 enhancement:
  http://www.openssh.org/txt/release-5.6

 * Expand %h to the hostname in ssh_config Hostname options.

Thanks
-- 

rgds
Stephen

From leo.liou at centrify.com  Wed Jan 25 07:22:47 2012
From: leo.liou at centrify.com (Leo Liou)
Date: Tue, 24 Jan 2012 12:22:47 -0800
Subject: Solaris BSM audit support
Message-ID: <9C50C7EBEE767343AB45090430D1E3A101029EABEB38@exch-07.centrify.com>

Does anyone know if openssh has removed the experimental designation for  BSM audit support for Solaris systems?
If so, which release, please.
Thanks.

From jmitchell at ll.mit.edu  Thu Jan 26 04:26:34 2012
From: jmitchell at ll.mit.edu (Jeff Mitchell)
Date: Wed, 25 Jan 2012 12:26:34 -0500
Subject: Server/Client Alive mechanism issues
Message-ID: <4F203B4A.6050305@ll.mit.edu>

Hello,

I have a bandwidth-constrained connection that I'd like to run rsync
over through an SSH tunnel. I also want to detect any network drops
pretty rapidly.

On the servers I'm setting (via sshd_config):

ClientAliveCountMax 5
ClientAliveInterval 1
TCPKeepAlive no

and on the clients I'm setting (via ssh_config):

ServerAliveCountMax 5
ServerAliveInterval 1
TCPKeepAlive no

After about 5 seconds, the connection is being dropped, but during that
time the rsync is successfully transferring data near the full bandwidth
of the connection.

My understanding is that since the alive mechanism is running inside the
encrypted connection, OpenSSH would be able to (and would) prioritize
the alive packets over other data. So if any data is able to get through
(and it does) the alive packets should be able to as well. But this
doesn't seem to be the case.

Is my understanding of how this is supposed to work wrong? If not, could
I have a misconfiguration somewhere, or is it possible that this is some
old bug?  (This is OpenSSH_5.5p1 with OpenSSL 1.0.0a.)

Thanks,
Jeff

From gert at greenie.muc.de  Thu Jan 26 09:06:57 2012
From: gert at greenie.muc.de (Gert Doering)
Date: Wed, 25 Jan 2012 23:06:57 +0100
Subject: Server/Client Alive mechanism issues
In-Reply-To: <4F203B4A.6050305@ll.mit.edu>
References: <4F203B4A.6050305@ll.mit.edu>
Message-ID: <20120125220657.GD5060@greenie.muc.de>

Hi,

On Wed, Jan 25, 2012 at 12:26:34PM -0500, Jeff Mitchell wrote:
> My understanding is that since the alive mechanism is running inside the
> encrypted connection, OpenSSH would be able to (and would) prioritize
> the alive packets over other data. So if any data is able to get through
> (and it does) the alive packets should be able to as well. But this
> doesn't seem to be the case.

For that, OpenSSH would need to know that there is congestion, and 
throttle it's send rate to avoid buffers building up *elsewhere*.

If there is 10 seconds worth of data in your DSL router, there is nothing
OpenSSH can do to achieve a round-trip time of 1s for it's keepalives.

gert
-- 
USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             gert at greenie.muc.de
fax: +49-89-35655025                        gert at net.informatik.tu-muenchen.de

From jmitchell at ll.mit.edu  Thu Jan 26 09:49:05 2012
From: jmitchell at ll.mit.edu (Jeff Mitchell)
Date: Wed, 25 Jan 2012 17:49:05 -0500
Subject: Server/Client Alive mechanism issues
In-Reply-To: <20120125220657.GD5060@greenie.muc.de>
References: <4F203B4A.6050305@ll.mit.edu>
 <20120125220657.GD5060@greenie.muc.de>
Message-ID: <4F2086E1.6030708@ll.mit.edu>

On 01/25/2012 05:06 PM, Gert Doering wrote:
> Hi,
> 
> On Wed, Jan 25, 2012 at 12:26:34PM -0500, Jeff Mitchell wrote:
>> My understanding is that since the alive mechanism is running inside the
>> encrypted connection, OpenSSH would be able to (and would) prioritize
>> the alive packets over other data. So if any data is able to get through
>> (and it does) the alive packets should be able to as well. But this
>> doesn't seem to be the case.
> 
> For that, OpenSSH would need to know that there is congestion, and 
> throttle it's send rate to avoid buffers building up *elsewhere*.

It isn't really the buffers elsewhere that are the problem...I don't
really care if those buffers build up, but I *do* care if OpenSSH
terminates the connection so they can never drain.

I guess I figured that OpenSSH would already have some insight into the
state of its connection (or be performing something like
double-buffering) simply for its own performance optimization, and thus
would have an idea as to whether its channel was saturated, at which
point it could ensure to carve out some space for its own purposes.

--Jeff

From keisial at gmail.com  Thu Jan 26 10:49:34 2012
From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=)
Date: Thu, 26 Jan 2012 00:49:34 +0100
Subject: Server/Client Alive mechanism issues
In-Reply-To: <20120125220657.GD5060@greenie.muc.de>
References: <4F203B4A.6050305@ll.mit.edu>
 <20120125220657.GD5060@greenie.muc.de>
Message-ID: <4F20950E.2070903@gmail.com>

On 25/01/12 23:06, Gert Doering wrote:
> Hi,
>
> On Wed, Jan 25, 2012 at 12:26:34PM -0500, Jeff Mitchell wrote:
>> My understanding is that since the alive mechanism is running inside the
>> encrypted connection, OpenSSH would be able to (and would) prioritize
>> the alive packets over other data. So if any data is able to get through
>> (and it does) the alive packets should be able to as well. But this
>> doesn't seem to be the case.
> For that, OpenSSH would need to know that there is congestion, and
> throttle it's send rate to avoid buffers building up *elsewhere*.
>
> If there is 10 seconds worth of data in your DSL router, there is nothing
> OpenSSH can do to achieve a round-trip time of 1s for it's keepalives.
>
> gert
Note that if you know the real bandwidth, you could use the --bwlimit 
parameter
of rsync a little below that to not saturate it.



From jmitchell at ll.mit.edu  Thu Jan 26 11:14:13 2012
From: jmitchell at ll.mit.edu (Jeff Mitchell)
Date: Wed, 25 Jan 2012 19:14:13 -0500
Subject: Server/Client Alive mechanism issues
In-Reply-To: <4F20950E.2070903@gmail.com>
References: <4F203B4A.6050305@ll.mit.edu>
 <20120125220657.GD5060@greenie.muc.de> <4F20950E.2070903@gmail.com>
Message-ID: <4F209AD5.5060509@ll.mit.edu>

On 01/25/2012 06:49 PM, ?ngel Gonz?lez wrote:
> On 25/01/12 23:06, Gert Doering wrote:
>> Hi,
>>
>> On Wed, Jan 25, 2012 at 12:26:34PM -0500, Jeff Mitchell wrote:
>>> My understanding is that since the alive mechanism is running inside the
>>> encrypted connection, OpenSSH would be able to (and would) prioritize
>>> the alive packets over other data. So if any data is able to get through
>>> (and it does) the alive packets should be able to as well. But this
>>> doesn't seem to be the case.
>> For that, OpenSSH would need to know that there is congestion, and
>> throttle it's send rate to avoid buffers building up *elsewhere*.
>>
>> If there is 10 seconds worth of data in your DSL router, there is nothing
>> OpenSSH can do to achieve a round-trip time of 1s for it's keepalives.
>>
>> gert
> Note that if you know the real bandwidth, you could use the --bwlimit 
> parameter
> of rsync a little below that to not saturate it.

Good catch...I'll have to see if I can make the tool running rsync
accept custom parameters.

Thanks!
--Jeff


From imorgan at nas.nasa.gov  Thu Jan 26 11:34:45 2012
From: imorgan at nas.nasa.gov (Iain Morgan)
Date: Wed, 25 Jan 2012 16:34:45 -0800
Subject: Server/Client Alive mechanism issues
In-Reply-To: <4F2086E1.6030708@ll.mit.edu>
References: <4F203B4A.6050305@ll.mit.edu>
 <20120125220657.GD5060@greenie.muc.de>
 <4F2086E1.6030708@ll.mit.edu>
Message-ID: <20120126003445.GA4834@linux124.nas.nasa.gov>

On Wed, Jan 25, 2012 at 16:49:05 -0600, Jeff Mitchell wrote:
> On 01/25/2012 05:06 PM, Gert Doering wrote:
> > Hi,
> > 
> > On Wed, Jan 25, 2012 at 12:26:34PM -0500, Jeff Mitchell wrote:
> >> My understanding is that since the alive mechanism is running inside the
> >> encrypted connection, OpenSSH would be able to (and would) prioritize
> >> the alive packets over other data. So if any data is able to get through
> >> (and it does) the alive packets should be able to as well. But this
> >> doesn't seem to be the case.
> > 
> > For that, OpenSSH would need to know that there is congestion, and 
> > throttle it's send rate to avoid buffers building up *elsewhere*.
> 
> It isn't really the buffers elsewhere that are the problem...I don't
> really care if those buffers build up, but I *do* care if OpenSSH
> terminates the connection so they can never drain.
> 
> I guess I figured that OpenSSH would already have some insight into the
> state of its connection (or be performing something like
> double-buffering) simply for its own performance optimization, and thus
> would have an idea as to whether its channel was saturated, at which
> point it could ensure to carve out some space for its own purposes.
> 

What happens if you increase the interval somewhat, say 10 seconds?
-- 
Iain Morgan

From loganaden at gmail.com  Fri Jan 27 00:29:35 2012
From: loganaden at gmail.com (Loganaden Velvindron)
Date: Thu, 26 Jan 2012 17:29:35 +0400
Subject: PermitOpen None diff
Message-ID: <CAOp4FwSpnq0v_q6VzacSOmk3ZFJSLwSVP=yHzOk6pD5ZjM_UrA@mail.gmail.com>

Hi,

I was wondering if this diff would make it into the next release:
https://bugzilla.mindrot.org/show_bug.cgi?id=1949

Thanks,
//Logan
C-x-C-c

-- 
Brightest day,
Blackest night,
No bug shall escape my sight,
And those who worship evil's mind,
be wary of my powers,
puffy lantern's light !

From jmitchell at ll.mit.edu  Fri Jan 27 04:20:50 2012
From: jmitchell at ll.mit.edu (Jeff Mitchell)
Date: Thu, 26 Jan 2012 12:20:50 -0500
Subject: Server/Client Alive mechanism issues
In-Reply-To: <20120126003445.GA4834@linux124.nas.nasa.gov>
References: <4F203B4A.6050305@ll.mit.edu>
 <20120125220657.GD5060@greenie.muc.de> <4F2086E1.6030708@ll.mit.edu>
 <20120126003445.GA4834@linux124.nas.nasa.gov>
Message-ID: <4F218B72.8050302@ll.mit.edu>

On 01/25/2012 07:34 PM, Iain Morgan wrote:
>> I guess I figured that OpenSSH would already have some insight into the
>> state of its connection (or be performing something like
>> double-buffering) simply for its own performance optimization, and thus
>> would have an idea as to whether its channel was saturated, at which
>> point it could ensure to carve out some space for its own purposes.
>>
> 
> What happens if you increase the interval somewhat, say 10 seconds?

Essentially, from our testing, if the interval*maxcount > amount of time
we're shoving data through the pipe, we are fine, otherwise we get
disconnected.

It's what you would expect if the keepalives are in contention with the
data...that's just not what I expected would be the case  :-)

Thanks,
Jeff

From zevweiss at gmail.com  Sat Jan 28 20:25:57 2012
From: zevweiss at gmail.com (Zev Weiss)
Date: Sat, 28 Jan 2012 03:25:57 -0600
Subject: PATCH: Support for encrypted host keys
Message-ID: <30D9F5B0-59F6-420E-AC97-FF6FD09C0339@gmail.com>

Hello all,

I recently found myself wanting to run sshd with passphrase-protected host keys rather than the usual unencrypted format, and was somewhat surprised to discover that sshd did not support this.  I'm not sure if there's any particular reason for that, but I've developed the below patch (relative to current CVS at time of writing) that implements this.  It prompts for the passphrase when the daemon is started, similarly to Apache's behavior with encrypted SSL certificates.

My initial implementation instead operated by passing the passphrase along to the rexec child, but I decided I thought it was slightly nicer to decrypt the key once and pass it along rather than redoing it every time.  I can send the previous version if that would be preferred though -- this key-passing version does have some resulting ugliness in its handling of options.num_host_key_files, as described in a comment in the patch.


Thanks,
Zev Weiss
--

 Makefile.in |    2 +-
 buffer.h    |    5 ++
 bufkey.c    |  132 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
 sshd.c      |  141 ++++++++++++++++++++++++++++++++++++++++++++++++-----------
 4 files changed, 253 insertions(+), 27 deletions(-)

diff --git a/Makefile.in b/Makefile.in
index 3be3aa6..3b47d18 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -61,7 +61,7 @@ MANFMT=@MANFMT@
 
 TARGETS=ssh$(EXEEXT) sshd$(EXEEXT) ssh-add$(EXEEXT) ssh-keygen$(EXEEXT) ssh-keyscan${EXEEXT} ssh-keysign${EXEEXT} ssh-pkcs11-helper$(EXEEXT) ssh-agent$(EXEEXT) scp$(EXEEXT) sftp-server$(EXEEXT) sftp$(EXEEXT)
 
-LIBSSH_OBJS=acss.o authfd.o authfile.o bufaux.o bufbn.o buffer.o \
+LIBSSH_OBJS=acss.o authfd.o authfile.o bufaux.o bufbn.o bufkey.o buffer.o \
 	canohost.o channels.o cipher.o cipher-acss.o cipher-aes.o \
 	cipher-bf1.o cipher-ctr.o cipher-3des1.o cleanup.o \
 	compat.o compress.o crc32.o deattack.o fatal.o hostfile.o \
diff --git a/buffer.h b/buffer.h
index e2a9dd1..a0c62c1 100644
--- a/buffer.h
+++ b/buffer.h
@@ -86,6 +86,11 @@ char	*buffer_get_cstring_ret(Buffer *, u_int *);
 void	*buffer_get_string_ptr_ret(Buffer *, u_int *);
 int	buffer_get_char_ret(char *, Buffer *);
 
+#include "key.h"
+
+void	buffer_put_key(Buffer *buffer, const Key *key);
+Key	*buffer_get_key(Buffer *buffer);
+
 #ifdef OPENSSL_HAS_ECC
 #include <openssl/ec.h>
 
diff --git a/bufkey.c b/bufkey.c
new file mode 100644
index 0000000..85a0c35
--- /dev/null
+++ b/bufkey.c
@@ -0,0 +1,132 @@
+/*
+ * Author: Zev Weiss <zevweiss at gmail.com>
+ *
+ * Functions for storing and retrieving Key structs into/from Buffers.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *    notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *    notice, this list of conditions and the following disclaimer in the
+ *    documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
+ * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
+ * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
+ * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
+ * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
+ * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+
+#include "includes.h"
+
+#include <sys/types.h>
+
+#include <openssl/bn.h>
+
+#include "xmalloc.h"
+#include "buffer.h"
+#include "log.h"
+#include "key.h"
+#include "rsa.h"
+
+static void
+buffer_put_key_rsa(Buffer *buffer, const RSA *key)
+{
+	buffer_put_bignum(buffer, key->e);
+	buffer_put_bignum(buffer, key->n);
+	buffer_put_bignum(buffer, key->d);
+	buffer_put_bignum(buffer, key->iqmp);
+	buffer_put_bignum(buffer, key->p);
+	buffer_put_bignum(buffer, key->q);
+}
+
+static void
+buffer_get_key_rsa(Buffer *buffer, RSA *key)
+{
+	buffer_get_bignum(buffer, key->e);
+	buffer_get_bignum(buffer, key->n);
+	buffer_get_bignum(buffer, key->d);
+	buffer_get_bignum(buffer, key->iqmp);
+	buffer_get_bignum(buffer, key->p);
+	buffer_get_bignum(buffer, key->q);
+	rsa_generate_additional_parameters(key);
+}
+
+static void
+buffer_put_key_dsa(Buffer *buffer, const DSA *key)
+{
+	buffer_put_bignum(buffer, key->p);
+	buffer_put_bignum(buffer, key->q);
+	buffer_put_bignum(buffer, key->g);
+	buffer_put_bignum(buffer, key->pub_key);
+	buffer_put_bignum(buffer, key->priv_key);
+}
+
+static void
+buffer_get_key_dsa(Buffer *buffer, DSA *key)
+{
+	buffer_get_bignum(buffer, key->p);
+	buffer_get_bignum(buffer, key->q);
+	buffer_get_bignum(buffer, key->g);
+	buffer_get_bignum(buffer, key->pub_key);
+	buffer_get_bignum(buffer, key->priv_key);
+}
+
+void
+buffer_put_key(Buffer *buffer, const Key *key)
+{
+	if (key->cert != NULL || key->ecdsa != NULL || key->ecdsa_nid != -1)
+		fatal("%s: unsupported key feature", __func__);
+
+	buffer_put_int(buffer, key->type);
+	buffer_put_int(buffer, key->flags);
+
+	switch (key->type) {
+	case KEY_RSA1:
+	case KEY_RSA:
+		buffer_put_key_rsa(buffer, key->rsa);
+		break;
+	case KEY_DSA:
+		buffer_put_key_dsa(buffer, key->dsa);
+		break;
+	default:
+		fatal("%s: unsupported key type (%s)", __func__,
+		    key_type(key));
+	}
+}
+
+Key *
+buffer_get_key(Buffer *buffer)
+{
+	Key *key;
+	int type, flags;
+
+	type = buffer_get_int(buffer);
+	flags = buffer_get_int(buffer);
+
+	key = key_new_private(type);
+	key->flags = flags;
+
+	switch (type) {
+	case KEY_RSA1:
+	case KEY_RSA:
+		buffer_get_key_rsa(buffer, key->rsa);
+		break;
+	case KEY_DSA:
+		buffer_get_key_dsa(buffer, key->dsa);
+		break;
+	default:
+		fatal("%s: unsupported key type (%s)", __func__,
+		    key_type(key));
+	}
+
+	return key;
+}
diff --git a/sshd.c b/sshd.c
index c8d71f8..f458860 100644
--- a/sshd.c
+++ b/sshd.c
@@ -175,6 +175,7 @@ int rexeced_flag = 0;
 int rexec_flag = 1;
 int rexec_argc = 0;
 char **rexec_argv;
+int num_rexec_recvd_host_keys = 0;
 
 /*
  * The sockets that the server is listening; this is used in the SIGHUP
@@ -898,6 +899,7 @@ usage(void)
 static void
 send_rexec_state(int fd, Buffer *conf)
 {
+	int i, num_host_keys;
 	Buffer m;
 
 	debug3("%s: entering fd = %d config len %d", __func__, fd,
@@ -914,6 +916,8 @@ send_rexec_state(int fd, Buffer *conf)
 	 *	bignum	p			"
 	 *	bignum	q			"
 	 *	string rngseed		(only if OpenSSL is not self-seeded)
+	 *      u_int	num_host_keys
+	 *	Key	host_keys	num_host_keys times
 	 */
 	buffer_init(&m);
 	buffer_put_cstring(&m, buffer_ptr(conf));
@@ -934,6 +938,18 @@ send_rexec_state(int fd, Buffer *conf)
 	rexec_send_rng_seed(&m);
 #endif
 
+	num_host_keys = 0;
+	for (i = 0; i < options.num_host_key_files; i++) {
+		if (sensitive_data.host_keys[i] != NULL)
+			++num_host_keys;
+	}
+
+	buffer_put_int(&m, num_host_keys);
+	for (i = 0; i < options.num_host_key_files; i++) {
+		if (sensitive_data.host_keys[i] != NULL)
+			buffer_put_key(&m, sensitive_data.host_keys[i]);
+	}
+
 	if (ssh_msg_send(fd, 0, &m) == -1)
 		fatal("%s: ssh_msg_send failed", __func__);
 
@@ -946,8 +962,10 @@ static void
 recv_rexec_state(int fd, Buffer *conf)
 {
 	Buffer m;
+	Key *hk;
 	char *cp;
 	u_int len;
+	int i, num_host_keys;
 
 	debug3("%s: entering fd = %d", __func__, fd);
 
@@ -981,6 +999,30 @@ recv_rexec_state(int fd, Buffer *conf)
 	rexec_recv_rng_seed(&m);
 #endif
 
+	num_host_keys = buffer_get_int(&m);
+	debug("%s: receiving %d host keys", __func__, num_host_keys);
+	sensitive_data.host_keys = xcalloc(num_host_keys, sizeof(Key *));
+
+	num_rexec_recvd_host_keys = num_host_keys;
+
+	for (i = 0; i < num_host_keys; i++) {
+		hk = buffer_get_key(&m);
+		debug("%s: received %s host key", __func__, key_type(hk));
+		sensitive_data.host_keys[i] = hk;
+		switch (hk->type) {
+		case KEY_RSA1:
+			sensitive_data.ssh1_host_key = hk;
+			sensitive_data.have_ssh1_key = 1;
+			break;
+		case KEY_RSA:
+		case KEY_DSA:
+			sensitive_data.have_ssh2_key = 1;
+			break;
+		default:
+			fatal("%s: unsupported host key type", __func__);
+		}
+	}
+
 	buffer_free(&m);
 
 	debug3("%s: done", __func__);
@@ -1308,6 +1350,41 @@ server_accept_loop(int *sock_in, int *sock_out, int *newsock, int *config_s)
 	}
 }
 
+static Key *
+sshd_key_load_private(const char *filename)
+{
+	Key *key;
+	char prompt[300], *passphrase = "";
+	int quit, i;
+
+	key = key_load_private(filename, passphrase, NULL);
+
+	if (key == NULL) {
+		snprintf(prompt, sizeof prompt,
+		    "Enter passphrase for key '%.100s': ", filename);
+		/* options.number_of_password_prompts doesn't exist in sshd */
+		for (i = 0; i < 3; i++) {
+			passphrase = read_passphrase(prompt, 0);
+			if (strcmp(passphrase, "") != 0) {
+				key = key_load_private(filename, passphrase,
+				    NULL);
+				quit = 0;
+			} else {
+				debug2("no passphrase given, try next key");
+				quit = 1;
+			}
+			if (key != NULL || quit) {
+				memset(passphrase, 0, strlen(passphrase));
+				xfree(passphrase);
+				break;
+			}
+			memset(passphrase, 0, strlen(passphrase));
+			xfree(passphrase);
+			debug2("bad passphrase given, try again...");
+		}
+	}
+	return key;
+}
 
 /*
  * Main program for the daemon.
@@ -1550,6 +1627,15 @@ main(int ac, char **av)
 	parse_server_config(&options, rexeced_flag ? "rexec" : config_file_name,
 	    &cfg, NULL, NULL, NULL);
 
+	/*
+	 * parse_server_config() changes options.num_host_key_files,
+	 * but we need to change it back to what we received via
+	 * recv_rexec_state to accurately reflect the number of keys
+	 * in sensitive_data.host_keys.  This is a bit ugly.
+	 */
+	if (rexeced_flag)
+		options.num_host_key_files = num_rexec_recvd_host_keys;
+
 	seed_rng();
 
 	/* Fill in default values for those options not explicitly set. */
@@ -1583,35 +1669,38 @@ main(int ac, char **av)
 	}
 	endpwent();
 
-	/* load private host keys */
-	sensitive_data.host_keys = xcalloc(options.num_host_key_files,
-	    sizeof(Key *));
-	for (i = 0; i < options.num_host_key_files; i++)
-		sensitive_data.host_keys[i] = NULL;
-
-	for (i = 0; i < options.num_host_key_files; i++) {
-		key = key_load_private(options.host_key_files[i], "", NULL);
-		sensitive_data.host_keys[i] = key;
-		if (key == NULL) {
-			error("Could not load host key: %s",
-			    options.host_key_files[i]);
+	if (!rexeced_flag) {
+		/* load private host keys */
+		sensitive_data.host_keys = xcalloc(options.num_host_key_files,
+		    sizeof(Key *));
+		for (i = 0; i < options.num_host_key_files; i++)
 			sensitive_data.host_keys[i] = NULL;
-			continue;
-		}
-		switch (key->type) {
-		case KEY_RSA1:
-			sensitive_data.ssh1_host_key = key;
-			sensitive_data.have_ssh1_key = 1;
-			break;
-		case KEY_RSA:
-		case KEY_DSA:
-		case KEY_ECDSA:
-			sensitive_data.have_ssh2_key = 1;
-			break;
+
+		for (i = 0; i < options.num_host_key_files; i++) {
+			key = sshd_key_load_private(options.host_key_files[i]);
+			sensitive_data.host_keys[i] = key;
+			if (key == NULL) {
+				error("Could not load host key: %s",
+				    options.host_key_files[i]);
+				sensitive_data.host_keys[i] = NULL;
+				continue;
+			}
+			switch (key->type) {
+			case KEY_RSA1:
+				sensitive_data.ssh1_host_key = key;
+				sensitive_data.have_ssh1_key = 1;
+				break;
+			case KEY_RSA:
+			case KEY_DSA:
+			case KEY_ECDSA:
+				sensitive_data.have_ssh2_key = 1;
+				break;
+			}
+			debug("private host key: #%d type %d %s", i, key->type,
+			    key_type(key));
 		}
-		debug("private host key: #%d type %d %s", i, key->type,
-		    key_type(key));
 	}
+
 	if ((options.protocol & SSH_PROTO_1) && !sensitive_data.have_ssh1_key) {
 		logit("Disabling protocol version 1. Could not load host key");
 		options.protocol &= ~SSH_PROTO_1;


From zevweiss at gmail.com  Sat Jan 28 20:30:34 2012
From: zevweiss at gmail.com (Zev Weiss)
Date: Sat, 28 Jan 2012 03:30:34 -0600
Subject: PATCH: Fix memory leak in sshd
Message-ID: <650C8332-58DF-443B-A8B6-E2BB9626D97F@gmail.com>

Hello,

The below patch fixes a memory leak I noticed in monitor_read_load() when the child's log pipe is closed.

Thanks,
Zev Weiss
--

diff --git a/monitor.c b/monitor.c
index a166fed..6464eec 100644
--- a/monitor.c
+++ b/monitor.c
@@ -510,6 +510,7 @@ monitor_read_log(struct monitor *pmonitor)
 			debug("%s: child log fd closed", __func__);
 			close(pmonitor->m_log_recvfd);
 			pmonitor->m_log_recvfd = -1;
+			buffer_free(&logmsg);
 			return -1;
 		}
 		fatal("%s: log fd read: %s", __func__, strerror(errno));



From mfriedl at gmail.com  Tue Jan 31 23:16:52 2012
From: mfriedl at gmail.com (Markus Friedl)
Date: Tue, 31 Jan 2012 13:16:52 +0100
Subject: PATCH: Fix memory leak in sshd
In-Reply-To: <650C8332-58DF-443B-A8B6-E2BB9626D97F@gmail.com>
References: <650C8332-58DF-443B-A8B6-E2BB9626D97F@gmail.com>
Message-ID: <CACANGek6-v8cwZzRD8qRKOs87C94HhrJTm+i16qX0arXBtMCDw@mail.gmail.com>

thanks for the report. Damien fixed that bug some weeks ago.

-m



On Sat, Jan 28, 2012 at 10:30 AM, Zev Weiss <zevweiss at gmail.com> wrote:
> Hello,
>
> The below patch fixes a memory leak I noticed in monitor_read_load() when the child's log pipe is closed.
>
> Thanks,
> Zev Weiss
> --
>
> diff --git a/monitor.c b/monitor.c
> index a166fed..6464eec 100644
> --- a/monitor.c
> +++ b/monitor.c
> @@ -510,6 +510,7 @@ monitor_read_log(struct monitor *pmonitor)
> ? ? ? ? ? ? ? ? ? ? ? ?debug("%s: child log fd closed", __func__);
> ? ? ? ? ? ? ? ? ? ? ? ?close(pmonitor->m_log_recvfd);
> ? ? ? ? ? ? ? ? ? ? ? ?pmonitor->m_log_recvfd = -1;
> + ? ? ? ? ? ? ? ? ? ? ? buffer_free(&logmsg);
> ? ? ? ? ? ? ? ? ? ? ? ?return -1;
> ? ? ? ? ? ? ? ?}
> ? ? ? ? ? ? ? ?fatal("%s: log fd read: %s", __func__, strerror(errno));
>
>
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev